mirror of
https://github.com/django/django.git
synced 2025-07-24 05:36:15 +00:00
Fixed #26447 -- Deprecated settings.USE_ETAGS in favor of ConditionalGetMiddleware.
This commit is contained in:
parent
46a3d7604e
commit
a840710e1e
15 changed files with 126 additions and 24 deletions
|
@ -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
|
||||
|
|
|
@ -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::
|
||||
|
||||
|
|
|
@ -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`
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue