{"title":"Middleware","version":"1.9","locale":"es","docname":"topics/http/middleware","url":"/es/1.9/topics/http/middleware/","canonical":"https://djangodocs.dev/es/1.9/topics/http/middleware/","summary":"Middleware is a framework of hooks into Django’s request/response processing. It’s a light, low-level «plugin» system for globally altering Django’s input or…","html":"
Middleware is a framework of hooks into Django’s request/response processing.\nIt’s a light, low-level «plugin» system for globally altering Django’s input\nor output.
\n
Each middleware component is responsible for doing some specific function. For\nexample, Django includes a middleware component,\nAuthenticationMiddleware, that\nassociates users with requests using sessions.
\n
This document explains how middleware works, how you activate middleware, and\nhow to write your own middleware. Django ships with some built-in middleware\nyou can use right out of the box. They’re documented in the built-in\nmiddleware reference.
To activate a middleware component, add it to the\nMIDDLEWARE_CLASSES list in your Django settings.
\n
In MIDDLEWARE_CLASSES, each middleware component is represented by\na string: the full Python path to the middleware’s class name. For example,\nhere’s the default value created by django-adminstartproject:
A Django installation doesn’t require any middleware —\nMIDDLEWARE_CLASSES can be empty, if you’d like — but it’s strongly\nsuggested that you at least use\nCommonMiddleware.
\n
The order in MIDDLEWARE_CLASSES matters because a middleware can\ndepend on other middleware. For instance,\nAuthenticationMiddleware stores the\nauthenticated user in the session; therefore, it must run after\nSessionMiddleware. See\nMiddleware ordering for some common hints about ordering of Django\nmiddleware classes.
During the request phase, before calling the view, Django applies middleware\nin the order it’s defined in MIDDLEWARE_CLASSES, top-down. Two\nhooks are available:
process_request() is called on each request, before Django decides which\nview to execute.
\n
It should return either None or an HttpResponse\nobject. If it returns None, Django will continue processing this request,\nexecuting any other process_request() middleware, then, process_view()\nmiddleware, and finally, the appropriate view. If it returns an\nHttpResponse object, Django won’t bother calling any\nother request, view or exception middleware, or the appropriate view; it’ll\napply response middleware to that HttpResponse, and\nreturn the result.
request is an HttpRequest object. view_func is\nthe Python function that Django is about to use. (It’s the actual function\nobject, not the name of the function as a string.) view_args is a list of\npositional arguments that will be passed to the view, and view_kwargs is a\ndictionary of keyword arguments that will be passed to the view. Neither\nview_args nor view_kwargs include the first view argument\n(request).
\n
process_view() is called just before Django calls the view.
\n
It should return either None or an HttpResponse\nobject. If it returns None, Django will continue processing this request,\nexecuting any other process_view() middleware and, then, the appropriate\nview. If it returns an HttpResponse object, Django won’t\nbother calling any other view or exception middleware, or the appropriate\nview; it’ll apply response middleware to that\nHttpResponse, and return the result.
request is an HttpRequest object. response is\nthe TemplateResponse object (or equivalent)\nreturned by a Django view or by a middleware.
\n
process_template_response() is called just after the view has finished\nexecuting, if the response instance has a render() method, indicating that\nit is a TemplateResponse or equivalent.
\n
It must return a response object that implements a render method. It could\nalter the given response by changing response.template_name and\nresponse.context_data, or it could create and return a brand-new\nTemplateResponse or equivalent.
\n
You don’t need to explicitly render responses – responses will be\nautomatically rendered once all template response middleware has been\ncalled.
\n
Middleware are run in reverse order during the response phase, which\nincludes process_template_response().
Unlike the process_request() and process_view() methods, the\nprocess_response() method is always called, even if the\nprocess_request() and process_view() methods of the same middleware\nclass were skipped (because an earlier middleware method returned an\nHttpResponse). In particular, this means that your\nprocess_response() method cannot rely on setup done in\nprocess_request().
\n
Finally, remember that during the response phase, middleware are applied in\nreverse order, from the bottom up. This means classes defined at the end of\nMIDDLEWARE_CLASSES will be run first.
Unlike HttpResponse,\nStreamingHttpResponse does not have a content\nattribute. As a result, middleware can no longer assume that all responses\nwill have a content attribute. If they need access to the content, they\nmust test for streaming responses and adjust their behavior accordingly:
request is an HttpRequest object. exception is an\nException object raised by the view function.
\n
Django calls process_exception() when a view raises an exception.\nprocess_exception() should return either None or an\nHttpResponse object. If it returns an\nHttpResponse object, the template response and response\nmiddleware will be applied, and the resulting response returned to the\nbrowser. Otherwise, default exception handling kicks in.
\n
Again, middleware are run in reverse order during the response phase, which\nincludes process_exception. If an exception middleware returns a response,\nthe middleware classes above that middleware will not be called at all.
Most middleware classes won’t need an initializer since middleware classes are\nessentially placeholders for the process_* methods. If you do need some\nglobal state you may use __init__ to set up. However, keep in mind a couple\nof caveats:
\n
\n
Django initializes your middleware without any arguments, so you can’t\ndefine __init__ as requiring any arguments.
\n
Unlike the process_* methods which get called once per request,\n__init__ gets called only once, when the Web server responds to the\nfirst request.
It’s sometimes useful to determine at run-time whether a piece of middleware\nshould be used. In these cases, your middleware’s __init__ method may\nraise django.core.exceptions.MiddlewareNotUsed. Django will then remove\nthat piece of middleware from the middleware process and a debug message will\nbe logged to the django.request logger when DEBUG is set to\nTrue.
If you write a middleware component that you think would be useful to\nother people, contribute to the community! Let us know, and we’ll consider adding it to Django.
\n
\n\n","rootId":"middleware","toc":[{"title":"Activating middleware","anchor":"activating-middleware","children":[]},{"title":"Hooks and application order","anchor":"hooks-and-application-order","children":[]},{"title":"Writing your own middleware","anchor":"writing-your-own-middleware","children":[{"title":"process_request()","anchor":"process-request","children":[]},{"title":"process_view()","anchor":"process-view","children":[]},{"title":"process_template_response()","anchor":"process-template-response","children":[]},{"title":"process_response()","anchor":"process-response","children":[{"title":"Dealing with streaming responses","anchor":"dealing-with-streaming-responses","children":[]}]},{"title":"process_exception()","anchor":"process-exception","children":[]},{"title":"__init__()","anchor":"init","children":[{"title":"Marking middleware as unused","anchor":"marking-middleware-as-unused","children":[]}]},{"title":"Guidelines","anchor":"guidelines","children":[]}]}],"breadcrumbs":[{"docname":"topics/index","title":"Using Django","url":"/es/1.9/topics/"},{"docname":"topics/http/index","title":"Handling HTTP requests","url":"/es/1.9/topics/http/"}],"prev":{"docname":"topics/http/generic-views","title":"Generic views","url":"/es/1.9/topics/http/generic-views/"},"next":{"docname":"topics/http/sessions","title":"How to use sessions","url":"/es/1.9/topics/http/sessions/"},"formats":{"html":"/es/1.9/topics/http/middleware/","markdown":"/es/1.9/topics/http/middleware.md","json":"/es/1.9/topics/http/middleware.json"},"source":"https://github.com/django/django/blob/stable/1.9.x/docs/topics/http/middleware.txt","official":"https://docs.djangoproject.com/es/1.9/topics/http/middleware/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9"],"inLocales":["en","fr","ja","id","pt-br","es"]}
![\"middleware](\"../../../../../../_images/middleware.svg\")
\n\n