draft-ietf-httpbis-rfc6265bis-14.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 M. West, Ed. | |||
Obsoletes: 6265 (if approved) Google LLC | Obsoletes: 6265 (if approved) Google LLC | |||
Intended status: Standards Track J. Wilander, Ed. | Intended status: Standards Track J. Wilander, Ed. | |||
Expires: November 3, 2024 Apple, Inc | Expires: January 15, 2025 Apple, Inc | |||
May 2, 2024 | July 14, 2024 | |||
Cookies: HTTP State Management Mechanism | Cookies: HTTP State Management Mechanism | |||
draft-ietf-httpbis-rfc6265bis-14 | 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 7 ¶ | |||
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 November 3, 2024. | This Internet-Draft will expire on January 15, 2025. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 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 2, line 41 ¶ | skipping to change at page 2, line 41 ¶ | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 5 | 2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . 5 | |||
2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 | 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.2. Which Requirements to Implement . . . . . . . . . . . . . 9 | 3.2. Which Requirements to Implement . . . . . . . . . . . . . 9 | |||
3.2.1. Cookie Producing Implementations . . . . . . . . . . 10 | 3.2.1. Cookie Producing Implementations . . . . . . . . . . 10 | |||
3.2.2. Cookie Consuming Implementations . . . . . . . . . . 10 | 3.2.2. Cookie Consuming Implementations . . . . . . . . . . 10 | |||
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 11 | 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 11 | 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 13 | 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 13 | |||
4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 17 | 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 16 | |||
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 18 | 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 18 | 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 18 | |||
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 19 | 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 19 | |||
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 19 | 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 19 | |||
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 19 | 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 21 | 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 21 | |||
5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 22 | 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 22 | |||
5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 22 | 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 22 | |||
5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 23 | 5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 23 | |||
5.2.1. Document-based requests . . . . . . . . . . . . . . . 23 | 5.2.1. Document-based requests . . . . . . . . . . . . . . . 23 | |||
5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 24 | 5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 24 | |||
5.3. Ignoring Set-Cookie Header Fields . . . . . . . . . . . . 25 | 5.3. Ignoring Set-Cookie Header Fields . . . . . . . . . . . . 25 | |||
5.4. Cookie Name Prefixes . . . . . . . . . . . . . . . . . . 25 | 5.4. Cookie Name Prefixes . . . . . . . . . . . . . . . . . . 25 | |||
5.5. The Set-Cookie Header Field . . . . . . . . . . . . . . . 27 | 5.5. Cookie Lifetime Limits . . . . . . . . . . . . . . . . . 27 | |||
5.5.1. The Expires Attribute . . . . . . . . . . . . . . . . 30 | 5.6. The Set-Cookie Header Field . . . . . . . . . . . . . . . 27 | |||
5.5.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 30 | 5.6.1. The Expires Attribute . . . . . . . . . . . . . . . . 30 | |||
5.5.3. The Domain Attribute . . . . . . . . . . . . . . . . 31 | 5.6.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 30 | |||
5.5.4. The Path Attribute . . . . . . . . . . . . . . . . . 31 | 5.6.3. The Domain Attribute . . . . . . . . . . . . . . . . 31 | |||
5.5.5. The Secure Attribute . . . . . . . . . . . . . . . . 31 | 5.6.4. The Path Attribute . . . . . . . . . . . . . . . . . 31 | |||
5.5.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 32 | 5.6.5. The Secure Attribute . . . . . . . . . . . . . . . . 32 | |||
5.5.7. The SameSite Attribute . . . . . . . . . . . . . . . 32 | 5.6.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 32 | |||
5.6. Storage Model . . . . . . . . . . . . . . . . . . . . . . 34 | 5.6.7. The SameSite Attribute . . . . . . . . . . . . . . . 32 | |||
5.7. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 39 | 5.7. Storage Model . . . . . . . . . . . . . . . . . . . . . . 34 | |||
5.7.1. The Cookie Header Field . . . . . . . . . . . . . . . 40 | 5.8. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 39 | |||
5.7.2. Non-HTTP APIs . . . . . . . . . . . . . . . . . . . . 40 | 5.8.1. The Cookie Header Field . . . . . . . . . . . . . . . 40 | |||
5.7.3. Retrieval Algorithm . . . . . . . . . . . . . . . . . 40 | 5.8.2. Non-HTTP APIs . . . . . . . . . . . . . . . . . . . . 40 | |||
5.8.3. Retrieval Algorithm . . . . . . . . . . . . . . . . . 41 | ||||
6. Implementation Considerations . . . . . . . . . . . . . . . . 42 | 6. Implementation Considerations . . . . . . . . . . . . . . . . 42 | |||
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 42 | 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
6.2. Application Programming Interfaces . . . . . . . . . . . 43 | 6.2. Application Programming Interfaces . . . . . . . . . . . 43 | |||
6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 43 | 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 43 | |||
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44 | 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44 | |||
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 45 | 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 45 | |||
7.2. Cookie Policy . . . . . . . . . . . . . . . . . . . . . . 45 | 7.2. Cookie Policy . . . . . . . . . . . . . . . . . . . . . . 45 | |||
7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 46 | 7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 46 | |||
7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 46 | 7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 46 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 | |||
skipping to change at page 4, line 12 ¶ | skipping to change at page 4, line 13 ¶ | |||
8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 50 | 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 50 | |||
8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 51 | 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 51 | |||
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 . . . . . . . . . . . . . . . . . 52 | 8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 52 | |||
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 Attribute Registry . . . . . . . . . . . . . . . . 54 | 9.3. Cookie Attribute Registry . . . . . . . . . . . . . . . . 54 | |||
9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 54 | 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 55 | |||
9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 55 | 9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 55 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 55 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 55 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 57 | 10.2. Informative References . . . . . . . . . . . . . . . . . 57 | |||
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59 | 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59 | |||
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 62 | Appendix A. Changes from RFC 6265 . . . . . . . . . . . . . . . 59 | |||
A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 62 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 60 | |||
A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 62 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 | |||
A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 62 | ||||
A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 63 | ||||
A.5. draft-ietf-httpbis-rfc6265bis-04 . . . . . . . . . . . . 63 | ||||
A.6. draft-ietf-httpbis-rfc6265bis-05 . . . . . . . . . . . . 63 | ||||
A.7. draft-ietf-httpbis-rfc6265bis-06 . . . . . . . . . . . . 64 | ||||
A.8. draft-ietf-httpbis-rfc6265bis-07 . . . . . . . . . . . . 64 | ||||
A.9. draft-ietf-httpbis-rfc6265bis-08 . . . . . . . . . . . . 64 | ||||
A.10. draft-ietf-httpbis-rfc6265bis-09 . . . . . . . . . . . . 65 | ||||
A.11. draft-ietf-httpbis-rfc6265bis-10 . . . . . . . . . . . . 65 | ||||
A.12. draft-ietf-httpbis-rfc6265bis-11 . . . . . . . . . . . . 66 | ||||
A.13. draft-ietf-httpbis-rfc6265bis-12 . . . . . . . . . . . . 66 | ||||
A.14. draft-ietf-httpbis-rfc6265bis-14 . . . . . . . . . . . . 67 | ||||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 67 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 | ||||
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. | |||
Using the Set-Cookie header field, an HTTP server can pass name/value | Using the Set-Cookie header field, an HTTP server can pass name/value | |||
pairs and associated metadata (called cookies) to a user agent. When | pairs and associated metadata (called cookies) to a user agent. When | |||
the user agent makes subsequent requests to the server, the user | the user agent makes subsequent requests to the server, the user | |||
agent uses the metadata and other information to determine whether to | agent uses the metadata and other information to determine whether to | |||
return the name/value pairs in the Cookie header field. | return the name/value pairs in the Cookie header field. | |||
skipping to change at page 6, line 25 ¶ | skipping to change at page 6, line 11 ¶ | |||
The following core rules are included by reference, as defined in | The following core rules are included by reference, as defined in | |||
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | |||
(CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | (CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | |||
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet), | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet), | |||
OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB | OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB | |||
(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 [HTTPSEM]. | 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 | |||
([HTTPSEM], Section 3). | ([HTTP], Section 3). | |||
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 [HTTPSEM]. | 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", | |||
skipping to change at page 7, line 13 ¶ | skipping to change at page 6, line 48 ¶ | |||
"WorkerGlobalScope" are defined in [HTML]. | "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 [HTTPSEM]. | defined in Section 9.2.1 of [HTTP]. | |||
A domain's "public suffix" is the portion of a domain that is | A domain's "public suffix" is the portion of a domain that is | |||
controlled by a public registry, such as "com", "co.uk", and | controlled by a public registry, such as "com", "co.uk", and | |||
"pvt.k12.wy.us". A domain's "registrable domain" is the domain's | "pvt.k12.wy.us". A domain's "registrable domain" is the domain's | |||
public suffix plus the label to its left. That is, for | public suffix plus the label to its left. That is, for | |||
"https://www.site.example", the public suffix is "example", and the | "https://www.site.example", the public suffix is "example", and the | |||
registrable domain is "site.example". Whenever possible, user agents | registrable domain is "site.example". Whenever possible, user agents | |||
SHOULD use an up-to-date public suffix list, such as the one | SHOULD use an up-to-date public suffix list, such as the one | |||
maintained by the Mozilla project at [PSL]. | maintained by the Mozilla project at [PSL]. | |||
skipping to change at page 8, line 9 ¶ | skipping to change at page 7, line 44 ¶ | |||
purpose. | purpose. | |||
Origin servers MAY send a Set-Cookie response header field with any | Origin servers MAY send a Set-Cookie response header field with any | |||
response. An origin server can include multiple Set-Cookie header | response. An origin server can include multiple Set-Cookie header | |||
fields in a single response. The presence of a Cookie or a Set- | fields in a single response. The presence of a Cookie or a Set- | |||
Cookie header field does not preclude HTTP caches from storing and | Cookie header field does not preclude HTTP caches from storing and | |||
reusing a response. | reusing a response. | |||
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into | Origin servers SHOULD NOT fold multiple Set-Cookie header fields into | |||
a single header field. The usual mechanism for folding HTTP headers | a single header field. The usual mechanism for folding HTTP headers | |||
fields (i.e., as defined in Section 5.3 of [HTTPSEM]) might change | fields (i.e., as defined in Section 5.3 of [HTTP]) might change the | |||
the semantics of the Set-Cookie header field because the %x2C (",") | semantics of the Set-Cookie header field because the %x2C (",") | |||
character is used by Set-Cookie in a way that conflicts with such | character is used by Set-Cookie in a way that conflicts with such | |||
folding. | folding. | |||
User agents MAY ignore Set-Cookie header fields based on response | User agents MAY ignore Set-Cookie header fields based on response | |||
status codes or the user agent's cookie policy (see Section 5.3). | status codes or the user agent's cookie policy (see Section 5.3). | |||
3.1. Examples | 3.1. Examples | |||
Using the Set-Cookie header field, a server can send the user agent a | Using the Set-Cookie header field, a server can send the user agent a | |||
short string in an HTTP response that the user agent will return in | short string in an HTTP response that the user agent will return in | |||
skipping to change at page 12, line 20 ¶ | skipping to change at page 12, line 20 ¶ | |||
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E | cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E | |||
; US-ASCII characters excluding CTLs, | ; US-ASCII characters excluding CTLs, | |||
; whitespace DQUOTE, comma, semicolon, | ; whitespace DQUOTE, comma, semicolon, | |||
; and backslash | ; and backslash | |||
cookie-av = expires-av / max-age-av / domain-av / | cookie-av = expires-av / max-age-av / domain-av / | |||
path-av / secure-av / httponly-av / | path-av / secure-av / httponly-av / | |||
samesite-av / extension-av | samesite-av / extension-av | |||
expires-av = "Expires" BWS "=" BWS sane-cookie-date | expires-av = "Expires" BWS "=" BWS sane-cookie-date | |||
sane-cookie-date = | sane-cookie-date = | |||
<IMF-fixdate, defined in [HTTPSEM], Section 5.6.7> | <IMF-fixdate, defined in [HTTP], Section 5.6.7> | |||
max-age-av = "Max-Age" BWS "=" BWS non-zero-digit *DIGIT | max-age-av = "Max-Age" BWS "=" BWS non-zero-digit *DIGIT | |||
non-zero-digit = %x31-39 | non-zero-digit = %x31-39 | |||
; digits 1 through 9 | ; digits 1 through 9 | |||
domain-av = "Domain" BWS "=" BWS domain-value | domain-av = "Domain" BWS "=" BWS domain-value | |||
domain-value = <subdomain> | domain-value = <subdomain> | |||
; see details below | ; see details below | |||
path-av = "Path" BWS "=" BWS path-value | path-av = "Path" BWS "=" BWS path-value | |||
path-value = *av-octet | path-value = *av-octet | |||
secure-av = "Secure" | secure-av = "Secure" | |||
httponly-av = "HttpOnly" | httponly-av = "HttpOnly" | |||
skipping to change at page 13, line 15 ¶ | skipping to change at page 13, line 15 ¶ | |||
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 [RFC1034], Section 3.5, | |||
and as enhanced by [RFC1123], Section 2.1. Thus, domain-value is a | and as enhanced by [RFC1123], Section 2.1. Thus, domain-value is a | |||
string of [USASCII] characters, such as one obtained by applying the | string of [USASCII] characters, such as one obtained by applying the | |||
"ToASCII" operation defined in Section 4 of [RFC3490]. | "ToASCII" operation defined in Section 4 of [RFC3490]. | |||
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 SHOULD NOT produce two attributes with the same name in the | servers SHOULD NOT produce two attributes with the same name in the | |||
same set-cookie-string. (See Section 5.6 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 SHOULD NOT include more than one Set-Cookie header field in | Servers SHOULD NOT include more than one Set-Cookie header field in | |||
the same response with the same cookie-name. (See Section 5.5 for | the same response with the same cookie-name. (See Section 5.6 for | |||
how user agents handle this case.) | how 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. | |||
skipping to change at page 14, line 21 ¶ | skipping to change at page 14, line 21 ¶ | |||
Unless the cookie's attributes indicate otherwise, the cookie is | Unless the cookie's attributes indicate otherwise, the cookie is | |||
returned only to the origin server (and not, for example, to any | returned only to the origin server (and not, for example, to any | |||
subdomains), and it expires at the end of the current session (as | subdomains), and it expires at the end of the current session (as | |||
defined by the user agent). User agents ignore unrecognized cookie | defined by the user agent). User agents ignore unrecognized cookie | |||
attributes (but not the entire cookie). | attributes (but not the entire cookie). | |||
4.1.2.1. The Expires Attribute | 4.1.2.1. The Expires Attribute | |||
The Expires attribute indicates the maximum lifetime of the cookie, | The Expires attribute indicates the maximum lifetime of the cookie, | |||
represented as the date and time at which the cookie expires. The | represented as the date and time at which the cookie expires. The | |||
user agent is not required to retain the cookie until the specified | user agent may adjust the specified date and is not required to | |||
date has passed. In fact, user agents often evict cookies due to | retain the cookie until that date has passed. In fact, user agents | |||
memory pressure or privacy concerns. | often evict cookies due to memory pressure or privacy concerns. | |||
The user agent MUST limit the maximum value of the Expires attribute. | ||||
The limit SHOULD NOT be greater than 400 days (34560000 seconds) in | ||||
the future. The RECOMMENDED limit is 400 days in the future, but the | ||||
user agent MAY adjust the limit (see Section 7.2). Expires | ||||
attributes that are greater than the limit MUST be reduced to the | ||||
limit. | ||||
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 is not required to retain the cookie for the specified | user agent may adjust the specified duration and is not required to | |||
duration. In fact, user agents often evict cookies due to memory | retain the cookie for that duration. In fact, user agents often | |||
pressure or privacy concerns. | evict cookies due to memory pressure or privacy concerns. | |||
The user agent MUST limit the maximum value of the Max-Age attribute. | ||||
The limit SHOULD NOT be greater than 400 days (34560000 seconds) in | ||||
duration. The RECOMMENDED limit is 400 days in duration, but the | ||||
user agent MAY adjust the limit (see Section 7.2). Max-Age | ||||
attributes that are greater than the limit MUST be reduced to the | ||||
limit. | ||||
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). | |||
skipping to change at page 15, line 35 ¶ | skipping to change at page 15, line 21 ¶ | |||
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.6 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.) | |||
The user agent will include the cookie in an HTTP request only if the | The user agent will include the cookie in an HTTP request only if the | |||
path portion of the request-uri matches (or is a subdirectory of) the | path portion of the request-uri matches (or is a subdirectory of) the | |||
skipping to change at page 16, line 37 ¶ | skipping to change at page 16, line 22 ¶ | |||
will only be attached to requests if those requests are same-site, as | will only be attached to requests if those requests are same-site, as | |||
defined by the algorithm in Section 5.2. For example, requests for | defined by the algorithm in Section 5.2. For example, requests for | |||
"https://site.example/sekrit-image" will attach same-site cookies if | "https://site.example/sekrit-image" will attach same-site cookies if | |||
and only if initiated from a context whose "site for cookies" is an | and only if initiated from a context whose "site for cookies" is an | |||
origin with a scheme and registered domain of "https" and | origin with a scheme and registered domain of "https" and | |||
"site.example" respectively. | "site.example" respectively. | |||
If the "SameSite" attribute's value is "Strict", the cookie will only | If the "SameSite" attribute's value is "Strict", the cookie will only | |||
be sent along with "same-site" requests. If the value is "Lax", the | be sent along with "same-site" requests. If the value is "Lax", the | |||
cookie will be sent with same-site requests, and with "cross-site" | cookie will be sent with same-site requests, and with "cross-site" | |||
top-level navigations, as described in Section 5.5.7.1. If the value | top-level navigations, as described in Section 5.6.7.1. If the value | |||
is "None", the cookie will be sent with same-site and cross-site | is "None", the cookie will be sent with same-site and cross-site | |||
requests. If the "SameSite" attribute's value is something other | requests. If the "SameSite" attribute's value is something other | |||
than these three known keywords, the attribute's value will be | than these three known keywords, the attribute's value will be | |||
subject to a default enforcement mode that is equivalent to "Lax". | subject to a default enforcement mode that is equivalent to "Lax". | |||
The "SameSite" attribute affects cookie creation as well as delivery. | The "SameSite" attribute affects cookie creation as well as delivery. | |||
Cookies which assert "SameSite=Lax" or "SameSite=Strict" cannot be | Cookies which assert "SameSite=Lax" or "SameSite=Strict" cannot be | |||
set in responses to cross-site subresource requests, or cross-site | set in responses to cross-site subresource requests, or cross-site | |||
nested navigations. They can be set along with any top-level | nested navigations. They can be set along with any top-level | |||
navigation, cross-site or otherwise. | navigation, cross-site or otherwise. | |||
skipping to change at page 18, line 36 ¶ | skipping to change at page 18, line 20 ¶ | |||
The user agent sends stored cookies to the origin server in the | The user agent sends stored cookies to the origin server in the | |||
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 | ||||
fields it is likely that the web server's implementation does impose | ||||
a limit; many popular implementations have default limits of 8K. | ||||
Servers SHOULD avoid setting a large number of large cookies such | ||||
that the final cookie-string would exceed their header field 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] connection might split a cookie | HTTP/2 [RFC9113] or HTTP/3 [RFC9114] client or intermediary might | |||
header to improve compression. | split a cookie header to improve compression. Servers are free to | |||
determine what form this tolerance takes. For example, the server | ||||
could process each cookie header individually or the server could | ||||
concatenate all the cookie headers into one and then process that | ||||
final, single, header. The server should be mindful of any header | ||||
field limits when deciding which approach to take. | ||||
Note: Since intermediaries can modify cookie headers they should also | ||||
be mindful of common server header field limits in order to avoid | ||||
sending servers headers that they cannot process. For example, | ||||
concatenating multiple cookie headers into a single header might | ||||
exceed a server's size limit. | ||||
4.2.2. Semantics | 4.2.2. Semantics | |||
Each cookie-pair represents a cookie stored by the user agent. The | Each cookie-pair represents a cookie stored by the user agent. The | |||
cookie-pair contains the cookie-name and cookie-value the user agent | cookie-pair contains the cookie-name and cookie-value the user agent | |||
received in the Set-Cookie header field. | received in the Set-Cookie header field. | |||
Notice that the cookie attributes are not returned. In particular, | Notice that the cookie attributes are not returned. In particular, | |||
the server cannot determine from the Cookie field alone when a cookie | the server cannot determine from the Cookie field alone when a cookie | |||
will expire, for which hosts the cookie is valid, for which paths the | will expire, for which hosts the cookie is valid, for which paths the | |||
skipping to change at page 25, line 43 ¶ | skipping to change at page 25, line 43 ¶ | |||
How user agents handle Service Workers may differ, but user agents | How user agents handle Service Workers may differ, but user agents | |||
SHOULD match the [SERVICE-WORKERS] specification. | SHOULD match the [SERVICE-WORKERS] specification. | |||
5.3. Ignoring Set-Cookie Header Fields | 5.3. Ignoring Set-Cookie Header Fields | |||
User agents MAY ignore Set-Cookie header fields contained in | User agents MAY ignore Set-Cookie header fields contained in | |||
responses with 100-level status codes or based on its cookie policy | responses with 100-level status codes or based on its cookie policy | |||
(see Section 7.2). | (see Section 7.2). | |||
All other Set-Cookie header fields SHOULD be processed according to | All other Set-Cookie header fields SHOULD be processed according to | |||
Section 5.5. That is, Set-Cookie header fields contained in | Section 5.6. That is, Set-Cookie header fields contained in | |||
responses with non-100-level status codes (including those in | responses with non-100-level status codes (including those in | |||
responses with 400- and 500-level status codes) SHOULD be processed | responses with 400- and 500-level status codes) SHOULD be processed | |||
unless ignored according to the user agent's cookie policy. | unless ignored according to the user agent's cookie policy. | |||
5.4. Cookie Name Prefixes | 5.4. Cookie Name Prefixes | |||
User agents' requirements for cookie name prefixes differ slightly | User agents' requirements for cookie name prefixes differ slightly | |||
from servers' (Section 4.1.3) in that UAs MUST match the prefix | from servers' (Section 4.1.3) in that UAs MUST match the prefix | |||
string case-insensitively. | string case-insensitively. | |||
The normative requirements for the prefixes are detailed in the | The normative requirements for the prefixes are detailed in the | |||
storage model algorithm defined in Section 5.6. | storage model algorithm defined in Section 5.7. | |||
This is because some servers will process cookie case-insensitively, | This is because some servers will process cookie case-insensitively, | |||
resulting in them unintentionally miscapitalizing and accepting | resulting in them unintentionally miscapitalizing and accepting | |||
miscapitalized prefixes. | miscapitalized prefixes. | |||
For example, if a server sends the following "Set-Cookie" header | For example, if a server sends the following "Set-Cookie" header | |||
field | field | |||
Set-Cookie: __SECURE-SID=12345 | Set-Cookie: __SECURE-SID=12345 | |||
skipping to change at page 27, line 26 ¶ | skipping to change at page 27, line 26 ¶ | |||
Whereas the following "Set-Cookie" header fields would be accepted if | Whereas the following "Set-Cookie" header fields would be accepted if | |||
set from a secure origin. | set from a secure origin. | |||
Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure | Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure | |||
Set-Cookie: __secure-SID=12345; Domain=site.example; Secure | Set-Cookie: __secure-SID=12345; Domain=site.example; Secure | |||
Set-Cookie: __SECURE-SID=12345; Domain=site.example; Secure | Set-Cookie: __SECURE-SID=12345; Domain=site.example; Secure | |||
Set-Cookie: __Host-SID=12345; Secure; Path=/ | Set-Cookie: __Host-SID=12345; Secure; Path=/ | |||
Set-Cookie: __host-SID=12345; Secure; Path=/ | Set-Cookie: __host-SID=12345; Secure; Path=/ | |||
Set-Cookie: __HOST-SID=12345; Secure; Path=/ | Set-Cookie: __HOST-SID=12345; Secure; Path=/ | |||
5.5. The Set-Cookie Header Field | 5.5. Cookie Lifetime Limits | |||
When processing cookies with a specified lifetime, either with the | ||||
Expires or with the Max-Age attribute, the user agent MUST limit the | ||||
maximum age of the cookie. The limit SHOULD NOT be greater than 400 | ||||
days (34560000 seconds) in the future. The RECOMMENDED limit is 400 | ||||
days in the future, but the user agent MAY adjust the limit (see | ||||
Section 7.2). Expires or Max-Age attributes that specify a lifetime | ||||
longer than the limit MUST be reduced to the limit. | ||||
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 | |||
skipping to change at page 29, line 48 ¶ | skipping to change at page 30, line 14 ¶ | |||
7. Process the attribute-name and attribute-value according to the | 7. Process the attribute-name and attribute-value according to the | |||
requirements in the following subsections. (Notice that | requirements in the following subsections. (Notice that | |||
attributes with unrecognized attribute-names are ignored.) | attributes with unrecognized attribute-names are ignored.) | |||
8. Return to Step 1 of this algorithm. | 8. Return to Step 1 of this algorithm. | |||
When the user agent finishes parsing the set-cookie-string, the user | When the user agent finishes parsing the set-cookie-string, the user | |||
agent is said to "receive a cookie" from the request-uri with name | agent is said to "receive a cookie" from the request-uri with name | |||
cookie-name, value cookie-value, and attributes cookie-attribute- | cookie-name, value cookie-value, and attributes cookie-attribute- | |||
list. (See Section 5.6 for additional requirements triggered by | list. (See Section 5.7 for additional requirements triggered by | |||
receiving a cookie.) | receiving a cookie.) | |||
5.5.1. The Expires Attribute | 5.6.1. The Expires Attribute | |||
If the attribute-name case-insensitively matches the string | If the attribute-name case-insensitively matches the string | |||
"Expires", the user agent MUST process the cookie-av as follows. | "Expires", the user agent MUST process the cookie-av as follows. | |||
1. Let the expiry-time be the result of parsing the attribute-value | 1. Let the expiry-time be the result of parsing the attribute-value | |||
as cookie-date (see Section 5.1.1). | as cookie-date (see Section 5.1.1). | |||
2. If the attribute-value failed to parse as a cookie date, ignore | 2. If the attribute-value failed to parse as a cookie date, ignore | |||
the cookie-av. | the cookie-av. | |||
3. Let cookie-age-limit be the maximum age of the cookie (which | 3. Let cookie-age-limit be the maximum age of the cookie (which | |||
SHOULD be 400 days in the future or sooner, see Section 4.1.2.1). | SHOULD be 400 days in the future or sooner, see Section 5.5). | |||
4. If the expiry-time is more than cookie-age-limit, the user agent | 4. If the expiry-time is more than cookie-age-limit, the user agent | |||
MUST set the expiry time to cookie-age-limit in seconds. | MUST set the expiry time to cookie-age-limit in seconds. | |||
5. If the expiry-time is earlier than the earliest date the user | 5. If the expiry-time is earlier than the earliest date the user | |||
agent can represent, the user agent MAY replace the expiry-time | agent can represent, the user agent MAY replace the expiry-time | |||
with the earliest representable date. | with the earliest representable date. | |||
6. Append an attribute to the cookie-attribute-list with an | 6. Append an attribute to the cookie-attribute-list with an | |||
attribute-name of Expires and an attribute-value of expiry-time. | attribute-name of Expires and an attribute-value of expiry-time. | |||
5.5.2. The Max-Age Attribute | 5.6.2. The Max-Age Attribute | |||
If the attribute-name case-insensitively matches the string "Max- | If the attribute-name case-insensitively matches the string "Max- | |||
Age", the user agent MUST process the cookie-av as follows. | Age", the user agent MUST process the cookie-av as follows. | |||
1. If the attribute-value is empty, ignore the cookie-av. | 1. If the attribute-value is empty, ignore the cookie-av. | |||
2. If the first character of the attribute-value is neither a DIGIT, | 2. If the first character of the attribute-value is neither a DIGIT, | |||
nor a "-" character followed by a DIGIT, ignore the cookie-av. | nor a "-" character followed by a DIGIT, ignore the cookie-av. | |||
3. If the remainder of attribute-value contains a non-DIGIT | 3. If the remainder of attribute-value contains a non-DIGIT | |||
character, ignore the cookie-av. | character, ignore the cookie-av. | |||
4. Let delta-seconds be the attribute-value converted to a base 10 | 4. Let delta-seconds be the attribute-value converted to a base 10 | |||
integer. | integer. | |||
5. Let cookie-age-limit be the maximum age of the cookie (which | 5. Let cookie-age-limit be the maximum age of the cookie (which | |||
SHOULD be 400 days or less, see Section 4.1.2.2). | SHOULD be 400 days or less, see Section 5.5). | |||
6. Set delta-seconds to the smaller of its present value and cookie- | 6. Set delta-seconds to the smaller of its present value and cookie- | |||
age-limit. | age-limit. | |||
7. If delta-seconds is less than or equal to zero (0), let expiry- | 7. If delta-seconds is less than or equal to zero (0), let expiry- | |||
time be the earliest representable date and time. Otherwise, let | time be the earliest representable date and time. Otherwise, let | |||
the expiry-time be the current date and time plus delta-seconds | the expiry-time be the current date and time plus delta-seconds | |||
seconds. | seconds. | |||
8. Append an attribute to the cookie-attribute-list with an | 8. Append an attribute to the cookie-attribute-list with an | |||
attribute-name of Max-Age and an attribute-value of expiry-time. | attribute-name of Max-Age and an attribute-value of expiry-time. | |||
5.5.3. The Domain Attribute | 5.6.3. The Domain Attribute | |||
If the attribute-name case-insensitively matches the string "Domain", | If the attribute-name case-insensitively matches the string "Domain", | |||
the user agent MUST process the cookie-av as follows. | the user agent MUST process the cookie-av as follows. | |||
1. Let cookie-domain be the attribute-value. | 1. Let cookie-domain be the attribute-value. | |||
2. If cookie-domain starts with %x2E ("."), let cookie-domain be | 2. If cookie-domain starts with %x2E ("."), let cookie-domain be | |||
cookie-domain without its leading %x2E ("."). | cookie-domain without its leading %x2E ("."). | |||
3. Convert the cookie-domain to lower case. | 3. Convert the cookie-domain to lower case. | |||
4. Append an attribute to the cookie-attribute-list with an | 4. Append an attribute to the cookie-attribute-list with an | |||
attribute-name of Domain and an attribute-value of cookie-domain. | attribute-name of Domain and an attribute-value of cookie-domain. | |||
5.5.4. The Path Attribute | 5.6.4. The Path Attribute | |||
If the attribute-name case-insensitively matches the string "Path", | If the attribute-name case-insensitively matches the string "Path", | |||
the user agent MUST process the cookie-av as follows. | the user agent MUST process the cookie-av as follows. | |||
1. If the attribute-value is empty or if the first character of the | 1. If the attribute-value is empty or if the first character of the | |||
attribute-value is not %x2F ("/"): | attribute-value is not %x2F ("/"): | |||
1. Let cookie-path be the default-path. | 1. Let cookie-path be the default-path. | |||
Otherwise: | Otherwise: | |||
1. Let cookie-path be the attribute-value. | 1. Let cookie-path be the attribute-value. | |||
2. Append an attribute to the cookie-attribute-list with an | 2. Append an attribute to the cookie-attribute-list with an | |||
attribute-name of Path and an attribute-value of cookie-path. | attribute-name of Path and an attribute-value of cookie-path. | |||
5.5.5. The Secure Attribute | 5.6.5. The Secure Attribute | |||
If the attribute-name case-insensitively matches the string "Secure", | If the attribute-name case-insensitively matches the string "Secure", | |||
the user agent MUST append an attribute to the cookie-attribute-list | the user agent MUST append an attribute to the cookie-attribute-list | |||
with an attribute-name of Secure and an empty attribute-value. | with an attribute-name of Secure and an empty attribute-value. | |||
5.5.6. The HttpOnly Attribute | 5.6.6. The HttpOnly Attribute | |||
If the attribute-name case-insensitively matches the string | If the attribute-name case-insensitively matches the string | |||
"HttpOnly", the user agent MUST append an attribute to the cookie- | "HttpOnly", the user agent MUST append an attribute to the cookie- | |||
attribute-list with an attribute-name of HttpOnly and an empty | attribute-list with an attribute-name of HttpOnly and an empty | |||
attribute-value. | attribute-value. | |||
5.5.7. The SameSite Attribute | 5.6.7. The SameSite Attribute | |||
If the attribute-name case-insensitively matches the string | If the attribute-name case-insensitively matches the string | |||
"SameSite", the user agent MUST process the cookie-av as follows: | "SameSite", the user agent MUST process the cookie-av as follows: | |||
1. Let "enforcement" be "Default". | 1. Let "enforcement" be "Default". | |||
2. If cookie-av's attribute-value is a case-insensitive match for | 2. If cookie-av's attribute-value is a case-insensitive match for | |||
"None", set "enforcement" to "None". | "None", set "enforcement" to "None". | |||
3. If cookie-av's attribute-value is a case-insensitive match for | 3. If cookie-av's attribute-value is a case-insensitive match for | |||
"Strict", set "enforcement" to "Strict". | "Strict", set "enforcement" to "Strict". | |||
4. If cookie-av's attribute-value is a case-insensitive match for | 4. If cookie-av's attribute-value is a case-insensitive match for | |||
"Lax", set "enforcement" to "Lax". | "Lax", set "enforcement" to "Lax". | |||
5. Append an attribute to the cookie-attribute-list with an | 5. Append an attribute to the cookie-attribute-list with an | |||
attribute-name of "SameSite" and an attribute-value of | attribute-name of "SameSite" and an attribute-value of | |||
"enforcement". | "enforcement". | |||
5.5.7.1. "Strict" and "Lax" enforcement | 5.6.7.1. "Strict" and "Lax" enforcement | |||
Same-site cookies in "Strict" enforcement mode will not be sent along | Same-site cookies in "Strict" enforcement mode will not be sent along | |||
with top-level navigations which are triggered from a cross-site | with top-level navigations which are triggered from a cross-site | |||
document context. As discussed in Section 8.8.2, this might or might | document context. As discussed in Section 8.8.2, this might or might | |||
not be compatible with existing session management systems. In the | not be compatible with existing session management systems. In the | |||
interests of providing a drop-in mechanism that mitigates the risk of | interests of providing a drop-in mechanism that mitigates the risk of | |||
CSRF attacks, developers may set the "SameSite" attribute in a "Lax" | CSRF attacks, developers may set the "SameSite" attribute in a "Lax" | |||
enforcement mode that carves out an exception which sends same-site | enforcement mode that carves out an exception which sends same-site | |||
cookies along with cross-site requests if and only if they are top- | cookies along with cross-site requests if and only if they are top- | |||
level navigations which use a "safe" (in the [HTTPSEM] sense) HTTP | level navigations which use a "safe" (in the [HTTP] sense) HTTP | |||
method. (Note that a request's method may be changed from POST to | method. (Note that a request's method may be changed from POST to | |||
GET for some redirects (see Sections 15.4.2 and 15.4.3 of [HTTPSEM]); | GET for some redirects (see Sections 15.4.2 and 15.4.3 of [HTTP]); in | |||
in these cases, a request's "safe"ness is determined based on the | these cases, a request's "safe"ness is determined based on the method | |||
method of the current redirect hop.) | of the current redirect hop.) | |||
Lax enforcement provides reasonable defense in depth against CSRF | Lax enforcement provides reasonable defense in depth against CSRF | |||
attacks that rely on unsafe HTTP methods (like "POST"), but does not | attacks that rely on unsafe HTTP methods (like "POST"), but does not | |||
offer a robust defense against CSRF as a general category of attack: | offer a robust defense against CSRF as a general category of attack: | |||
1. Attackers can still pop up new windows or trigger top-level | 1. Attackers can still pop up new windows or trigger top-level | |||
navigations in order to create a "same-site" request (as | navigations in order to create a "same-site" request (as | |||
described in Section 5.2.1), which is only a speedbump along the | described in Section 5.2.1), which is only a speedbump along the | |||
road to exploitation. | road to exploitation. | |||
2. Features like "<link rel='prerender'>" [prerendering] can be | 2. Features like "<link rel='prerender'>" [prerendering] can be | |||
exploited to create "same-site" requests without the risk of user | exploited to create "same-site" requests without the risk of user | |||
detection. | detection. | |||
When possible, developers should use a session management mechanism | When possible, developers should use a session management mechanism | |||
such as that described in Section 8.8.2 to mitigate the risk of CSRF | such as that described in Section 8.8.2 to mitigate the risk of CSRF | |||
more completely. | more completely. | |||
5.5.7.2. "Lax-Allowing-Unsafe" enforcement | 5.6.7.2. "Lax-Allowing-Unsafe" enforcement | |||
As discussed in Section 8.8.6, compatibility concerns may necessitate | As discussed in Section 8.8.6, compatibility concerns may necessitate | |||
the use of a "Lax-allowing-unsafe" enforcement mode that allows | the use of a "Lax-allowing-unsafe" enforcement mode that allows | |||
cookies to be sent with a cross-site HTTP request if and only if it | cookies to be sent with a cross-site HTTP request if and only if it | |||
is a top-level request, regardless of request method. That is, the | is a top-level request, regardless of request method. That is, the | |||
"Lax-allowing-unsafe" enforcement mode waives the requirement for the | "Lax-allowing-unsafe" enforcement mode waives the requirement for the | |||
HTTP request's method to be "safe" in the "SameSite" enforcement step | HTTP request's method to be "safe" in the "SameSite" enforcement step | |||
of the retrieval algorithm in Section 5.7.3. (All cookies, | of the retrieval algorithm in Section 5.8.3. (All cookies, | |||
regardless of "SameSite" enforcement mode, may be set for top-level | regardless of "SameSite" enforcement mode, may be set for top-level | |||
navigations, regardless of HTTP request method, as specified in | navigations, regardless of HTTP request method, as specified in | |||
Section 5.6.) | Section 5.7.) | |||
"Lax-allowing-unsafe" is not a distinct value of the "SameSite" | "Lax-allowing-unsafe" is not a distinct value of the "SameSite" | |||
attribute. Rather, user agents MAY apply "Lax-allowing-unsafe" | attribute. Rather, user agents MAY apply "Lax-allowing-unsafe" | |||
enforcement only to cookies that did not explicitly specify a | enforcement only to cookies that did not explicitly specify a | |||
"SameSite" attribute (i.e., those whose same-site-flag was set to | "SameSite" attribute (i.e., those whose same-site-flag was set to | |||
"Default" by default). To limit the scope of this compatibility | "Default" by default). To limit the scope of this compatibility | |||
mode, user agents which apply "Lax-allowing-unsafe" enforcement | mode, user agents which apply "Lax-allowing-unsafe" enforcement | |||
SHOULD restrict the enforcement to cookies which were created | SHOULD restrict the enforcement to cookies which were created | |||
recently. Deployment experience has shown a cookie age of 2 minutes | recently. Deployment experience has shown a cookie age of 2 minutes | |||
or less to be a reasonable limit. | or less to be a reasonable limit. | |||
If the user agent uses "Lax-allowing-unsafe" enforcement, it MUST | If the user agent uses "Lax-allowing-unsafe" enforcement, it MUST | |||
apply the following modification to the retrieval algorithm defined | apply the following modification to the retrieval algorithm defined | |||
in Section 5.7.3: | in Section 5.8.3: | |||
Replace the condition in the penultimate bullet point of step 1 of | Replace the condition in the penultimate bullet point of step 1 of | |||
the retrieval algorithm reading | the retrieval algorithm reading | |||
* The HTTP request associated with the retrieval uses a "safe" | * The HTTP request associated with the retrieval uses a "safe" | |||
method. | method. | |||
with | with | |||
* At least one of the following is true: | * At least one of the following is true: | |||
1. The HTTP request associated with the retrieval uses a "safe" | 1. The HTTP request associated with the retrieval uses a "safe" | |||
method. | method. | |||
2. The cookie's same-site-flag is "Default" and the amount of | 2. The cookie's same-site-flag is "Default" and the amount of | |||
time elapsed since the cookie's creation-time is at most a | time elapsed since the cookie's creation-time is at most a | |||
duration of the user agent's choosing. | duration of the user agent's choosing. | |||
5.6. Storage Model | 5.7. Storage Model | |||
The user agent stores the following fields about each cookie: name, | The user agent stores the following fields about each cookie: name, | |||
value, expiry-time, domain, path, creation-time, last-access-time, | value, expiry-time, domain, path, creation-time, last-access-time, | |||
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: | |||
skipping to change at page 39, line 45 ¶ | skipping to change at page 39, line 45 ¶ | |||
4. All cookies. | 4. All cookies. | |||
If two cookies have the same removal priority, the user agent MUST | If two cookies have the same removal priority, the user agent MUST | |||
evict the cookie with the earliest last-access-time first. | evict the cookie with the earliest last-access-time first. | |||
When "the current session is over" (as defined by the user agent), | When "the current session is over" (as defined by the user agent), | |||
the user agent MUST remove from the cookie store all cookies with the | the user agent MUST remove from the cookie store all cookies with the | |||
persistent-flag set to false. | persistent-flag set to false. | |||
5.7. Retrieval Model | 5.8. Retrieval Model | |||
This section defines how cookies are retrieved from a cookie store in | This section defines how cookies are retrieved from a cookie store in | |||
the form of a cookie-string. A "retrieval" is any event which | the form of a cookie-string. A "retrieval" is any event which | |||
requires generating a cookie-string. For example, a retrieval may | requires generating a cookie-string. For example, a retrieval may | |||
occur in order to build a Cookie header field for an HTTP request, or | occur in order to build a Cookie header field for an HTTP request, or | |||
may be required in order to return a cookie-string from a call to a | may be required in order to return a cookie-string from a call to a | |||
"non-HTTP" API that provides access to cookies. A retrieval has an | "non-HTTP" API that provides access to cookies. A retrieval has an | |||
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.7.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 from setting cookies (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.7.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". | |||
5.7.2. Non-HTTP APIs | Note: Previous versions of this specification required that only one | |||
Cookie header field be sent in requests. This is no longer a | ||||
requirement. While this specification requires that a single cookie- | ||||
string be produced, some user agents may split that string across | ||||
multiple cookie header fields. For examples, see Section 8.2.3 of | ||||
[RFC9113] and Section 4.2.1 of [RFC9114]. | ||||
5.8.2. Non-HTTP APIs | ||||
The user agent MAY implement "non-HTTP" APIs that can be used to | The user agent MAY implement "non-HTTP" APIs that can be used to | |||
access stored cookies. | access stored cookies. | |||
A user agent MAY return an empty cookie-string in certain contexts, | A user agent MAY return an empty cookie-string in certain contexts, | |||
such as when a retrieval occurs within a third-party context (see | such as when a retrieval occurs within a third-party context (see | |||
Section 7.1). | Section 7.1). | |||
If a user agent does return cookies for a given call to a "non-HTTP" | If a user agent does return cookies for a given call to a "non-HTTP" | |||
API with an associated Document, then the user agent MUST compute the | API with an associated Document, then the user agent MUST compute the | |||
cookie-string following the algorithm defined in Section 5.7.3, where | cookie-string following the algorithm defined in Section 5.8.3, where | |||
the retrieval's URI is defined by the caller (see | the retrieval's URI is defined by the caller (see | |||
[DOM-DOCUMENT-COOKIE]), the retrieval's same-site status is "same- | [DOM-DOCUMENT-COOKIE]), the retrieval's same-site status is "same- | |||
site" if the Document's "site for cookies" is same-site with the top- | site" if the Document's "site for cookies" is same-site with the top- | |||
level origin as defined in Section 5.2.1 (otherwise it is "cross- | level origin as defined in Section 5.2.1 (otherwise it is "cross- | |||
site"), and the retrieval's type is "non-HTTP". | site"), and the retrieval's type is "non-HTTP". | |||
5.7.3. Retrieval Algorithm | 5.8.3. Retrieval Algorithm | |||
Given a cookie store and a retrieval, the following algorithm returns | Given a cookie store and a retrieval, the following algorithm returns | |||
a cookie-string from a given cookie store. | a cookie-string from a given cookie store. | |||
1. Let cookie-list be the set of cookies from the cookie store that | 1. Let cookie-list be the set of cookies from the cookie store that | |||
meets all of the following requirements: | meets all of the following requirements: | |||
* Either: | * Either: | |||
+ The cookie's host-only-flag is true and the canonicalized | + The cookie's host-only-flag is true and the canonicalized | |||
skipping to change at page 41, line 20 ¶ | skipping to change at page 41, line 30 ¶ | |||
+ 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") | NOTE: (For user agents configured to reject "public suffixes") | |||
It's possible that the public suffix list was changed since a | It's possible that the public suffix list was changed since a | |||
cookie was created. If this change results in a cookie's | cookie was created. If this change results in a cookie's | |||
domain becoming a public suffix then that cookie is considered | domain becoming a public suffix then that cookie is considered | |||
invalid as it would have been rejected during creation (See | invalid as it would have been rejected during creation (See | |||
Section 5.6 step 9). User agents should be careful to avoid | Section 5.7 step 9). User agents should be careful to avoid | |||
retrieving these invalid cookies even if they domain-match the | retrieving these invalid cookies even if they domain-match the | |||
host of the retrieval's URI. | host of the retrieval's URI. | |||
* 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 | |||
skipping to change at page 43, line 11 ¶ | skipping to change at page 43, line 15 ¶ | |||
o At least 50 cookies per domain. | o At least 50 cookies per domain. | |||
o At least 3000 cookies total. | o At least 3000 cookies total. | |||
User agents MAY limit the maximum number of cookies they store, and | User agents MAY limit the maximum number of cookies they store, and | |||
may evict any cookie at any time (whether at the request of the user | may evict any cookie at any time (whether at the request of the user | |||
or due to implementation limitations). | or due to implementation limitations). | |||
Note that a limit on the maximum number of cookies also limits the | Note that a limit on the maximum number of cookies also limits the | |||
total size of the stored cookies, due to the length limits which MUST | total size of the stored cookies, due to the length limits which MUST | |||
be enforced in Section 5.5. | be enforced in Section 5.6. | |||
Servers SHOULD use as few and as small cookies as possible to avoid | Servers SHOULD use as few and as small cookies as possible to avoid | |||
reaching these implementation limits and to minimize network | reaching these implementation limits and to minimize network | |||
bandwidth due to the Cookie header field being included in every | bandwidth due to the Cookie header field being included in every | |||
request. | request. | |||
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. | |||
skipping to change at page 45, line 41 ¶ | skipping to change at page 45, line 43 ¶ | |||
treated consistently by user agents for the foreseeable future. | treated consistently by user agents for the foreseeable future. | |||
7.2. Cookie Policy | 7.2. Cookie Policy | |||
User agents MAY enforce a cookie policy consisting of restrictions on | User agents MAY enforce a cookie policy consisting of restrictions on | |||
how cookies may be used or ignored (see Section 5.3). | how cookies may be used or ignored (see Section 5.3). | |||
A cookie policy may govern which domains or parties, as in first and | A cookie policy may govern which domains or parties, as in first and | |||
third parties (see Section 7.1), for which the user agent will allow | third parties (see Section 7.1), for which the user agent will allow | |||
cookie access. The policy can also define limits on cookie size, | cookie access. The policy can also define limits on cookie size, | |||
cookie expiry (see Section 4.1.2.1 and Section 4.1.2.2), and the | cookie expiry (see Section 5.5), and the number of cookies per domain | |||
number of cookies per domain or in total. | or in total. | |||
The recommended cookie expiry upper limit is 400 days. User agents | The recommended cookie expiry upper limit is 400 days. User agents | |||
may set a lower limit to enforce shorter data retention timelines, or | may set a lower limit to enforce shorter data retention timelines, or | |||
set the limit higher to support longer retention when appropriate | set the limit higher to support longer retention when appropriate | |||
(e.g., server-to-server communication over HTTPS). | (e.g., server-to-server communication over HTTPS). | |||
The goal of a restrictive cookie policy is often to improve security | The goal of a restrictive cookie policy is often to improve security | |||
or privacy. User agents often allow users to change the cookie | or privacy. User agents often allow users to change the cookie | |||
policy (see Section 7.3). | policy (see Section 7.3). | |||
skipping to change at page 53, line 27 ¶ | skipping to change at page 53, line 29 ¶ | |||
cross-site, like the request that initially navigated to the page. | cross-site, like the request that initially navigated to the page. | |||
Because requests issued for, non-user initiated, reloads attach all | Because requests issued for, non-user initiated, reloads attach all | |||
SameSite cookies, developers should be careful and thoughtful about | SameSite cookies, developers should be careful and thoughtful about | |||
when to initiate a reload in order to avoid a CSRF attack. For | when to initiate a reload in order to avoid a CSRF attack. For | |||
example, the page could only initiate a reload if a CSRF token is | example, the page could only initiate a reload if a CSRF token is | |||
present on the initial request. | present on the initial request. | |||
8.8.6. Top-level requests with "unsafe" methods | 8.8.6. Top-level requests with "unsafe" methods | |||
The "Lax" enforcement mode described in Section 5.5.7.1 allows a | The "Lax" enforcement mode described in Section 5.6.7.1 allows a | |||
cookie to be sent with a cross-site HTTP request if and only if it is | cookie to be sent with a cross-site HTTP request if and only if it is | |||
a top-level navigation with a "safe" HTTP method. Implementation | a top-level navigation with a "safe" HTTP method. Implementation | |||
experience shows that this is difficult to apply as the default | experience shows that this is difficult to apply as the default | |||
behavior, as some sites may rely on cookies not explicitly specifying | behavior, as some sites may rely on cookies not explicitly specifying | |||
a "SameSite" attribute being included on top-level cross-site | a "SameSite" attribute being included on top-level cross-site | |||
requests with "unsafe" HTTP methods (as was the case prior to the | requests with "unsafe" HTTP methods (as was the case prior to the | |||
introduction of the "SameSite" attribute). | introduction of the "SameSite" attribute). | |||
For example, a login flow may involve a cross-site top-level "POST" | For example, the concluding step of a login flow may involve a cross- | |||
request to an endpoint which expects a cookie with login information. | site top-level "POST" request to an endpoint; this endpoint expects a | |||
For such a cookie, "Lax" enforcement is not appropriate, as it would | recently created cookie containing transactional state information, | |||
cause the cookie to be excluded due to the unsafe HTTP request | necessary to securely complete the login. For such a cookie, "Lax" | |||
method. On the other hand, "None" enforcement would allow the cookie | enforcement is not appropriate, as it would cause the cookie to be | |||
to be sent with all cross-site requests, which may not be desirable | excluded due to the unsafe HTTP request method, resulting in an | |||
due to the cookie's sensitive contents. | unrecoverable failure of the whole login flow. | |||
The "Lax-allowing-unsafe" enforcement mode described in | The "Lax-allowing-unsafe" enforcement mode described in | |||
Section 5.5.7.2 retains some of the protections of "Lax" enforcement | Section 5.6.7.2 retains some of the protections of "Lax" enforcement | |||
(as compared to "None") while still allowing cookies to be sent | (as compared to "None") while still allowing recently created cookies | |||
cross-site with unsafe top-level requests. | to be sent cross-site with unsafe top-level requests. | |||
As a more permissive variant of "Lax" mode, "Lax-allowing-unsafe" | As a more permissive variant of "Lax" mode, "Lax-allowing-unsafe" | |||
mode necessarily provides fewer protections against CSRF. | mode necessarily provides fewer protections against CSRF. | |||
Ultimately, the provision of such an enforcement mode should be seen | Ultimately, the provision of such an enforcement mode should be seen | |||
as a temporary, transitional measure to ease adoption of "Lax" | as a temporary, transitional measure to ease adoption of "Lax" | |||
enforcement by default. | enforcement by default. | |||
9. IANA Considerations | 9. IANA Considerations | |||
9.1. Cookie | 9.1. Cookie | |||
The permanent message header field registry (see [RFC3864]) needs to | The HTTP Field Name Registry (see [HttpFieldNameRegistry]) needs to | |||
be updated with the following registration: | be updated with the following registration: | |||
Header field name: Cookie | Header field name: 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.7.1) | Specification document: this specification (Section 5.8.1) | |||
9.2. Set-Cookie | 9.2. Set-Cookie | |||
The permanent message header field registry (see [RFC3864]) needs to | The permanent message header field registry (see | |||
be updated with the following registration: | [HttpFieldNameRegistry]) needs to be updated with the following | |||
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.5) | Specification document: this specification (Section 5.6) | |||
9.3. Cookie Attribute Registry | 9.3. Cookie Attribute Registry | |||
IANA is requested to create the "Cookie Attribute Registry", defining | IANA is requested to create the "Cookie Attribute" registry, defining | |||
the name space of attribute used to control cookies' behavior. The | the name space of attribute used to control cookies' behavior. The | |||
registry should be maintained at https://www.iana.org/assignments/ | registry should be maintained at https://www.iana.org/assignments/ | |||
cookie-attribute-names [1]. | cookie-attribute-names [1]. | |||
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. | |||
skipping to change at page 55, line 43 ¶ | skipping to change at page 55, line 49 ¶ | |||
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., | [FETCH] van Kesteren, A., "Fetch", n.d., | |||
<https://fetch.spec.whatwg.org/>. | <https://fetch.spec.whatwg.org/>. | |||
[HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt, | [HTML] Hickson, I., Pieters, S., van Kesteren, A., Jaegenstedt, | |||
P., and D. Denicola, "HTML", n.d., | P., and D. Denicola, "HTML", n.d., | |||
<https://html.spec.whatwg.org/>. | <https://html.spec.whatwg.org/>. | |||
[HTTPSEM] Fielding, R., Nottingham, M., and J. Reschke, "HTTP | [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Semantics", draft-ietf-httpbis-semantics-19 (work in | Ed., "HTTP Semantics", STD 97, RFC 9110, | |||
progress), September 2021. | DOI 10.17487/RFC9110, June 2022, | |||
<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 - | |||
Application and Support", STD 3, RFC 1123, | Application and Support", STD 3, RFC 1123, | |||
DOI 10.17487/RFC1123, October 1989, | DOI 10.17487/RFC1123, October 1989, | |||
<https://www.rfc-editor.org/info/rfc1123>. | <https://www.rfc-editor.org/info/rfc1123>. | |||
skipping to change at page 57, line 33 ¶ | skipping to change at page 57, line 37 ¶ | |||
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>. | |||
[HttpFieldNameRegistry] | ||||
"Hypertext Transfer Protocol (HTTP) Field Name Registry", | ||||
n.d., <https://www.iana.org/assignments/http-fields/>. | ||||
[I-D.ietf-httpbis-cookie-alone] | [I-D.ietf-httpbis-cookie-alone] | |||
West, M., "Deprecate modification of 'secure' cookies from | West, M., "Deprecate modification of 'secure' cookies from | |||
non-secure origins", draft-ietf-httpbis-cookie-alone-01 | non-secure origins", draft-ietf-httpbis-cookie-alone-01 | |||
(work in progress), September 2016. | (work in progress), September 2016. | |||
[I-D.ietf-httpbis-cookie-prefixes] | [I-D.ietf-httpbis-cookie-prefixes] | |||
West, M., "Cookie Prefixes", draft-ietf-httpbis-cookie- | West, M., "Cookie Prefixes", draft-ietf-httpbis-cookie- | |||
prefixes-00 (work in progress), February 2016. | prefixes-00 (work in progress), February 2016. | |||
[I-D.ietf-httpbis-cookie-same-site] | [I-D.ietf-httpbis-cookie-same-site] | |||
skipping to change at page 58, line 13 ¶ | skipping to change at page 58, line 21 ¶ | |||
<https://publicsuffix.org/list/>. | <https://publicsuffix.org/list/>. | |||
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management | [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management | |||
Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997, | Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997, | |||
<https://www.rfc-editor.org/info/rfc2109>. | <https://www.rfc-editor.org/info/rfc2109>. | |||
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | |||
DOI 10.17487/RFC2818, May 2000, | DOI 10.17487/RFC2818, May 2000, | |||
<https://www.rfc-editor.org/info/rfc2818>. | <https://www.rfc-editor.org/info/rfc2818>. | |||
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | ||||
Procedures for Message Header Fields", BCP 90, RFC 3864, | ||||
DOI 10.17487/RFC3864, September 2004, | ||||
<https://www.rfc-editor.org/info/rfc3864>. | ||||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Resource Identifier (URI): Generic Syntax", STD 66, | Resource Identifier (URI): Generic Syntax", STD 66, | |||
RFC 3986, DOI 10.17487/RFC3986, January 2005, | RFC 3986, DOI 10.17487/RFC3986, January 2005, | |||
<https://www.rfc-editor.org/info/rfc3986>. | <https://www.rfc-editor.org/info/rfc3986>. | |||
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data | |||
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, | Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, | |||
<https://www.rfc-editor.org/info/rfc4648>. | <https://www.rfc-editor.org/info/rfc4648>. | |||
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for | [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for | |||
skipping to change at page 59, line 9 ¶ | skipping to change at page 59, line 9 ¶ | |||
June 2022, <https://www.rfc-editor.org/info/rfc9114>. | June 2022, <https://www.rfc-editor.org/info/rfc9114>. | |||
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility | [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility | |||
Processing", UNICODE Unicode Technical Standards # 46, | Processing", UNICODE Unicode Technical Standards # 46, | |||
June 2016, <http://unicode.org/reports/tr46/>. | June 2016, <http://unicode.org/reports/tr46/>. | |||
10.3. URIs | 10.3. URIs | |||
[1] https://www.iana.org/assignments/cookie-attribute-names | [1] https://www.iana.org/assignments/cookie-attribute-names | |||
[2] https://github.com/httpwg/http-extensions/issues/243 | Appendix A. Changes from RFC 6265 | |||
[3] https://github.com/httpwg/http-extensions/issues/246 | ||||
[4] https://www.rfc-editor.org/errata_search.php?rfc=6265 | ||||
[5] https://github.com/httpwg/http-extensions/issues/247 | ||||
[6] https://github.com/httpwg/http-extensions/issues/201 | ||||
[7] https://github.com/httpwg/http-extensions/issues/204 | ||||
[8] https://github.com/httpwg/http-extensions/issues/222 | ||||
[9] https://github.com/httpwg/http-extensions/issues/248 | ||||
[10] https://github.com/httpwg/http-extensions/issues/295 | ||||
[11] https://github.com/httpwg/http-extensions/issues/302 | ||||
[12] https://github.com/httpwg/http-extensions/issues/389 | ||||
[13] https://github.com/httpwg/http-extensions/issues/199 | ||||
[14] https://github.com/httpwg/http-extensions/issues/788 | ||||
[15] https://github.com/httpwg/http-extensions/issues/594 | ||||
[16] https://github.com/httpwg/http-extensions/issues/159 | ||||
[17] https://github.com/httpwg/http-extensions/issues/159 | ||||
[18] https://github.com/httpwg/http-extensions/issues/901 | ||||
[19] https://github.com/httpwg/http-extensions/pull/1035 | ||||
[20] https://github.com/httpwg/http-extensions/pull/1038 | ||||
[21] https://github.com/httpwg/http-extensions/pull/1040 | ||||
[22] https://github.com/httpwg/http-extensions/pull/1047 | ||||
[23] https://github.com/httpwg/http-extensions/issues/1059 | ||||
[24] https://github.com/httpwg/http-extensions/issues/1158 | ||||
[25] https://github.com/httpwg/http-extensions/pull/1060 | ||||
[26] https://github.com/httpwg/http-extensions/issues/1074 | ||||
[27] https://github.com/httpwg/http-extensions/issues/1119 | ||||
[28] https://github.com/httpwg/http-extensions/pull/1143 | ||||
[29] https://github.com/httpwg/http-extensions/issues/1159 | ||||
[30] https://github.com/httpwg/http-extensions/issues/1234 | ||||
[31] https://github.com/httpwg/http-extensions/pull/1325 | ||||
[32] https://github.com/httpwg/http-extensions/pull/1323 | ||||
[33] https://github.com/httpwg/http-extensions/pull/1324 | ||||
[34] https://github.com/httpwg/http-extensions/pull/1384 | ||||
[35] https://github.com/httpwg/http-extensions/pull/1348 | ||||
[36] https://github.com/httpwg/http-extensions/pull/1416 | ||||
[37] https://github.com/httpwg/http-extensions/pull/1420 | ||||
[38] https://github.com/httpwg/http-extensions/pull/1428 | ||||
[39] https://github.com/httpwg/http-extensions/pull/1435 | ||||
[40] https://github.com/httpwg/http-extensions/pull/1527 | ||||
[41] https://github.com/httpwg/http-extensions/pull/1563 | ||||
[42] https://github.com/httpwg/http-extensions/pull/1576 | ||||
[43] https://github.com/httpwg/http-extensions/pull/1589 | ||||
[44] https://github.com/httpwg/http-extensions/pull/1709 | ||||
[45] https://github.com/httpwg/http-extensions/pull/1732 | ||||
[46] https://github.com/httpwg/http-extensions/pull/1980 | ||||
[47] https://github.com/httpwg/http-extensions/pull/1878 | ||||
[48] https://github.com/httpwg/http-extensions/pull/1902 | ||||
[49] https://github.com/httpwg/http-extensions/pull/1969 | ||||
[50] https://github.com/httpwg/http-extensions/pull/1789 | ||||
[51] https://github.com/httpwg/http-extensions/pull/1858 | ||||
[52] https://github.com/httpwg/http-extensions/pull/2069 | ||||
[53] https://github.com/httpwg/http-extensions/pull/2087 | ||||
[54] https://github.com/httpwg/http-extensions/pull/2092 | ||||
[55] https://github.com/httpwg/http-extensions/pull/2090 | ||||
[56] https://github.com/httpwg/http-extensions/pull/2165 | ||||
[57] https://github.com/httpwg/http-extensions/pull/2167 | ||||
[58] https://github.com/httpwg/http-extensions/pull/2215 | ||||
[59] https://github.com/httpwg/http-extensions/pull/2220 | ||||
[60] https://github.com/httpwg/http-extensions/pull/2217 | ||||
[61] https://github.com/httpwg/http-extensions/pull/2236 | ||||
[62] https://github.com/httpwg/http-extensions/pull/2244 | ||||
[63] https://github.com/httpwg/http-extensions/pull/2251 | ||||
[64] https://github.com/httpwg/http-extensions/pull/2478 | ||||
[65] https://github.com/httpwg/http-extensions/pull/2481 | ||||
[66] https://github.com/httpwg/http-extensions/pull/2478 | ||||
[67] https://github.com/httpwg/http-extensions/pull/2753 | ||||
[68] https://github.com/httpwg/http-extensions/pull/2759 | ||||
[69] https://github.com/httpwg/http-extensions/pull/2758 | ||||
[70] https://github.com/httpwg/http-extensions/pull/2750 | ||||
Appendix A. Changes | ||||
A.1. draft-ietf-httpbis-rfc6265bis-00 | ||||
o Port [RFC6265] to Markdown. No (intentional) normative changes. | ||||
A.2. draft-ietf-httpbis-rfc6265bis-01 | ||||
o Fixes to formatting caused by mistakes in the initial port to | ||||
Markdown: | ||||
* https://github.com/httpwg/http-extensions/issues/243 [2] | ||||
* https://github.com/httpwg/http-extensions/issues/246 [3] | ||||
o Addresses errata 3444 by updating the "path-value" and "extension- | ||||
av" grammar, errata 4148 by updating the "day-of-month", "year", | ||||
and "time" grammar, and errata 3663 by adding the requested note. | ||||
https://www.rfc-editor.org/errata_search.php?rfc=6265 [4] | ||||
o Dropped "Cookie2" and "Set-Cookie2" from the IANA Considerations | ||||
section: https://github.com/httpwg/http-extensions/issues/247 [5] | ||||
o Merged the recommendations from [I-D.ietf-httpbis-cookie-alone], | ||||
removing the ability for a non-secure origin to set cookies with a | ||||
'secure' flag, and to overwrite cookies whose 'secure' flag is | ||||
true. | ||||
o Merged the recommendations from | ||||
[I-D.ietf-httpbis-cookie-prefixes], adding "__Secure-" and | ||||
"__Host-" cookie name prefix processing instructions. | ||||
A.3. draft-ietf-httpbis-rfc6265bis-02 | ||||
o Merged the recommendations from | ||||
[I-D.ietf-httpbis-cookie-same-site], adding support for the | ||||
"SameSite" attribute. | ||||
o Closed a number of editorial bugs: | ||||
* Clarified address bar behavior for SameSite cookies: | ||||
https://github.com/httpwg/http-extensions/issues/201 [6] | ||||
* Added the word "Cookies" to the document's name: | ||||
https://github.com/httpwg/http-extensions/issues/204 [7] | ||||
* Clarified that the "__Host-" prefix requires an explicit "Path" | ||||
attribute: https://github.com/httpwg/http-extensions/issues/222 | ||||
[8] | ||||
* Expanded the options for dealing with third-party cookies to | ||||
include a brief mention of partitioning based on first-party: | ||||
https://github.com/httpwg/http-extensions/issues/248 [9] | ||||
* Noted that double-quotes in cookie values are part of the | ||||
value, and are not stripped: https://github.com/httpwg/http- | ||||
extensions/issues/295 [10] | ||||
* Fixed the "site for cookies" algorithm to return something that | ||||
makes sense: https://github.com/httpwg/http-extensions/ | ||||
issues/302 [11] | ||||
A.4. draft-ietf-httpbis-rfc6265bis-03 | ||||
o Clarified handling of invalid SameSite values: | ||||
https://github.com/httpwg/http-extensions/issues/389 [12] | ||||
o Reflect widespread implementation practice of including a cookie's | ||||
"host-only-flag" when calculating its uniqueness: | ||||
https://github.com/httpwg/http-extensions/issues/199 [13] | ||||
o Introduced an explicit "None" value for the SameSite attribute: | ||||
https://github.com/httpwg/http-extensions/issues/788 [14] | ||||
A.5. draft-ietf-httpbis-rfc6265bis-04 | ||||
o Allow "SameSite" cookies to be set for all top-level navigations. | ||||
https://github.com/httpwg/http-extensions/issues/594 [15] | ||||
o Treat "Set-Cookie: token" as creating the cookie "("", "token")": | ||||
https://github.com/httpwg/http-extensions/issues/159 [16] | ||||
o Reject cookies with neither name nor value (e.g. "Set-Cookie: =" | ||||
and "Set-Cookie:": https://github.com/httpwg/http-extensions/ | ||||
issues/159 [17] | ||||
o Clarified behavior of multiple "SameSite" attributes in a cookie | ||||
string: https://github.com/httpwg/http-extensions/issues/901 [18] | ||||
A.6. draft-ietf-httpbis-rfc6265bis-05 | ||||
o Typos and editorial fixes: https://github.com/httpwg/http- | ||||
extensions/pull/1035 [19], https://github.com/httpwg/http- | ||||
extensions/pull/1038 [20], https://github.com/httpwg/http- | ||||
extensions/pull/1040 [21], https://github.com/httpwg/http- | ||||
extensions/pull/1047 [22]. | ||||
A.7. draft-ietf-httpbis-rfc6265bis-06 | ||||
o Editorial fixes: https://github.com/httpwg/http-extensions/ | ||||
issues/1059 [23], https://github.com/httpwg/http-extensions/ | ||||
issues/1158 [24]. | ||||
o Created a registry for cookie attribute names: | ||||
https://github.com/httpwg/http-extensions/pull/1060 [25]. | ||||
o Tweaks to ABNF for "cookie-pair" and the "Cookie" header | ||||
production: https://github.com/httpwg/http-extensions/issues/1074 | ||||
[26], https://github.com/httpwg/http-extensions/issues/1119 [27]. | ||||
o Fixed serialization for nameless/valueless cookies: | ||||
https://github.com/httpwg/http-extensions/pull/1143 [28]. | ||||
o Converted a normative reference to Mozilla's Public Suffix List | ||||
[PSL] into an informative reference: https://github.com/httpwg/ | ||||
http-extensions/issues/1159 [29]. | ||||
A.8. draft-ietf-httpbis-rfc6265bis-07 | ||||
o Moved instruction to ignore cookies with empty cookie-name and | ||||
cookie-value from Section 5.5 to Section 5.6 to ensure that they | ||||
apply to cookies created without parsing a cookie string: | ||||
https://github.com/httpwg/http-extensions/issues/1234 [30]. | ||||
o Add a default enforcement value to the "same-site-flag", | ||||
equivalent to "SameSite=Lax": https://github.com/httpwg/http- | ||||
extensions/pull/1325 [31]. | ||||
o Require a Secure attribute for "SameSite=None": | ||||
https://github.com/httpwg/http-extensions/pull/1323 [32]. | ||||
o Consider scheme when running the same-site algorithm: | ||||
https://github.com/httpwg/http-extensions/pull/1324 [33]. | ||||
A.9. draft-ietf-httpbis-rfc6265bis-08 | ||||
o Define "same-site" for reload navigation requests, e.g. those | ||||
triggered via user interface elements: https://github.com/httpwg/ | ||||
http-extensions/pull/1384 [34] | ||||
o Consider redirects when defining same-site: | ||||
https://github.com/httpwg/http-extensions/pull/1348 [35] | ||||
o Align on using HTML terminology for origins: | ||||
https://github.com/httpwg/http-extensions/pull/1416 [36] | ||||
o Modify cookie parsing and creation algorithms in Section 5.5 and | ||||
Section 5.6 to explicitly handle control characters: | ||||
https://github.com/httpwg/http-extensions/pull/1420 [37] | ||||
o Refactor cookie retrieval algorithm to support non-HTTP APIs: | ||||
https://github.com/httpwg/http-extensions/pull/1428 [38] | ||||
o Define "Lax-allowing-unsafe" SameSite enforcement mode: | ||||
https://github.com/httpwg/http-extensions/pull/1435 [39] | ||||
o Consistently use "header field" (vs 'header"): | ||||
https://github.com/httpwg/http-extensions/pull/1527 [40] | ||||
A.10. draft-ietf-httpbis-rfc6265bis-09 | ||||
o Update cookie size requirements: https://github.com/httpwg/http- | ||||
extensions/pull/1563 [41] | ||||
o Reject cookies with control characters: https://github.com/httpwg/ | ||||
http-extensions/pull/1576 [42] | ||||
o No longer treat horizontal tab as a control character: | ||||
https://github.com/httpwg/http-extensions/pull/1589 [43] | ||||
o Specify empty domain attribute handling: | ||||
https://github.com/httpwg/http-extensions/pull/1709 [44] | ||||
A.11. draft-ietf-httpbis-rfc6265bis-10 | ||||
o Standardize Max-Age/Expires upper bound: | ||||
https://github.com/httpwg/http-extensions/pull/1732 [45], | ||||
https://github.com/httpwg/http-extensions/pull/1980 [46]. | ||||
o Expand on privacy considerations and third-party cookies: | ||||
https://github.com/httpwg/http-extensions/pull/1878 [47] | ||||
o Specify that no decoding of Set-Cookie line should occur: | ||||
https://github.com/httpwg/http-extensions/pull/1902 [48] | ||||
o Require ASCII for domain attributes: https://github.com/httpwg/ | ||||
http-extensions/pull/1969 [49] | ||||
o Typos, formatting and editorial fixes: https://github.com/httpwg/ | o Adds the same-site concept and the SameSite attribute. | |||
http-extensions/pull/1789 [50], https://github.com/httpwg/http- | (Section 5.2 and Section 4.1.2.7) | |||
extensions/pull/1858 [51], https://github.com/httpwg/http- | ||||
extensions/pull/2069 [52]. | ||||
A.12. draft-ietf-httpbis-rfc6265bis-11 | o Introduces cookie prefixes and prohibits nameless cookies from | |||
setting a value that would mimic a cookie prefix. (Section 4.1.3 | ||||
and Section 5.7) | ||||
o Remove note to ignore Domain attribute with trailing dot: | o Prohibits non-secure origins from setting cookies with a 'secure' | |||
https://github.com/httpwg/http-extensions/pull/2087 [53], | flag or overwriting cookies with this flag. (Section 5.7) | |||
https://github.com/httpwg/http-extensions/pull/2092 [54]. | ||||
o Remove an inadvertant change to cookie-octet: | o Limits maximum cookie size. (Section 5.7) | |||
https://github.com/httpwg/http-extensions/pull/2090 [55] | ||||
o Remove note regarding cookie serialization: | o Limits maximum values for max-age and expire. (Section 5.6.1 and | |||
https://github.com/httpwg/http-extensions/pull/2165 [56] | Section 5.6.2) | |||
o Add case insensitivity note to Set-Cookie Syntax: | o Includes the host-only-flag as part of a cookie's uniqueness | |||
https://github.com/httpwg/http-extensions/pull/2167 [57] | computation. (Section 5.7) | |||
o Add note not to send invalid cookies due to public suffix list | o Considers potentially trustworthy origins as "secure". | |||
changes: https://github.com/httpwg/http-extensions/pull/2215 [58] | (Section 5.7) | |||
o Add warning to not send nameless cookies: | o Improves cookie syntax | |||
https://github.com/httpwg/http-extensions/pull/2220 [59] | ||||
o Add note regarding Service Worker's computation of "site for | * Treats Set-Cookie: token as creating the cookie ("", "token"). | |||
cookies": https://github.com/httpwg/http-extensions/pull/2217 [60] | (Section 5.6) | |||
o Compare cookie name prefixes case-insensitively: | * Rejects cookies without a name nor value. (Section 5.7) | |||
https://github.com/httpwg/http-extensions/pull/2236 [61] | ||||
o Update editors and the acknowledgements https://github.com/httpwg/ | * Specifies how to serialize a nameless/valueless cookie. | |||
http-extensions/pull/2244 [62] | (Section 5.8.3) | |||
o Prevent nameless cookies with prefixed values | * Adjusts ABNF for cookie-pair and the Cookie header production | |||
https://github.com/httpwg/http-extensions/pull/2251 [63] | to allow for spaces. (Section 4.1.1) | |||
A.13. draft-ietf-httpbis-rfc6265bis-12 | * Explicitly handle control characters. (Section 5.6 and | |||
Section 5.7) | ||||
o Advise the reader which section to implement | * Specifies how to handle empty domain attributes. (Section 5.7) | |||
https://github.com/httpwg/http-extensions/pull/2478 [64] | ||||
o Define top-level navigation https://github.com/httpwg/http- | * Requires ASCII characters for the domain attribute. | |||
extensions/pull/2481 [65] | (Section 5.7) | |||
o Use navigables concept https://github.com/httpwg/http-extensions/ | o Refactors cookie retrieval algorithm to support non-HTTP APIs. | |||
pull/2478 [66] | (Section 5.8.2) | |||
A.14. draft-ietf-httpbis-rfc6265bis-14 | o Specifies that the Set-Cookie line should not be decoded. | |||
(Section 5.6) | ||||
o Refactor cookie header text https://github.com/httpwg/http- | o Adds an advisory section to assist implementers in deciding which | |||
extensions/pull/2753 [67] | requirements to implement. (Section 3.2) | |||
o Support potentially trustworthy origins https://github.com/httpwg/ | o Advises against sending invalid cookies due to public suffix list | |||
http-extensions/pull/2759 [68] | changes. (Section 5.8.3) | |||
o Add additional developer warnings for SameSite cookies | o Removes the single cookie header requirement. (Section 5.8.1) | |||
https://github.com/httpwg/http-extensions/pull/2758 [69] | ||||
o Remove consideration of same-site redirect chain | o Address errata 3444 by updating the path-value andextension-av | |||
https://github.com/httpwg/http-extensions/pull/2750 [70] | grammar, errata 4148 by updating the day-of-month, year, and time | |||
grammar, and errata 3663 by adding the requested note. | ||||
(Section 4.1 and Section 5.1.4) | ||||
Acknowledgements | Acknowledgements | |||
RFC 6265 was written by Adam Barth. This document is an update of | RFC 6265 was written by Adam Barth. This document is an update of | |||
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. | |||
End of changes. 87 change blocks. | ||||
497 lines changed or deleted | 179 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/ |