Middleware

This document explains all middleware components that come with Django. For information on how how to use them and how to write your own middleware, see the middleware usage guide.

Available middleware

Cache middleware

class django.middleware.cache.UpdateCacheMiddleware
class django.middleware.cache.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.

“Common” middleware

class django.middleware.common.CommonMiddleware

Adds a few conveniences for perfectionists:

  • Forbids access to user agents in the DISALLOWED_USER_AGENTS setting, which should be a list of strings.

  • 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/.

    Changed in Django 1.0: The behavior of APPEND_SLASH has changed slightly in this version. It didn’t used to check whether the pattern was matched in the URLconf.

    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.

View metadata middleware

class django.middleware.doc.XViewMiddleware

Sends custom X-View HTTP headers to HEAD requests that come from IP addresses defined in the INTERNAL_IPS setting. This is used by Django’s automatic documentation system.

GZIP middleware

class django.middleware.gzip.GZipMiddleware

Compresses content for browsers that understand gzip compression (all modern browsers).

It is suggested to place this first in the middleware list, so that the compression of the response content is the last thing that happens. Will not compress content bodies less than 200 bytes long, when the response code is something other than 200, JavaScript files (for IE compatibility), or responses that have the Content-Encoding header already specified.

Conditional GET middleware

class django.middleware.http.ConditionalGetMiddleware

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

Also sets the Date and Content-Length response-headers.

Reverse proxy middleware

class django.middleware.http.SetRemoteAddrFromForwardedFor
Changed in Django 1.1: Please, see the release notes

This middleware was removed in Django 1.1. See the release notes for details.

Locale middleware

class django.middleware.locale.LocaleMiddleware

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

Message middleware

class django.contrib.messages.middleware.MessageMiddleware
New in Django 1.2: MessageMiddleware was added.

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

Session middleware

class django.contrib.sessions.middleware.SessionMiddleware

Enables session support. See the session documentation.

Authentication middleware

class django.contrib.auth.middleware.AuthenticationMiddleware

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

CSRF protection middleware

class django.middleware.csrf.CsrfMiddleware
New in Django 1.0: Please, see the release notes

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 django.middleware.transaction.TransactionMiddleware

Binds commit and rollback 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.

« previous | up | next »