draft-ietf-httpbis-rfc6265bis-02.txt   draft-ietf-httpbis-rfc6265bis-03.txt 
HTTP Working Group A. Barth HTTP Working Group A. Barth
Internet-Draft M. West Internet-Draft M. West
Obsoletes: 6265 (if approved) Google, Inc Obsoletes: 6265 (if approved) Google, Inc
Intended status: Standards Track August 7, 2017 Intended status: Standards Track April 27, 2019
Expires: February 8, 2018 Expires: October 29, 2019
Cookies: HTTP State Management Mechanism Cookies: HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-02 draft-ietf-httpbis-rfc6265bis-03
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.
Note to Readers Note to Readers
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/ . https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].
Working Group information can be found at http://httpwg.github.io/ ; Working Group information can be found at http://httpwg.github.io/
source code and issues list for this draft can be found at [2]; source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/6265bis . https://github.com/httpwg/http-extensions/labels/6265bis [3].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 February 8, 2018. This Internet-Draft will expire on October 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2019 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
(http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 51 skipping to change at page 2, line 51
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 9 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 9
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 11
4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 14 4.1.3. Cookie Name Prefixes . . . . . . . . . . . . . . . . 14
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 16
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16
5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 16 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 16
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 18 5.1.2. Canonicalized Host Names . . . . . . . . . . . . . . 18
5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 19 5.1.3. Domain Matching . . . . . . . . . . . . . . . . . . . 19
5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 19 5.1.4. Paths and Path-Match . . . . . . . . . . . . . . . . 19
5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 20 5.2. "Same-site" and "cross-site" Requests . . . . . . . . . . 20
5.2.1. Document-based requests . . . . . . . . . . . . . . . 20 5.2.1. Document-based requests . . . . . . . . . . . . . . . 21
5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 21 5.2.2. Worker-based requests . . . . . . . . . . . . . . . . 22
5.3. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 23 5.3. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 23
5.3.1. The Expires Attribute . . . . . . . . . . . . . . . . 25 5.3.1. The Expires Attribute . . . . . . . . . . . . . . . . 25
5.3.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 25 5.3.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 26
5.3.3. The Domain Attribute . . . . . . . . . . . . . . . . 26 5.3.3. The Domain Attribute . . . . . . . . . . . . . . . . 26
5.3.4. The Path Attribute . . . . . . . . . . . . . . . . . 26 5.3.4. The Path Attribute . . . . . . . . . . . . . . . . . 27
5.3.5. The Secure Attribute . . . . . . . . . . . . . . . . 27 5.3.5. The Secure Attribute . . . . . . . . . . . . . . . . 27
5.3.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27 5.3.6. The HttpOnly Attribute . . . . . . . . . . . . . . . 27
5.3.7. The SameSite Attribute . . . . . . . . . . . . . . . 27 5.3.7. The SameSite Attribute . . . . . . . . . . . . . . . 27
5.4. Storage Model . . . . . . . . . . . . . . . . . . . . . . 28 5.4. Storage Model . . . . . . . . . . . . . . . . . . . . . . 28
5.5. The Cookie Header . . . . . . . . . . . . . . . . . . . . 33 5.5. The Cookie Header . . . . . . . . . . . . . . . . . . . . 33
6. Implementation Considerations . . . . . . . . . . . . . . . . 35 6. Implementation Considerations . . . . . . . . . . . . . . . . 35
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.2. Application Programming Interfaces . . . . . . . . . . . 35 6.2. Application Programming Interfaces . . . . . . . . . . . 35
6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 35 6.3. IDNA Dependency and Migration . . . . . . . . . . . . . . 36
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 36 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 36
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 37 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 37
7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 37 7.3. Expiration Dates . . . . . . . . . . . . . . . . . . . . 37
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 38
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 38 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 38
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 38 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . 39
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 39 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 40
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 40 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . 40
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 40 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . 41
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 41 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 42
8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 41 8.8. SameSite Cookies . . . . . . . . . . . . . . . . . . . . 42
8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 41 8.8.1. Defense in depth . . . . . . . . . . . . . . . . . . 42
8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 42 8.8.2. Top-level Navigations . . . . . . . . . . . . . . . . 42
8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 42 8.8.3. Mashups and Widgets . . . . . . . . . . . . . . . . . 43
8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 43 8.8.4. Server-controlled . . . . . . . . . . . . . . . . . . 43
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 43 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 43 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 44
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.1. Normative References . . . . . . . . . . . . . . . . . . 44 10.1. Normative References . . . . . . . . . . . . . . . . . . 44
10.2. Informative References . . . . . . . . . . . . . . . . . 45 10.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 47 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 47 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 48
A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 47 A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 48
A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 48 A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 48
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 48 A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 49
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
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. return the name/value pairs in the Cookie header.
skipping to change at page 6, line 9 skipping to change at page 6, line 9
; "optional" whitespace ; "optional" whitespace
obs-fold = CRLF obs-fold = CRLF
OWS SHOULD either not be produced or be produced as a single SP OWS SHOULD either not be produced or be produced as a single SP
character. character.
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
([RFC2616], Section 1.3). ([RFC7230], Section 2).
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 is defined in Section 5.1.2 of [RFC2616]. The term request-uri refers to "request-target" as defined in
Section 5.3 of [RFC7230].
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 document", "ancestor browsing context", "browsing The terms "active document", "ancestor browsing context", "browsing
context", "dedicated worker", "Document", "WorkerGlobalScope", context", "dedicated worker", "Document", "WorkerGlobalScope",
"sandboxed origin browsing context flag", "parent browsing context", "sandboxed origin browsing context flag", "parent browsing context",
skipping to change at page 6, line 42 skipping to change at page 6, line 43
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 4.2.1 of [RFC7231]. defined in Section 4.2.1 of [RFC7231].
The term "public suffix" is defined in a note in Section 5.3 of The term "public suffix" is defined in a note in Section 5.3 of
[RFC6265] as "a domain that is controlled by a public registry", and [RFC6265] as "a domain that is controlled by a public registry", and
are also know as "effective top-level domains" (eTLDs). For example, are also known as "effective top-level domains" (eTLDs). For
"example.com"'s public suffix is "com". User agents SHOULD use an example, "example.com"'s public suffix is "com". User agents SHOULD
up-to-date public suffix list, such as the one maintained by Mozilla use an up-to-date public suffix list, such as the one maintained by
at [PSL]. Mozilla at [PSL].
An origin's "registered domain" is the origin's host's public suffix An origin's "registered domain" is the origin's host's public suffix
plus the label to its left. That is, for "https://www.example.com", plus the label to its left. That is, for "https://www.example.com",
the public suffix is "com", and the registered domain is the public suffix is "com", and the registered domain is
"example.com". This concept is defined more rigorously in [PSL], and "example.com". This concept is defined more rigorously in [PSL], and
is also know as "effective top-level domain plus one" (eTLD+1). is also known as "effective top-level domain plus one" (eTLD+1).
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", and "target browsing context", are defined in [FETCH]. "method", and "target browsing context", are defined in [FETCH].
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.
skipping to change at page 7, line 32 skipping to change at page 7, line 32
response. User agents MAY ignore Set-Cookie headers contained in response. User agents MAY ignore Set-Cookie headers contained in
responses with 100-level status codes but MUST process Set-Cookie responses with 100-level status codes but MUST process Set-Cookie
headers contained in other responses (including responses with 400- headers contained in other responses (including responses with 400-
and 500-level status codes). An origin server can include multiple and 500-level status codes). An origin server can include multiple
Set-Cookie header fields in a single response. The presence of a Set-Cookie header fields in a single response. The presence of a
Cookie or a Set-Cookie header field does not preclude HTTP caches Cookie or a Set-Cookie header field does not preclude HTTP caches
from storing and reusing a response. from storing and 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 [RFC2616]) might change the semantics of fields (i.e., as defined in Section 3.2.2 of [RFC7230]) might change
the Set-Cookie header field because the %x2C (",") character is used the semantics of the Set-Cookie header field because the %x2C (",")
by Set-Cookie in a way that conflicts with such folding. character is used by Set-Cookie in a way that conflicts with such
folding.
3.1. Examples 3.1. Examples
Using the Set-Cookie header, a server can send the user agent a short Using the Set-Cookie header, a server can send the user agent a short
string in an HTTP response that the user agent will return in future string in an HTTP response that the user agent will return in future
HTTP requests that are within the scope of the cookie. For example, HTTP requests that are within the scope of the cookie. For example,
the server can send the user agent a "session identifier" named SID the server can send the user agent a "session identifier" named SID
with the value 31d4d96e407aad42. The user agent then returns the with the value 31d4d96e407aad42. The user agent then returns the
session identifier in subsequent requests. session identifier in subsequent requests.
skipping to change at page 10, line 14 skipping to change at page 10, line 14
set-cookie-header = "Set-Cookie:" SP set-cookie-string set-cookie-header = "Set-Cookie:" SP set-cookie-string
set-cookie-string = cookie-pair *( ";" SP cookie-av ) set-cookie-string = cookie-pair *( ";" SP cookie-av )
cookie-pair = cookie-name "=" cookie-value cookie-pair = cookie-name "=" cookie-value
cookie-name = token cookie-name = token
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE ) cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
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
token = <token, defined in [RFC2616], Section 2.2> token = <token, defined in [RFC7230], Section 3.2.6>
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=" sane-cookie-date expires-av = "Expires=" sane-cookie-date
sane-cookie-date = sane-cookie-date =
<rfc1123-date, defined in [RFC2616], Section 3.3.1> <IMF-fixdate, defined in [RFC7231], Section 7.1.1.1>
max-age-av = "Max-Age=" non-zero-digit *DIGIT max-age-av = "Max-Age=" non-zero-digit *DIGIT
; In practice, both expires-av and max-age-av ; In practice, both expires-av and max-age-av
; are limited to dates representable by the ; are limited to dates representable by the
; user agent. ; user agent.
non-zero-digit = %x31-39 non-zero-digit = %x31-39
; digits 1 through 9 ; digits 1 through 9
domain-av = "Domain=" domain-value domain-av = "Domain=" domain-value
domain-value = <subdomain> domain-value = <subdomain>
; defined in [RFC1034], Section 3.5, as ; defined in [RFC1034], Section 3.5, as
; enhanced by [RFC1123], Section 2.1 ; enhanced by [RFC1123], Section 2.1
path-av = "Path=" path-value path-av = "Path=" 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=" samesite-value samesite-av = "SameSite=" samesite-value
samesite-value = "Strict" / "Lax" samesite-value = "Strict" / "Lax" / "None"
extension-av = *av-octet extension-av = *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]).
The semantics of the cookie-value are not defined by this document. The semantics of the cookie-value are not defined by this document.
skipping to change at page 14, line 28 skipping to change at page 14, line 28
The "SameSite" attribute limits the scope of the cookie such that it The "SameSite" attribute limits the scope of the cookie such that it
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://example.com/sekrit-image" will attach same-site cookies if "https://example.com/sekrit-image" will attach same-site cookies if
and only if initiated from a context whose "site for cookies" is and only if initiated from a context whose "site for cookies" is
"example.com". "example.com".
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.3.7.1. If the top-level navigations, as described in Section 5.3.7.1. If the value
"SameSite" attribute's value is neither of these, the cookie will be is "None", the cookie will be sent with same-site and cross-site
ignored. requests. If the "SameSite" attribute's value is something other
than these three known keywords, the attribute's value will be
treated as "None".
4.1.3. Cookie Name Prefixes 4.1.3. Cookie Name Prefixes
Section 8.5 and Section 8.6 of this document spell out some of the Section 8.5 and Section 8.6 of this document spell out some of the
drawbacks of cookies' historical implementation. In particular, it drawbacks of cookies' historical implementation. In particular, it
is impossible for a server to have confidence that a given cookie was is impossible for a server to have confidence that a given cookie was
set with a particular set of attributes. In order to provide such set with a particular set of attributes. In order to provide such
confidence in a backwards-compatible way, two common sets of confidence in a backwards-compatible way, two common sets of
requirements can be inferred from the first few characters of the requirements can be inferred from the first few characters of the
cookie's name. cookie's name.
skipping to change at page 21, line 11 skipping to change at page 21, line 21
represents the context in which a user most likely believes represents the context in which a user most likely believes
themselves to be interacting. We'll label this domain the "top-level themselves to be interacting. We'll label this domain the "top-level
site". site".
For a document displayed in a top-level browsing context, we can stop For a document displayed in a top-level browsing context, we can stop
here: the document's "site for cookies" is the top-level site. here: the document's "site for cookies" is the top-level site.
For documents which are displayed in nested browsing contexts, we For documents which are displayed in nested browsing contexts, we
need to audit the origins of each of a document's ancestor browsing need to audit the origins of each of a document's ancestor browsing
contexts' active documents in order to account for the "multiple- contexts' active documents in order to account for the "multiple-
nested scenarios" described in Section 4 of [RFC7034]. These nested scenarios" described in Section 4 of [RFC7034]. A document's
document's "site for cookies" is the top-level site if and only if "site for cookies" is the top-level site if and only if the document
the document and each of its ancestor documents' origins have the and each of its ancestor documents' origins have the same registered
same registered domain as the top-level site. Otherwise its "site domain as the top-level site. Otherwise its "site for cookies" is
for cookies" is the empty string. the empty string.
Given a Document ("document"), the following algorithm returns its Given a Document ("document"), the following algorithm returns its
"site for cookies" (either a registered domain, or the empty string): "site for cookies" (either a registered domain, or the empty string):
1. Let "top-document" be the active document in "document"'s 1. Let "top-document" be the active document in "document"'s
browsing context's top-level browsing context. browsing context's top-level browsing context.
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 22, line 42 skipping to change at page 23, line 5
the empty string. the empty string.
3. Return "site". 3. Return "site".
5.2.2.2. Service Workers 5.2.2.2. Service Workers
Service Workers are more complicated, as they act as a completely Service Workers are more complicated, as they act as a completely
separate execution context with only tangential relationship to the separate execution context with only tangential relationship to the
Document which registered them. Document which registered them.
Requests which simply pass through a service worker will be handled Requests which simply pass through a Service Worker will be handled
as described above: the request's client will be the Document or as described above: the request's client will be the Document or
Worker which initiated the request, and its "site for cookies" will Worker which initiated the request, and its "site for cookies" will
be those defined in Section 5.2.1 and Section 5.2.2.1 be those defined in Section 5.2.1 and Section 5.2.2.1
Requests which are initiated by the Service Worker itself (via a Requests which are initiated by the Service Worker itself (via a
direct call to "fetch()", for instance), on the other hand, will have direct call to "fetch()", for instance), on the other hand, will have
a client which is a ServiceWorkerGlobalScope. Its "site for cookies" a client which is a ServiceWorkerGlobalScope. Its "site for cookies"
will be the registered domain of the Service Worker's URI. will be the registered domain of the Service Worker's URI.
Given a ServiceWorkerGlobalScope ("worker"), the following algorithm Given a ServiceWorkerGlobalScope ("worker"), the following algorithm
skipping to change at page 27, line 23 skipping to change at page 27, line 40
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.3.7. The SameSite Attribute 5.3.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. If cookie-av's attribute-value is not a case-insensitive match 1. Let "enforcement" be "None".
for "Strict" or "Lax", ignore the "cookie-av".
2. Let "enforcement" be "Lax" if cookie-av's attribute-value is a 2. If cookie-av's attribute-value is a case-insensitive match for
case-insensitive match for "Lax", and "Strict" otherwise. "Strict", set "enforcement" to "Strict".
3. Append an attribute to the cookie-attribute-list with an 3. If cookie-av's attribute-value is a case-insensitive match for
"Lax", set "enforcement" to "Lax".
4. 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".
Note: This algorithm maps the "None" value, as well as any unknown
value, to the "None" behavior, which is helpful for backwards
compatibility when introducing new variants.
5.3.7.1. "Strict" and "Lax" enforcement 5.3.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-
skipping to change at page 29, line 47 skipping to change at page 30, line 22
1. Ignore the cookie entirely and abort these steps. 1. Ignore the cookie entirely and abort these steps.
NOTE: A "public suffix" is a domain that is controlled by a NOTE: A "public suffix" is a domain that is controlled by a
public registry, such as "com", "co.uk", and "pvt.k12.wy.us". public registry, such as "com", "co.uk", and "pvt.k12.wy.us".
This step is essential for preventing attacker.com from This step is essential for preventing attacker.com from
disrupting the integrity of example.com by setting a cookie with disrupting the integrity of example.com by setting a cookie with
a Domain attribute of "com". Unfortunately, the set of public a Domain attribute of "com". Unfortunately, the set of public
suffixes (also known as "registry controlled domains") changes suffixes (also known as "registry controlled domains") changes
over time. If feasible, user agents SHOULD use an up-to-date over time. If feasible, user agents SHOULD use an up-to-date
public suffix list, such as the one maintained by the Mozilla public suffix list, such as the one maintained by the Mozilla
project at http://publicsuffix.org/ . project at http://publicsuffix.org/ [4].
6. If the domain-attribute is non-empty: 6. If the domain-attribute is non-empty:
1. If the canonicalized request-host does not domain-match the 1. If the canonicalized request-host does not domain-match the
domain-attribute: domain-attribute:
1. Ignore the cookie entirely and abort these steps. 1. Ignore the cookie entirely and abort these steps.
Otherwise: Otherwise:
skipping to change at page 31, line 21 skipping to change at page 31, line 44
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'
or '/login/en'. or '/login/en'.
13. If the cookie-attribute-list contains an attribute with an 13. If the cookie-attribute-list contains an attribute with an
attribute-name of "SameSite", set the cookie's same-site-flag to attribute-name of "SameSite", set the cookie's same-site-flag to
attribute-value (i.e. either "Strict" or "Lax"). Otherwise, set attribute-value (i.e. either "Strict", "Lax", or "None").
the cookie's same-site-flag to "None". Otherwise, set the cookie's same-site-flag to "None".
14. If the cookie's "same-site-flag" is not "None", and the cookie 14. If the cookie's "same-site-flag" is not "None", and the cookie
is being set from a context whose "site for cookies" is not an is being set from a context whose "site for cookies" is not an
exact match for request-uri's host's registered domain, then exact match for request-uri's host's registered domain, then
abort these steps and ignore the newly created cookie entirely. abort these steps and ignore the newly created cookie entirely.
15. If the cookie-name begins with a case-sensitive match for the 15. If the cookie-name begins with a case-sensitive match for the
string "__Secure-", abort these steps and ignore the cookie string "__Secure-", abort these steps and ignore the cookie
entirely unless the cookie's secure-only-flag is true. entirely unless the cookie's secure-only-flag is true.
skipping to change at page 31, line 45 skipping to change at page 32, line 21
entirely unless the cookie meets all the following criteria: entirely unless the cookie meets all the following criteria:
1. The cookie's secure-only-flag is true. 1. The cookie's secure-only-flag is true.
2. The cookie's host-only-flag is true. 2. The cookie's host-only-flag is true.
3. The cookie-attribute-list contains an attribute with an 3. The cookie-attribute-list contains an attribute with an
attribute-name of "Path", and the cookie's path is "/". attribute-name of "Path", and the cookie's path is "/".
17. If the cookie store contains a cookie with the same name, 17. If the cookie store contains a cookie with the same name,
domain, and path as the newly-created cookie: domain, host-only-flag, and path as the newly-created cookie:
1. Let old-cookie be the existing cookie with the same name, 1. Let old-cookie be the existing cookie with the same name,
domain, and path as the newly-created cookie. (Notice that domain, host-only-flag, and path as the newly-created
this algorithm maintains the invariant that there is at most cookie. (Notice that this algorithm maintains the invariant
one such cookie.) that there is at most one such cookie.)
2. If the newly-created cookie was received from a "non-HTTP" 2. If the newly-created cookie was received from a "non-HTTP"
API and the old-cookie's http-only-flag is true, abort these API and the old-cookie's http-only-flag is true, abort these
steps and ignore the newly created cookie entirely. steps and ignore the newly created cookie entirely.
3. Update the creation-time of the newly-created cookie to 3. Update the creation-time of the newly-created cookie to
match the creation-time of the old-cookie. match the creation-time of the old-cookie.
4. Remove the old-cookie from the cookie store. 4. Remove the old-cookie from the cookie store.
skipping to change at page 44, line 16 skipping to change at page 44, line 28
10.1. Normative References 10.1. Normative References
[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/>.
[PSL] "Public Suffix List", n.d., <https://publicsuffix.org/ [PSL] "Public Suffix List", n.d.,
list/>. <https://publicsuffix.org/list/>.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc1123>. <https://www.rfc-editor.org/info/rfc1123>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>.
[RFC3490] Costello, A., "Internationalizing Domain Names in [RFC3490] Costello, A., "Internationalizing Domain Names in
Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490, Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490,
March 2003, <http://www.rfc-editor.org/info/rfc3490>. March 2003, <https://www.rfc-editor.org/info/rfc3490>.
See Section 6.3 for an explanation why the normative See Section 6.3 for an explanation why the normative
reference to an obsoleted specification is needed. reference to an obsoleted specification is needed.
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790, Application Protocol Collation Registry", RFC 4790,
DOI 10.17487/RFC4790, March 2007, DOI 10.17487/RFC4790, March 2007,
<http://www.rfc-editor.org/info/rfc4790>. <https://www.rfc-editor.org/info/rfc4790>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
DOI 10.17487/RFC6454, December 2011, DOI 10.17487/RFC6454, December 2011,
<http://www.rfc-editor.org/info/rfc6454>. <https://www.rfc-editor.org/info/rfc6454>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[SERVICE-WORKERS] [SERVICE-WORKERS]
Russell, A., Song, J., and J. Archibald, "Service Russell, A., Song, J., and J. Archibald, "Service
Workers", n.d., <http://www.w3.org/TR/service-workers/>. Workers", n.d., <http://www.w3.org/TR/service-workers/>.
[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
skipping to change at page 46, line 33 skipping to change at page 46, line 40
West, M. and M. Goodwin, "Same-Site Cookies", draft-ietf- West, M. and M. Goodwin, "Same-Site Cookies", draft-ietf-
httpbis-cookie-same-site-00 (work in progress), June 2016. httpbis-cookie-same-site-00 (work in progress), June 2016.
[prerendering] [prerendering]
Bentzel, C., "Chrome Prerendering", n.d., Bentzel, C., "Chrome Prerendering", n.d.,
<https://www.chromium.org/developers/design-documents/ <https://www.chromium.org/developers/design-documents/
prerender>. prerender>.
[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,
<http://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, DOI 10.17487/RFC3864, September 2004,
<http://www.rfc-editor.org/info/rfc3864>. <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,
<http://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,
<http://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
Internationalized Domain Names in Applications (IDNA) Internationalized Domain Names in Applications (IDNA)
2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010,
<http://www.rfc-editor.org/info/rfc5895>. <https://www.rfc-editor.org/info/rfc5895>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame- [RFC7034] Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
Options", RFC 7034, DOI 10.17487/RFC7034, October 2013, Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
<http://www.rfc-editor.org/info/rfc7034>. <https://www.rfc-editor.org/info/rfc7034>.
[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
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] http://httpwg.github.io/
[3] https://github.com/httpwg/http-extensions/labels/6265bis
[4] http://publicsuffix.org/
[5] https://github.com/httpwg/http-extensions/issues/243
[6] https://github.com/httpwg/http-extensions/issues/246
[7] https://www.rfc-editor.org/errata_search.php?rfc=6265
[8] https://github.com/httpwg/http-extensions/issues/247
[9] https://github.com/httpwg/http-extensions/issues/201
[10] https://github.com/httpwg/http-extensions/issues/204
[11] https://github.com/httpwg/http-extensions/issues/222
[12] https://github.com/httpwg/http-extensions/issues/248
[13] https://github.com/httpwg/http-extensions/issues/295
[14] https://github.com/httpwg/http-extensions/issues/302
[15] https://github.com/httpwg/http-extensions/issues/389
[16] https://github.com/httpwg/http-extensions/issues/199
[17] https://github.com/httpwg/http-extensions/issues/788
Appendix A. Changes Appendix A. Changes
A.1. draft-ietf-httpbis-rfc6265bis-00 A.1. draft-ietf-httpbis-rfc6265bis-00
o Port [RFC6265] to Markdown. No (intentional) normative changes. o Port [RFC6265] to Markdown. No (intentional) normative changes.
A.2. draft-ietf-httpbis-rfc6265bis-01 A.2. draft-ietf-httpbis-rfc6265bis-01
o Fixes to formatting caused by mistakes in the initial port to o Fixes to formatting caused by mistakes in the initial port to
Markdown: Markdown:
* https://github.com/httpwg/http-extensions/issues/243 * https://github.com/httpwg/http-extensions/issues/243 [5]
* https://github.com/httpwg/http-extensions/issues/246 * https://github.com/httpwg/http-extensions/issues/246 [6]
o Addresses errata 3444 by updating the "path-value" and "extension- o Addresses errata 3444 by updating the "path-value" and "extension-
av" grammar, errata 4148 by updating the "day-of-month", "year", av" grammar, errata 4148 by updating the "day-of-month", "year",
and "time" grammar, and errata 3663 by adding the requested note. and "time" grammar, and errata 3663 by adding the requested note.
https://www.rfc-editor.org/errata_search.php?rfc=6265 https://www.rfc-editor.org/errata_search.php?rfc=6265 [7]
o Dropped "Cookie2" and "Set-Cookie2" from the IANA Considerations o Dropped "Cookie2" and "Set-Cookie2" from the IANA Considerations
section: https://github.com/httpwg/http-extensions/issues/247 section: https://github.com/httpwg/http-extensions/issues/247 [8]
o Merged the recommendations from [I-D.ietf-httpbis-cookie-alone], o Merged the recommendations from [I-D.ietf-httpbis-cookie-alone],
removing the ability for a non-secure origin to set cookies with a removing the ability for a non-secure origin to set cookies with a
'secure' flag, and to overwrite cookies whose 'secure' flag is 'secure' flag, and to overwrite cookies whose 'secure' flag is
true. true.
o Merged the recommendations from o Merged the recommendations from
[I-D.ietf-httpbis-cookie-prefixes], adding "__Secure-" and [I-D.ietf-httpbis-cookie-prefixes], adding "__Secure-" and
"__Host-" cookie name prefix processing instructions. "__Host-" cookie name prefix processing instructions.
A.3. draft-ietf-httpbis-rfc6265bis-02 A.3. draft-ietf-httpbis-rfc6265bis-02
o Merged the recommendations from o Merged the recommendations from
[I-D.ietf-httpbis-cookie-same-site], adding support for the [I-D.ietf-httpbis-cookie-same-site], adding support for the
"SameSite" attribute. "SameSite" attribute.
o Closed a number of editorial bugs: o Closed a number of editorial bugs:
* Clarified address bar behavior for SameSite cookies: * Clarified address bar behavior for SameSite cookies:
https://github.com/httpwg/http-extensions/issues/201 https://github.com/httpwg/http-extensions/issues/201 [9]
* Added the word "Cookies" to the document's name: * Added the word "Cookies" to the document's name:
https://github.com/httpwg/http-extensions/issues/204 https://github.com/httpwg/http-extensions/issues/204 [10]
* Clarified that the "__Host-" prefix requires an explicit "Path" * Clarified that the "__Host-" prefix requires an explicit "Path"
attribute: https://github.com/httpwg/http-extensions/issues/222 attribute: https://github.com/httpwg/http-extensions/issues/222
[11]
* Expanded the options for dealing with third-party cookies to * Expanded the options for dealing with third-party cookies to
include a brief mention of partitioning based on first-party: include a brief mention of partitioning based on first-party:
https://github.com/httpwg/http-extensions/issues/248 https://github.com/httpwg/http-extensions/issues/248 [12]
* Noted that double-quotes in cookie values are part of the * Noted that double-quotes in cookie values are part of the
value, and are not stripped: https://github.com/httpwg/http- value, and are not stripped: https://github.com/httpwg/http-
extensions/issues/295 extensions/issues/295 [13]
* Fixed the "site for cookies" algorithm to return something that * Fixed the "site for cookies" algorithm to return something that
makes sense: https://github.com/httpwg/http-extensions/ makes sense: https://github.com/httpwg/http-extensions/
issues/302 issues/302 [14]
Appendix B. Acknowledgements A.4. draft-ietf-httpbis-rfc6265bis-03
o Clarified handling of invalid SameSite values:
https://github.com/httpwg/http-extensions/issues/389 [15]
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 [16]
o Introduced an explicit "None" value for the SameSite attribute:
https://github.com/httpwg/http-extensions/issues/788 [17]
Acknowledgements
This document is a minor update of RFC 6265, adding small features, This document is a minor update of RFC 6265, adding small features,
and aligning the specification with the reality of today's and aligning the specification with the reality of today's
deployments. Here, we're standing upon the shoulders of giants. deployments. Here, we're standing upon the shoulders of giants.
Authors' Addresses Authors' Addresses
Adam Barth Adam Barth
Google, Inc Google, Inc
 End of changes. 68 change blocks. 
102 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/