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/