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 25, 2026 J. Wilander, Ed.
March 17, 2025 Apple, Inc
July 24, 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 25, 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/