mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-31 07:47:37 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Updated documentation and comments for RFC updates.

Browse source 
- Updated references to RFC 1123 to RFC 5322
  - Only partial as RFC 5322 sort of sub-references RFC 1123.
- Updated references to RFC 2388 to RFC 7578
  - Except RFC 2388 Section 5.3 which has no equivalent.
- Updated references to RFC 2396 to RFC 3986
- Updated references to RFC 2616 to RFC 9110
- Updated references to RFC 3066 to RFC 5646
- Updated references to RFC 7230 to RFC 9112
- Updated references to RFC 7231 to RFC 9110
- Updated references to RFC 7232 to RFC 9110
- Updated references to RFC 7234 to RFC 9111
- Tidied up style of text when referring to RFC documents
This commit is contained in:
Nick Pope 2022-11-04 12:33:09 +00:00 • committed by Mariusz Felisiak
parent fad070b07b
commit 9bd174b9a7
34 changed files with 97 additions and 103 deletions
Download patch file Download diff file Expand all files Collapse all files

30
docs/topics/conditional-view-processing.txt
View file

@ -15,16 +15,16 @@ 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
such as either :rfc:`If-modified-since <7232#section-3.3>` or
:rfc:`If-unmodified-since <7232#section-3.4>`, containing the date of the last
modification time it was sent, or either :rfc:`If-match <7232#section-3.1>` or
:rfc:`If-none-match <7232#section-3.2>`, containing the last ``ETag`` it was
sent. If the current version of the page matches the ``ETag`` sent by the
client, or if the resource has not been modified, a 304 status code can be sent
back, instead of a full response, telling the client that nothing has changed.
Depending on the header, if the page has been modified or does not match the
``ETag`` sent by the client, a 412 status code (Precondition Failed) may be
returned.
such as either :rfc:`If-Modified-Since <9110#section-13.1.3>` or
:rfc:`If-Unmodified-Since <9110#section-13.1.4>`, containing the date of the
last modification time it was sent, or either :rfc:`If-Match
<9110#section-13.1.1>` or :rfc:`If-None-Match <9110#section-13.1.2>`,
containing the last ``ETag`` it was sent. If the current version of the page
matches the ``ETag`` sent by the client, or if the resource has not been
modified, a 304 status code can be sent back, instead of a full response,
telling the client that nothing has changed. Depending on the header, if the
page has been modified or does not match the ``ETag`` sent by the client, a 412
status code (Precondition Failed) may be returned.
When you need more fine-grained control you may use per-view conditional
processing functions.
@ -35,7 +35,7 @@ The ``condition`` decorator
===========================
Sometimes (in fact, quite often) you can create functions to rapidly compute
the :rfc:`ETag <7232#section-2.3>` value or the last-modified time for a
the :rfc:`ETag <9110#section-8.8.3>` value or the last-modified time for a
resource, **without** needing to do all the computations needed to construct
the full view. Django can then use these functions to provide an
"early bailout" option for the view processing. Telling the client that the
@ -58,7 +58,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 :rfc:`ETag <7232#section-2.3>` for the resource, or ``None``
representing the :rfc:`ETag <9110#section-8.8.3>` for the resource, or ``None``
if it doesn't exist.
The decorator sets the ``ETag`` and ``Last-Modified`` headers on the response
@ -105,8 +105,8 @@ for your front page view::
:func:`~django.views.decorators.vary.vary_on_cookie`,
:func:`~django.views.decorators.vary.vary_on_headers`, and
:func:`~django.views.decorators.cache.cache_control` should come first
because :rfc:`RFC 7232 <7232#section-4.1>` requires that the headers they
set be present on 304 responses.
because :rfc:`RFC 9110 <9110#section-15.4.5>` requires that the headers
they set be present on 304 responses.
Shortcuts for only computing one value
======================================
@ -194,7 +194,7 @@ every time.
The ``condition`` decorator only sets validator headers (``ETag`` and
``Last-Modified``) for safe HTTP methods, i.e. ``GET`` and ``HEAD``. If you
wish to return them in other cases, set them in your view. See
:rfc:`7231#section-4.3.4` to learn about the distinction between setting a
:rfc:`9110#section-9.3.4` to learn about the distinction between setting a
validator header in response to requests made with ``PUT`` versus ``POST``.
Comparison with middleware conditional processing