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 July 16, 2018
Expires: February 8, 2018 Expires: January 17, 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 January 17, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 51 skipping to change at page 6, line 52
[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 know as "effective top-level domains" (eTLDs). For example,
"example.com"'s public suffix is "com". User agents SHOULD use an "example.com"'s public suffix is "com". User agents SHOULD use an
up-to-date public suffix list, such as the one maintained by Mozilla up-to-date public suffix list, such as the one maintained by Mozilla
at [PSL]. 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 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
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]
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. 31 change blocks. 
40 lines changed or deleted 50 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/