Normalized spelling of ETag.
This commit is contained in:
parent
ca9c69a968
commit
ef021412d5
|
@ -22,7 +22,7 @@ DEBUG = False
|
|||
# on a live site.
|
||||
DEBUG_PROPAGATE_EXCEPTIONS = False
|
||||
|
||||
# Whether to use the "Etag" header. This saves bandwidth but slows down performance.
|
||||
# Whether to use the "ETag" header. This saves bandwidth but slows down performance.
|
||||
USE_ETAGS = False
|
||||
|
||||
# People who get code error notifications.
|
||||
|
|
|
@ -58,7 +58,7 @@ def condition(etag_func=None, last_modified_func=None):
|
|||
|
||||
The parameters are callables to compute the ETag and last modified time for
|
||||
the requested resource, respectively. The callables are passed the same
|
||||
parameters as the view itself. The Etag function should return a string (or
|
||||
parameters as the view itself. The ETag function should return a string (or
|
||||
None if the resource doesn't exist), while the last_modified function
|
||||
should return a datetime object (or None if the resource doesn't exist).
|
||||
|
||||
|
|
|
@ -472,7 +472,7 @@ Here are some hints about the ordering of various Django middleware classes:
|
|||
|
||||
#. :class:`~django.middleware.http.ConditionalGetMiddleware`
|
||||
|
||||
Before ``CommonMiddleware``: uses its ``Etag`` header when
|
||||
Before ``CommonMiddleware``: uses its ``ETag`` header when
|
||||
:setting:`USE_ETAGS` = ``True``.
|
||||
|
||||
#. :class:`~django.contrib.sessions.middleware.SessionMiddleware`
|
||||
|
|
|
@ -2527,7 +2527,7 @@ to ensure your processes are running in the correct environment.
|
|||
|
||||
Default: ``False``
|
||||
|
||||
A boolean that specifies whether to output the "Etag" header. This saves
|
||||
A boolean that specifies whether to output the ``ETag`` header. This saves
|
||||
bandwidth but slows down performance. This is used by the ``CommonMiddleware``
|
||||
(see :doc:`/topics/http/middleware`) and in the``Cache Framework``
|
||||
(see :doc:`/topics/cache`).
|
||||
|
|
|
@ -239,7 +239,6 @@ environ
|
|||
escapejs
|
||||
esque
|
||||
Ess
|
||||
Etag
|
||||
ETag
|
||||
ETags
|
||||
exe
|
||||
|
|
|
@ -64,7 +64,7 @@ order, as the view function they are helping to wrap. The function passed
|
|||
``last_modified_func`` should return a standard datetime value specifying the
|
||||
last time the resource was modified, or ``None`` if the resource doesn't
|
||||
exist. The function passed to the ``etag`` decorator should return a string
|
||||
representing the `Etag`_ for the resource, or ``None`` if it doesn't exist.
|
||||
representing the `ETag`_ for the resource, or ``None`` if it doesn't exist.
|
||||
|
||||
Using this feature usefully is probably best explained with an example.
|
||||
Suppose you have this pair of models, representing a simple blog system::
|
||||
|
|
|
@ -6047,7 +6047,7 @@ class InlineAdminViewOnSiteTest(TestCase):
|
|||
|
||||
|
||||
@override_settings(ROOT_URLCONF='admin_views.urls')
|
||||
class TestEtagWithAdminView(SimpleTestCase):
|
||||
class TestETagWithAdminView(SimpleTestCase):
|
||||
# See https://code.djangoproject.com/ticket/16003
|
||||
|
||||
def test_admin(self):
|
||||
|
|
|
@ -2163,7 +2163,7 @@ class TestWithTemplateResponse(SimpleTestCase):
|
|||
Tests various headers w/ TemplateResponse.
|
||||
|
||||
Most are probably redundant since they manipulate the same object
|
||||
anyway but the Etag header is 'special' because it relies on the
|
||||
anyway but the ETag header is 'special' because it relies on the
|
||||
content being complete (which is not necessarily always the case
|
||||
with a TemplateResponse)
|
||||
"""
|
||||
|
|
Loading…
Reference in New Issue