1. __init__(self)
In a middleware class, the __init__() method is used to perform system-wide initialization settings.
For performance reasons, each enabled middleware is initialized only once per server process. That is, __init__() is called only when the server process starts, and is not executed while handling an individual request.
For a middleware, the usual reason to define an __init__() method is to check whether it is needed at all. If __init__() raises the exception django.core.exceptions.MiddlewareNotUsed, Django will remove that middleware from the middleware stack. You can use this mechanism to check whether the software the middleware depends on is present, whether the service is running in debug mode, and any other environmental factor.
When you define an __init__() method in middleware, you should not define any parameters beyond the standard self parameter.
Execution order:
process_request2.process_view3.process_template_response4.process_response5.process_exception
2. process_request
It (process_request) returns either None or an HttpResponse object. If it returns None, Django will continue processing this request and run the other request middleware. Then it runs the view middleware, and then the view function. Once Django returns an HttpResponse object, it will no longer run the other (request, view, exception) middleware, nor the corresponding view function. It will call the response middleware, and then return the result.
3. process_view
Django calls process_view before calling the view function.
request is an HttpRequest object, view_func is a function object rather than the string matching the function name. view_args and view_kwargs are the arguments passed in (neither includes request). It returns either None or an HttpResponse object. If it returns None, Django will continue processing this request, run the other process_view middleware, and then the matched view function. Once it returns an HttpResponse object, it will no longer run the other view middleware and exception middleware, nor the corresponding view function. It will continue by calling the response middleware, and then return.
4. process_template_response
request is an HttpRequest object, and response is a TemplateResponse object, or an equivalent object produced by a view or another middleware. After the view has finished executing, if the response instance contains a render method, indicating that it is a TemplateResponse object or equivalent, the process_template_response middleware will be called. It must return a response object that inherits a render method; this may change the template_name and context_data in the original response, or create a brand-new TemplateResponse object (or equivalent). You do not have to explicitly render responses β responses are rendered automatically after all template response middleware has been called.
During the response generation phase, all middleware runs in reverse order, which naturally includes process_template_response.
5. process_response
request is an HttpRequest object, and response is the HttpResponse or StreamingHttpResponse object returned by the view or middleware. Before the data is returned to the browser, process_response processes all responses. The result must return an HttpResponse or StreamingHttpResponse object; it may modify an existing object, or create a brand-new HttpResponse or StreamingHttpResponse object. Unlike process_request and process_view, process_response is always called, even if the process_request and process_view methods were skipped (because an HttpResponse was generated before them). In particular, note that your process_response must not depend on process_request. Finally, keep in mind that during the response generation phase, middleware is called from the bottom up, which means middleware defined later will be executed first.
6. process_exception
request is an HttpRequest object, and exception is an exception object thrown by the view. When the view throws an exception, Django will call the process_exception middleware, which then returns either None or an HttpResponse object. If it returns an HttpResponse object, the process_template_response middleware and the process_response middleware will continue to be called. If it returns None, the default exception handling is triggered. In addition, during the progressive formation of the response, middleware is called in the reverse of the load order, including process_exception. That is, if some middleware returns a response, no middleware above that one will be called.
You can think of django.contrib as an optional Python standard library, or as practical implementations of common patterns. They are bundled with Django so that you do not have to “reinvent the wheel” during development.
7. Multiple Middleware, Execution Order
Below is the log printed by assembling two middleware, Middleware1 and Middleware2
| |
