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/