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

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

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
 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
 </topics/http/sessions>`.
@@ -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

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