draft-ietf-httpbis-rfc6265bis-20.txt | draft-ietf-httpbis-rfc6265bis-latest.txt | |||
---|---|---|---|---|
HTTP Working Group S. Bingler, Ed. | HTTP Working Group S. Bingler, Ed. | |||
Internet-Draft M. West, Ed. | Internet-Draft | |||
Obsoletes: 6265 (if approved) Google LLC | Obsoletes: 6265 (if approved) M. West, Ed. | |||
Intended status: Standards Track J. Wilander, Ed. | Intended status: Standards Track Google LLC | |||
Expires: September 18, 2025 Apple, Inc | Expires: January 14, 2026 J. Wilander, Ed. | |||
March 17, 2025 | Apple, Inc | |||
July 13, 2025 | ||||
Cookies: HTTP State Management Mechanism | Cookies: HTTP State Management Mechanism | |||
draft-ietf-httpbis-rfc6265bis-20 | draft-ietf-httpbis-rfc6265bis-latest | |||
Abstract | Abstract | |||
This document defines the HTTP Cookie and Set-Cookie header fields. | This document defines the HTTP Cookie and Set-Cookie header fields. | |||
These header fields can be used by HTTP servers to store state | These header fields can be used by HTTP servers to store state | |||
(called cookies) at HTTP user agents, letting the servers maintain a | (called cookies) at HTTP user agents, letting the servers maintain a | |||
stateful session over the mostly stateless HTTP protocol. Although | stateful session over the mostly stateless HTTP protocol. Although | |||
cookies have many historical infelicities that degrade their security | cookies have many historical infelicities that degrade their security | |||
and privacy, the Cookie and Set-Cookie header fields are widely used | and privacy, the Cookie and Set-Cookie header fields are widely used | |||
on the Internet. This document obsoletes RFC 6265. | on the Internet. This document obsoletes RFC 6265. | |||
skipping to change at page 2, line 7 ¶ | skipping to change at page 2, line 10 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on September 18, 2025. | This Internet-Draft will expire on January 14, 2026. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2025 IETF Trust and the persons identified as the | Copyright (c) 2025 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 4, line 14 ¶ | skipping to change at page 4, line 16 ¶ | |||
8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 52 | 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 52 | |||
8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 52 | 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 52 | |||
8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 53 | 8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 53 | |||
8.8.6. Top-level requests with "unsafe" methods . . . . . . 53 | 8.8.6. Top-level requests with "unsafe" methods . . . . . . 53 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 | |||
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 54 | 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 54 | 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
9.3. "Cookie Attributes" Registry . . . . . . . . . . . . . . 55 | 9.3. "Cookie Attributes" Registry . . . . . . . . . . . . . . 55 | |||
9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 55 | 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 55 | |||
9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 55 | 9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 55 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 56 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 56 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 57 | 10.2. Informative References . . . . . . . . . . . . . . . . . 57 | |||
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59 | 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59 | |||
Appendix A. Changes from RFC 6265 . . . . . . . . . . . . . . . 59 | Appendix A. Changes from RFC 6265 . . . . . . . . . . . . . . . 59 | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 60 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 60 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 | |||
1. Introduction | 1. Introduction | |||
This document defines the HTTP Cookie and Set-Cookie header fields. | This document defines the HTTP Cookie and Set-Cookie header fields. | |||
skipping to change at page 5, line 38 ¶ | skipping to change at page 5, line 38 ¶ | |||
2.1. Conformance Criteria | 2.1. Conformance Criteria | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
Requirements phrased in the imperative as part of algorithms (such as | Requirements phrased in the imperative as part of algorithms (such as | |||
"strip any leading space characters" or "return false and abort these | "strip any leading space characters" or "return false and abort this | |||
steps") are to be interpreted with the meaning of the key word | algorithm") are to be interpreted with the meaning of the key word | |||
("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm. | ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm. | |||
Conformance requirements phrased as algorithms or specific steps can | Conformance requirements phrased as algorithms or specific steps can | |||
be implemented in any manner, so long as the end result is | be implemented in any manner, so long as the end result is | |||
equivalent. In particular, the algorithms defined in this | equivalent. In particular, the algorithms defined in this | |||
specification are intended to be easy to understand and are not | specification are intended to be easy to understand and are not | |||
intended to be performant. | intended to be performant. | |||
2.2. Syntax Notation | 2.2. Syntax Notation | |||
skipping to change at page 6, line 20 ¶ | skipping to change at page 6, line 20 ¶ | |||
(horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible | (horizontal tab), CHAR (any [USASCII] character), VCHAR (any visible | |||
[USASCII] character), and WSP (whitespace). | [USASCII] character), and WSP (whitespace). | |||
The OWS (optional whitespace) and BWS (bad whitespace) rules are | The OWS (optional whitespace) and BWS (bad whitespace) rules are | |||
defined in Section 5.6.3 of [HTTP]. | defined in Section 5.6.3 of [HTTP]. | |||
2.3. Terminology | 2.3. Terminology | |||
The terms "user agent", "client", "server", "proxy", and "origin | The terms "user agent", "client", "server", "proxy", and "origin | |||
server" have the same meaning as in the HTTP/1.1 specification | server" have the same meaning as in the HTTP/1.1 specification | |||
([HTTP], Section 3). | (Section 3 of [HTTP]). | |||
The request-host is the name of the host, as known by the user agent, | The request-host is the name of the host, as known by the user agent, | |||
to which the user agent is sending an HTTP request or from which it | to which the user agent is sending an HTTP request or from which it | |||
is receiving an HTTP response (i.e., the name of the host to which it | is receiving an HTTP response (i.e., the name of the host to which it | |||
sent the corresponding HTTP request). | sent the corresponding HTTP request). | |||
The term request-uri refers to "target URI" as defined in Section 7.1 | The term request-uri refers to "target URI" as defined in Section 7.1 | |||
of [HTTP]. | of [HTTP]. | |||
Two sequences of octets are said to case-insensitively match each | Two sequences of octets are said to case-insensitively match each | |||
other if and only if they are equivalent under the i;ascii-casemap | other if and only if they are equivalent under the i;ascii-casemap | |||
collation defined in [RFC4790]. | collation defined in [RFC4790]. | |||
The term string means a sequence of non-NUL octets. | The term string means a sequence of non-NUL octets. | |||
The terms "active browsing context", "active document", "ancestor | The terms "active browsing context", "active document", "ancestor | |||
navigables", "container document", "content navigable", "dedicated | navigables", "container document", "content navigable", "dedicated | |||
worker", "Document", "inclusive ancestor navigables", "navigable", | worker", "Document", "inclusive ancestor navigables", "navigable", | |||
"opaque origin", "sandboxed origin browsing context flag", "shared | "navigate", "opaque origin", "sandboxed origin browsing context | |||
worker", "the worker's Documents", "top-level traversable", and | flag", "shared worker", "the worker's Documents", "top-level | |||
"WorkerGlobalScope" are defined in [HTML]. | traversable", and "WorkerGlobalScope" are defined in [HTML]. | |||
"Service Workers" are defined in the Service Workers specification | "Service Workers" are defined in the Service Workers specification | |||
[SERVICE-WORKERS]. | [SERVICE-WORKERS]. | |||
The term "origin", the mechanism of deriving an origin from a URI, | The term "origin", the mechanism of deriving an origin from a URI, | |||
and the "the same" matching algorithm for origins are defined in | and the "the same" matching algorithm for origins are defined in | |||
[RFC6454]. | [RFC6454]. | |||
"Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as | "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as | |||
defined in Section 9.2.1 of [HTTP]. | defined in Section 9.2.1 of [HTTP]. | |||
skipping to change at page 13, line 24 ¶ | skipping to change at page 13, line 24 ¶ | |||
To maximize compatibility with user agents, servers that wish to | To maximize compatibility with user agents, servers that wish to | |||
store arbitrary data in a cookie-value SHOULD encode that data, for | store arbitrary data in a cookie-value SHOULD encode that data, for | |||
example, using Base64 [RFC4648]. | example, using Base64 [RFC4648]. | |||
Per the grammar above, the cookie-value MAY be wrapped in DQUOTE | Per the grammar above, the cookie-value MAY be wrapped in DQUOTE | |||
characters. Note that in this case, the initial and trailing DQUOTE | characters. Note that in this case, the initial and trailing DQUOTE | |||
characters are not stripped. They are part of the cookie-value, and | characters are not stripped. They are part of the cookie-value, and | |||
will be included in Cookie header fields sent to the server. | will be included in Cookie header fields sent to the server. | |||
The domain-value is a subdomain as defined by [RFC1034], Section 3.5, | The domain-value is a subdomain as defined by Section 3.5 of | |||
and as enhanced by [RFC1123], Section 2.1. Thus, domain-value is a | [RFC1034], and as enhanced by Section 2.1 of [RFC1123]. Thus, | |||
string of [USASCII] characters, such as an "A-label" as defined in | domain-value is a string of [USASCII] characters, such as an | |||
Section 2.3.2.1 of [RFC5890]. | "A-label" as defined in Section 2.3.2.1 of [RFC5890]. | |||
The portions of the set-cookie-string produced by the cookie-av term | The portions of the set-cookie-string produced by the cookie-av term | |||
are known as attributes. To maximize compatibility with user agents, | are known as attributes. To maximize compatibility with user agents, | |||
servers MUST NOT produce two attributes with the same name in the | servers MUST NOT produce two attributes with the same name in the | |||
same set-cookie-string. (See Section 5.7 for how user agents handle | same set-cookie-string. (See Section 5.7 for how user agents handle | |||
this case.) | this case.) | |||
NOTE: The name of an attribute-value pair is not case-sensitive. So | Note: The name of an attribute-value pair is not case-sensitive. So | |||
while they are presented here in CamelCase, such as "HttpOnly" or | while they are presented here in CamelCase, such as "HttpOnly" or | |||
"SameSite", any case is accepted. E.x.: "httponly", "Httponly", | "SameSite", any case is accepted. E.x.: "httponly", "Httponly", | |||
"hTTPoNLY", etc. | "hTTPoNLY", etc. | |||
Servers MUST NOT include more than one Set-Cookie header field in the | Servers MUST NOT include more than one Set-Cookie header field in the | |||
same response with the same cookie-name. (See Section 5.6 for how | same response with the same cookie-name. (See Section 5.6 for how | |||
user agents handle this case.) | user agents handle this case.) | |||
If a server sends multiple responses containing Set-Cookie header | If a server sends multiple responses containing Set-Cookie header | |||
fields concurrently to the user agent (e.g., when communicating with | fields concurrently to the user agent (e.g., when communicating with | |||
the user agent over multiple sockets), these responses create a "race | the user agent over multiple sockets), these responses create a "race | |||
condition" that can lead to unpredictable behavior. | condition" that can lead to unpredictable behavior. | |||
NOTE: Some existing user agents differ in their interpretation of | Note: Some existing user agents differ in their interpretation of | |||
two-digit years. To avoid compatibility issues, servers SHOULD use | two-digit years. To avoid compatibility issues, servers SHOULD use | |||
the rfc1123-date format, which requires a four-digit year. | the rfc1123-date format, which requires a four-digit year. | |||
NOTE: Some user agents store and process dates in cookies as 32-bit | Note: Some user agents store and process dates in cookies as 32-bit | |||
UNIX time_t values. Implementation bugs in the libraries supporting | UNIX time_t values. Implementation bugs in the libraries supporting | |||
time_t processing on some systems might cause such user agents to | time_t processing on some systems might cause such user agents to | |||
process dates after the year 2038 incorrectly. | process dates after the year 2038 incorrectly. | |||
4.1.2. Semantics (Non-Normative) | 4.1.2. Semantics (Non-Normative) | |||
This section describes simplified semantics of the Set-Cookie header | This section describes simplified semantics of the Set-Cookie header | |||
field. These semantics are detailed enough to be useful for | field. These semantics are detailed enough to be useful for | |||
understanding the most common uses of cookies by servers. The full | understanding the most common uses of cookies by servers. The full | |||
semantics are described in Section 5. | semantics are described in Section 5. | |||
skipping to change at page 14, line 50 ¶ | skipping to change at page 14, line 50 ¶ | |||
often evict cookies due to memory pressure or privacy concerns. | often evict cookies due to memory pressure or privacy concerns. | |||
4.1.2.2. The Max-Age Attribute | 4.1.2.2. The Max-Age Attribute | |||
The Max-Age attribute indicates the maximum lifetime of the cookie, | The Max-Age attribute indicates the maximum lifetime of the cookie, | |||
represented as the number of seconds until the cookie expires. The | represented as the number of seconds until the cookie expires. The | |||
user agent may adjust the specified duration and is not required to | user agent may adjust the specified duration and is not required to | |||
retain the cookie for that duration. In fact, user agents often | retain the cookie for that duration. In fact, user agents often | |||
evict cookies due to memory pressure or privacy concerns. | evict cookies due to memory pressure or privacy concerns. | |||
NOTE: Some existing user agents do not support the Max-Age attribute. | Note: Some existing user agents do not support the Max-Age attribute. | |||
User agents that do not support the Max-Age attribute ignore the | User agents that do not support the Max-Age attribute ignore the | |||
attribute. | attribute. | |||
If a cookie has both the Max-Age and the Expires attribute, the Max- | If a cookie has both the Max-Age and the Expires attribute, the Max- | |||
Age attribute has precedence and controls the expiration date of the | Age attribute has precedence and controls the expiration date of the | |||
cookie. If a cookie has neither the Max-Age nor the Expires | cookie. If a cookie has neither the Max-Age nor the Expires | |||
attribute, the user agent will retain the cookie until "the current | attribute, the user agent will retain the cookie until "the current | |||
session is over" (as defined by the user agent). | session is over" (as defined by the user agent). | |||
4.1.2.3. The Domain Attribute | 4.1.2.3. The Domain Attribute | |||
skipping to change at page 15, line 35 ¶ | skipping to change at page 15, line 35 ¶ | |||
field without a Domain attribute, these user agents will erroneously | field without a Domain attribute, these user agents will erroneously | |||
send the cookie to www.site.example as well. | send the cookie to www.site.example as well. | |||
The user agent will reject cookies unless the Domain attribute | The user agent will reject cookies unless the Domain attribute | |||
specifies a scope for the cookie that would include the origin | specifies a scope for the cookie that would include the origin | |||
server. For example, the user agent will accept a cookie with a | server. For example, the user agent will accept a cookie with a | |||
Domain attribute of "site.example" or of "foo.site.example" from | Domain attribute of "site.example" or of "foo.site.example" from | |||
foo.site.example, but the user agent will not accept a cookie with a | foo.site.example, but the user agent will not accept a cookie with a | |||
Domain attribute of "bar.site.example" or of "baz.foo.site.example". | Domain attribute of "bar.site.example" or of "baz.foo.site.example". | |||
NOTE: For security reasons, many user agents are configured to reject | Note: For security reasons, many user agents are configured to reject | |||
Domain attributes that correspond to "public suffixes". For example, | Domain attributes that correspond to "public suffixes". For example, | |||
some user agents will reject Domain attributes of "com" or "co.uk". | some user agents will reject Domain attributes of "com" or "co.uk". | |||
(See Section 5.7 for more information.) | (See Section 5.7 for more information.) | |||
4.1.2.4. The Path Attribute | 4.1.2.4. The Path Attribute | |||
The scope of each cookie is limited to a set of paths, controlled by | The scope of each cookie is limited to a set of paths, controlled by | |||
the Path attribute. If the server omits the Path attribute, the user | the Path attribute. If the server omits the Path attribute, the user | |||
agent will use the "directory" of the request-uri's path component as | agent will use the "directory" of the request-uri's path component as | |||
the default value. (See Section 5.1.4 for more details.) | the default value. (See Section 5.1.4 for more details.) | |||
skipping to change at page 18, line 40 ¶ | skipping to change at page 18, line 40 ¶ | |||
Cookie header field. If the server conforms to the requirements in | Cookie header field. If the server conforms to the requirements in | |||
Section 4.1 (and the user agent conforms to the requirements in | Section 4.1 (and the user agent conforms to the requirements in | |||
Section 5), the user agent will send a Cookie header field that | Section 5), the user agent will send a Cookie header field that | |||
conforms to the following grammar: | conforms to the following grammar: | |||
cookie = cookie-string | cookie = cookie-string | |||
cookie-string = cookie-pair *( ";" SP cookie-pair ) | cookie-string = cookie-pair *( ";" SP cookie-pair ) | |||
While Section 5.4 of [HTTP] does not define a length limit for header | While Section 5.4 of [HTTP] does not define a length limit for header | |||
fields it is likely that the web server's implementation does impose | fields it is likely that the web server's implementation does impose | |||
a limit; many popular implementations have default limits of 8K. | a limit; many popular implementations have default limits of 8192 | |||
Servers SHOULD avoid setting a large number of large cookies such | octets. Servers SHOULD avoid setting a large number of large cookies | |||
that the final cookie-string would exceed their header field limit. | such that the final cookie-string would exceed their header field | |||
Not doing so could result in requests to the server failing. | limit. Not doing so could result in requests to the server failing. | |||
Servers MUST be tolerant of multiple cookie headers. For example, an | Servers MUST be tolerant of multiple cookie headers. For example, an | |||
HTTP/2 [RFC9113] or HTTP/3 [RFC9114] client or intermediary might | HTTP/2 [RFC9113] or HTTP/3 [RFC9114] client or intermediary might | |||
split a cookie header to improve compression. Servers are free to | split a cookie header to improve compression. Servers are free to | |||
determine what form this tolerance takes. For example, the server | determine what form this tolerance takes. For example, the server | |||
could process each cookie header individually or the server could | could process each cookie header individually or the server could | |||
concatenate all the cookie headers into one and then process that | concatenate all the cookie headers into one and then process that | |||
final, single, header. The server should be mindful of any header | final, single, header. The server should be mindful of any header | |||
field limits when deciding which approach to take. | field limits when deciding which approach to take. | |||
skipping to change at page 21, line 21 ¶ | skipping to change at page 21, line 21 ¶ | |||
the year production, set the found-year flag and set the | the year production, set the found-year flag and set the | |||
year-value to the number denoted by the date-token. Skip the | year-value to the number denoted by the date-token. Skip the | |||
remaining sub-steps and continue to the next date-token. | remaining sub-steps and continue to the next date-token. | |||
3. If the year-value is greater than or equal to 70 and less than or | 3. If the year-value is greater than or equal to 70 and less than or | |||
equal to 99, increment the year-value by 1900. | equal to 99, increment the year-value by 1900. | |||
4. If the year-value is greater than or equal to 0 and less than or | 4. If the year-value is greater than or equal to 0 and less than or | |||
equal to 69, increment the year-value by 2000. | equal to 69, increment the year-value by 2000. | |||
1. NOTE: Some existing user agents interpret two-digit years | 1. Note: Some existing user agents interpret two-digit years | |||
differently. | differently. | |||
5. Abort these steps and fail to parse the cookie-date if: | 5. Abort this algorithm and fail to parse the cookie-date if: | |||
* at least one of the found-day-of-month, found-month, found- | * at least one of the found-day-of-month, found-month, found- | |||
year, or found-time flags is not set, | year, or found-time flags is not set, | |||
* the day-of-month-value is less than 1 or greater than 31, | * the day-of-month-value is less than 1 or greater than 31, | |||
* the year-value is less than 1601, | * the year-value is less than 1601, | |||
* the hour-value is greater than 23, | * the hour-value is greater than 23, | |||
* the minute-value is greater than 59, or | * the minute-value is greater than 59, or | |||
* the second-value is greater than 59. | * the second-value is greater than 59. | |||
(Note that leap seconds cannot be represented in this syntax.) | (Note that leap seconds cannot be represented in this syntax.) | |||
6. Let the parsed-cookie-date be the date whose day-of-month, month, | 6. Let the parsed-cookie-date be the date whose day-of-month, month, | |||
year, hour, minute, and second (in UTC) are the day-of-month- | year, hour, minute, and second (in UTC) are the day-of-month- | |||
value, the month-value, the year-value, the hour-value, the | value, the month-value, the year-value, the hour-value, the | |||
minute-value, and the second-value, respectively. If no such | minute-value, and the second-value, respectively. If no such | |||
date exists, abort these steps and fail to parse the cookie-date. | date exists, abort this algorithm and fail to parse the cookie- | |||
date. | ||||
7. Return the parsed-cookie-date as the result of this algorithm. | 7. Return the parsed-cookie-date as the result of this algorithm. | |||
5.1.2. Canonicalized Host Names | 5.1.2. Canonicalized Host Names | |||
A canonicalized host name is the string generated by the following | A canonicalized host name is the string generated by the following | |||
algorithm: | algorithm: | |||
1. Convert the host name to a sequence of individual domain name | 1. Convert the host name to a sequence of individual domain name | |||
labels. | labels. | |||
skipping to change at page 27, line 9 ¶ | skipping to change at page 27, line 9 ¶ | |||
Set-Cookie: __SeCuRe-SID=evil | Set-Cookie: __SeCuRe-SID=evil | |||
The next time a user visits the site the UA will send both cookies: | The next time a user visits the site the UA will send both cookies: | |||
Cookie: __Secure-SID=12345; __SeCuRe-SID=evil | Cookie: __Secure-SID=12345; __SeCuRe-SID=evil | |||
The server, being case-insensitive, won't be able to tell the | The server, being case-insensitive, won't be able to tell the | |||
difference between the two cookies allowing the attacker to | difference between the two cookies allowing the attacker to | |||
compromise the site. | compromise the site. | |||
To prevent these issues, UAs MUST match cookie name prefixes case- | To prevent these issues, UAs MUST match cookie name prefixes case- | |||
insensitive. | insensitively. | |||
Note: Cookies with different names are still considered separate by | Note: Cookies with different names are still considered separate by | |||
UAs. So both "__Secure-foo=bar" and "__secure-foo=baz" can exist as | UAs. So both "__Secure-foo=bar" and "__secure-foo=baz" can exist as | |||
distinct cookies simultaneously and both would have the requirements | distinct cookies simultaneously and both would have the requirements | |||
of the "__Secure-" prefix applied. | of the "__Secure-" prefix applied. | |||
The following are examples of "Set-Cookie" header fields that would | The following are examples of "Set-Cookie" header fields that would | |||
be rejected by a conformant user agent. | be rejected by a conformant user agent. | |||
Set-Cookie: __Secure-SID=12345; Domain=site.example | Set-Cookie: __Secure-SID=12345; Domain=site.example | |||
skipping to change at page 28, line 15 ¶ | skipping to change at page 28, line 15 ¶ | |||
5.6. The Set-Cookie Header Field | 5.6. The Set-Cookie Header Field | |||
When a user agent receives a Set-Cookie header field in an HTTP | When a user agent receives a Set-Cookie header field in an HTTP | |||
response, the user agent MAY ignore the Set-Cookie header field in | response, the user agent MAY ignore the Set-Cookie header field in | |||
its entirety (see Section 5.3). | its entirety (see Section 5.3). | |||
If the user agent does not ignore the Set-Cookie header field in its | If the user agent does not ignore the Set-Cookie header field in its | |||
entirety, the user agent MUST parse the field-value of the Set-Cookie | entirety, the user agent MUST parse the field-value of the Set-Cookie | |||
header field as a set-cookie-string (defined below). | header field as a set-cookie-string (defined below). | |||
NOTE: The algorithm below is more permissive than the grammar in | Note: The algorithm below is more permissive than the grammar in | |||
Section 4.1. For example, the algorithm allows cookie-name to be | Section 4.1. For example, the algorithm allows cookie-name to be | |||
comprised of cookie-octets instead of being a token as specified in | comprised of cookie-octets instead of being a token as specified in | |||
Section 4.1 and the algorithm accommodates some characters that are | Section 4.1 and the algorithm accommodates some characters that are | |||
not cookie-octets according to the grammar in Section 4.1. In | not cookie-octets according to the grammar in Section 4.1. In | |||
addition, the algorithm below also strips leading and trailing | addition, the algorithm below also strips leading and trailing | |||
whitespace from the cookie name and value (but maintains internal | whitespace from the cookie name and value (but maintains internal | |||
whitespace), whereas the grammar in Section 4.1 forbids whitespace in | whitespace), whereas the grammar in Section 4.1 forbids whitespace in | |||
these positions. User agents use this algorithm so as to | these positions. User agents use this algorithm so as to | |||
interoperate with servers that do not follow the recommendations in | interoperate with servers that do not follow the recommendations in | |||
Section 4. | Section 4. | |||
NOTE: As set-cookie-string may originate from a non-HTTP API, it is | Note: As set-cookie-string may originate from a non-HTTP API, it is | |||
not guaranteed to be free of CTL characters, so this algorithm | not guaranteed to be free of CTL characters, so this algorithm | |||
handles them explicitly. Horizontal tab (%x09) is excluded from the | handles them explicitly. Horizontal tab (%x09) is excluded from the | |||
CTL characters that lead to set-cookie-string rejection, as it is | CTL characters that lead to set-cookie-string rejection, as it is | |||
considered whitespace, which is handled separately. | considered whitespace, which is handled separately. | |||
NOTE: The set-cookie-string may contain octet sequences that appear | Note: The set-cookie-string may contain octet sequences that appear | |||
percent-encoded as per Section 2.1 of [RFC3986]. However, a user | percent-encoded as per Section 2.1 of [RFC3986]. However, a user | |||
agent MUST NOT decode these sequences and instead parse the | agent MUST NOT decode these sequences and instead parse the | |||
individual octets as specified in this algorithm. | individual octets as specified in this algorithm. | |||
A user agent MUST use an algorithm equivalent to the following | A user agent MUST use an algorithm equivalent to the following | |||
algorithm to parse a set-cookie-string: | algorithm to parse a set-cookie-string: | |||
1. If the set-cookie-string contains a %x00-08 / %x0A-1F / %x7F | 1. If the set-cookie-string contains a %x00-08 / %x0A-1F / %x7F | |||
character (CTL characters excluding HTAB): Abort these steps and | character (CTL characters excluding HTAB): Abort this algorithm | |||
ignore the set-cookie-string entirely. | and ignore the set-cookie-string entirely. | |||
2. If the set-cookie-string contains a %x3B (";") character: | 2. If the set-cookie-string contains a %x3B (";") character: | |||
1. The name-value-pair string consists of the characters up to, | 1. The name-value-pair string consists of the characters up to, | |||
but not including, the first %x3B (";"), and the unparsed- | but not including, the first %x3B (";"), and the unparsed- | |||
attributes consist of the remainder of the set-cookie-string | attributes consist of the remainder of the set-cookie-string | |||
(including the %x3B (";") in question). | (including the %x3B (";") in question). | |||
Otherwise: | Otherwise: | |||
skipping to change at page 29, line 22 ¶ | skipping to change at page 29, line 22 ¶ | |||
Otherwise, the (possibly empty) name string consists of the | Otherwise, the (possibly empty) name string consists of the | |||
characters up to, but not including, the first %x3D ("=") | characters up to, but not including, the first %x3D ("=") | |||
character, and the (possibly empty) value string consists of the | character, and the (possibly empty) value string consists of the | |||
characters after the first %x3D ("=") character. | characters after the first %x3D ("=") character. | |||
4. Remove any leading or trailing WSP characters from the name | 4. Remove any leading or trailing WSP characters from the name | |||
string and the value string. | string and the value string. | |||
5. If the sum of the lengths of the name string and the value string | 5. If the sum of the lengths of the name string and the value string | |||
is more than 4096 octets, abort these steps and ignore the set- | is more than 4096 octets, abort this algorithm and ignore the | |||
cookie-string entirely. | set-cookie-string entirely. | |||
6. The cookie-name is the name string, and the cookie-value is the | 6. The cookie-name is the name string, and the cookie-value is the | |||
value string. | value string. | |||
The user agent MUST use an algorithm equivalent to the following | The user agent MUST use an algorithm equivalent to the following | |||
algorithm to parse the unparsed-attributes: | algorithm to parse the unparsed-attributes: | |||
1. If the unparsed-attributes string is empty, skip the rest of | 1. If the unparsed-attributes string is empty, skip the rest of | |||
these steps. | these steps. | |||
skipping to change at page 29, line 47 ¶ | skipping to change at page 29, line 47 ¶ | |||
3. If the remaining unparsed-attributes contains a %x3B (";") | 3. If the remaining unparsed-attributes contains a %x3B (";") | |||
character: | character: | |||
1. Consume the characters of the unparsed-attributes up to, but | 1. Consume the characters of the unparsed-attributes up to, but | |||
not including, the first %x3B (";") character. | not including, the first %x3B (";") character. | |||
Otherwise: | Otherwise: | |||
1. Consume the remainder of the unparsed-attributes. | 1. Consume the remainder of the unparsed-attributes. | |||
Let the cookie-av string be the characters consumed in this step. | Let the cookie-av string be the characters consumed in this step; | |||
unparsed-attributes now contains any remaining characters. | ||||
4. If the cookie-av string contains a %x3D ("=") character: | 4. If the cookie-av string contains a %x3D ("=") character: | |||
1. The (possibly empty) attribute-name string consists of the | 1. The (possibly empty) attribute-name string consists of the | |||
characters up to, but not including, the first %x3D ("=") | characters up to, but not including, the first %x3D ("=") | |||
character, and the (possibly empty) attribute-value string | character, and the (possibly empty) attribute-value string | |||
consists of the characters after the first %x3D ("=") | consists of the characters after the first %x3D ("=") | |||
character. | character. | |||
Otherwise: | Otherwise: | |||
skipping to change at page 34, line 49 ¶ | skipping to change at page 34, line 49 ¶ | |||
persistent-flag, host-only-flag, secure-only-flag, http-only-flag, | persistent-flag, host-only-flag, secure-only-flag, http-only-flag, | |||
and same-site-flag. | and same-site-flag. | |||
When the user agent "receives a cookie" from a request-uri with name | When the user agent "receives a cookie" from a request-uri with name | |||
cookie-name, value cookie-value, and attributes cookie-attribute- | cookie-name, value cookie-value, and attributes cookie-attribute- | |||
list, the user agent MUST process the cookie as follows: | list, the user agent MUST process the cookie as follows: | |||
1. A user agent MAY ignore a received cookie in its entirety. See | 1. A user agent MAY ignore a received cookie in its entirety. See | |||
Section 5.3. | Section 5.3. | |||
2. If cookie-name is empty and cookie-value is empty, abort these | 2. If cookie-name is empty and cookie-value is empty, abort this | |||
steps and ignore the cookie entirely. | algorithm and ignore the cookie entirely. | |||
3. If the cookie-name or the cookie-value contains a %x00-08 / | 3. If the cookie-name or the cookie-value contains a %x00-08 / | |||
%x0A-1F / %x7F character (CTL characters excluding HTAB), abort | %x0A-1F / %x7F character (CTL characters excluding HTAB), abort | |||
these steps and ignore the cookie entirely. | this algorithm and ignore the cookie entirely. | |||
4. If the sum of the lengths of cookie-name and cookie-value is | 4. If the sum of the lengths of cookie-name and cookie-value is | |||
more than 4096 octets, abort these steps and ignore the cookie | more than 4096 octets, abort this algorithm and ignore the | |||
entirely. | cookie entirely. | |||
5. Create a new cookie with name cookie-name, value cookie-value. | 5. Create a new cookie with name cookie-name, value cookie-value. | |||
Set the creation-time and the last-access-time to the current | Set the creation-time and the last-access-time to the current | |||
date and time. | date and time. | |||
6. If the cookie-attribute-list contains an attribute with an | 6. If the cookie-attribute-list contains an attribute with an | |||
attribute-name of "Max-Age": | attribute-name of "Max-Age": | |||
1. Set the cookie's persistent-flag to true. | 1. Set the cookie's persistent-flag to true. | |||
skipping to change at page 36, line 10 ¶ | skipping to change at page 36, line 10 ¶ | |||
attribute-name of "Domain" and an attribute-value whose | attribute-name of "Domain" and an attribute-value whose | |||
length is no more than 1024 octets. (Note that a leading | length is no more than 1024 octets. (Note that a leading | |||
%x2E ("."), if present, is ignored even though that | %x2E ("."), if present, is ignored even though that | |||
character is not permitted.) | character is not permitted.) | |||
Otherwise: | Otherwise: | |||
1. Let the domain-attribute be the empty string. | 1. Let the domain-attribute be the empty string. | |||
8. If the domain-attribute contains a character that is not in the | 8. If the domain-attribute contains a character that is not in the | |||
range of [USASCII] characters, abort these steps and ignore the | range of [USASCII] characters, abort this algorithm and ignore | |||
cookie entirely. | the cookie entirely. | |||
9. If the user agent is configured to reject "public suffixes" and | 9. If the user agent is configured to reject "public suffixes" and | |||
the domain-attribute is a public suffix: | the domain-attribute is a public suffix: | |||
1. If the domain-attribute is identical to the canonicalized | 1. If the domain-attribute is identical to the canonicalized | |||
request-host: | request-host: | |||
1. Let the domain-attribute be the empty string. | 1. Let the domain-attribute be the empty string. | |||
Otherwise: | Otherwise: | |||
1. Abort these steps and ignore the cookie entirely. | 1. Abort this algorithm and ignore the cookie entirely. | |||
NOTE: This step prevents "attacker.example" from disrupting the | Note: This step prevents "attacker.example" from disrupting the | |||
integrity of "site.example" by setting a cookie with a Domain | integrity of "site.example" by setting a cookie with a Domain | |||
attribute of "example". | attribute of "example". | |||
10. If the domain-attribute is non-empty: | 10. If the domain-attribute is non-empty: | |||
1. If the canonicalized request-host does not domain-match the | 1. If the canonicalized request-host does not domain-match the | |||
domain-attribute: | domain-attribute: | |||
1. Abort these steps and ignore the cookie entirely. | 1. Abort this algorithm and ignore the cookie entirely. | |||
Otherwise: | Otherwise: | |||
1. Set the cookie's host-only-flag to false. | 1. Set the cookie's host-only-flag to false. | |||
2. Set the cookie's domain to the domain-attribute. | 2. Set the cookie's domain to the domain-attribute. | |||
Otherwise: | Otherwise: | |||
1. Set the cookie's host-only-flag to true. | 1. Set the cookie's host-only-flag to true. | |||
skipping to change at page 37, line 20 ¶ | skipping to change at page 37, line 20 ¶ | |||
13. If the request-uri does not denote a "secure" connection (as | 13. If the request-uri does not denote a "secure" connection (as | |||
defined by the user agent), and the cookie's secure-only-flag is | defined by the user agent), and the cookie's secure-only-flag is | |||
true, then abort these steps and ignore the cookie entirely. | true, then abort these steps and ignore the cookie entirely. | |||
14. If the cookie-attribute-list contains an attribute with an | 14. If the cookie-attribute-list contains an attribute with an | |||
attribute-name of "HttpOnly", set the cookie's http-only-flag to | attribute-name of "HttpOnly", set the cookie's http-only-flag to | |||
true. Otherwise, set the cookie's http-only-flag to false. | true. Otherwise, set the cookie's http-only-flag to false. | |||
15. If the cookie was received from a "non-HTTP" API and the | 15. If the cookie was received from a "non-HTTP" API and the | |||
cookie's http-only-flag is true, abort these steps and ignore | cookie's http-only-flag is true, abort this algorithm and ignore | |||
the cookie entirely. | the cookie entirely. | |||
16. If the cookie's secure-only-flag is false, and the request-uri | 16. If the cookie's secure-only-flag is false, and the request-uri | |||
does not denote a "secure" connection, then abort these steps | does not denote a "secure" connection, then abort this algorithm | |||
and ignore the cookie entirely if the cookie store contains one | and ignore the cookie entirely if the cookie store contains one | |||
or more cookies that meet all of the following criteria: | or more cookies that meet all of the following criteria: | |||
1. Their name matches the name of the newly-created cookie. | 1. Their name matches the name of the newly-created cookie. | |||
2. Their secure-only-flag is true. | 2. Their secure-only-flag is true. | |||
3. Their domain domain-matches the domain of the newly-created | 3. Their domain domain-matches the domain of the newly-created | |||
cookie, or vice-versa. | cookie, or vice-versa. | |||
skipping to change at page 38, line 10 ¶ | skipping to change at page 38, line 10 ¶ | |||
"Strict", "Lax", or "None", set the cookie's same-site-flag to | "Strict", "Lax", or "None", set the cookie's same-site-flag to | |||
the attribute-value of the last attribute in the cookie- | the attribute-value of the last attribute in the cookie- | |||
attribute-list with an attribute-name of "SameSite". Otherwise, | attribute-list with an attribute-name of "SameSite". Otherwise, | |||
set the cookie's same-site-flag to "Default". | set the cookie's same-site-flag to "Default". | |||
18. If the cookie's "same-site-flag" is not "None": | 18. If the cookie's "same-site-flag" is not "None": | |||
1. If the cookie was received from a "non-HTTP" API, and the | 1. If the cookie was received from a "non-HTTP" API, and the | |||
API was called from a navigable's active document whose | API was called from a navigable's active document whose | |||
"site for cookies" is not same-site with the top-level | "site for cookies" is not same-site with the top-level | |||
origin, then abort these steps and ignore the newly created | origin, then abort this algorithm and ignore the newly | |||
cookie entirely. | created cookie entirely. | |||
2. If the cookie was received from a "same-site" request (as | 2. If the cookie was received from a "same-site" request (as | |||
defined in Section 5.2), skip the remaining substeps and | defined in Section 5.2), skip the remaining substeps and | |||
continue processing the cookie. | continue processing the cookie. | |||
3. If the cookie was received from a request which is | 3. If the cookie was received from a request which is | |||
navigating a top-level traversable [HTML] (e.g. if the | navigating a top-level traversable [HTML] (e.g. if the | |||
request's "reserved client" is either "null" or an | request's "reserved client" is either "null" or an | |||
environment whose "target browsing context"'s navigable is a | environment whose "target browsing context"'s navigable is a | |||
top-level traversable), skip the remaining substeps and | top-level traversable), skip the remaining substeps and | |||
continue processing the cookie. | continue processing the cookie. | |||
Note: Top-level navigations can create a cookie with any | Note: Top-level navigations can create a cookie with any | |||
"SameSite" value, even if the new cookie wouldn't have been | "SameSite" value, even if the new cookie wouldn't have been | |||
sent along with the request had it already existed prior to | sent along with the request had it already existed prior to | |||
the navigation. | the navigation. | |||
4. Abort these steps and ignore the newly created cookie | 4. Abort this algorithm and ignore the newly created cookie | |||
entirely. | entirely. | |||
19. If the cookie's "same-site-flag" is "None", abort these steps | 19. If the cookie's "same-site-flag" is "None", abort this algorithm | |||
and ignore the cookie entirely unless the cookie's secure-only- | and ignore the cookie entirely unless the cookie's secure-only- | |||
flag is true. | flag is true. | |||
20. If the cookie-name begins with a case-insensitive match for the | 20. If the cookie-name begins with a case-insensitive match for the | |||
string "__Secure-", abort these steps and ignore the cookie | string "__Secure-", abort this algorithm and ignore the cookie | |||
entirely unless the cookie's secure-only-flag is true. | entirely unless the cookie's secure-only-flag is true. | |||
21. If the cookie-name begins with a case-insensitive match for the | 21. If the cookie-name begins with a case-insensitive match for the | |||
string "__Host-", abort these steps and ignore the cookie | string "__Host-", abort this algorithm and ignore the cookie | |||
entirely unless the cookie meets all the following criteria: | entirely unless the cookie meets all the following criteria: | |||
1. The cookie's secure-only-flag is true. | 1. The cookie's secure-only-flag is true. | |||
2. The cookie's host-only-flag is true. | 2. The cookie's host-only-flag is true. | |||
3. The cookie-attribute-list contains an attribute with an | 3. The cookie-attribute-list contains an attribute with an | |||
attribute-name of "Path", and the cookie's path is "/". | attribute-name of "Path", and the cookie's path is "/". | |||
22. If the cookie-name is empty and either of the following | 22. If the cookie-name is empty and either of the following | |||
conditions are true, abort these steps and ignore the cookie | conditions are true, abort this algorithm and ignore the cookie | |||
entirely: | entirely: | |||
* the cookie-value begins with a case-insensitive match for the | * the cookie-value begins with a case-insensitive match for the | |||
string "__Secure-" | string "__Secure-" | |||
* the cookie-value begins with a case-insensitive match for the | * the cookie-value begins with a case-insensitive match for the | |||
string "__Host-" | string "__Host-" | |||
23. If the cookie store contains a cookie with the same name, | 23. If the cookie store contains a cookie with the same name, | |||
domain, host-only-flag, and path as the newly-created cookie: | domain, host-only-flag, and path as the newly-created cookie: | |||
1. Let old-cookie be the existing cookie with the same name, | 1. Let old-cookie be the existing cookie with the same name, | |||
domain, host-only-flag, and path as the newly-created | domain, host-only-flag, and path as the newly-created | |||
cookie. (Notice that this algorithm maintains the invariant | cookie. (Notice that this algorithm maintains the invariant | |||
that there is at most one such cookie.) | that there is at most one such cookie.) | |||
2. If the newly-created cookie was received from a "non-HTTP" | 2. If the newly-created cookie was received from a "non-HTTP" | |||
API and the old-cookie's http-only-flag is true, abort these | API and the old-cookie's http-only-flag is true, abort this | |||
steps and ignore the newly created cookie entirely. | algorithm and ignore the newly created cookie entirely. | |||
3. Update the creation-time of the newly-created cookie to | 3. Update the creation-time of the newly-created cookie to | |||
match the creation-time of the old-cookie. | match the creation-time of the old-cookie. | |||
4. Remove the old-cookie from the cookie store. | 4. Remove the old-cookie from the cookie store. | |||
24. Insert the newly-created cookie into the cookie store. | 24. Insert the newly-created cookie into the cookie store. | |||
A cookie is "expired" if the cookie has an expiry date in the past. | A cookie is "expired" if the cookie has an expiry date in the past. | |||
skipping to change at page 40, line 38 ¶ | skipping to change at page 40, line 38 ¶ | |||
associated URI, same-site status, and type, which are defined below | associated URI, same-site status, and type, which are defined below | |||
depending on the type of retrieval. | depending on the type of retrieval. | |||
5.8.1. The Cookie Header Field | 5.8.1. The Cookie Header Field | |||
The user agent includes stored cookies in the Cookie HTTP request | The user agent includes stored cookies in the Cookie HTTP request | |||
header field. | header field. | |||
A user agent MAY omit the Cookie header field in its entirety. For | A user agent MAY omit the Cookie header field in its entirety. For | |||
example, the user agent might wish to block sending cookies during | example, the user agent might wish to block sending cookies during | |||
"third-party" requests from setting cookies (see Section 7.1). | "third-party" requests (see Section 7.1). | |||
If the user agent does attach a Cookie header field to an HTTP | If the user agent does attach a Cookie header field to an HTTP | |||
request, the user agent MUST generate a single cookie-string and the | request, the user agent MUST generate a single cookie-string and the | |||
user agent MUST compute the cookie-string following the algorithm | user agent MUST compute the cookie-string following the algorithm | |||
defined in Section 5.8.3, where the retrieval's URI is the request- | defined in Section 5.8.3, where the retrieval's URI is the request- | |||
uri, the retrieval's same-site status is computed for the HTTP | uri, the retrieval's same-site status is computed for the HTTP | |||
request as defined in Section 5.2, and the retrieval's type is | request as defined in Section 5.2, and the retrieval's type is | |||
"HTTP". | "HTTP". | |||
Note: Previous versions of this specification required that only one | Note: Previous versions of this specification required that only one | |||
skipping to change at page 41, line 45 ¶ | skipping to change at page 41, line 45 ¶ | |||
+ The cookie's host-only-flag is true and the canonicalized | + The cookie's host-only-flag is true and the canonicalized | |||
host of the retrieval's URI is identical to the cookie's | host of the retrieval's URI is identical to the cookie's | |||
domain. | domain. | |||
Or: | Or: | |||
+ The cookie's host-only-flag is false and the canonicalized | + The cookie's host-only-flag is false and the canonicalized | |||
host of the retrieval's URI domain-matches the cookie's | host of the retrieval's URI domain-matches the cookie's | |||
domain. | domain. | |||
NOTE: (For user agents configured to reject "public suffixes") | + The cookie's domain is not a public suffix, for user agents | |||
It's possible that the public suffix list was changed since a | configured to reject "public suffixes". | |||
cookie was created. If this change results in a cookie's | ||||
domain becoming a public suffix then that cookie is considered | Note: It's possible that the public suffix list was changed | |||
invalid as it would have been rejected during creation (See | since the cookie was created. If this change resulted in the | |||
Section 5.7 step 9). User agents should be careful to avoid | cookie's domain becoming a public suffix then that cookie | |||
retrieving these invalid cookies even if they domain-match the | would have been rejected during creation if it had been | |||
host of the retrieval's URI. | created now. (See Section 5.7 step 9). | |||
* The retrieval's URI's path path-matches the cookie's path. | * The retrieval's URI's path path-matches the cookie's path. | |||
* If the cookie's secure-only-flag is true, then the retrieval's | * If the cookie's secure-only-flag is true, then the retrieval's | |||
URI must denote a "secure" connection (as defined by the user | URI must denote a "secure" connection (as defined by the user | |||
agent). | agent). | |||
NOTE: The notion of a "secure" connection is not defined by | Note: The notion of a "secure" connection is not defined by | |||
this document. Typically, user agents consider a connection | this document. Typically, user agents consider a connection | |||
secure if the connection makes use of transport-layer | secure if the connection makes use of transport-layer | |||
security, such as SSL or TLS [TLS13], or if the host is | security, such as SSL or TLS [TLS13], or if the host is | |||
trusted. For example, most user agents consider "https" to be | trusted. For example, most user agents consider "https" to be | |||
a scheme that denotes a secure protocol and "localhost" to be | a scheme that denotes a secure protocol and "localhost" to be | |||
trusted host. | trusted host. | |||
* If the cookie's http-only-flag is true, then exclude the | * If the cookie's http-only-flag is true, then exclude the | |||
cookie if the retrieval's type is "non-HTTP". | cookie if the retrieval's type is "non-HTTP". | |||
skipping to change at page 42, line 49 ¶ | skipping to change at page 42, line 49 ¶ | |||
2. The user agent SHOULD sort the cookie-list in the following | 2. The user agent SHOULD sort the cookie-list in the following | |||
order: | order: | |||
* Cookies with longer paths are listed before cookies with | * Cookies with longer paths are listed before cookies with | |||
shorter paths. | shorter paths. | |||
* Among cookies that have equal-length path fields, cookies with | * Among cookies that have equal-length path fields, cookies with | |||
earlier creation-times are listed before cookies with later | earlier creation-times are listed before cookies with later | |||
creation-times. | creation-times. | |||
NOTE: Not all user agents sort the cookie-list in this order, but | Note: Not all user agents sort the cookie-list in this order, but | |||
this order reflects common practice when this document was | this order reflects common practice when this document was | |||
written, and, historically, there have been servers that | written, and, historically, there have been servers that | |||
(erroneously) depended on this order. | (erroneously) depended on this order. | |||
3. Update the last-access-time of each cookie in the cookie-list to | 3. Update the last-access-time of each cookie in the cookie-list to | |||
the current date and time. | the current date and time. | |||
4. Serialize the cookie-list into a cookie-string by processing each | 4. Serialize the cookie-list into a cookie-string by processing each | |||
cookie in the cookie-list in order: | cookie in the cookie-list in order: | |||
1. If the cookies' name is not empty, output the cookie's name | 1. If the cookies' name is not empty, output the cookie's name | |||
followed by the %x3D ("=") character. | followed by the %x3D ("=") character. | |||
2. If the cookies' value is not empty, output the cookie's | 2. If the cookies' value is not empty, output the cookie's | |||
value. | value. | |||
3. If there is an unprocessed cookie in the cookie-list, output | 3. If the cookie was not the last cookie in the cookie-list, | |||
the characters %x3B and %x20 ("; "). | output the characters %x3B and %x20 ("; "). | |||
6. Implementation Considerations | 6. Implementation Considerations | |||
6.1. Limits | 6.1. Limits | |||
Practical user agent implementations have limits on the number and | Practical user agent implementations have limits on the number and | |||
size of cookies that they can store. General-use user agents SHOULD | size of cookies that they can store. General-use user agents SHOULD | |||
provide each of the following minimum capabilities: | provide each of the following minimum capabilities: | |||
o At least 50 cookies per domain. | o At least 50 cookies per domain. | |||
skipping to change at page 44, line 8 ¶ | skipping to change at page 44, line 8 ¶ | |||
to the Cookie header field being included in every request, and to | to the Cookie header field being included in every request, and to | |||
avoid reaching server header field limits (See Section 4.2.1). | avoid reaching server header field limits (See Section 4.2.1). | |||
Servers SHOULD gracefully degrade if the user agent fails to return | Servers SHOULD gracefully degrade if the user agent fails to return | |||
one or more cookies in the Cookie header field because the user agent | one or more cookies in the Cookie header field because the user agent | |||
might evict any cookie at any time. | might evict any cookie at any time. | |||
6.2. Application Programming Interfaces | 6.2. Application Programming Interfaces | |||
One reason the Cookie and Set-Cookie header fields use such esoteric | One reason the Cookie and Set-Cookie header fields use such esoteric | |||
syntax is that many platforms (both in servers and user agents) | handling is that many platforms (both in servers and user agents) | |||
provide a string-based application programming interface (API) to | provide a string-based application programming interface (API) to | |||
cookies, requiring application-layer programmers to generate and | cookies, requiring application-layer programmers to generate and | |||
parse the syntax used by the Cookie and Set-Cookie header fields, | parse the syntax used by the Cookie and Set-Cookie header fields, | |||
which many programmers have done incorrectly, resulting in | which many programmers have done incorrectly, resulting in | |||
interoperability problems. | interoperability problems. | |||
Instead of providing string-based APIs to cookies, platforms would be | Instead of providing string-based APIs to cookies, platforms would be | |||
well-served by providing more semantic APIs. It is beyond the scope | well-served by providing more semantic APIs. It is beyond the scope | |||
of this document to recommend specific API designs, but there are | of this document to recommend specific API designs, but there are | |||
clear benefits to accepting an abstract "Date" object instead of a | clear benefits to accepting an abstract "Date" object instead of a | |||
skipping to change at page 54, line 45 ¶ | skipping to change at page 54, line 45 ¶ | |||
Applicable protocol: http | Applicable protocol: http | |||
Status: standard | Status: standard | |||
Author/Change controller: IETF | Author/Change controller: IETF | |||
Specification document: this specification (Section 5.8.1) | Specification document: this specification (Section 5.8.1) | |||
9.2. Set-Cookie | 9.2. Set-Cookie | |||
The permanent message header field registry (see | The HTTP Field Name Registry (see [HttpFieldNameRegistry]) needs to | |||
[HttpFieldNameRegistry]) needs to be updated with the following | be updated with the following registration: | |||
registration: | ||||
Header field name: Set-Cookie | Header field name: Set-Cookie | |||
Applicable protocol: http | Applicable protocol: http | |||
Status: standard | Status: standard | |||
Author/Change controller: IETF | Author/Change controller: IETF | |||
Specification document: this specification (Section 5.6) | Specification document: this specification (Section 5.6) | |||
skipping to change at page 55, line 27 ¶ | skipping to change at page 55, line 27 ¶ | |||
9.3.1. Procedure | 9.3.1. Procedure | |||
Each registered attribute name is associated with a description, and | Each registered attribute name is associated with a description, and | |||
a reference detailing how the attribute is to be processed and | a reference detailing how the attribute is to be processed and | |||
stored. | stored. | |||
New registrations happen on a "RFC Required" basis (see Section 4.7 | New registrations happen on a "RFC Required" basis (see Section 4.7 | |||
of [RFC8126]). The attribute to be registered MUST match the | of [RFC8126]). The attribute to be registered MUST match the | |||
"extension-av" syntax defined in Section 4.1.1. Note that attribute | "extension-av" syntax defined in Section 4.1.1. Note that attribute | |||
names are generally defined in CamelCase, but technically accepted | names are generally defined in CamelCase but MUST be recognized case- | |||
case-insensitively. | insensitively. Two attribute names that case-insensitively match | |||
MUST NOT be registered. | ||||
9.3.2. Registration | 9.3.2. Registration | |||
The "Cookie Attributes" registry should be created with the | The "Cookie Attributes" registry should be created with the | |||
registrations below: | registrations below: | |||
+----------+----------------------------------+ | +----------+----------------------------------+ | |||
| Name | Reference | | | Name | Reference | | |||
+----------+----------------------------------+ | +----------+----------------------------------+ | |||
| Domain | Section 4.1.2.3 of this document | | | Domain | Section 4.1.2.3 of this document | | |||
skipping to change at page 56, line 4 ¶ | skipping to change at page 56, line 6 ¶ | |||
| Domain | Section 4.1.2.3 of this document | | | Domain | Section 4.1.2.3 of this document | | |||
| Expires | Section 4.1.2.1 of this document | | | Expires | Section 4.1.2.1 of this document | | |||
| HttpOnly | Section 4.1.2.6 of this document | | | HttpOnly | Section 4.1.2.6 of this document | | |||
| Max-Age | Section 4.1.2.2 of this document | | | Max-Age | Section 4.1.2.2 of this document | | |||
| Path | Section 4.1.2.4 of this document | | | Path | Section 4.1.2.4 of this document | | |||
| SameSite | Section 4.1.2.7 of this document | | | SameSite | Section 4.1.2.7 of this document | | |||
| Secure | Section 4.1.2.5 of this document | | | Secure | Section 4.1.2.5 of this document | | |||
+----------+----------------------------------+ | +----------+----------------------------------+ | |||
10. References | 10. References | |||
10.1. Normative References | 10.1. Normative References | |||
[DOM-DOCUMENT-COOKIE] | [DOM-DOCUMENT-COOKIE] | |||
WHATWG, "HTML - Living Standard", May 2021, | WHATWG, "HTML - Living Standard", May 2021, | |||
<https://html.spec.whatwg.org/#dom-document-cookie>. | <https://html.spec.whatwg.org/#dom-document-cookie>. | |||
[FETCH] van Kesteren, A., "Fetch", n.d., | ||||
<https://fetch.spec.whatwg.org/>. | ||||
[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt, | ||||
P., and D. Denicola, "HTML", n.d., | ||||
<https://html.spec.whatwg.org/>. | ||||
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "HTTP Semantics", STD 97, RFC 9110, | Ed., "HTTP Semantics", STD 97, RFC 9110, | |||
DOI 10.17487/RFC9110, June 2022, | DOI 10.17487/RFC9110, June 2022, | |||
<https://www.rfc-editor.org/info/rfc9110>. | <https://www.rfc-editor.org/info/rfc9110>. | |||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | |||
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | |||
<https://www.rfc-editor.org/info/rfc1034>. | <https://www.rfc-editor.org/info/rfc1034>. | |||
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - | [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - | |||
skipping to change at page 57, line 50 ¶ | skipping to change at page 57, line 46 ¶ | |||
appisolation.pdf>. | appisolation.pdf>. | |||
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses | [CSRF] Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses | |||
for Cross-Site Request Forgery", | for Cross-Site Request Forgery", | |||
DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7, | DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7, | |||
ACM CCS '08: Proceedings of the 15th ACM conference on | ACM CCS '08: Proceedings of the 15th ACM conference on | |||
Computer and communications security (pages 75-88), | Computer and communications security (pages 75-88), | |||
October 2008, | October 2008, | |||
<http://portal.acm.org/citation.cfm?id=1455770.1455782>. | <http://portal.acm.org/citation.cfm?id=1455770.1455782>. | |||
[FETCH] van Kesteren, A., "Fetch Living Standard", n.d., | ||||
<https://fetch.spec.whatwg.org/>. | ||||
WHATWG | ||||
[HTML] van Kesteren, A., Denicola, D., Farolino, D., Hickson, I., | ||||
Jaegenstedt, P., and S. Pieters, "HTML Living Standard", | ||||
n.d., <https://html.spec.whatwg.org/>. | ||||
WHATWG | ||||
[HttpFieldNameRegistry] | [HttpFieldNameRegistry] | |||
"Hypertext Transfer Protocol (HTTP) Field Name Registry", | "Hypertext Transfer Protocol (HTTP) Field Name Registry", | |||
n.d., <https://www.iana.org/assignments/http-fields/>. | n.d., <https://www.iana.org/assignments/http-fields/>. | |||
[prerendering] | [prerendering] | |||
Bentzel, C., "Chrome Prerendering", n.d., | Bentzel, C., "Chrome Prerendering", n.d., | |||
<https://www.chromium.org/developers/design-documents/ | <https://www.chromium.org/developers/design-documents/ | |||
prerender>. | prerender>. | |||
[PSL] "Public Suffix List", n.d., | [PSL] "Public Suffix List", n.d., | |||
skipping to change at page 60, line 37 ¶ | skipping to change at page 60, line 45 ¶ | |||
RFC 6265, adding features and aligning the specification with the | RFC 6265, adding features and aligning the specification with the | |||
reality of today's deployments. Here, we're standing upon the | reality of today's deployments. Here, we're standing upon the | |||
shoulders of a giant since the majority of the text is still Adam's. | shoulders of a giant since the majority of the text is still Adam's. | |||
Thank you to both Lily Chen and Steven Englehardt, editors emeritus, | Thank you to both Lily Chen and Steven Englehardt, editors emeritus, | |||
for their significant contributions improving this draft. | for their significant contributions improving this draft. | |||
Authors' Addresses | Authors' Addresses | |||
Steven Bingler (editor) | Steven Bingler (editor) | |||
Google LLC | ||||
Email: bingler@google.com | ||||
Email: bingler@chromium.org | ||||
Mike West (editor) | Mike West (editor) | |||
Google LLC | Google LLC | |||
Email: mkwst@google.com | Email: mkwst@google.com | |||
URI: https://mikewest.org/ | URI: https://mikewest.org/ | |||
John Wilander (editor) | John Wilander (editor) | |||
Apple, Inc | Apple, Inc | |||
Email: wilander@apple.com | Email: wilander@apple.com | |||
End of changes. 53 change blocks. | ||||
89 lines changed or deleted | 95 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |