draft-ietf-httpbis-rfc6265bis-21.txt   draft-ietf-httpbis-rfc6265bis-latest.txt 
HTTP Working Group S. Bingler, Ed. HTTP Working Group S. Bingler, Ed.
Internet-Draft Internet-Draft
Obsoletes: 6265 (if approved) M. West, Ed. Obsoletes: 6265 (if approved) M. West, Ed.
Intended status: Standards Track Google LLC Intended status: Standards Track Google LLC
Expires: March 28, 2026 J. Wilander, Ed. Expires: May 28, 2026 J. Wilander, Ed.
Apple, Inc Apple, Inc
September 24, 2025 November 24, 2025
Cookies: HTTP State Management Mechanism Cookies: HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-21 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 flaws that degrade their security and
and privacy, the Cookie and Set-Cookie header fields are widely used privacy, the Cookie and Set-Cookie header fields are widely used on
on the Internet. This document obsoletes RFC 6265. the Internet. This document obsoletes RFC 6265.
About This Document About This Document
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Status information for this document may be found at Status information for this document may be found at
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/>. <https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/>.
Discussion of this document takes place on the HTTP Working Group Discussion of this document takes place on the HTTP Working Group
mailing list (<mailto:ietf-http-wg@w3.org>), which is archived at mailing list (<mailto:ietf-http-wg@w3.org>), which is archived at
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 28, 2026. This Internet-Draft will expire on May 28, 2026.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
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 . . . . . . . . . . . . . . . . . . . . . 5 2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Name Resolution System . . . . . . . . . . . . . . . . . 7
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Which Requirements to Implement . . . . . . . . . . . . . 10 3.2. Which Requirements to Implement . . . . . . . . . . . . . 10
3.2.1. Cookie Producing Implementations . . . . . . . . . . 10 3.2.1. Cookie Producing Implementations . . . . . . . . . . 11
3.2.2. Cookie Consuming Implementations . . . . . . . . . . 11 3.2.2. Cookie Consuming Implementations . . . . . . . . . . 11
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 11 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 12
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Set-Cookie Header . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 14 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 14
4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 17 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 18
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Cookie Header . . . . . . . . . . . . . . . . . . . . . . 19
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 19 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 20
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 19 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 20
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 20 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 20
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 22 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 22
5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 22 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 23
5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 22 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 23
5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 23 5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 24
5.2.1. Document-based requests . . . . . . . . . . . . . . . 24 5.2.1. Document-based requests . . . . . . . . . . . . . . . 24
5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 25 5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 25
5.3. Ignoring Set-Cookie Header Fields . . . . . . . . . . . . 26 5.3. Ignoring Set-Cookie Header Fields . . . . . . . . . . . . 26
5.4. Cookie Name Prefixes . . . . . . . . . . . . . . . . . . 26 5.4. Cookie Name Prefixes . . . . . . . . . . . . . . . . . . 27
5.5. Cookie Lifetime Limits . . . . . . . . . . . . . . . . . 27 5.5. Cookie Lifetime Limits . . . . . . . . . . . . . . . . . 28
5.6. The Set-Cookie Header Field . . . . . . . . . . . . . . . 28 5.6. The Set-Cookie Header Field . . . . . . . . . . . . . . . 28
5.6.1. The Expires Attribute . . . . . . . . . . . . . . . . 30 5.6.1. The Expires Attribute . . . . . . . . . . . . . . . . 31
5.6.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 31 5.6.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 32
5.6.3. The Domain Attribute . . . . . . . . . . . . . . . . 31 5.6.3. The Domain Attribute . . . . . . . . . . . . . . . . 32
5.6.4. The Path Attribute . . . . . . . . . . . . . . . . . 32 5.6.4. The Path Attribute . . . . . . . . . . . . . . . . . 33
5.6.5. The Secure Attribute . . . . . . . . . . . . . . . . 32 5.6.5. The Secure Attribute . . . . . . . . . . . . . . . . 33
5.6.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 32 5.6.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 33
5.6.7. The SameSite Attribute . . . . . . . . . . . . . . . 32 5.6.7. The SameSite Attribute . . . . . . . . . . . . . . . 33
5.7. Storage Model . . . . . . . . . . . . . . . . . . . . . . 34 5.7. Storage Model . . . . . . . . . . . . . . . . . . . . . . 35
5.8. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 40 5.8. Retrieval Model . . . . . . . . . . . . . . . . . . . . . 41
5.8.1. The Cookie Header Field . . . . . . . . . . . . . . . 40 5.8.1. The Cookie Header Field . . . . . . . . . . . . . . . 41
5.8.2. Non-HTTP APIs . . . . . . . . . . . . . . . . . . . . 41 5.8.2. Non-HTTP APIs . . . . . . . . . . . . . . . . . . . . 42
5.8.3. Retrieval Algorithm . . . . . . . . . . . . . . . . . 41 5.8.3. Retrieval Algorithm . . . . . . . . . . . . . . . . . 42
6. Implementation Considerations . . . . . . . . . . . . . . . . 43 6. Implementation Considerations . . . . . . . . . . . . . . . . 44
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2. Application Programming Interfaces . . . . . . . . . . . 43 6.2. Application Programming Interfaces . . . . . . . . . . . 45
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 45
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 45 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 46
7.2. Cookie Policy . . . . . . . . . . . . . . . . . . . . . . 45 7.2. Cookie Policy . . . . . . . . . . . . . . . . . . . . . . 47
7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 46 7.3. User Controls . . . . . . . . . . . . . . . . . . . . . . 47
7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 46 7.4. Expiration Dates . . . . . . . . . . . . . . . . . . . . 47
8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 8. Security Considerations . . . . . . . . . . . . . . . . . . . 48
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 47 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 48
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 47 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 48
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 48 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 49
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 48 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 50
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 49 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 50
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 50 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 51
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 51 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 52
8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 51 8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 52
8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 51 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 52
8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 51 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 53
8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 52 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 53
8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 52 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 53
8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 52 8.8.5. Reload navigations . . . . . . . . . . . . . . . . . 54
8.8.6. Top-level requests with "unsafe" methods . . . . . . 53 8.8.6. Top-level requests with "unsafe" methods . . . . . . 55
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 8.9. Public Suffix List . . . . . . . . . . . . . . . . . . . 55
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 54 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 54 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.3. "Cookie Attributes" Registry . . . . . . . . . . . . . . 55 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 56
9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 55 9.3. "Cookie Attributes" Registry . . . . . . . . . . . . . . 56
9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 55 9.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 56
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 9.3.2. Registration . . . . . . . . . . . . . . . . . . . . 57
10.1. Normative References . . . . . . . . . . . . . . . . . . 55 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
10.2. Informative References . . . . . . . . . . . . . . . . . 57 10.1. Normative References . . . . . . . . . . . . . . . . . . 57
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 59 10.2. Informative References . . . . . . . . . . . . . . . . . 58
Appendix A. Changes from RFC 6265 . . . . . . . . . . . . . . . 59 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 60 Appendix A. Changes from RFC 6265 . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
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.
Although simple on their surface, cookies have a number of Although simple on their surface, cookies have a number of
complexities. For example, the server indicates a scope for each complexities. For example, the server indicates a scope for each
cookie when sending it to the user agent. The scope indicates the cookie when sending it to the user agent. The scope indicates the
maximum amount of time in which the user agent should return the maximum amount of time in which the user agent should return the
cookie, the servers to which the user agent should return the cookie, cookie, the servers to which the user agent should return the cookie,
and the connection types for which the cookie is applicable. and the connection types for which the cookie is applicable.
For historical reasons, cookies contain a number of security and For historical reasons, cookies contain a number of security and
privacy infelicities. For example, a server can indicate that a privacy flaws. For example, a server can indicate that a given
given cookie is intended for "secure" connections, but the Secure cookie is intended for "secure" connections, but the Secure attribute
attribute does not provide integrity in the presence of an active does not provide integrity in the presence of an active network
network attacker. Similarly, cookies for a given host are shared attacker. Similarly, cookies for a given host are shared across all
across all the ports on that host, even though the usual "same-origin the ports on that host, even though the usual "same-origin policy"
policy" used by web browsers isolates content retrieved via different used by web browsers isolates content retrieved via different ports.
ports.
This specification applies to developers of both cookie-producing This specification applies to developers of both cookie-producing
servers and cookie-consuming user agents. Section 3.2 helps to servers and cookie-consuming user agents. Section 3.2 helps to
clarify the intended target audience for each implementation type. clarify the intended target audience for each implementation type.
To maximize interoperability with user agents, servers SHOULD limit To maximize interoperability with user agents, servers SHOULD limit
themselves to the well-behaved profile defined in Section 4 when themselves to the well-behaved profile defined in Section 4 when
generating cookies. generating cookies.
User agents MUST implement the more liberal processing rules defined User agents MUST implement the more liberal processing rules defined
skipping to change at page 7, line 10 skipping to change at page 7, line 17
[RFC6454]. [RFC6454].
"Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as
defined in Section 9.2.1 of [HTTP]. defined in Section 9.2.1 of [HTTP].
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". See Section 8.9 for security
SHOULD use an up-to-date public suffix list, such as the one considerations.
maintained by the Mozilla project at [PSL].
The term "request", as well as a request's "client", "current url", The term "request", as well as a request's "client", "current url",
"method", "target browsing context", and "url list", are defined in "method", "target browsing context", and "url list", are defined in
[FETCH]. [FETCH].
The term "non-HTTP APIs" refers to non-HTTP mechanisms used to set The term "non-HTTP APIs" refers to non-HTTP mechanisms used to set
and retrieve cookies, such as a web browser API that exposes cookies and retrieve cookies, such as a web browser API that exposes cookies
to scripts. to scripts.
The term "top-level navigation" refers to a navigation of a top-level The term "top-level navigation" refers to a navigation of a top-level
traversable. traversable.
2.4. Name Resolution System
While this document does not strictly prescribe any specific name
resolution system for use with cookies it does require that the
system uses only [USASCII] characters or uses an ASCII-compatible
encoding (ACE). As the Domain Name System (DNS) is a typical and
conventional example this document will reference name resolution in
terms of DNS.
Name resolution systems that directly expose non-ASCII characters,
such as Unicode, are out of scope of this document.
3. Overview 3. Overview
This section outlines a way for an origin server to send state This section outlines a way for an origin server to send state
information to a user agent and for the user agent to return the information to a user agent and for the user agent to return the
state information to the origin server. state information to the origin server.
To store state, the origin server includes a Set-Cookie header field To store state, the origin server includes a Set-Cookie header field
in an HTTP response. In subsequent requests, the user agent returns in an HTTP response. In subsequent requests, the user agent returns
a Cookie request header field to the origin server. The Cookie a Cookie request header field to the origin server. The Cookie
header field contains cookies the user agent received in previous header field contains cookies the user agent received in previous
skipping to change at page 9, line 42 skipping to change at page 10, line 23
If the server wishes the user agent to persist the cookie over If the server wishes the user agent to persist the cookie over
multiple "sessions" (e.g., user agent restarts), the server can multiple "sessions" (e.g., user agent restarts), the server can
specify an expiration date in the Expires attribute. Note that the specify an expiration date in the Expires attribute. Note that the
user agent might delete the cookie before the expiration date if the user agent might delete the cookie before the expiration date if the
user agent's cookie store exceeds its quota or if the user manually user agent's cookie store exceeds its quota or if the user manually
deletes the server's cookie. deletes the server's cookie.
== Server -> User Agent == == Server -> User Agent ==
Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2026 10:18:14 GMT
== User Agent -> Server == == User Agent -> Server ==
Cookie: SID=31d4d96e407aad42; lang=en-US Cookie: SID=31d4d96e407aad42; lang=en-US
Finally, to remove a cookie, the server returns a Set-Cookie header Finally, to remove a cookie, the server returns a Set-Cookie header
field with an expiration date in the past. The server will be field with an expiration date in the past. The server will be
successful in removing the cookie only if the Path and the Domain successful in removing the cookie only if the Path and the Domain
attribute in the Set-Cookie header field match the values used when attribute in the Set-Cookie header field match the values used when
the cookie was created. the cookie was created.
skipping to change at page 12, line 5 skipping to change at page 12, line 31
Section 4's requirements. Section 4's requirements.
Doing so will reduce the chances that a developer's application can Doing so will reduce the chances that a developer's application can
inadvertently create cookies that cannot be read by other servers. inadvertently create cookies that cannot be read by other servers.
4. Server Requirements 4. Server Requirements
This section describes the syntax and semantics of a well-behaved This section describes the syntax and semantics of a well-behaved
profile of the Cookie and Set-Cookie header fields. profile of the Cookie and Set-Cookie header fields.
4.1. Set-Cookie 4.1. Set-Cookie Header
The Set-Cookie HTTP response header field is used to send cookies The Set-Cookie HTTP response header field is used to send cookies
from the server to the user agent. from the server to the user agent.
4.1.1. Syntax 4.1.1. Syntax
Informally, the Set-Cookie response header field contains a cookie, Informally, the Set-Cookie response header field contains a cookie,
which begins with a name-value-pair, followed by zero or more which begins with a name-value-pair, followed by zero or more
attribute-value pairs. Servers conforming to this profile MUST NOT attribute-value pairs. Servers conforming to this profile MUST NOT
send Set-Cookie header fields that deviate from the following send Set-Cookie header fields that deviate from the following
skipping to change at page 12, line 47 skipping to change at page 13, line 34
; 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"
samesite-av = "SameSite" BWS "=" BWS samesite-value samesite-av = "SameSite" BWS "=" BWS samesite-value
samesite-value = "Strict" / "Lax" / "None" samesite-value = "Strict" / "Lax" / "None"
extension-av = *av-octet extension-av = 1*av-octet
av-octet = %x20-3A / %x3C-7E av-octet = %x20-3A / %x3C-7E
; any CHAR except CTLs or ";" ; any CHAR except CTLs or ";"
Note that some of the grammatical terms above reference documents Note that some of the grammatical terms above reference documents
that use different grammatical notations than this document (which that use different grammatical notations than this document (which
uses ABNF from [RFC5234]). uses ABNF from [RFC5234]).
Per the grammar above, servers MUST NOT produce nameless cookies Per the grammar above, servers MUST NOT produce nameless cookies
(i.e.: an empty cookie-name) as such cookies may be unpredictably (i.e.: an empty cookie-name) as such cookies may be unpredictably
serialized by UAs when sent back to the server. serialized by UAs when sent back to the server.
skipping to change at page 13, line 24 skipping to change at page 14, line 10
To maximize compatibility with user agents, servers that wish to To maximize compatibility with user agents, servers that wish to
store arbitrary data in a cookie-value SHOULD encode that data, for store arbitrary data in a cookie-value SHOULD encode that data, for
example, using Base64 [RFC4648]. example, using Base64 [RFC4648].
Per the grammar above, the cookie-value MAY be wrapped in DQUOTE Per the grammar above, the cookie-value MAY be wrapped in DQUOTE
characters. Note that in this case, the initial and trailing DQUOTE characters. Note that in this case, the initial and trailing DQUOTE
characters are not stripped. They are part of the cookie-value, and characters are not stripped. They are part of the cookie-value, and
will be included in Cookie header fields sent to the server. will be included in Cookie header fields sent to the server.
Per the grammar above, cookie-avs MUST NOT contain leading or Per the grammar above, extension-av MUST NOT contain leading or
trailing WSP characters as they will be interpreted as BWS and trailing WSP characters as they will be interpreted as BWS and
removed. removed.
The domain-value is a subdomain as defined by Section 3.5 of The domain-value is a subdomain as defined by Section 3.5 of
[RFC1034], and as enhanced by Section 2.1 of [RFC1123]. Thus, [RFC1034], and as enhanced by Section 2.1 of [RFC1123]. Thus,
domain-value is a string of [USASCII] characters, such as an domain-value is a string of [USASCII] characters, such as an
"A-label" as defined in Section 2.3.2.1 of [RFC5890]. "A-label" as defined in Section 2.3.2.1 of [RFC5890].
The portions of the set-cookie-string produced by the cookie-av term The portions of the set-cookie-string produced by the cookie-av term
are known as attributes. To maximize compatibility with user agents, are known as attributes. To maximize compatibility with user agents,
skipping to change at page 15, line 29 skipping to change at page 16, line 13
cookie. If a cookie has neither the Max-Age nor the Expires cookie. If a cookie has neither the Max-Age nor the Expires
attribute, the user agent will retain the cookie until "the current attribute, the user agent will retain the cookie until "the current
session is over" (as defined by the user agent). session is over" (as defined by the user agent).
4.1.2.3. The Domain Attribute 4.1.2.3. The Domain Attribute
The Domain attribute specifies those hosts to which the cookie will The Domain attribute specifies those hosts to which the cookie will
be sent. For example, if the value of the Domain attribute is be sent. For example, if the value of the Domain attribute is
"site.example", the user agent will include the cookie in the Cookie "site.example", the user agent will include the cookie in the Cookie
header field when making HTTP requests to site.example, header field when making HTTP requests to site.example,
www.site.example, and www.corp.site.example. (Note that a leading www.site.example, and www.corp.site.example. If the server omits the
%x2E ("."), if present, is ignored even though that character is not Domain attribute, the user agent will return the cookie only to the
permitted.) If the server omits the Domain attribute, the user agent origin server.
will return the cookie only to the origin server.
WARNING: Some existing user agents treat an absent Domain attribute WARNING: Some existing user agents treat an absent Domain attribute
as if the Domain attribute were present and contained the current as if the Domain attribute were present and contained the current
host name. For example, if site.example returns a Set-Cookie header host name. For example, if site.example returns a Set-Cookie header
field without a Domain attribute, these user agents will erroneously field without a Domain attribute, these user agents will erroneously
send the cookie to www.site.example as well. send the cookie to www.site.example as well.
The user agent will reject cookies unless the Domain attribute The user agent will reject cookies unless the Domain attribute
specifies a scope for the cookie that would include the origin specifies a scope for the cookie that would include the origin
server. For example, the user agent will accept a cookie with a server. For example, the user agent will accept a cookie with a
skipping to change at page 18, line 37 skipping to change at page 19, line 23
Set-Cookie: __Host-SID=12345; Secure Set-Cookie: __Host-SID=12345; Secure
Set-Cookie: __Host-SID=12345; Domain=site.example Set-Cookie: __Host-SID=12345; Domain=site.example
Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/ Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/
Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/ Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/
While the following would be accepted if set from a secure origin While the following would be accepted if set from a secure origin
(e.g. "https://site.example/"), and rejected otherwise: (e.g. "https://site.example/"), and rejected otherwise:
Set-Cookie: __Host-SID=12345; Secure; Path=/ Set-Cookie: __Host-SID=12345; Secure; Path=/
4.2. Cookie 4.2. Cookie Header
4.2.1. Syntax 4.2.1. Syntax
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
skipping to change at page 22, line 15 skipping to change at page 23, line 5
7. Return the parsed-cookie-date as the result of this algorithm. 7. Return the parsed-cookie-date as the result of this algorithm.
5.1.2. Canonicalized Host Names 5.1.2. Canonicalized Host Names
A canonicalized host name is the string generated by the following A canonicalized host name is the string generated by the following
algorithm: algorithm:
1. Convert the host name to a sequence of individual domain name 1. Convert the host name to a sequence of individual domain name
labels. labels.
2. Convert each label that is not a Non-Reserved LDH (NR-LDH) label, 2. All labels must be one of U-label, A-label, or Non-Reserved LDH
to an A-label (see Section 2.3.2.1 of [RFC5890] for the former (NR-LDH) label (see Section 2.3.1 of [RFC5890]). If any label is
and latter). not one of these then abort this algorithm and fail to
canonicalize the host name.
3. Concatenate the resulting labels, separated by a %x2E (".") 3. Convert each U-label to an A-label (see Section 2.3.2.1 of
[RFC5890]).
4. If any label is a Fake A-label then abort this algorithm and fail
to canonicalize the host name.
5. Concatenate the resulting labels, separated by a %x2E (".")
character. character.
5.1.3. Domain Matching 5.1.3. Domain Matching
Note: This algorithm expects that both inputs are canonicalized.
A string domain-matches a given domain string if at least one of the A string domain-matches a given domain string if at least one of the
following conditions hold: following conditions hold:
o The domain string and the string are identical. (Note that both o The domain string and the string are identical. (Note that both
the domain string and the string will have been canonicalized to the domain string and the string will have been canonicalized to
lower case at this point.) lower case at this point.)
o All of the following conditions hold: o All of the following conditions hold:
* The domain string is a suffix of the string. * The domain string is a suffix of the string.
skipping to change at page 24, line 12 skipping to change at page 25, line 5
The request's client's "site for cookies" is calculated depending The request's client's "site for cookies" is calculated depending
upon its client's type, as described in the following subsections: upon its client's type, as described in the following subsections:
5.2.1. Document-based requests 5.2.1. Document-based requests
The URI displayed in a user agent's address bar is the only security The URI displayed in a user agent's address bar is the only security
context directly exposed to users, and therefore the only signal context directly exposed to users, and therefore the only signal
users can reasonably rely upon to determine whether or not they trust users can reasonably rely upon to determine whether or not they trust
a particular website. The origin of that URI represents the context a particular website. The origin of that URI represents the context
in which a user most likely believes themselves to be interacting. in which a user most likely believes themselves to be interacting.
We'll define this origin, the top-level traversable's active This origin, the top-level traversable's active document's origin, is
document's origin, as the "top-level origin". defined as the "top-level origin".
For a document displayed in a top-level traversable, we can stop For a document displayed in a top-level traversable, the document's
here: the document's "site for cookies" is the top-level origin. "site for cookies" is the top-level origin.
For container documents, we need to audit the origins of each of a For container documents, the origins of each of a document's ancestor
document's ancestor navigables' active documents in order to account navigables' active documents must be audited in order to account for
for the "multiple-nested scenarios" described in Section 4 of the "multiple-nested scenarios" described in Section 4 of [RFC7034].
[RFC7034]. A document's "site for cookies" is the top-level origin A document's "site for cookies" is the top-level origin if and only
if and only if the top-level origin is same-site with the document's if the top-level origin is same-site with the document's origin, and
origin, and with each of the document's ancestor documents' origins. with each of the document's ancestor documents' origins. Otherwise
Otherwise its "site for cookies" is an origin set to an opaque its "site for cookies" is an origin set to an opaque origin.
origin.
Given a Document ("document"), the following algorithm returns its Given a Document ("document"), the following algorithm returns its
"site for cookies": "site for cookies":
1. Let "top-document" be the active document in "document"'s 1. Let "top-document" be the active document in "document"'s
navigable's top-level traversable. navigable's top-level traversable.
2. Let "top-origin" be the origin of "top-document"'s URI if "top- 2. Let "top-origin" be the origin of "top-document"'s URI if "top-
document"'s sandboxed origin browsing context flag is set, and document"'s sandboxed origin browsing context flag is set, and
"top-document"'s origin otherwise. "top-document"'s origin otherwise.
skipping to change at page 36, line 15 skipping to change at page 37, line 15
Otherwise: Otherwise:
1. Let the domain-attribute be the empty string. 1. Let the domain-attribute be the empty string.
8. If the domain-attribute contains a character that is not in 8. If the domain-attribute contains a character that is not in
CHAR, abort this algorithm and ignore the cookie entirely. CHAR, abort this algorithm and ignore the cookie entirely.
9. If the user agent is configured to reject "public suffixes" and 9. If the user agent is configured to reject "public suffixes" and
the domain-attribute is a public suffix: the domain-attribute is a public suffix:
1. If the domain-attribute is identical to the canonicalized 1. Let request-host-canonical be the canonicalized request-
request-host: host.
2. If request-host fails to be canonicalized then abort this
algorithm and ignore the cookie entirely.
3. If the domain-attribute is identical to the request-host-
canonical:
1. Let the domain-attribute be the empty string. 1. Let the domain-attribute be the empty string.
Otherwise: Otherwise:
1. Abort this algorithm and ignore the cookie entirely. 1. Abort this algorithm and ignore the cookie entirely.
Note: This step prevents "attacker.example" from disrupting the Note: This step prevents "attacker.example" from disrupting the
integrity of "site.example" by setting a cookie with a Domain integrity of "site.example" by setting a cookie with a Domain
attribute of "example". attribute of "example".
10. If the domain-attribute is non-empty: 10. If the domain-attribute is non-empty:
1. If the canonicalized request-host does not domain-match the 1. If request-host-canonical does not domain-match (see
domain-attribute: Section 5.1.3) the domain-attribute:
1. Abort this algorithm and ignore the cookie entirely. 1. Abort this algorithm and ignore the cookie entirely.
Otherwise: Otherwise:
1. Set the cookie's host-only-flag to false. 1. Set the cookie's host-only-flag to false.
2. Set the cookie's domain to the domain-attribute. 2. Set the cookie's domain to the domain-attribute.
Otherwise: Otherwise:
1. Set the cookie's host-only-flag to true. 1. Set the cookie's host-only-flag to true.
2. Set the cookie's domain to the canonicalized request-host. 2. Set the cookie's domain to request-host-canonical.
11. If the cookie-attribute-list contains an attribute with an 11. If the cookie-attribute-list contains an attribute with an
attribute-name of "Path", set the cookie's path to attribute- attribute-name of "Path", set the cookie's path to attribute-
value of the last attribute in the cookie-attribute-list with value of the last attribute in the cookie-attribute-list with
both an attribute-name of "Path" and an attribute-value whose both an attribute-name of "Path" and an attribute-value whose
length is no more than 1024 octets. Otherwise, set the cookie's length is no more than 1024 octets. Otherwise, set the cookie's
path to the default-path of the request-uri. path to the default-path of the request-uri.
12. If the cookie-attribute-list contains an attribute with an 12. If the cookie-attribute-list contains an attribute with an
attribute-name of "Secure", set the cookie's secure-only-flag to attribute-name of "Secure", set the cookie's secure-only-flag to
skipping to change at page 37, line 30 skipping to change at page 38, line 37
16. If the cookie's secure-only-flag is false, and the request-uri 16. If the cookie's secure-only-flag is false, and the request-uri
does not denote a "secure" connection, then abort this algorithm does not denote a "secure" connection, then abort this algorithm
and ignore the cookie entirely if the cookie store contains one and ignore the cookie entirely if the cookie store contains one
or more cookies that meet all of the following criteria: or more cookies that meet all of the following criteria:
1. Their name matches the name of the newly-created cookie. 1. Their name matches the name of the newly-created cookie.
2. Their secure-only-flag is true. 2. Their secure-only-flag is true.
3. Their domain domain-matches the domain of the newly-created 3. Their domain domain-matches (see Section 5.1.3) the domain
cookie, or vice-versa. of the newly-created cookie, or vice-versa.
4. The path of the newly-created cookie path-matches the path 4. The path of the newly-created cookie path-matches the path
of the existing cookie. of the existing cookie.
Note: The path comparison is not symmetric, ensuring only that a Note: The path comparison is not symmetric, ensuring only that a
newly-created, non-secure cookie does not overlay an existing newly-created, non-secure cookie does not overlay an existing
secure cookie, providing some mitigation against cookie-fixing secure cookie, providing some mitigation against cookie-fixing
attacks. That is, given an existing secure cookie named 'a' attacks. That is, given an existing secure cookie named 'a'
with a path of '/login', a non-secure cookie named 'a' could be with a path of '/login', a non-secure cookie named 'a' could be
set for a path of '/' or '/foo', but not for a path of '/login' set for a path of '/' or '/foo', but not for a path of '/login'
skipping to change at page 41, line 28 skipping to change at page 42, line 31
[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.8.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 retrieval-host-canonical be the canonicalized host of the
retrieval's URI.
2. If the host of the retrieval's URI fails to be canonicalized then
abort this algorithm.
3. 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 retrieval-host-
host of the retrieval's URI is identical to the cookie's canonical is identical to the cookie's domain.
domain.
Or: Or:
+ The cookie's host-only-flag is false and the canonicalized + The cookie's host-only-flag is false and retrieval-host-
host of the retrieval's URI domain-matches the cookie's canonical domain-matches (see Section 5.1.3) the cookie's
domain. domain.
+ The cookie's domain is not a public suffix, for user agents + The cookie's domain is not a public suffix, for user agents
configured to reject "public suffixes". configured to reject "public suffixes".
Note: It's possible that the public suffix list was changed Note: It's possible that the public suffix list was changed
since the cookie was created. If this change resulted in the since the cookie was created. If this change resulted in the
cookie's domain becoming a public suffix then that cookie cookie's domain becoming a public suffix then that cookie
would have been rejected during creation if it had been would have been rejected during creation if it had been
created now. (See Section 5.7 step 9). created now. (See Section 5.7 step 9).
skipping to change at page 42, line 35 skipping to change at page 43, line 46
+ The same-site-flag is "Lax" or "Default". + The same-site-flag is "Lax" or "Default".
+ The HTTP request associated with the retrieval uses a + The HTTP request associated with the retrieval uses a
"safe" method. "safe" method.
+ The target browsing context of the HTTP request associated + The target browsing context of the HTTP request associated
with the retrieval is the active browsing context or a top- with the retrieval is the active browsing context or a top-
level traversable. level traversable.
2. The user agent SHOULD sort the cookie-list in the following 4. The user agent SHOULD sort the cookie-list in the following
order: order:
* Cookies with longer paths are listed before cookies with * Cookies with longer paths are listed before cookies with
shorter paths. shorter paths.
* Among cookies that have equal-length path fields, cookies with * Among cookies that have equal-length path fields, cookies with
earlier creation-times are listed before cookies with later earlier creation-times are listed before cookies with later
creation-times. creation-times.
Note: Not all user agents sort the cookie-list in this order, but Note: Not all user agents sort the cookie-list in this order, but
this order reflects common practice when this document was this order reflects common practice when this document was
written, and, historically, there have been servers that written, and, historically, there have been servers that
(erroneously) depended on this order. (erroneously) depended on this order.
3. Update the last-access-time of each cookie in the cookie-list to 5. Update the last-access-time of each cookie in the cookie-list to
the current date and time. the current date and time.
4. Serialize the cookie-list into a cookie-string by processing each 6. Serialize the cookie-list into a cookie-string by processing each
cookie in the cookie-list in order: cookie in the cookie-list in order:
1. If the cookies' name is not empty, output the cookie's name 1. If the cookies' name is not empty, output the cookie's name
followed by the %x3D ("=") character. followed by the %x3D ("=") character.
2. If the cookies' value is not empty, output the cookie's 2. If the cookies' value is not empty, output the cookie's
value. value.
3. If the cookie was not the last cookie in the cookie-list, 3. If the cookie was not the last cookie in the cookie-list,
output the characters %x3B and %x20 ("; "). output the characters %x3B and %x20 ("; ").
skipping to change at page 47, line 4 skipping to change at page 48, line 10
Although servers can set the expiration date for cookies to the Although servers can set the expiration date for cookies to the
distant future, most user agents do not actually retain cookies for distant future, most user agents do not actually retain cookies for
multiple decades. Rather than choosing gratuitously long expiration multiple decades. Rather than choosing gratuitously long expiration
periods, servers SHOULD promote user privacy by selecting reasonable periods, servers SHOULD promote user privacy by selecting reasonable
cookie expiration periods based on the purpose of the cookie. For cookie expiration periods based on the purpose of the cookie. For
example, a typical session identifier might reasonably be set to example, a typical session identifier might reasonably be set to
expire in two weeks. expire in two weeks.
8. Security Considerations 8. Security Considerations
8.1. Overview 8.1. Overview
Cookies have a number of security pitfalls. This section overviews a Cookies have a number of security pitfalls. This section overviews a
few of the more salient issues. few of the more salient issues.
In particular, cookies encourage developers to rely on ambient In particular, cookies encourage developers to rely on ambient
authority for authentication, often becoming vulnerable to attacks authority for authentication, often becoming vulnerable to attacks
such as cross-site request forgery [CSRF]. Also, when storing such as cross-site request forgery [CSRF]. Also, when storing
session identifiers in cookies, developers often create session session identifiers in cookies, developers often create session
fixation vulnerabilities. fixation vulnerabilities.
Transport-layer encryption, such as that employed in HTTPS, offers a Transport-layer encryption, such as that employed in HTTPS, offers a
significant layer of defense against network attacks on cookies. significant layer of defense against network attacks on cookies.
However, it is insufficient in fully preventing a networking attacker However, it is insufficient in fully preventing a networking attacker
from obtaining or altering a victim's cookies because of inherent from obtaining or altering a victim's cookies because of inherent
vulnerabilities in the cookie protocol itself (see "Weak vulnerabilities in the cookie protocol itself (see "Weak
Confidentiality" and "Weak Integrity", below). In addition, by Confidentiality" and "Weak Integrity", below). In addition, by
default, cookies do not provide confidentiality or integrity from default, cookies do not provide confidentiality or integrity from
network attackers, even when used in conjunction with HTTPS. network attackers, even when used in conjunction with HTTPS. This
means that a cookie needs to explicitly specify any protective
attributes. For example, the cookie:
"Set-Cookie: a=b"
doesn't specify the Secure attribute and will therefore be accessible
on both secure and insecure connections, regardless of the original
connection type it was created on. This behavior could allow an
attacker to read or modify the cookie.
8.2. Ambient Authority 8.2. Ambient Authority
A server that uses cookies to authenticate users can suffer security A server that uses cookies to authenticate users can suffer security
vulnerabilities because some user agents let remote parties issue vulnerabilities because some user agents let remote parties issue
HTTP requests from the user agent (e.g., via HTTP redirects or HTML HTTP requests from the user agent (e.g., via HTTP redirects or HTML
forms). When issuing those requests, user agents attach cookies even forms). When issuing those requests, user agents attach cookies even
if the remote party does not know the contents of the cookies, if the remote party does not know the contents of the cookies,
potentially letting the remote party exercise authority at an unwary potentially letting the remote party exercise authority at an unwary
server. server.
skipping to change at page 54, line 21 skipping to change at page 55, line 35
Section 5.6.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 recently created cookies (as compared to "None") while still allowing recently created cookies
to be sent 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.
8.9. Public Suffix List
The boundaries of cookies depend on a site's "registrable domain"
which in turn depends on the public suffix of the domain.
Whenever possible, user agents SHOULD use an up-to-date public suffix
list, such as the one maintained by the Mozilla project at [PSL].
Failure to do so could allow malicious or sensitive cookies to leak
between registrable domains.
9. IANA Considerations 9. IANA Considerations
9.1. Cookie 9.1. Cookie
The HTTP Field Name Registry (see [HttpFieldNameRegistry]) 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
skipping to change at page 55, line 48 skipping to change at page 57, line 27
| Path | Section 4.1.2.4 of this document | | Path | Section 4.1.2.4 of this document |
| SameSite | Section 4.1.2.7 of this document | | SameSite | Section 4.1.2.7 of this document |
| Secure | Section 4.1.2.5 of this document | | Secure | Section 4.1.2.5 of this document |
+----------+----------------------------------+ +----------+----------------------------------+
10. References 10. References
10.1. Normative References 10.1. Normative References
[DOM-DOCUMENT-COOKIE] [DOM-DOCUMENT-COOKIE]
WHATWG, "HTML - Living Standard", May 2021, van Kesteren, A., Denicola, D., Farolino, D., Hickson, I.,
<https://html.spec.whatwg.org/#dom-document-cookie>. Jaegenstedt, P., and S. Pieters, "HTML - Living Standard",
n.d., <https://html.spec.whatwg.org/#dom-document-cookie>.
WHATWG
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
skipping to change at page 57, line 6 skipping to change at page 58, line 34
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SAMESITE] [SAMESITE]
WHATWG, "HTML - Living Standard", January 2021, van Kesteren, A., Denicola, D., Farolino, D., Hickson, I.,
<https://html.spec.whatwg.org/#same-site>. Jaegenstedt, P., and S. Pieters, "HTML Living Standard",
n.d., <https://html.spec.whatwg.org/#same-site>.
WHATWG
[USASCII] American National Standards Institute, "Coded Character [USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986. Interchange", ANSI X3.4, 1986.
10.2. Informative References 10.2. Informative References
[Aggarwal2010] [Aggarwal2010]
Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh, Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh,
"An Analysis of Private Browsing Modes in Modern "An Analysis of Private Browsing Modes in Modern
 End of changes. 44 change blocks. 
126 lines changed or deleted 183 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/