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

git-svn-id: http://code.djangoproject.com/svn/django/trunk@11048 bcc190cf-cafb-0310-a4f2-bffc1f526a37

1 files changed, 9 insertions, 6 deletions

diff --git a/docs/topics/http/middleware.txt b/docs/topics/http/middleware.txt
index 9040533f33..19facb8371 100644
--- a/docs/topics/http/middleware.txt
+++ b/docs/topics/http/middleware.txt
@@ -107,15 +107,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: