• Language: en


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.

Available middleware

Cache middleware

class UpdateCacheMiddleware[source]
class FetchFromCacheMiddleware[source]

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.

“Common” middleware

class CommonMiddleware

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.

class BrokenLinkEmailsMiddleware

GZip middleware

class GZipMiddleware[source]


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:

  • The content body is less than 200 bytes long.
  • The response has already set the Content-Encoding header.
  • The request (the browser) hasn’t sent an Accept-Encoding header containing gzip.
  • The request is from Internet Explorer and the 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.

Conditional GET middleware

class ConditionalGetMiddleware[source]

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.

Locale middleware

class LocaleMiddleware

Enables language selection based on data from the request. It customizes content for each user. See the internationalization documentation.


Defaults to HttpResponseRedirect. Subclass LocaleMiddleware and override the attribute to customize the redirects issued by the middleware.

Message middleware

class MessageMiddleware

Enables cookie- and session-based message support. See the messages documentation.

Session middleware

class SessionMiddleware[source]

Enables session support. See the session documentation.

Site middleware

class CurrentSiteMiddleware
New in Django 1.7.

Adds the site attribute representing the current site to every incoming HttpRequest object. See the sites documentation.

Authentication middleware

class AuthenticationMiddleware

Adds the user attribute, representing the currently-logged-in user, to every incoming HttpRequest object. See Authentication in Web requests.

class RemoteUserMiddleware

Middleware for utilizing Web server provided authentication. See Authentication using REMOTE_USER for usage details.

class SessionAuthenticationMiddleware
New in Django 1.7.

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.

CSRF protection middleware

class 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.

Transaction middleware

class TransactionMiddleware[source]
Changed in Django 1.6:

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.

X-Frame-Options middleware

class XFrameOptionsMiddleware[source]

Simple clickjacking protection via the X-Frame-Options header.

Middleware ordering

Here are some hints about the ordering of various Django middleware classes:

  1. UpdateCacheMiddleware

    Before those that modify the Vary header (SessionMiddleware, GZipMiddleware, LocaleMiddleware).

  2. GZipMiddleware

    Before any middleware that may change or use the response body.

    After UpdateCacheMiddleware: Modifies Vary header.

  3. ConditionalGetMiddleware

    Before CommonMiddleware: uses its Etag header when USE_ETAGS = True.

  4. SessionMiddleware

    After UpdateCacheMiddleware: Modifies Vary header.

  5. LocaleMiddleware

    One of the topmost, after SessionMiddleware (uses session data) and UpdateCacheMiddleware (modifies Vary header).

  6. CommonMiddleware

    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.

  7. CsrfViewMiddleware

    Before any view middleware that assumes that CSRF attacks have been dealt with.

  8. AuthenticationMiddleware

    After SessionMiddleware: uses session storage.

  9. MessageMiddleware

    After SessionMiddleware: can use session-based storage.

  10. FetchFromCacheMiddleware

    After any middleware that modifies the Vary header: that header is used to pick a value for the cache hash-key.

  11. FlatpageFallbackMiddleware

    Should be near the bottom as it’s a last-resort type of middleware.

  12. RedirectFallbackMiddleware

    Should be near the bottom as it’s a last-resort type of middleware.

Back to Top