Fixed a whole bunch of small docs typos, errors, and ommissions.

Fixes #8358, #8396, #8724, #9043, #9128, #9247, #9267, #9267, #9375, #9409, #9414, #9416, #9446, #9454, #9464, #9503, #9518, #9533, #9657, #9658, #9683, #9733, #9771, #9835, #9836, #9837, #9897, #9906, #9912, #9945, #9986, #9992, #10055, #10084, #10091, #10145, #10245, #10257, #10309, #10358, #10359, #10424, #10426, #10508, #10531, #10551, #10635, #10637, #10656, #10658, #10690, #10699, #19528.

Thanks to all the respective authors of those tickets.

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

1 files changed, 10 insertions, 0 deletions

diff --git a/docs/topics/http/middleware.txt b/docs/topics/http/middleware.txt
index fe05909a4f..9040533f33 100644
--- a/docs/topics/http/middleware.txt
+++ b/docs/topics/http/middleware.txt
@@ -111,6 +111,12 @@ middleware is always called on every response.
 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.
+
 .. _exception-middleware:
 
 ``process_exception``
@@ -127,6 +133,10 @@ Django calls ``process_exception()`` when a view raises an exception.
 :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
+includes ``process_exception``. If an exception middleware return a response,
+the middleware classes above that middleware will not be called at all.
+
 ``__init__``
 ------------