draft-ietf-httpbis-key-01.txt		draft-ietf-httpbis-key-latest.txt
	HTTP Working Group R. Fielding		HTTP Working Group R. Fielding
	Internet-Draft Adobe Systems Incorporated		Internet-Draft Adobe Systems Incorporated
	Intended status: Standards Track M. Nottingham		Intended status: Standards Track M. Nottingham
	Expires: September 3, 2016 March 2, 2016		Expires: January 7, 2025 July 6, 2024
	The Key HTTP Response Header Field		The Key HTTP Response Header Field
	draft-ietf-httpbis-key-01		draft-ietf-httpbis-key-latest
	Abstract		Abstract
	The 'Key' header field for HTTP responses allows an origin server to		The 'Key' header field for HTTP responses allows an origin server to
	describe the secondary cache key (RFC 7234, Section 4.1) for a		describe the secondary cache key (RFC 7234, Section 4.1) for a
	resource, by conveying what is effectively a short algorithm that can		resource, by conveying what is effectively a short algorithm that can
	be used upon later requests to determine if a stored response is		be used upon later requests to determine if a stored response is
	reusable for a given request.		reusable for a given request.
	Key has the advantage of avoiding an additional round trip for		Key has the advantage of avoiding an additional round trip for
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	Key also informs user agents of the request characteristics that		Key also informs user agents of the request characteristics that
	might result in different content, which can be useful if the user		might result in different content, which can be useful if the user
	agent is not sending request header fields in order to reduce the		agent is not sending request header fields in order to reduce the
	risk of fingerprinting.		risk of fingerprinting.
	Note to Readers		Note to Readers
	Discussion of this draft takes place on the HTTP working group		Discussion of this draft takes place on the HTTP working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	https://lists.w3.org/Archives/Public/ietf-http-wg/.		https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].
	Working Group information can be found at http://httpwg.github.io/;		Working Group information can be found at http://httpwg.github.io/
	source code and issues list for this draft can be found at		[2]; source code and issues list for this draft can be found at
	https://github.com/httpwg/http-extensions/labels/key.		https://github.com/httpwg/http-extensions/labels/key [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 September 3, 2016.		This Internet-Draft will expire on January 7, 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2024 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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 5		1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
	2. The "Key" Response Header Field . . . . . . . . . . . . . . . 5		2. The "Key" Response Header Field . . . . . . . . . . . . . . . 4
	2.1. Relationship with Vary . . . . . . . . . . . . . . . . . . 6		2.1. Relationship with Vary . . . . . . . . . . . . . . . . . 5
	2.2. Calculating a Secondary Cache Key . . . . . . . . . . . . 7		2.2. Calculating a Secondary Cache Key . . . . . . . . . . . . 6
	2.2.1. Creating a Header Field Value . . . . . . . . . . . . 9		2.2.1. Creating a Header Field Value . . . . . . . . . . . . 8
	2.2.2. Failing Parameter Processing . . . . . . . . . . . . . 9		2.2.2. Failing Parameter Processing . . . . . . . . . . . . 9
	2.3. Key Parameters . . . . . . . . . . . . . . . . . . . . . . 9		2.3. Key Parameters . . . . . . . . . . . . . . . . . . . . . 9
	2.3.1. div . . . . . . . . . . . . . . . . . . . . . . . . . 10		2.3.1. div . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.3.2. partition . . . . . . . . . . . . . . . . . . . . . . 11		2.3.2. partition . . . . . . . . . . . . . . . . . . . . . . 10
	2.3.3. match . . . . . . . . . . . . . . . . . . . . . . . . 12		2.3.3. match . . . . . . . . . . . . . . . . . . . . . . . . 11
	2.3.4. substr . . . . . . . . . . . . . . . . . . . . . . . . 13		2.3.4. substr . . . . . . . . . . . . . . . . . . . . . . . 12
	2.3.5. param . . . . . . . . . . . . . . . . . . . . . . . . 13		2.3.5. param . . . . . . . . . . . . . . . . . . . . . . . . 13
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15		3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 14
	3.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 15		3.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 14
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 15		4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		5. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 16		5.1. Normative References . . . . . . . . . . . . . . . . . . 15
	5.2. Informative References . . . . . . . . . . . . . . . . . . 16		5.2. Informative References . . . . . . . . . . . . . . . . . 16
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17		5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 17		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
	B.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 17		Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		B.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 16
			B.2. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	In HTTP caching [RFC7234], the Vary response header field effectively		In HTTP caching [RFC7234], the Vary response header field effectively
	modifies the key used to store and access a response to include		modifies the key used to store and access a response to include
	information from the request's headers. This "secondary cache key"		information from the request's headers. This "secondary cache key"
	allows proactive content negotiation [RFC7231] to work with caches.		allows proactive content negotiation [RFC7231] to work with caches.
	Vary's operation is generic; it works well when caches understand the		Vary's operation is generic; it works well when caches understand the
	semantics of the selecting headers. For example, the Accept-Language		semantics of the selecting headers. For example, the Accept-Language
	skipping to change at page 4, line 27 ¶		skipping to change at page 3, line 29 ¶
	header field) and serve it to a client, without any knowledge of the		header field) and serve it to a client, without any knowledge of the
	underlying resource.		underlying resource.
	Vary does not work as well when the criteria for selecting a response		Vary does not work as well when the criteria for selecting a response
	are specific to the resource. For example, if the nature of the		are specific to the resource. For example, if the nature of the
	response depends upon the presence or absence of a particular Cookie		response depends upon the presence or absence of a particular Cookie
	([RFC6265]) in a request, Vary doesn't have a mechanism to offer		([RFC6265]) in a request, Vary doesn't have a mechanism to offer
	enough fine-grained, resource-specific information to aid a cache's		enough fine-grained, resource-specific information to aid a cache's
	selection of the appropriate response.		selection of the appropriate response.
			Additionally, when new selecting headers are defined, caches need to
			be updated to understand their semantics before Vary can operate over
			them efficiently; due to the sometimes slow rate of cache deployment,
			this can be problematic.
			Finally, Vary has proven to be difficult to implement correctly and
			efficiently by high-performance intermediary caches, because doing so
			involves examining all cached responses with the request's URL.
	This document defines a new response header field, "Key", that allows		This document defines a new response header field, "Key", that allows
	resources to describe the secondary cache key in a fine-grained,		resources to describe the secondary cache key in a fine-grained,
	resource-specific manner, leading to improved cache efficiency when		resource-specific manner, leading to improved cache efficiency when
	responses depend upon such headers.		responses depend upon such headers.
	1.1. Examples		1.1. Examples
	For example, this response header field:		For example, this response header field:
	Key: cookie;param=_sess;param=ID		Key: cookie;param=_sess;param=ID
	skipping to change at page 7, line 19 ¶		skipping to change at page 6, line 28 ¶
	2.2. Calculating a Secondary Cache Key		2.2. Calculating a Secondary Cache Key
	When used by a cache to determine whether a stored response can be		When used by a cache to determine whether a stored response can be
	used to satisfy a presented request, each field-name in Key		used to satisfy a presented request, each field-name in Key
	identifies a potential request header, just as with the Vary response		identifies a potential request header, just as with the Vary response
	header field.		header field.
	However, each of these can have zero to many key parameters that		However, each of these can have zero to many key parameters that
	change how the response selection process (as defined in [RFC7234],		change how the response selection process (as defined in [RFC7234],
	Section 4.3)) works.		Section 4.3) works.
	In particular, when a cache fully implements this specification, it		In particular, when a cache fully implements this specification, it
	creates a secondary cache key for every request by following the		creates a secondary cache key for every request by following the
	instructions in the Key header field, ignoring the Vary header for		instructions in the Key header field, ignoring the Vary header for
	this purpose.		this purpose.
	Then, when a new request is presented, the secondary cache key		Then, when a new request is presented, the secondary cache key
	generated for that request can be compared to the stored one to find		generated for that request can be compared to the stored one to find
	the appropriate response, to determine if it can be selected.		the appropriate response, to determine if it can be selected.
	skipping to change at page 7, line 43 ¶		skipping to change at page 7, line 4 ¶
	1) If the Key header field is not present on the most recent		1) If the Key header field is not present on the most recent
	cacheable (as per [RFC7234], Section 3)) response seen for the		cacheable (as per [RFC7234], Section 3)) response seen for the
	resource, abort this algorithm (i.e., fall back to using Vary to		resource, abort this algorithm (i.e., fall back to using Vary to
	determine the secondary cache key).		determine the secondary cache key).
	2) Let "key_value" be the result of Creating a Header Field Value		2) Let "key_value" be the result of Creating a Header Field Value
	(Section 2.2.1) with "key" as the "target_field_name" and the		(Section 2.2.1) with "key" as the "target_field_name" and the
	most recently seen response header list for the resource as		most recently seen response header list for the resource as
	"header_list".		"header_list".
	3) Let "secondary_key" be an empty string.		3) Let "secondary_key" be an empty string.
	4) Create "key_list" by splitting "key_value" on "," characters,		4) Create "key_list" by splitting "key_value" on "," characters,
	excepting "," characters within quoted strings, as per [RFC7230]		excepting "," characters within quoted strings, as per [RFC7230],
	Section 3.2.6..		Section 3.2.6.
	5) For "key_item" in "key_list":		5) For "key_item" in "key_list":
	1) Remove any leading and trailing WSP from "key_item".		1) Remove any leading and trailing WSP from "key_item".
	2) If "key_item" does not contain a ";" character, fail		2) If "key_item" does not contain a ";" character, fail
	parameter processing (Section 2.2.2) and skip to the next		parameter processing (Section 2.2.2) and skip to the next
	"key_item".		"key_item".
	3) Let "field_name" be the string before the first ";" character		3) Let "field_name" be the string before the first ";" character
	in "key_item", removing any WSP between them.		in "key_item", removing any WSP between them.
	4) Let "field_value" be the result of Creating a Header Field		4) Let "field_value" be the result of Creating a Header Field
	Value (Section 2.2.1) with "field_name" as the		Value (Section 2.2.1) with "field_name" as the
	"target_field_name" and the request header list as		"target_field_name" and the request header list as
	"header_list".		"header_list".
	5) Let "parameters" be the string after the first ";" character		5) Let "parameters" be the string after the first ";" character
	in "key_item", removing any WSP between them.		in "key_item", removing any WSP between them.
	6) Create "param_list" by splitting "parameters" on ";"		6) Create "param_list" by splitting "parameters" on ";"
	characters, excepting ";" characters within quoted strings,		characters, excepting ";" characters within quoted strings,
	as per [RFC7230] Section 3.2.6.		as per [RFC7230], Section 3.2.6.
	7) For "parameter" in "param_list":		7) For "parameter" in "param_list":
	1) If "parameter" does not contain a "=", fail parameter		1) If "parameter" does not contain a "=", fail parameter
	processing (Section 2.2.2) and skip to the next		processing (Section 2.2.2) and skip to the next
	"key_item".		"key_item".
	2) Remove any WSP at the beginning and/or end of		2) Remove any WSP at the beginning and/or end of
	"parameter".		"parameter".
	3) Let "param_name" be the string before the first "="		3) Let "param_name" be the string before the first "="
	character in "parameter", case-normalized to lowercase.		character in "parameter", case-normalized to lowercase.
	4) If "param_name" does not identify a Key parameter		4) If "param_name" does not identify a Key parameter
	processing algorithm that is implemented, fail parameter		processing algorithm that is implemented, fail parameter
	processing (Section 2.2.2) and skip to the next		processing (Section 2.2.2) and skip to the next
	skipping to change at page 8, line 32 ¶		skipping to change at page 7, line 42 ¶
	3) Let "param_name" be the string before the first "="		3) Let "param_name" be the string before the first "="
	character in "parameter", case-normalized to lowercase.		character in "parameter", case-normalized to lowercase.
	4) If "param_name" does not identify a Key parameter		4) If "param_name" does not identify a Key parameter
	processing algorithm that is implemented, fail parameter		processing algorithm that is implemented, fail parameter
	processing (Section 2.2.2) and skip to the next		processing (Section 2.2.2) and skip to the next
	"key_item".		"key_item".
	5) Let "param_value" be the string after the first "="		5) Let "param_value" be the string after the first "="
	character in "parameter".		character in "parameter".
	6) If the first and last characters of "param_value" are		6) If the first and last characters of "param_value" are
	both DQUOTE:		both DQUOTE:
	1) Remove the first and last characters of		1) Remove the first and last characters of
	"param_value".		"param_value".
	2) Replace quoted-pairs within "param_value" with the		2) Replace quoted-pairs within "param_value" with the
	octet following the backslash, as per [RFC7230]		octet following the backslash, as per [RFC7230],
	Section 3.2.6.		Section 3.2.6.
	7) If "param_value" does not conform to the syntax defined		7) If "param_value" does not conform to the syntax defined
	for it by the parameter definition, fail parameter		for it by the parameter definition, fail parameter
	processing Section 2.2.2 and skip to the next "key_item".		processing (Section 2.2.2) and skip to the next
			"key_item".
	8) Run the identified processing algorithm on "field_value"		8) Run the identified processing algorithm on "field_value"
	with the "param_value", and append the result to		with the "param_value", and append the result to
	"secondary_key". If parameter processing fails		"secondary_key". If parameter processing fails
	Section 2.2.2, skip to the next "key_item".		(Section 2.2.2), skip to the next "key_item".
	9) Append a separator character (e.g., NULL) to		9) Append a separator character (e.g., NULL) to
	"secondary_key".		"secondary_key".
	6) Return "secondary_key".		6) Return "secondary_key".
	Note that this specification does not require that exact algorithm to		Note that this specification does not require that exact algorithm to
	be implemented. However, implementations' observable behavior MUST		be implemented. However, implementations' observable behavior MUST
	be identical to running it. This includes parameter processing		be identical to running it. This includes parameter processing
	algorithms; implementations MAY use different internal artefacts for		algorithms; implementations MAY use different internal artefacts for
	secondary cache keys, as long as the results are the same.		secondary cache keys, as long as the results are the same.
	skipping to change at page 9, line 27 ¶		skipping to change at page 8, line 41 ¶
	invalidating the stored response(s) when the Key header field is		invalidating the stored response(s) when the Key header field is
	observed to change.		observed to change.
	2.2.1. Creating a Header Field Value		2.2.1. Creating a Header Field Value
	Given a header field name "target_field_name" and "header_list", a		Given a header field name "target_field_name" and "header_list", a
	list of ("field_name", "field_value") tuples:		list of ("field_name", "field_value") tuples:
	1) Let "target_field_values" be an empty list.		1) Let "target_field_values" be an empty list.
	2) For each ("field_name", "field_value") tuple in "header_list":		2) For each ("field_name", "field_value") tuple in "header_list":
	1) If "field_name" does not match "target_field_name", skip to		1) If "field_name" does not match "target_field_name", skip to
	the next tuple.		the next tuple.
	2) Strip leading and trailing WSP from "field_value" and append		2) Strip leading and trailing WSP from "field_value" and append
	it to "target_field_values".		it to "target_field_values".
	3) If "target_field_values" is empty, return an empty string.		3) If "target_field_values" is empty, return an empty string.
	4) Return the concatenation of "target_field_values", separating		4) Return the concatenation of "target_field_values", separating
	each with "," characters.		each with "," characters.
	2.2.2. Failing Parameter Processing		2.2.2. Failing Parameter Processing
	In some cases, a key parameter cannot determine a secondary cache key		In some cases, a key parameter cannot determine a secondary cache key
	corresponding to its nominated header field value. When this		corresponding to its nominated header field value. When this
	happens, Key processing needs to fail safely, so that the correct		happens, Key processing needs to fail safely, so that the correct
	behavior is observed.		behavior is observed.
	When this happens, implementations MUST either behave as if the Key		When this happens, implementations MUST either behave as if the whole
	header was not present, or assure that the nominated header fields		Key header field was not present (i.e., abort processing of Key,
	being compared match, as per [RFC7234], Section 4.1.		ignoring it entirely and falling back to Vary), or assure that the
			nominated header fields being compared match, as per [RFC7234],
			Section 4.1 (i.e., treat the failing portion of the Key header as
			falling back to Vary, but continuing to process the rest).
	2.3. Key Parameters		2.3. Key Parameters
	A Key parameter associates a name with a specific processing		A Key parameter associates a name with a specific processing
	algorithm that takes two inputs; a HTTP header value "header_value"		algorithm that takes two inputs; a HTTP header value "header_value"
	(as described in Section 2.2.1), and "parameter_value", a string that		(as described in Section 2.2.1), and "parameter_value", a string that
	indicates how the identified header should be processed.		indicates how the identified header should be processed.
	The set of key parameters (and their associated processing		The set of key parameters (and their associated processing
	algorithms) is extensible; see Section 3. This document defines the		algorithms) is extensible; see Section 3. This document defines the
	skipping to change at page 10, line 22 ¶		skipping to change at page 9, line 43 ¶
	groups by dividing them by a configured value.		groups by dividing them by a configured value.
	Its value's syntax is:		Its value's syntax is:
	div = 1*DIGIT		div = 1*DIGIT
	To process a set of header fields against a div parameter, follow		To process a set of header fields against a div parameter, follow
	these steps (or their equivalent):		these steps (or their equivalent):
	1) If "parameter_value" is "0", fail parameter processing		1) If "parameter_value" is "0", fail parameter processing
	Section 2.2.2.		(Section 2.2.2).
	2) If "header_value" is the empty string, return "none".		2) If "header_value" is the empty string, return "none".
	3) If "header_value" contains a ",", remove it and all subsequent		3) If "header_value" contains a ",", remove it and all subsequent
	characters.		characters.
	4) Remove all WSP characters from "header_value".		4) Remove all WSP characters from "header_value".
	5) If "header_value" does not match the div ABNF rule, fail		5) If "header_value" does not match the div ABNF rule, fail
	parameter processing (Section 2.2.2).		parameter processing (Section 2.2.2).
	6) Return the quotient of "header_value" / "parameter_value"		6) Return the quotient of "header_value" / "parameter_value"
	(omitting the modulus).		(omitting the modulus).
	For example, the Key:		For example, the Key:
	skipping to change at page 14, line 49 ¶		skipping to change at page 14, line 24 ¶
	Def: liam=123 // '123'		Def: liam=123 // '123'
	Def: mno=456 // ''		Def: mno=456 // ''
	Def: // ''		Def: // ''
	Def: abc=123; liam=890 // '890'		Def: abc=123; liam=890 // '890'
	Def: liam="678" // '"678"'		Def: liam="678" // '"678"'
	3. IANA Considerations		3. IANA Considerations
	This specification defines the HTTP Key Parameter Registry,		This specification defines the HTTP Key Parameter Registry,
	maintained at http://www.iana.org/assignments/http-parameters/		maintained at http://www.iana.org/assignments/http-parameters/http-
	http-parameters.xhtml#key.		parameters.xhtml#key [4].
	3.1. Procedure		3.1. Procedure
	Key Parameter registrations MUST include the following fields:		Key Parameter registrations MUST include the following fields:
	o Parameter Name: [name]		o Parameter Name: [name]
	o Reference: [Pointer to specification text]		o Reference: [Pointer to specification text]
	Values to be added to this namespace require IETF Review (see Section		Values to be added to this namespace require IETF Review (see
	4.1 of [RFC5226]) and MUST conform to the purpose of content coding		Section 4.1 of [RFC5226]) and MUST conform to the purpose of content
	defined in this section.		coding defined in this section.
	3.2. Registrations		3.2. Registrations
	This specification makes the following entries in the HTTP Key		This specification makes the following entries in the HTTP Key
	Parameter Registry:		Parameter Registry:
	+----------------+---------------+		+----------------+----------------+
	| Parameter Name | Reference |		| Parameter Name | Reference |
	+----------------+---------------+		+----------------+----------------+
	| div | Section 2.3.1 |		| div | Section 2.3.1 |
	| partition | Section 2.3.2 |		| partition | Section 2.3.2 |
	| match | Section 2.3.3 |		| match | Section 2.3.3 |
	| substr | Section 2.3.4 |		| substr | Section 2.3.4 |
	| param | Section 2.3.5 |		| param | Section 2.3.5 |
	+----------------+---------------+		+----------------+----------------+
	4. Security Considerations		4. Security Considerations
	Because Key is an alternative to Vary, it is possible for caches to		Because Key is an alternative to Vary, it is possible for caches to
	behave differently based upon whether they implement Key. Likewise,		behave differently based upon whether they implement Key. Likewise,
	because support for any one Key parameter is not required, it is		because support for any one Key parameter is not required, it is
	possible for different implementations of Key to behave differently.		possible for different implementations of Key to behave differently.
	In both cases, an attacker might be able to exploit these		In both cases, an attacker might be able to exploit these
	differences.		differences.
	skipping to change at page 16, line 13 ¶		skipping to change at page 15, line 35 ¶
	responses for a given resource in caches; this, in turn, might be		responses for a given resource in caches; this, in turn, might be
	used to create an attack upon the cache itself. Good cache		used to create an attack upon the cache itself. Good cache
	replacement algorithms and denial of service monitoring in cache		replacement algorithms and denial of service monitoring in cache
	implementations are reasonable mitigations against this risk.		implementations are reasonable mitigations against this risk.
	5. References		5. References
	5.1. Normative References		5.1. Normative References
	[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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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, DOI 10.17487/		Specifications: ABNF", STD 68, RFC 5234,
	RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<http://www.rfc-editor.org/info/rfc7230>.		<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>.
	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	RFC 7234, DOI 10.17487/RFC7234, June 2014,		RFC 7234, DOI 10.17487/RFC7234, June 2014,
	<http://www.rfc-editor.org/info/rfc7234>.		<https://www.rfc-editor.org/info/rfc7234>.
	5.2. Informative References		5.2. Informative References
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<https://www.rfc-editor.org/info/rfc5226>.
	[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>.
			5.3. URIs
			[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
			[2] http://httpwg.github.io/
			[3] https://github.com/httpwg/http-extensions/labels/key
			[4] http://www.iana.org/assignments/http-parameters/http-
			parameters.xhtml#key
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	Thanks to Ilya Grigorik, Amos Jeffries and Yoav Weiss for their		Thanks to Ilya Grigorik, Amos Jeffries and Yoav Weiss for their
	feedback.		feedback.
	Appendix B. Changes		Appendix B. Changes
	B.1. Since -00		B.1. Since -00
	o Issue 108 (field-name cardinality) closed with no action.		o Issue 108 (field-name cardinality) closed with no action.
	o Issue 104 (Support "Or" operator) closed with no action.		o Issue 104 (Support "Or" operator) closed with no action.
	o Issue 107 (Whitespace requirement) addressed by allowing		o Issue 107 (Whitespace requirement) addressed by allowing
	whitespace around parameters.		whitespace around parameters.
	o Issue 106 (Policy for Key parameter registry) closed with no		o Issue 106 (Policy for Key parameter registry) closed with no
	action.		action.
			B.2. Since -01
			None yet.
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding		Roy T. Fielding
	Adobe Systems Incorporated		Adobe Systems Incorporated
	Email: fielding@gbiv.com		Email: fielding@gbiv.com
	URI: http://roy.gbiv.com/		URI: http://roy.gbiv.com/
	Mark Nottingham		Mark Nottingham
End of changes. 37 change blocks.
	74 lines changed or deleted		110 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/