Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Fixed #14785 - fixes to middleware docs - thanks adamv for the patch.

git-svn-id: bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit 9d3b3d11f434ef3a50402fb8a937ded61e0dbd06 1 parent 6051a7d
Tim Graham timgraham authored
Showing with 22 additions and 22 deletions.
  1. +13 −13 docs/ref/middleware.txt
  2. +9 −9 docs/topics/http/middleware.txt
26 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 </topics/cache>`.
.. 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
@@ -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
-.. 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
18 docs/topics/http/middleware.txt
@@ -89,12 +89,12 @@ dictionary of keyword arguments that will be passed to the view. Neither
``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
Please sign in to comment.
Something went wrong with that request. Please try again.