draft-ietf-httpbis-rfc6265bis-02.txt   draft-ietf-httpbis-rfc6265bis-latest.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 February 19, 2019
Expires: February 8, 2018 Expires: August 23, 2019
Cookies: HTTP State Management Mechanism Cookies: HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-latest 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
skipping to change at page 1, line 40 skipping to change at page 1, line 40
https://github.com/httpwg/http-extensions/labels/6265bis [3]. 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 August 23, 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 3, line 51 skipping to change at page 3, line 51
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 43 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 43 9.2. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . 43
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
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 47 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 48 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 48
A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 48 A.1. draft-ietf-httpbis-rfc6265bis-00 . . . . . . . . . . . . 48
A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 48 A.2. draft-ietf-httpbis-rfc6265bis-01 . . . . . . . . . . . . 48
A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 48 A.3. draft-ietf-httpbis-rfc6265bis-02 . . . . . . . . . . . . 48
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 49 A.4. draft-ietf-httpbis-rfc6265bis-03 . . . . . . . . . . . . 49
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
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
skipping to change at page 14, line 29 skipping to change at page 14, line 29
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
"SameSite" attribute's value is neither of these, the cookie will be "SameSite" attribute's value is neither of these, the attribute will
ignored. be ignored.
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 11
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 22, line 42
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 31, line 45 skipping to change at page 31, line 45
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 21 skipping to change at page 44, line 21
[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., [PSL] "Public Suffix List", n.d.,
<https://publicsuffix.org/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, <https://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 33
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 10.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/ [1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] http://httpwg.github.io/ [2] http://httpwg.github.io/
skipping to change at page 48, line 5 skipping to change at page 47, line 52
[10] https://github.com/httpwg/http-extensions/issues/204 [10] https://github.com/httpwg/http-extensions/issues/204
[11] https://github.com/httpwg/http-extensions/issues/222 [11] https://github.com/httpwg/http-extensions/issues/222
[12] https://github.com/httpwg/http-extensions/issues/248 [12] https://github.com/httpwg/http-extensions/issues/248
[13] https://github.com/httpwg/http-extensions/issues/295 [13] https://github.com/httpwg/http-extensions/issues/295
[14] https://github.com/httpwg/http-extensions/issues/302 [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
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:
skipping to change at page 49, line 21 skipping to change at page 49, line 21
https://github.com/httpwg/http-extensions/issues/248 [12] 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 [13] 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 [14] 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]
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. 36 change blocks. 
54 lines changed or deleted 70 lines changed or added

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