Details about the middleware in the Python Django framework

This article mainly introduces the middleware in the Python Django framework, including the installation of the middleware. For more information, see What is middleware?

Let's start with a simple example.

High-traffic websites usually need to deploy Django after the server load balancer proxy. This method brings some complexity. One is that the remote IP address (request. META ["REMOTE_IP"]) in each request points to the server load balancer proxy, rather than the actual IP address that initiates the request. The server load balancer proxy can solve this problem by setting the actual IP address of the request in the special X-Forwarded-.

Therefore, a small middleware is required to ensure that the site running after the proxy can also get the correct IP address in request. META ["REMOTE_ADDR:

class SetRemoteAddrFromForwardedFor(object):  def process_request(self, request):    try:      real_ip = request.META['HTTP_X_FORWARDED_FOR']    except KeyError:      pass    else:      # HTTP_X_FORWARDED_FOR can be a comma-separated list of IPs.      # Take just the first one.      real_ip = real_ip.split(",")[0]      request.META['REMOTE_ADDR'] = real_ip

(Note: Although the HTTP header is called X-Forwarded-For , Django makes it available as request.META['HTTP_X_FORWARDED_FOR'] . With the exception of content-length and content-type , any HTTP headers in the request are converted to request.META keys by converting all characters to uppercase, replacing any hyphens with underscores and adding an HTTP_ prefix to the name.)

Once the middleware is installed (see the next section), The X-Forwarded-For value in each request is automatically inserted into request. META ['remote _ ADDR. In this way, the Django application does not need to worry about whether it is behind the server load balancer proxy; simply reads the request. META ['remote _ ADDR '] works normally if a proxy exists.

In fact, for this very common scenario, Django has built this middleware. It is located in django. middleware. http. The next section will show more details about this middleware.
Install middleware

To enable a middleware, you only need to add it to the MIDDLEWARE_CLASSES tuples of the configuration module. In MIDDLEWARE_CLASSES, the middleware component is represented by a string: the complete Python path pointing to the middleware class name. For example, the default MIDDLEWARE_CLASSES created by the django-admin.py startproject is as follows:

MIDDLEWARE_CLASSES = (  'django.middleware.common.CommonMiddleware',  'django.contrib.sessions.middleware.SessionMiddleware',  'django.contrib.auth.middleware.AuthenticationMiddleware',)

The installation of the Django project does not require any middleware. if you want to, MIDDLEWARE_CLASSES can be empty.

The order in which middleware appears is very important. In the request and view processing stages, Django applies middleware according to the order in which MIDDLEWARE_CLASSES appear, while in the response and exception processing stages, Django calls them in reverse order. That is to say, Django regards MIDDLEWARE_CLASSES as the sequential packaging sub-of the outer layer of the view function: in the request stage, it passes from top to bottom, while in the response, it returns.