From ac77c55bc5fc54cd763a7ae426784650a8cc97c9 Mon Sep 17 00:00:00 2001
From: Vasiliy Faronov <vfaronov@gmail.com>
Date: Mon, 2 May 2016 15:35:05 +0300
Subject: [PATCH] Fixed #26567 -- Updated references to obsolete RFC2616.

Didn't touch comments where it wasn't obvious that the code adhered to
the newer standard.
---
 django/middleware/csrf.py                   |  2 +-
 django/test/client.py                       |  2 +-
 django/utils/cache.py                       |  2 +-
 django/utils/http.py                        |  6 +++---
 django/views/defaults.py                    |  2 +-
 docs/ref/csrf.txt                           | 11 +++++------
 docs/ref/models/querysets.txt               |  4 +---
 docs/ref/request-response.txt               | 18 +++++++-----------
 docs/ref/utils.txt                          |  5 ++---
 docs/ref/views.txt                          |  6 +++---
 docs/topics/cache.txt                       | 10 ++++------
 docs/topics/conditional-view-processing.txt | 10 +++++-----
 docs/topics/testing/tools.txt               | 10 ++++++----
 13 files changed, 40 insertions(+), 48 deletions(-)

diff --git a/django/middleware/csrf.py b/django/middleware/csrf.py
index 823fa46047..f2d6a49708 100644
--- a/django/middleware/csrf.py
+++ b/django/middleware/csrf.py
@@ -123,7 +123,7 @@ class CsrfViewMiddleware(object):
         if getattr(callback, 'csrf_exempt', False):
             return None
 
-        # Assume that anything not defined as 'safe' by RFC2616 needs protection
+        # Assume that anything not defined as 'safe' by RFC7231 needs protection
         if request.method not in ('GET', 'HEAD', 'OPTIONS', 'TRACE'):
             if getattr(request, '_dont_enforce_csrf_checks', False):
                 # Mechanism to turn off CSRF checks for test suite.
diff --git a/django/test/client.py b/django/test/client.py
index 0dfd2b5383..e6a3650701 100644
--- a/django/test/client.py
+++ b/django/test/client.py
@@ -96,7 +96,7 @@ def conditional_content_removal(request, response):
     """
     Simulate the behavior of most Web servers by removing the content of
     responses for HEAD requests, 1xx, 204, and 304 responses. Ensures
-    compliance with RFC 2616, section 4.3.
+    compliance with RFC 7230, section 3.3.3.
     """
     if 100 <= response.status_code < 200 or response.status_code in (204, 304):
         if response.streaming:
diff --git a/django/utils/cache.py b/django/utils/cache.py
index be1626a263..ad732327e8 100644
--- a/django/utils/cache.py
+++ b/django/utils/cache.py
@@ -6,7 +6,7 @@ that header-patching themselves.
 
 For information on the Vary header, see:
 
-    http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44
+    https://tools.ietf.org/html/rfc7231#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
diff --git a/django/utils/http.py b/django/utils/http.py
index 6c55314096..31de726184 100644
--- a/django/utils/http.py
+++ b/django/utils/http.py
@@ -109,7 +109,7 @@ def cookie_date(epoch_seconds=None):
 def http_date(epoch_seconds=None):
     """
     Formats the time to match the RFC1123 date format as specified by HTTP
-    RFC2616 section 3.3.1.
+    RFC7231 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, defaults to
@@ -122,7 +122,7 @@ def http_date(epoch_seconds=None):
 
 def parse_http_date(date):
     """
-    Parses a date format as specified by HTTP RFC2616 section 3.3.1.
+    Parses a date format as specified by HTTP RFC7231 section 7.1.1.1.
 
     The three formats allowed by the RFC are accepted, even if only the first
     one is still in widespread use.
@@ -130,7 +130,7 @@ def parse_http_date(date):
     Returns an integer expressed in seconds since the epoch, in UTC.
     """
     # emails.Util.parsedate does the job for RFC1123 dates; unfortunately
-    # RFC2616 makes it mandatory to support RFC850 dates too. So we roll
+    # RFC7231 makes it mandatory to support RFC850 dates too. So we roll
     # our own RFC-compliant parsing.
     for regex in RFC1123_DATE, RFC850_DATE, ASCTIME_DATE:
         m = regex.match(date)
diff --git a/django/views/defaults.py b/django/views/defaults.py
index 838e5c1f85..348837ed99 100644
--- a/django/views/defaults.py
+++ b/django/views/defaults.py
@@ -105,7 +105,7 @@ def permission_denied(request, exception, template_name=ERROR_403_TEMPLATE_NAME)
     Context: None
 
     If the template does not exist, an Http403 response containing the text
-    "403 Forbidden" (as per RFC 2616) will be returned.
+    "403 Forbidden" (as per RFC 7231) will be returned.
     """
     try:
         template = loader.get_template(template_name)
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 f8a2f10f7c..938ff87cab 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -1723,9 +1723,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 a1be4d64b9..8ff1d14a4a 100644
--- a/docs/ref/request-response.txt
+++ b/docs/ref/request-response.txt
@@ -685,7 +685,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
 
@@ -700,9 +700,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`.
@@ -737,7 +736,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.
@@ -865,8 +864,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
@@ -1057,7 +1054,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
 
@@ -1072,9 +1069,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 202cbb4c12..ed6869e21b 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
@@ -736,7 +735,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 d0dc595464..61d226dc77 100644
--- a/docs/ref/views.txt
+++ b/docs/ref/views.txt
@@ -134,9 +134,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
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index b0bf37c94c..484a76ab68 100644
--- a/docs/topics/cache.txt
+++ b/docs/topics/cache.txt
@@ -1127,9 +1127,8 @@ directly. This function sets, or adds to, the ``Vary header``. For example::
 its first argument and a list/tuple of case-insensitive header names as its
 second argument.
 
-For more on Vary headers, see the `official Vary spec`_.
-
-.. _`official Vary spec`: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44
+For more on Vary headers, see the :rfc:`official Vary spec
+<7231#section-7.1.4>`.
 
 Controlling cache: Using other headers
 ======================================
@@ -1211,7 +1210,8 @@ Here's a full list:
 * ``max_age=num_seconds``
 * ``s_maxage=num_seconds``
 
-For explanation of Cache-Control HTTP directives, see the `Cache-Control spec`_.
+For explanation of Cache-Control HTTP directives, see the :rfc:`Cache-Control
+spec <7234#section-5.2>`.
 
 (Note that the caching middleware already sets the cache header's max-age with
 the value of the :setting:`CACHE_MIDDLEWARE_SECONDS` setting. If you use a custom
@@ -1229,8 +1229,6 @@ Example::
     def myview(request):
         # ...
 
-.. _`Cache-Control spec`: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
-
 Order of ``MIDDLEWARE_CLASSES``
 ===============================
 
diff --git a/docs/topics/conditional-view-processing.txt b/docs/topics/conditional-view-processing.txt
index 742926e759..19cfae3fb1 100644
--- a/docs/topics/conditional-view-processing.txt
+++ b/docs/topics/conditional-view-processing.txt
@@ -25,10 +25,10 @@ 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.
 
-.. _If-match: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24
-.. _If-none-match: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26
-.. _If-modified-since: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25
-.. _If-unmodified-since: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.28
+.. _If-match: https://tools.ietf.org/html/rfc7232#section-3.1
+.. _If-none-match: https://tools.ietf.org/html/rfc7232#section-3.2
+.. _If-modified-since: https://tools.ietf.org/html/rfc7232#section-3.3
+.. _If-unmodified-since: https://tools.ietf.org/html/rfc7232#section-3.4
 
 When you need more fine-grained control you may use per-view conditional
 processing functions.
@@ -45,7 +45,7 @@ functions to provide an "early bailout" option for the view processing.
 Telling the client that the content has not been modified since the last
 request, perhaps.
 
-.. _ETag: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11
+.. _ETag: https://tools.ietf.org/html/rfc7232#section-2.3
 
 These two functions are passed as parameters the
 ``django.views.decorators.http.condition`` decorator. This decorator uses
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index 722debcc91..042608efbd 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -321,8 +321,8 @@ 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:`2616`, which mandates that
-        TRACE requests should not have an entity-body.
+        parameter in order to comply with :rfc:`7231#section-4.3.8`, which
+        mandates that TRACE requests must not have a body.
 
         The ``follow``, ``secure``, and ``extra`` arguments act the same as for
         :meth:`Client.get`.
@@ -484,8 +484,10 @@ Specifically, a ``Response`` object has the following attributes:
 
     .. attribute:: status_code
 
-        The HTTP status of the response, as an integer. See
-        :rfc:`2616#section-10` for a full list of HTTP status codes.
+        The HTTP status of the response, as an integer. For a full list
+        of defined codes, see the `IANA status code registry`_.
+
+        .. _IANA status code registry: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml
 
     .. attribute:: templates