[1.0.X] Fixed #11322 -- Clarified docs regarding middleware processing. Thanks the Michael Malone for the patch.

Merge of r11048 from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.0.X@11060 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Russell Keith-Magee 2009-06-18 14:16:13 +00:00
parent 82ffb6747f
commit c77f83ceae
1 changed files with 9 additions and 6 deletions

View File

@ -108,15 +108,18 @@ middleware is always called on every response.
``request`` is an :class:`~django.http.HttpRequest` object. ``response`` is the
:class:`~django.http. HttpResponse` object returned by a Django view.
``process_response()`` should return an :class:`~django.http. HttpResponse`
``process_response()`` must return an :class:`~django.http. HttpResponse`
object. It could alter the given ``response``, or it could create and return a
brand-new :class:`~django.http. HttpResponse`.
Remember that your middleware will not be called if another middleware object
returns a response before you. But unlike ``process_request()`` and
``process_view()``, during the response phase the classes are applied in reverse
order, from the bottom up. This means classes defined at the end of
:setting:`MIDDLEWARE_CLASSES` will be run first.
Unlike the ``process_request()`` and ``process_view()`` methods, the
``process_response()`` method is always called, even if the ``process_request()``
and ``process_view()`` methods of the same middleware class were skipped because
an earlier middleware method returned an :class:`~django.http. HttpResponse`
(this means that your ``process_response()`` method cannot rely on setup done in
``process_request()``, for example). In addition, during the response phase the
classes are applied in reverse order, from the bottom up. This means classes
defined at the end of :setting:`MIDDLEWARE_CLASSES` will be run first.
.. _exception-middleware: