Fixed #26447 -- Deprecated settings.USE_ETAGS in favor of ConditionalGetMiddleware.

This commit is contained in:
Denis Cornehl 2016-04-03 12:15:10 +02:00 committed by Tim Graham
parent 46a3d7604e
commit a840710e1e
15 changed files with 126 additions and 24 deletions

View file

@ -11,7 +11,7 @@ used for all HTTP methods (``POST``, ``PUT``, ``DELETE``, etc.).
For each page (response) that Django sends back from a view, it might provide
two HTTP headers: the ``ETag`` header and the ``Last-Modified`` header. These
headers are optional on HTTP responses. They can be set by your view function,
or you can rely on the :class:`~django.middleware.common.CommonMiddleware`
or you can rely on the :class:`~django.middleware.http.ConditionalGetMiddleware`
middleware to set the ``ETag`` header.
When the client next requests the same resource, it might send along a header
@ -189,17 +189,14 @@ every time.
Comparison with middleware conditional processing
=================================================
You may notice that Django already provides simple and straightforward
conditional ``GET`` handling via the
:class:`django.middleware.http.ConditionalGetMiddleware` and
:class:`~django.middleware.common.CommonMiddleware`. While certainly being
easy to use and suitable for many situations, those pieces of middleware
functionality have limitations for advanced usage:
Django provides simple and straightforward conditional ``GET`` handling via
:class:`django.middleware.http.ConditionalGetMiddleware`. While being easy to
use and suitable for many situations, the middleware has limitations for
advanced usage:
* They are applied globally to all views in your project
* They don't save you from generating the response itself, which may be
expensive
* They are only appropriate for HTTP ``GET`` requests.
* It's applied globally to all views in your project.
* It doesn't save you from generating the response, which may be expensive.
* It's only appropriate for HTTP ``GET`` requests.
You should choose the most appropriate tool for your particular problem here.
If you have a way to compute ETags and modification times quickly and if some

View file

@ -1372,8 +1372,8 @@ URL::
]
Client-side caching will save bandwidth and make your site load faster. If
you're using ETags (:setting:`USE_ETAGS = True <USE_ETAGS>`), you're already
covered. Otherwise, you can apply :ref:`conditional decorators
you're using ETags (:class:`~django.middleware.http.ConditionalGetMiddleware`),
you're already covered. Otherwise, you can apply :ref:`conditional decorators
<conditional-decorators>`. In the following example, the cache is invalidated
whenever you restart your application server::

View file

@ -262,7 +262,8 @@ that can help optimize your site's performance. They include:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Adds support for modern browsers to conditionally GET responses based on the
``ETag`` and ``Last-Modified`` headers.
``ETag`` and ``Last-Modified`` headers. It also calculates and sets an ETag if
needed.
:class:`~django.middleware.gzip.GZipMiddleware`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~