mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-24 06:06:09 +00:00
Code Issues 32 Releases Wiki Activity

[1.2.X] Fixed #14785 - fixes to middleware docs - thanks adamv for the patch.

Browse Source 
Backport of r14731 from trunk.

git-svn-id: http://code.djangoproject.com/svn/django/branches/releases/1.2.X@14732 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Timo Graham
2010-11-27 21:59:03 +00:00
parent 82261de2fe
commit 0a0d4884f6
2 changed files with 22 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/topics/http/middleware.txt
View File

@@ -89,12 +89,12 @@ dictionary of keyword arguments that will be passed to the view. Neither
(``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
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
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
view; it'll return that :class:`~django.http.HttpResponse`. Response
middleware is always called on every response.
.. _response-middleware:
@@ -105,16 +105,16 @@ middleware is always called on every response.
.. method:: process_response(self, request, response)
``request`` is an :class:`~django.http.HttpRequest` object. ``response`` is the
:class:`~django.http. HttpResponse` object returned by a Django view.
:class:`~django.http.HttpResponse` object returned by a Django view.
``process_response()`` must 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`.
brand-new :class:`~django.http.HttpResponse`.
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`
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
@@ -132,8 +132,8 @@ defined at the end of :setting:`MIDDLEWARE_CLASSES` will be run first.
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
: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.
Again, middleware are run in reverse order during the response phase, which