During the request phase, before calling the view, Django applies middleware in the order it\u2019s defined in MIDDLEWARE_CLASSES, top-down. Two hooks are available:<\/p>\n
During the response phase, after calling the view, middleware are applied in reverse order, from the bottom up. Three hooks are available:<\/p>\n
If you prefer, you can also think of it like an onion: each middleware class is a layer that wraps the view. The behavior of each hook is described below.<\/p>\n
Writing your own middleware is easy. Each middleware component is a single Python class that defines one or more of the following methods:
\nprocess_request
\nMethod: process_request(request)<\/p>\n
It should return either None or an HttpResponse object. If it returns None, Django will continue processing this request, executing any other process_request() middleware, then, process_view() middleware, and finally, the appropriate view.<\/p>\n
If it returns an HttpResponse object, Django won\u2019t bother calling any other request, view or exception middleware, or the appropriate view; it\u2019ll apply response middleware to that HttpResponse, and return the result.<\/p>\n
Method: process_view(request, view_func, view_args, view_kwargs)<\/p>\n
If it returns an HttpResponse object, Django won\u2019t bother calling any other view or exception middleware, or the appropriate view; it\u2019ll apply response middleware to that HttpResponse, and return the result.
\nAccessing request.POST inside middleware from process_request or process_view will prevent any view running after the middleware from being able to modify the upload handlers for the request, and should normally be avoided.<\/p>\n
The CsrfViewMiddleware class can be considered an exception, as it provides the csrf_exempt() and csrf_protect() decorators which allow views to explicitly control at what point the CSRF validation should occur.<\/p>\n
Method: process_template_response(request, response)<\/p>\n
It must return a response object that implements a render method. It could alter the given response by changing response.template_name and response.context_data, or it could create and return a brand-new TemplateResponse or equivalent.<\/p>\n
You don\u2019t need to explicitly render responses \u2013 responses will be automatically rendered once all template response middleware has been called.<\/p>\n
Middleware are run in reverse order during the response phase, which includes process_template_response().<\/p>\n
Method: process_response(request, response)<\/p>\n
Unlike the process_request() and process_view() methods, the process_response() method is always called, even if the process_request() and process_view() methods of the same middleware class were skipped (because an earlier middleware method returned an HttpResponse). In particular, this means that your process_response() method cannot rely on setup done in process_request().<\/p>\n
Finally, remember that during the response phase, middleware are applied in reverse order, from the bottom up. This means classes defined at the end of MIDDLEWARE_CLASSES will be run first.<\/p>\n
Dealing with streaming responses<\/strong> – Unlike HttpResponse, StreamingHttpResponse does not have a content attribute. As a result, middleware can no longer assume that all responses will have a content attribute. If they need access to the content, they must test for streaming responses and adjust their behavior accordingly:<\/p>\n if response.streaming: streaming_content should be assumed to be too large to hold in memory. Response middleware may wrap it in a new generator, but must not consume it. Wrapping is typically implemented as follows:<\/p>\n def wrap_streaming_content(content): Method: process_exception(request, exception)<\/p>\n Again, middleware are run in reverse order during the response phase, which includes process_exception. If an exception middleware returns a response, the middleware classes above that middleware will not be called at all.<\/p>\n Most middleware classes won\u2019t need an initializer since middleware classes are essentially placeholders for the process_* methods. If you do need some global state, you may use __init__ to set up. However, keep in mind a couple of caveats:<\/p>\n It\u2019s sometimes useful to determine at run-time whether a piece of middleware should be used. In these cases, your middleware\u2019s __init__ method may raise django.core.exceptions.MiddlewareNotUsed. Django will then remove that piece of middleware from the middleware process and a debug message will be logged to the django.request logger when DEBUG is set to True.<\/p>\n
\nresponse.streaming_content = wrap_streaming_content(response.streaming_content)
\nelse:
\nresponse.content = alter_content(response.content)<\/p>\n
\nfor chunk in content:
\nyield alter_content(chunk)<\/p>\nprocess_exception<\/h3>\n
\n
__init__<\/h3>\n
\n
Marking middleware as unused<\/h3>\n
Additional Guidelines<\/h3>\n