This document explains all middleware components that come with Django. For information on how to use them and how to write your own middleware, see the middleware usage guide.
UpdateCacheMiddleware
¶FetchFromCacheMiddleware
¶Enable the site-wide cache. If these are enabled, each Django-powered page will
be cached for as long as the CACHE_MIDDLEWARE_SECONDS
setting
defines. See the cache documentation.
Adds a few conveniences for perfectionists:
Forbids access to user agents in the DISALLOWED_USER_AGENTS
setting, which should be a list of compiled regular expression objects.
Performs URL rewriting based on the APPEND_SLASH
and
PREPEND_WWW
settings.
If APPEND_SLASH
is True
and the initial URL doesn’t end
with a slash, and it is not found in the URLconf, then a new URL is
formed by appending a slash at the end. If this new URL is found in the
URLconf, then Django redirects the request to this new URL. Otherwise,
the initial URL is processed as usual.
For example, foo.com/bar
will be redirected to foo.com/bar/
if
you don’t have a valid URL pattern for foo.com/bar
but do have a
valid pattern for foo.com/bar/
.
If PREPEND_WWW
is True
, URLs that lack a leading “www.”
will be redirected to the same URL with a leading “www.”
Both of these options are meant to normalize URLs. The philosophy is that
each URL should exist in one, and only one, place. Technically a URL
foo.com/bar
is distinct from foo.com/bar/
– a search-engine
indexer would treat them as separate URLs – so it’s best practice to
normalize URLs.
Handles ETags based on the USE_ETAGS
setting. If
USE_ETAGS
is set to True
, Django will calculate an ETag
for each request by MD5-hashing the page content, and it’ll take care of
sending Not Modified
responses, if appropriate.
MANAGERS
(see
Error reporting).GZipMiddleware
¶Warning
Security researchers recently revealed that when compression techniques
(including GZipMiddleware
) are used on a website, the site becomes
exposed to a number of possible attacks. These approaches can be used to
compromise, among other things, Django’s CSRF protection. Before using
GZipMiddleware
on your site, you should consider very carefully whether
you are subject to these attacks. If you’re in any doubt about whether
you’re affected, you should avoid using GZipMiddleware
. For more
details, see the the BREACH paper (PDF) and breachattack.com.
Compresses content for browsers that understand GZip compression (all modern browsers).
This middleware should be placed before any other middleware that need to read or write the response body so that compression happens afterward.
It will NOT compress content if any of the following are true:
Content-Encoding
header.Accept-Encoding
header
containing gzip
.Content-Type
header
contains javascript
or starts with anything other than text/
.
We do this to avoid a bug in early versions of IE that caused decompression
not to be performed on certain content types.You can apply GZip compression to individual views using the
gzip_page()
decorator.
Handles conditional GET operations. If the response has a ETag
or
Last-Modified
header, and the request has If-None-Match
or
If-Modified-Since
, the response is replaced by an
HttpResponseNotModified
.
Also sets the Date
and Content-Length
response-headers.
LocaleMiddleware
¶Enables language selection based on data from the request. It customizes content for each user. See the internationalization documentation.
LocaleMiddleware.
response_redirect_class
¶Defaults to HttpResponseRedirect
. Subclass
LocaleMiddleware
and override the attribute to customize the redirects
issued by the middleware.
Enables cookie- and session-based message support. See the messages documentation.
SessionMiddleware
¶Enables session support. See the session documentation.
CurrentSiteMiddleware
¶Adds the site
attribute representing the current site to every incoming
HttpRequest
object. See the sites documentation.
AuthenticationMiddleware
¶Adds the user
attribute, representing the currently-logged-in user, to
every incoming HttpRequest
object. See Authentication in Web requests.
RemoteUserMiddleware
¶Middleware for utilizing Web server provided authentication. See Authentication using REMOTE_USER for usage details.
SessionAuthenticationMiddleware
¶Allows a user’s sessions to be invalidated when their password changes. See
Session invalidation on password change for details. This middleware must
appear after django.contrib.auth.middleware.AuthenticationMiddleware
in MIDDLEWARE_CLASSES
.
CsrfViewMiddleware
¶Adds protection against Cross Site Request Forgeries by adding hidden form fields to POST forms and checking requests for the correct value. See the Cross Site Request Forgery protection documentation.
TransactionMiddleware
is deprecated. The documentation of transactions
contains upgrade instructions.
Binds commit and rollback of the default database to the request/response phase. If a view function runs successfully, a commit is done. If it fails with an exception, a rollback is done.
The order of this middleware in the stack is important: middleware modules running outside of it run with commit-on-save - the default Django behavior. Middleware modules running inside it (coming later in the stack) will be under the same transaction control as the view functions.
See the transaction management documentation.
Simple clickjacking protection via the X-Frame-Options header.
Here are some hints about the ordering of various Django middleware classes:
Before those that modify the Vary
header (SessionMiddleware
,
GZipMiddleware
, LocaleMiddleware
).
Before any middleware that may change or use the response body.
After UpdateCacheMiddleware
: Modifies Vary
header.
Before CommonMiddleware
: uses its Etag
header when
USE_ETAGS
= True
.
After UpdateCacheMiddleware
: Modifies Vary
header.
One of the topmost, after SessionMiddleware
(uses session data) and
UpdateCacheMiddleware
(modifies Vary
header).
Before any middleware that may change the response (it calculates ETags
).
After GZipMiddleware
so it won’t calculate an ETag
header on gzipped
contents.
Close to the top: it redirects when APPEND_SLASH
or
PREPEND_WWW
are set to True
.
Before any view middleware that assumes that CSRF attacks have been dealt with.
After SessionMiddleware
: uses session storage.
After SessionMiddleware
: can use session-based storage.
After any middleware that modifies the Vary
header: that header is used
to pick a value for the cache hash-key.
Should be near the bottom as it’s a last-resort type of middleware.
Should be near the bottom as it’s a last-resort type of middleware.
Feb 24, 2017