Updated documentation and comments for RFC updates.

- 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

1 files changed, 15 insertions, 15 deletions

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