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 October 11, 2018
	Expires: February 8, 2018		Expires: April 14, 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 April 14, 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 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. 33 change blocks.
	44 lines changed or deleted		60 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/