diff options
Diffstat (limited to 'docs/topics')
| -rw-r--r-- | docs/topics/cache.txt | 6 | ||||
| -rw-r--r-- | docs/topics/conditional-view-processing.txt | 30 | ||||
| -rw-r--r-- | docs/topics/testing/tools.txt | 2 |
3 files changed, 19 insertions, 19 deletions
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt index 34034c5541..6db9950c04 100644 --- a/docs/topics/cache.txt +++ b/docs/topics/cache.txt @@ -1351,7 +1351,7 @@ its first argument and a list/tuple of case-insensitive header names as its second argument. For more on Vary headers, see the :rfc:`official Vary spec -<7231#section-7.1.4>`. +<9110#section-12.5.5>`. Controlling cache: Using other headers ====================================== @@ -1402,10 +1402,10 @@ cache control header (it is internally called by the return response -You can control downstream caches in other ways as well (see :rfc:`7234` for +You can control downstream caches in other ways as well (see :rfc:`9111` for details on HTTP caching). For example, even if you don't use Django's server-side cache framework, you can still tell clients to cache a view for a -certain amount of time with the :rfc:`max-age <7234#section-5.2.2.8>` +certain amount of time with the :rfc:`max-age <9111#section-5.2.2.1>` directive:: from django.views.decorators.cache import cache_control diff --git a/docs/topics/conditional-view-processing.txt b/docs/topics/conditional-view-processing.txt index ed2c7f8363..ddf8170c77 100644 --- a/docs/topics/conditional-view-processing.txt +++ b/docs/topics/conditional-view-processing.txt @@ -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 diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt index 668ce61080..cdff8a1d4c 100644 --- a/docs/topics/testing/tools.txt +++ b/docs/topics/testing/tools.txt @@ -350,7 +350,7 @@ Use the ``django.test.Client`` class to make requests. ``Response`` object. Useful for simulating diagnostic probes. Unlike the other request methods, ``data`` is not provided as a keyword - parameter in order to comply with :rfc:`7231#section-4.3.8`, which + parameter in order to comply with :rfc:`9110#section-9.3.8`, which mandates that TRACE requests must not have a body. The ``follow``, ``secure``, and ``extra`` arguments act the same as for |