Fixed #26567 -- Updated references to obsolete RFC2616.

Didn't touch comments where it wasn't obvious that the code adhered to
the newer standard.
This commit is contained in:
Vasiliy Faronov 2016-05-02 15:35:05 +03:00 committed by Tim Graham
parent fb68674ea4
commit ac77c55bc5
13 changed files with 40 additions and 48 deletions

View file

@ -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

View file

@ -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::

View file

@ -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`.

View file

@ -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``,

View file

@ -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