From 9d3b3d11f434ef3a50402fb8a937ded61e0dbd06 Mon Sep 17 00:00:00 2001 From: Timo Graham Date: Sat, 27 Nov 2010 21:58:20 +0000 Subject: [PATCH] Fixed #14785 - fixes to middleware docs - thanks adamv for the patch. git-svn-id: http://code.djangoproject.com/svn/django/trunk@14731 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/ref/middleware.txt | 26 +++++++++++++------------- docs/topics/http/middleware.txt | 18 +++++++++--------- 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/docs/ref/middleware.txt b/docs/ref/middleware.txt index eb746e448e6..b3ddb236283 100644 --- a/docs/ref/middleware.txt +++ b/docs/ref/middleware.txt @@ -18,9 +18,9 @@ Cache middleware .. module:: django.middleware.cache :synopsis: Middleware for the site-wide cache. -.. class:: django.middleware.cache.UpdateCacheMiddleware +.. class:: UpdateCacheMiddleware -.. class:: django.middleware.cache.FetchFromCacheMiddleware +.. class:: FetchFromCacheMiddleware Enable the site-wide cache. If these are enabled, each Django-powered page will be cached for as long as the :setting:`CACHE_MIDDLEWARE_SECONDS` setting @@ -32,7 +32,7 @@ defines. See the :doc:`cache documentation `. .. module:: django.middleware.common :synopsis: Middleware adding "common" conveniences for perfectionists. -.. class:: django.middleware.common.CommonMiddleware +.. class:: CommonMiddleware Adds a few conveniences for perfectionists: @@ -80,7 +80,7 @@ View metadata middleware .. module:: django.middleware.doc :synopsis: Middleware to help your app self-document. -.. class:: django.middleware.doc.XViewMiddleware +.. class:: XViewMiddleware Sends custom ``X-View`` HTTP headers to HEAD requests that come from IP addresses defined in the :setting:`INTERNAL_IPS` setting. This is used by @@ -92,7 +92,7 @@ GZIP middleware .. module:: django.middleware.gzip :synopsis: Middleware to serve gziped content for performance. -.. class:: django.middleware.gzip.GZipMiddleware +.. class:: GZipMiddleware Compresses content for browsers that understand gzip compression (all modern browsers). @@ -109,7 +109,7 @@ Conditional GET middleware .. module:: django.middleware.http :synopsis: Middleware handling advanced HTTP features. -.. class:: django.middleware.http.ConditionalGetMiddleware +.. class:: ConditionalGetMiddleware Handles conditional GET operations. If the response has a ``ETag`` or ``Last-Modified`` header, and the request has ``If-None-Match`` or @@ -121,7 +121,7 @@ Also sets the ``Date`` and ``Content-Length`` response-headers. Reverse proxy middleware ------------------------ -.. class:: django.middleware.http.SetRemoteAddrFromForwardedFor +.. class:: SetRemoteAddrFromForwardedFor .. versionchanged:: 1.1 @@ -134,7 +134,7 @@ Locale middleware .. module:: django.middleware.locale :synopsis: Middleware to enable language selection based on the request. -.. class:: django.middleware.locale.LocaleMiddleware +.. class:: LocaleMiddleware Enables language selection based on data from the request. It customizes content for each user. See the :doc:`internationalization documentation @@ -146,7 +146,7 @@ Message middleware .. module:: django.contrib.messages.middleware :synopsis: Message middleware. -.. class:: django.contrib.messages.middleware.MessageMiddleware +.. class:: MessageMiddleware .. versionadded:: 1.2 ``MessageMiddleware`` was added. @@ -160,7 +160,7 @@ Session middleware .. module:: django.contrib.sessions.middleware :synopsis: Session middleware. -.. class:: django.contrib.sessions.middleware.SessionMiddleware +.. class:: SessionMiddleware Enables session support. See the :doc:`session documentation `. @@ -171,7 +171,7 @@ Authentication middleware .. module:: django.contrib.auth.middleware :synopsis: Authentication middleware. -.. class:: django.contrib.auth.middleware.AuthenticationMiddleware +.. class:: AuthenticationMiddleware Adds the ``user`` attribute, representing the currently-logged-in user, to every incoming ``HttpRequest`` object. See :doc:`Authentication in Web requests @@ -184,7 +184,7 @@ CSRF protection middleware :synopsis: Middleware adding protection against Cross Site Request Forgeries. -.. class:: django.middleware.csrf.CsrfMiddleware +.. class:: CsrfMiddleware .. versionadded:: 1.0 @@ -198,7 +198,7 @@ Transaction middleware .. module:: django.middleware.transaction :synopsis: Middleware binding a database transaction to each Web request. -.. class:: django.middleware.transaction.TransactionMiddleware +.. class:: TransactionMiddleware Binds commit and rollback to the request/response phase. If a view function runs successfully, a commit is done. If it fails with an exception, a rollback diff --git a/docs/topics/http/middleware.txt b/docs/topics/http/middleware.txt index 24d2a8ef7d5..d376c6b1e0a 100644 --- a/docs/topics/http/middleware.txt +++ b/docs/topics/http/middleware.txt @@ -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