[1.9.x] Fixed #26567 -- Updated references to obsolete RFC2616.

Didn't touch comments where it wasn't obvious that the code adhered to
the newer standard.

Backport of ac77c55bc5fc54cd763a7ae426784650a8cc97c9 from master

5 files changed, 18 insertions, 26 deletions

diff --git a/docs/ref/csrf.txt b/docs/ref/csrf.txt
index e5d32b27b3..f59b45646d 100644
--- a/docs/ref/csrf.txt
+++ b/docs/ref/csrf.txt
@@ -14,10 +14,9 @@ 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 9.1.1 Safe Methods, HTTP 1.1,
-:rfc:`2616#section-9.1.1`) are side-effect free. Requests via 'unsafe' methods,
-such as POST, PUT and DELETE, can then be protected by following the steps
-below.
+'safe' methods, as defined by :rfc:`7231#section-4.2.1`) are side effect free.
+Requests via 'unsafe' methods, such as POST, PUT, and DELETE, can then be
+protected by following the steps below.
 
 .. _Cross Site Request Forgeries: https://www.squarefree.com/securitytips/web-developers.html#CSRF
 
@@ -267,9 +266,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:`2616`). These requests ought never to have any potentially
+'safe' by :rfc:`7231`). 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:`2616` defines POST, PUT and DELETE as 'unsafe', and all other
+harmless. :rfc:`7231` defines POST, PUT, and DELETE as 'unsafe', and all other
 methods are also assumed to be unsafe, for maximum protection.
 
 The CSRF protection cannot protect against man-in-the-middle attacks, so use
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index b215cae761..92dbe803b6 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -1733,9 +1733,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
-`Safe methods`_ in the HTTP spec.
-
-.. _Safe methods: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1
+:rfc:`Safe methods <7231#section-4.2.1>` in the HTTP spec.
 
 .. warning::
 
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
index 41c2eafd59..5d9325fffe 100644
--- a/docs/ref/request-response.txt
+++ b/docs/ref/request-response.txt
@@ -673,7 +673,7 @@ Attributes
 
 .. attribute:: HttpResponse.status_code
 
-    The `HTTP status code`_ for the response.
+    The :rfc:`HTTP status code <7231#section-6>` for the response.
 
     .. versionchanged:: 1.9
 
@@ -688,9 +688,8 @@ Attributes
     .. versionchanged:: 1.9
 
         ``reason_phrase`` no longer defaults to all capital letters. It now
-        uses the `HTTP standard's`_ default reason phrases.
-
-        .. _`HTTP standard's`: https://www.ietf.org/rfc/rfc2616.txt
+        uses the :rfc:`HTTP standard's <7231#section-6.1>` default reason
+        phrases.
 
         Unless explicitly set, ``reason_phrase`` is determined by the current
         value of :attr:`status_code`.
@@ -727,7 +726,7 @@ Methods
     specified, it is formed by the :setting:`DEFAULT_CONTENT_TYPE` and
     :setting:`DEFAULT_CHARSET` settings, by default: "`text/html; charset=utf-8`".
 
-    ``status`` is the `HTTP status code`_ for the response.
+    ``status`` is the :rfc:`HTTP status code <7231#section-6>` for the response.
 
     ``reason`` is the HTTP response phrase. If not provided, a default phrase
     will be used.
@@ -853,8 +852,6 @@ Methods
     Writes a list of lines to the response. Line separators are not added. This
     method makes an :class:`HttpResponse` instance a stream-like object.
 
-.. _HTTP status code: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10
-
 .. _ref-httpresponse-subclasses:
 
 ``HttpResponse`` subclasses
@@ -1045,7 +1042,7 @@ Attributes
 
 .. attribute:: StreamingHttpResponse.status_code
 
-    The `HTTP status code`_ for the response.
+    The :rfc:`HTTP status code <7231#section-6>` for the response.
 
     .. versionchanged:: 1.9
 
@@ -1060,9 +1057,8 @@ Attributes
     .. versionchanged:: 1.9
 
         ``reason_phrase`` no longer defaults to all capital letters. It now
-        uses the `HTTP standard's`_ default reason phrases.
-
-        .. _`HTTP standard's`: https://www.ietf.org/rfc/rfc2616.txt
+        uses the :rfc:`HTTP standard's <7231#section-6.1>` default reason
+        phrases.
 
         Unless explicitly set, ``reason_phrase`` is determined by the current
         value of :attr:`status_code`.
diff --git a/docs/ref/utils.txt b/docs/ref/utils.txt
index a763fdc639..ee3054f181 100644
--- a/docs/ref/utils.txt
+++ b/docs/ref/utils.txt
@@ -21,8 +21,7 @@ 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:`2616#section-14.44` section
-14.44.
+For information on the ``Vary`` header, see :rfc:`7231#section-7.1.4`.
 
 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
@@ -739,7 +738,7 @@ escaping HTML.
 .. function:: http_date(epoch_seconds=None)
 
     Formats the time to match the :rfc:`1123` date format as specified by HTTP
-    :rfc:`2616#section-3.3.1` section 3.3.1.
+    :rfc:`7231#section-7.1.1.1`.
 
     Accepts a floating point number expressed in seconds since the epoch in
     UTC--such as that outputted by ``time.time()``. If set to ``None``,
diff --git a/docs/ref/views.txt b/docs/ref/views.txt
index fb3918064d..4f9b36b911 100644
--- a/docs/ref/views.txt
+++ b/docs/ref/views.txt
@@ -126,9 +126,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:`2616` (the HTTP 1.1 Specification). The template
-context contains ``exception``, which is the unicode representation of the
-exception that triggered the view.
+"403 Forbidden", as per :rfc:`7231#section-6.5.3` (the HTTP 1.1 Specification).
+The template context contains ``exception``, which is the unicode
+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