A few minor wording, whitespace, punctuation, and link changes for the middleware documentation.

   :synopsis: Django's built-in middleware classes.

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

:ref:`middleware usage guide <topics-http-middleware>`.

information on how how to use them and how to write your own middleware, see

the :ref:`middleware usage guide <topics-http-middleware>`.

Available middleware

====================

----------------

.. module:: django.middleware.cache

   :synopsis: Middleware for the site-wide cache

   :synopsis: Middleware for the site-wide cache.

.. class:: django.middleware.cache.UpdateCacheMiddleware

      :setting:`PREPEND_WWW` settings.

      If :setting:`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.

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

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

      .. versionchanged:: 1.0

         The behavior of :setting:`APPEND_SLASH` has changed slightly in this

      normalize URLs.

    * Handles ETags based on the :setting:`USE_ETAGS` setting. If

      :setting:`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

      :setting:`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.locale.LocaleMiddleware

Enables language selection based on data from the request. It customizes content

for each user. See the :ref:`internationalization documentation <topics-i18n>`.

Enables language selection based on data from the request. It customizes

content for each user. See the :ref:`internationalization documentation

<topics-i18n>`.

Session middleware

------------------

-------------------------

.. module:: django.contrib.auth.middleware

  :synopsis: Authentication middleware

  :synopsis: Authentication middleware.

.. class:: django.contrib.auth.middleware.AuthenticationMiddleware

Adds the ``user`` attribute, representing the currently-logged-in user, to every

incoming ``HttpRequest`` object. See :ref:`Authentication in Web requests <topics-auth>`.

Adds the ``user`` attribute, representing the currently-logged-in user, to

every incoming ``HttpRequest`` object. See :ref:`Authentication in Web requests

<topics-auth>`.

CSRF protection middleware

--------------------------

.. module:: django.contrib.csrf.middleware

   :synopsis: Middleware adding protection against Cross Site Request Forgeries.

   :synopsis: Middleware adding protection against Cross Site Request

              Forgeries.

.. class:: django.contrib.csrf.middleware.CsrfMiddleware

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

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.

the same transaction control as the view functions.

See the :ref:`transaction management documentation <topics-db-transactions>`.

an ``"X-View"`` HTTP header to every response to a ``HEAD`` request.

This document explains how middleware works, how you activate middleware, and

how to write your own middleware. Django ships with some built-in middleware you

can use right out of the box; they're documented in the :ref:`built-in

middleware guide <ref-middleware>`.

how to write your own middleware. Django ships with some built-in middleware

you can use right out of the box; they're documented in the :ref:`built-in

middleware reference <ref-middleware>`.

Activating middleware

=====================

During the request phases (:meth:`process_request` and :meth:`process_view`

middleware), Django applies middleware in the order it's defined in

:setting:`MIDDLEWARE_CLASSES`, top-down. During the response phases

(:meth:`process_response` and :meth:`process_exception` middleware), the classes

are applied in reverse order, from the bottom up. You can think of it like an

onion: each middleware class is a "layer" that wraps the view:

(:meth:`process_response` and :meth:`process_exception` middleware), the

classes are applied in reverse order, from the bottom up. You can think of it

like an onion: each middleware class is a "layer" that wraps the view:

.. image:: _images/middleware.png

   :width: 502

.. method:: process_view(self, request, view_func, view_args, view_kwargs)

``request`` is an :class:`~django.http.HttpRequest` object. ``view_func`` is the

Python function that Django is about to use. (It's the actual function object,

not the name of the function as a string.) ``view_args`` is a list of positional

arguments that will be passed to the view, and ``view_kwargs`` is a dictionary

of keyword arguments that will be passed to the view. Neither ``view_args`` nor

``view_kwargs`` include the first view argument (``request``).

``process_view()`` is called just before Django calls the view. It should return

either ``None`` or an :class:`~django.http. HttpResponse` object. If it returns

``None``, Django will continue processing this request, executing any other

``process_view()`` middleware and, then, the appropriate view. If it returns an

:class:`~django.http. HttpResponse` object, Django won't bother calling ANY

other request, view or exception middleware, or the appropriate view; it'll

return that :class:`~django.http. HttpResponse`. Response middleware is always

called on every response.

``request`` is an :class:`~django.http.HttpRequest` object. ``view_func`` is

the Python function that Django is about to use. (It's the actual function

object, not the name of the function as a string.) ``view_args`` is a list of

positional arguments that will be passed to the view, and ``view_kwargs`` is a

dictionary of keyword arguments that will be passed to the view. Neither

``view_args`` nor ``view_kwargs`` include the first view argument

(``request``).

``process_view()`` is called just before Django calls the view. It should

return either ``None`` or an :class:`~django.http. HttpResponse` object. If it

returns ``None``, Django will continue processing this request, executing any

other ``process_view()`` middleware and, then, the appropriate view. If it

returns an :class:`~django.http. HttpResponse` object, Django won't bother

calling ANY other request, view or exception middleware, or the appropriate

view; it'll return that :class:`~django.http. HttpResponse`. Response

middleware is always called on every response.

.. _response-middleware:

Django calls ``process_exception()`` when a view raises an exception.

``process_exception()`` should return either ``None`` or an

:class:`~django.http. HttpResponse` object. If it returns an

:class:`~django.http. HttpResponse` object, the response will be returned to the

browser. Otherwise, default exception handling kicks in.

:class:`~django.http. HttpResponse` object, the response will be returned to

the browser. Otherwise, default exception handling kicks in.

``__init__``

------------

It's sometimes useful to determine at run-time whether a piece of middleware

should be used. In these cases, your middleware's ``__init__`` method may raise

``django.core.exceptions.MiddlewareNotUsed``. Django will then remove that piece

of middleware from the middleware process.

``django.core.exceptions.MiddlewareNotUsed``. Django will then remove that

piece of middleware from the middleware process.

Guidelines

----------

    * Middleware classes don't have to subclass anything.

    * The middleware class can live anywhere on your Python path. All Django

      cares about is that the :setting:`MIDDLEWARE_CLASSES` setting includes the

      path

      to it.

    * Feel free to look at :mod:`Django's available middleware for examples

      <django.middleware>`. The core Django middleware classes are in

      ``django/middleware/`` in the Django distribution. The session middleware

      is in ``django/contrib/sessions``.

      cares about is that the :setting:`MIDDLEWARE_CLASSES` setting includes

      the path to it.

    * Feel free to look at :ref:`Django's available middleware

      <ref-middleware>` for examples.

    * If you write a middleware component that you think would be useful to

      other people, contribute to the community! :ref:`Let us know