Updated spelling and RFCs in HttpOnly cookie flag docs.

django/conf/global_settings.py

@@ -458,7 +458,7 @@ SESSION_COOKIE_DOMAIN = None
 SESSION_COOKIE_SECURE = False
 # The path of the session cookie.
 SESSION_COOKIE_PATH = '/'
-# Whether to use the non-RFC standard httpOnly flag (IE, FF3+, others)
+# Whether to use the HttpOnly flag.
 SESSION_COOKIE_HTTPONLY = True
 # Whether to set the flag restricting cookie leaks on cross-site requests.
 # This can be 'Lax', 'Strict', or None to disable the flag.

docs/ref/request-response.txt

@@ -802,18 +802,16 @@ Methods
     * Use ``httponly=True`` if you want to prevent client-side
       JavaScript from having access to the cookie.
 
-      HTTPOnly_ is a flag included in a Set-Cookie HTTP response
-      header. It is not part of the :rfc:`2109` standard for cookies,
-      and it isn't honored consistently by all browsers. However,
-      when it is honored, it can be a useful way to mitigate the
-      risk of a client-side script from accessing the protected cookie
+      HttpOnly_ is a flag included in a Set-Cookie HTTP response header. It's
+      part of the :rfc:`6265` standard for cookies and can be a useful way to
+      mitigate the risk of a client-side script accessing the protected cookie
       data.
     * Use ``samesite='Strict'`` or ``samesite='Lax'`` to tell the browser not
       to send this cookie when performing a cross-origin request. `SameSite`_
       isn't supported by all browsers, so it's not a replacement for Django's
       CSRF protection, but rather a defense in depth measure.
 
-    .. _HTTPOnly: https://www.owasp.org/index.php/HTTPOnly
+    .. _HttpOnly: https://www.owasp.org/index.php/HttpOnly
     .. _SameSite: https://www.owasp.org/index.php/SameSite
 
     .. warning::

docs/ref/settings.txt

@@ -2984,22 +2984,20 @@ This setting also affects cookies set by :mod:`django.contrib.messages`.
 
 Default: ``True``
 
-Whether to use ``HTTPOnly`` flag on the session cookie. If this is set to
-``True``, client-side JavaScript will not to be able to access the
-session cookie.
+Whether to use ``HttpOnly`` flag on the session cookie. If this is set to
+``True``, client-side JavaScript will not to be able to access the session
+cookie.
 
-HTTPOnly_ is a flag included in a Set-Cookie HTTP response header. It
-is not part of the :rfc:`2109` standard for cookies, and it isn't honored
-consistently by all browsers. However, when it is honored, it can be a
-useful way to mitigate the risk of a client side script accessing the
-protected cookie data.
+HttpOnly_ is a flag included in a Set-Cookie HTTP response header. It's part of
+the :rfc:`6265` standard for cookies and can be a useful way to mitigate the
+risk of a client-side script accessing the protected cookie data.
 
 This makes it less trivial for an attacker to escalate a cross-site scripting
 vulnerability into full hijacking of a user's session. There aren't many good
 reasons for turning this off. Your code shouldn't read session cookies from
 JavaScript.
 
-.. _HTTPOnly: https://www.owasp.org/index.php/HTTPOnly
+.. _HttpOnly: https://www.owasp.org/index.php/HttpOnly
 
 .. setting:: SESSION_COOKIE_NAME
 

docs/releases/1.3.txt

@@ -293,7 +293,7 @@ requests. These include:
 * Support for lookups spanning relations in admin's
   :attr:`~django.contrib.admin.ModelAdmin.list_filter`.
 
-* Support for HTTPOnly_ cookies.
+* Support for HttpOnly_ cookies.
 
 * :meth:`~django.core.mail.mail_admins()` and
   :meth:`~django.core.mail.mail_managers()` now support easily attaching
@@ -315,7 +315,7 @@ requests. These include:
 * Support for combining :class:`F expressions <django.db.models.F>`
   with ``timedelta`` values when retrieving or updating database values.
 
-.. _HTTPOnly: https://www.owasp.org/index.php/HTTPOnly
+.. _HttpOnly: https://www.owasp.org/index.php/HttpOnly
 
 .. _backwards-incompatible-changes-1.3: