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: