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