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

docs/ref/csrf.txt

@@ -14,7 +14,7 @@ who visits the malicious site in their browser. A related type of attack,
 a site with someone else's credentials, is also covered.
 
 The first defense against CSRF attacks is to ensure that GET requests (and other
-'safe' methods, as defined by :rfc:`7231#section-4.2.1`) are side effect free.
+'safe' methods, as defined by :rfc:`9110#section-9.2.1`) are side effect free.
 Requests via 'unsafe' methods, such as POST, PUT, and DELETE, can then be
 protected by the steps outlined in :ref:`using-csrf`.
 
@@ -90,9 +90,9 @@ This ensures that only forms that have originated from trusted domains can be
 used to POST data back.
 
 It deliberately ignores GET requests (and other requests that are defined as
-'safe' by :rfc:`7231#section-4.2.1`). These requests ought never to have any
+'safe' by :rfc:`9110#section-9.2.1`). These requests ought never to have any
 potentially dangerous side effects, and so a CSRF attack with a GET request
-ought to be harmless. :rfc:`7231#section-4.2.1` defines POST, PUT, and DELETE
+ought to be harmless. :rfc:`9110#section-9.2.1` defines POST, PUT, and DELETE
 as 'unsafe', and all other methods are also assumed to be unsafe, for maximum
 protection.
 

docs/ref/middleware.txt

@@ -122,7 +122,7 @@ It will NOT compress content if any of the following are true:
   containing ``gzip``.
 
 If the response has an ``ETag`` header, the ETag is made weak to comply with
-:rfc:`7232#section-2.1`.
+:rfc:`9110#section-8.8.1`.
 
 You can apply GZip compression to individual views using the
 :func:`~django.views.decorators.gzip.gzip_page()` decorator.

docs/ref/models/instances.txt

@@ -848,7 +848,7 @@ track down every place that the URL might be created. Specify it once, in
 
 .. note::
     The string you return from ``get_absolute_url()`` **must** contain only
-    ASCII characters (required by the URI specification, :rfc:`2396#section-2`)
+    ASCII characters (required by the URI specification, :rfc:`3986#section-2`)
     and be URL-encoded, if necessary.
 
     Code and templates calling ``get_absolute_url()`` should be able to use the

docs/ref/models/querysets.txt

@@ -2174,7 +2174,7 @@ Finally, a word on using ``get_or_create()`` in Django views. Please make sure
 to use it only in ``POST`` requests unless you have a good reason not to.
 ``GET`` requests shouldn't have any effect on data. Instead, use ``POST``
 whenever a request to a page has a side effect on your data. For more, see
-:rfc:`Safe methods <7231#section-4.2.1>` in the HTTP spec.
+:rfc:`Safe methods <9110#section-9.2.1>` in the HTTP spec.
 
 .. warning::
 

docs/ref/request-response.txt

@@ -759,7 +759,7 @@ Attributes
 
 .. attribute:: HttpResponse.status_code
 
-    The :rfc:`HTTP status code <7231#section-6>` for the response.
+    The :rfc:`HTTP status code <9110#section-15>` for the response.
 
     Unless :attr:`reason_phrase` is explicitly set, modifying the value of
     ``status_code`` outside the constructor will also modify the value of
@@ -768,7 +768,7 @@ Attributes
 .. attribute:: HttpResponse.reason_phrase
 
     The HTTP reason phrase for the response. It uses the :rfc:`HTTP standard's
-    <7231#section-6.1>` default reason phrases.
+    <9110#section-15.1>` default reason phrases.
 
     Unless explicitly set, ``reason_phrase`` is determined by the value of
     :attr:`status_code`.
@@ -803,9 +803,9 @@ Methods
     :setting:`DEFAULT_CHARSET` settings, by default:
     ``"text/html; charset=utf-8"``.
 
-    ``status`` is the :rfc:`HTTP status code <7231#section-6>` for the response.
-    You can use Python's :py:class:`http.HTTPStatus` for meaningful aliases,
-    such as ``HTTPStatus.NO_CONTENT``.
+    ``status`` is the :rfc:`HTTP status code <9110#section-15>` for the
+    response. You can use Python's :py:class:`http.HTTPStatus` for meaningful
+    aliases, such as ``HTTPStatus.NO_CONTENT``.
 
     ``reason`` is the HTTP response phrase. If not provided, a default phrase
     will be used.
@@ -1163,7 +1163,7 @@ Attributes
 
 .. attribute:: StreamingHttpResponse.status_code
 
-    The :rfc:`HTTP status code <7231#section-6>` for the response.
+    The :rfc:`HTTP status code <9110#section-15>` for the response.
 
     Unless :attr:`reason_phrase` is explicitly set, modifying the value of
     ``status_code`` outside the constructor will also modify the value of
@@ -1172,7 +1172,7 @@ Attributes
 .. attribute:: StreamingHttpResponse.reason_phrase
 
     The HTTP reason phrase for the response. It uses the :rfc:`HTTP standard's
-    <7231#section-6.1>` default reason phrases.
+    <9110#section-15.1>` default reason phrases.
 
     Unless explicitly set, ``reason_phrase`` is determined by the value of
     :attr:`status_code`.

docs/ref/unicode.txt

@@ -146,7 +146,7 @@ URI and IRI handling
 Web frameworks have to deal with URLs (which are a type of IRI). One
 requirement of URLs is that they are encoded using only ASCII characters.
 However, in an international environment, you might need to construct a
-URL from an :rfc:`IRI <3987>` -- very loosely speaking, a :rfc:`URI <2396>`
+URL from an :rfc:`IRI <3987>` -- very loosely speaking, a :rfc:`URI <3986>`
 that can contain Unicode characters. Use these functions for quoting and
 converting an IRI to a URI:
 

docs/ref/utils.txt

@@ -21,7 +21,7 @@ by managing the ``Vary`` header of responses. It includes functions to patch
 the header of response objects directly and decorators that change functions to
 do that header-patching themselves.
 
-For information on the ``Vary`` header, see :rfc:`7231#section-7.1.4`.
+For information on the ``Vary`` header, see :rfc:`9110#section-12.5.5`.
 
 Essentially, the ``Vary`` HTTP header defines which headers a cache should take
 into account when building its cache key. Requests with the same path but
@@ -75,7 +75,7 @@ need to distinguish caches by the ``Accept-language`` header.
     Adds (or updates) the ``Vary`` header in the given ``HttpResponse`` object.
     ``newheaders`` is a list of header names that should be in ``Vary``. If
     headers contains an asterisk, then ``Vary`` header will consist of a single
-    asterisk ``'*'``, according to :rfc:`7231#section-7.1.4`. Otherwise,
+    asterisk ``'*'``, according to :rfc:`9110#section-12.5.5`. Otherwise,
     existing headers in ``Vary`` aren't removed.
 
 .. function:: get_cache_key(request, key_prefix=None, method='GET', cache=None)
@@ -721,7 +721,7 @@ escaping HTML.
 .. function:: http_date(epoch_seconds=None)
 
     Formats the time to match the :rfc:`1123#section-5.2.14` date format as
-    specified by HTTP :rfc:`7231#section-7.1.1.1`.
+    specified by HTTP :rfc:`9110#section-5.6.7`.
 
     Accepts a floating point number expressed in seconds since the epoch in
     UTC--such as that outputted by ``time.time()``. If set to ``None``,

docs/ref/views.txt

@@ -121,9 +121,9 @@ default, call the view ``django.views.defaults.permission_denied``.
 
 This view loads and renders the template ``403.html`` in your root template
 directory, or if this file does not exist, instead serves the text
-"403 Forbidden", as per :rfc:`7231#section-6.5.3` (the HTTP 1.1 Specification).
-The template context contains ``exception``, which is the string
-representation of the exception that triggered the view.
+"403 Forbidden", as per :rfc:`9110#section-15.5.4` (the HTTP 1.1
+Specification). The template context contains ``exception``, which is the
+string representation of the exception that triggered the view.
 
 ``django.views.defaults.permission_denied`` is triggered by a
 :exc:`~django.core.exceptions.PermissionDenied` exception. To deny access in a

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

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

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