draft-ietf-httpbis-variants-06.txt   draft-ietf-httpbis-variants-latest.txt 
HTTP Working Group M. Nottingham HTTP Working Group M. Nottingham
Internet-Draft Fastly Internet-Draft Fastly
Updates: 7234 (if approved) November 2, 2019 Updates: 7234 (if approved) June 21, 2022
Intended status: Standards Track Intended status: Standards Track
Expires: May 5, 2020 Expires: December 23, 2022
HTTP Representation Variants HTTP Representation Variants
draft-ietf-httpbis-variants-06 draft-ietf-httpbis-variants-latest
Abstract Abstract
This specification introduces an alternative way to select a HTTP This specification introduces an alternative way to select a HTTP
response from a cache based upon its request headers, using the HTTP response from a cache based upon its request headers, using the HTTP
"Variants" and "Variant-Key" response header fields. Its aim is to "Variants" and "Variant-Key" response header fields. Its aim is to
make HTTP proactive content negotiation more cache-friendly. make HTTP proactive content negotiation more cache-friendly.
Note to Readers About This Document
_RFC EDITOR: please remove this section before publication_ This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group Status information for this document may be found at
mailing list (ietf-http-wg@w3.org), which is archived at <https://datatracker.ietf.org/doc/draft-ietf-httpbis-variants/>.
https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].
Working Group information can be found at https://httpwg.github.io/ Discussion of this document takes place on the HTTP Working Group
[2]; source code and issues list for this draft can be found at mailing list (<mailto:ietf-http-wg@w3.org>), which is archived at
https://github.com/httpwg/http-extensions/labels/variants [3]. <https://lists.w3.org/Archives/Public/ietf-http-wg/>. Working Group
information can be found at <https://httpwg.org/>.
There is a prototype implementation of the algorithms herein at Source for this draft and an issue tracker can be found at
https://github.com/mnot/variants-toy [4]. <https://github.com/httpwg/http-extensions/labels/variants>.
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 https://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 May 5, 2020. This Internet-Draft will expire on December 23, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2022 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
(https://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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
4.2. Check Vary . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Check Vary . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Example of Cache Behaviour . . . . . . . . . . . . . . . 11 4.3. Example of Cache Behaviour . . . . . . . . . . . . . . . 11
4.3.1. A Variant Missing From the Cache . . . . . . . . . . 12 4.3.1. A Variant Missing From the Cache . . . . . . . . . . 12
4.3.2. Variants That Don't Overlap the Client's Request . . 13 4.3.2. Variants That Don't Overlap the Client's Request . . 13
5. Origin Server Behaviour . . . . . . . . . . . . . . . . . . . 13 5. Origin Server Behaviour . . . . . . . . . . . . . . . . . . . 13
5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Single Variant . . . . . . . . . . . . . . . . . . . 14 5.1.1. Single Variant . . . . . . . . . . . . . . . . . . . 14
5.1.2. Multiple Variants . . . . . . . . . . . . . . . . . . 15 5.1.2. Multiple Variants . . . . . . . . . . . . . . . . . . 15
5.1.3. Partial Coverage . . . . . . . . . . . . . . . . . . 15 5.1.3. Partial Coverage . . . . . . . . . . . . . . . . . . 15
6. Defining Content Negotiation Using Variants . . . . . . . . . 16 6. Defining Content Negotiation Using Variants . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Implementations . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Variants for Existing Content Negotiation Mechanisms 19 Appendix A. Variants for Existing Content Negotiation Mechanisms 19
A.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 19 A.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.2. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20 A.2. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20
A.3. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20 A.3. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21
A.4. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 21 A.4. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
HTTP proactive content negotiation ([RFC7231], Section 3.4.1) is HTTP proactive content negotiation ([RFC7231], Section 3.4.1) is
seeing renewed interest, both for existing request headers like seeing renewed interest, both for existing request headers like
Accept-Language and for newer ones (for example, see Accept-Language and for newer ones (for example, see
[I-D.ietf-httpbis-client-hints]). [I-D.ietf-httpbis-client-hints]).
Successfully reusing negotiated responses that have been stored in a Successfully reusing negotiated responses that have been stored in a
skipping to change at page 4, line 8 skipping to change at page 4, line 8
Provided that the cache has full knowledge of the semantics of Provided that the cache has full knowledge of the semantics of
Accept-Language and Content-Language, it will know that an English Accept-Language and Content-Language, it will know that an English
representation is available and might be able to infer that a French representation is available and might be able to infer that a French
representation is not available. But, it does not know (for example) representation is not available. But, it does not know (for example)
whether a Japanese representation is available without making another whether a Japanese representation is available without making another
request, incurring possibly unnecessary latency. request, incurring possibly unnecessary latency.
This specification introduces the HTTP Variants response header field This specification introduces the HTTP Variants response header field
(Section 2) to enumerate the available variant representations on the (Section 2) to enumerate the available variant representations on the
origin server, to provide clients and caches with enough information origin server, to provide clients and caches with enough information
to properly satisfy requests - either by selecting a response from to properly satisfy requests -- either by selecting a response from
cache or by forwarding the request towards the origin - by following cache or by forwarding the request towards the origin -- by following
the algorithm defined in Section 4. the algorithm defined in Section 4.
Its companion Variant-Key response header field (Section 3) indicates Its companion Variant-Key response header field (Section 3) indicates
the applicable key(s) that the response is associated with, so that the applicable key(s) that the response is associated with, so that
it can be reliably reused in the future. Effectively, it allows the it can be reliably reused in the future. Effectively, it allows the
specification of a request header field to define how it affects the specification of a request header field to define how it affects the
secondary cache key. secondary cache key.
When this specification is in use, the example above might become: When this specification is in use, the example above might become:
GET /foo HTTP/1.1 GET /foo HTTP/1.1
Host: www.example.com Host: www.example.com
Accept-Language: en;q=0.5, fr;q=1.0 Accept-Language: en;q=0.5, fr;q=1.0
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/html Content-Type: text/html
Content-Language: en Content-Language: en
Vary: Accept-Language Vary: Accept-Language
Variants: Accept-Language;de;en;jp Variants: accept-language;de;en;jp
Variant-Key: en Variant-Key: en
Transfer-Encoding: chunked Transfer-Encoding: chunked
[English content] [English content]
Proactive content negotiation mechanisms that wish to be used with Proactive content negotiation mechanisms that wish to be used with
Variants need to define how to do so explicitly; see Section 6. As a Variants need to define how to do so explicitly; see Section 6. As a
result, it is best suited for negotiation over request headers that result, it is best suited for negotiation over request headers that
are well-understood. are well-understood.
skipping to change at page 5, line 9 skipping to change at page 5, line 9
Variants can be seen as a simpler version of the Alternates header Variants can be seen as a simpler version of the Alternates header
field introduced by [RFC2295]; unlike that mechanism, Variants does field introduced by [RFC2295]; unlike that mechanism, Variants does
not require specification of each combination of attributes, and does not require specification of each combination of attributes, and does
not assume that each combination has a unique URL. not assume that each combination has a unique URL.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] but relies on Structured Headers from notation of [RFC5234] but relies on Structured Headers from
[I-D.ietf-httpbis-header-structure] for parsing. [I-D.ietf-httpbis-header-structure] for parsing.
Additionally, it uses the "field-name" rule from [RFC7230], "type", Additionally, it uses the "field-name" rule from [RFC7230], "type",
"subtype", "content-coding" and "language-range" from [RFC7231], and "subtype", "content-coding" and "language-range" from [RFC7231], and
"cookie-name" from [RFC6265]. "cookie-name" from [RFC6265].
skipping to change at page 5, line 40 skipping to change at page 5, line 40
[I-D.ietf-httpbis-header-structure]). Its ABNF is: [I-D.ietf-httpbis-header-structure]). Its ABNF is:
Variants = sh-dict Variants = sh-dict
Each member-name represents the field-name of a request header that Each member-name represents the field-name of a request header that
is part of the secondary cache key; each member-value is an inner- is part of the secondary cache key; each member-value is an inner-
list of strings or tokens that convey representations of potential list of strings or tokens that convey representations of potential
values for that header field, hereafter referred to as "available- values for that header field, hereafter referred to as "available-
values". values".
If Structured Header parsing fails or a member's value does have the If Structured Header parsing fails or a member's value does not have
structure outlined above, the client MUST treat the representation as the structure outlined above, the client MUST treat the
having no Variants header field. representation as having no Variants header field.
Note that an available-value that is a token is interpreted as a Note that an available-value that is a token is interpreted as a
string containing the same characters, and vice versa. string containing the same characters, and vice versa.
So, given this example header field: So, given this example header field:
Variants: Accept-Encoding=(gzip) Variants: accept-encoding=(gzip)
a recipient can infer that the only content-coding available for that a recipient can infer that the only content-coding available for that
resource is "gzip" (along with the "identity" non-encoding; see resource is "gzip" (along with the "identity" non-encoding; see
Appendix A.2). Appendix A.2).
Given: Given:
Variants: accept-encoding=() Variants: accept-encoding=()
a recipient can infer that no content-codings (beyond identity) are a recipient can infer that no content-codings (beyond identity) are
supported. Note that as always, field-name is case-insensitive. supported. Note that as always, field-name is case-insensitive.
A more complex example: A more complex example:
Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr) Variants: accept-encoding=(gzip br), accept-language=(en fr)
Here, recipients can infer that two content-codings in addition to Here, recipients can infer that two content-codings in addition to
"identity" are available, as well as two content languages. Note "identity" are available, as well as two content languages. Note
that, as with all Structured Header dictionaries, they might occur in that, as with all Structured Header dictionaries, they might occur in
the same header field or separately, like this: the same header field or separately, like this:
Variants: Accept-Encoding=(gzip brotli) Variants: accept-encoding=(gzip brotli)
Variants: Accept-Language=(en fr) Variants: accept-language=(en fr)
The ordering of available-values is significant, as it might be used The ordering of available-values is significant, as it might be used
by the header's algorithm for selecting a response (in this example, by the header's algorithm for selecting a response (in this example,
the first language is the default; see Appendix A.3). the first language is the default; see Appendix A.3).
The ordering of the request header fields themselves indicates The ordering of the request header fields themselves indicates
descending application of preferences; in the example above, a cache descending application of preferences; in the example above, a cache
that has all of the possible permutations stored will honour the that has all of the possible permutations stored will honour the
client's preferences for Accept-Encoding before honouring Accept- client's preferences for Accept-Encoding before honouring Accept-
Language. Language.
skipping to change at page 8, line 11 skipping to change at page 8, line 11
the Variants header field; they can be interpreted by the algorithm the Variants header field; they can be interpreted by the algorithm
specific to processing that field. For example, Accept-Encoding specific to processing that field. For example, Accept-Encoding
defines an implicit "identity" available-value (Appendix A.2). defines an implicit "identity" available-value (Appendix A.2).
Each inner-list member is treated as identifying an available-value Each inner-list member is treated as identifying an available-value
for the corresponding variant-axis' field-name. Any list-member that for the corresponding variant-axis' field-name. Any list-member that
is a token is interpreted as a string containing the same characters. is a token is interpreted as a string containing the same characters.
For example: For example:
Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr) Variants: accept-encoding=(gzip br), accept-language=(en fr)
Variant-Key: (gzip fr) Variant-Key: (gzip fr)
This header pair indicates that the representation has a "gzip" This header pair indicates that the representation has a "gzip"
content-coding and "fr" content-language. content-coding and "fr" content-language.
If the response can be used to satisfy more than one request, they If the response can be used to satisfy more than one request, they
can be listed in additional members. For example: can be listed in additional members. For example:
Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr) Variants: accept-encoding=(gzip br), accept-language=(en fr)
Variant-Key: (gzip fr), ("identity" fr) Variant-Key: (gzip fr), ("identity" fr)
indicates that this response can be used for requests whose Accept- indicates that this response can be used for requests whose Accept-
Encoding algorithm selects "gzip" or "identity", as long as the Encoding algorithm selects "gzip" or "identity", as long as the
Accept-Language algorithm selects "fr" - perhaps because there is no Accept-Language algorithm selects "fr" -- perhaps because there is no
gzip-compressed French representation. gzip-compressed French representation.
When more than one Variant-Key value is in a response, the first one When more than one Variant-Key value is in a response, the first one
present MUST correspond to the request that caused that response to present MUST correspond to the request that caused that response to
be generated. For example: be generated. For example:
Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr) Variants: accept-encoding=(gzip br), accept-language=(en fr)
Variant-Key: (gzip fr), (identity fr), (br fr oops) Variant-Key: (gzip fr), (identity fr), (br fr oops)
is treated as if the Variant-Key header were completely absent, which is treated as if the Variant-Key header were completely absent, which
will tend to disable caching for the representation that contains it. will tend to disable caching for the representation that contains it.
Note that in Note that in
Variant-Key: (gzip fr) Variant-Key: (gzip fr)
Variant-Key: ("gzip " fr) Variant-Key: ("gzip " fr)
skipping to change at page 16, line 14 skipping to change at page 16, line 14
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: image/gif Content-Type: image/gif
Content-Language: en Content-Language: en
Content-Encoding: br Content-Encoding: br
Variants: Accept-Encoding=(br gzip) Variants: Accept-Encoding=(br gzip)
Variant-Key: (br) Variant-Key: (br)
Vary: Accept-Language, Accept-Encoding Vary: Accept-Language, Accept-Encoding
Transfer-Encoding: chunked Transfer-Encoding: chunked
Here, the cache will need to calculate a secondary cache key as per Here, the cache will need to calculate a secondary cache key as per
[RFC7234], Section 4.1 - but considering only Accept-Language to be [RFC7234], Section 4.1 -- but considering only Accept-Language to be
in its field-value - and then continue processing Variants for the in its field-value -- and then continue processing Variants for the
set of stored responses that the algorithm described there selects. set of stored responses that the algorithm described there selects.
6. Defining Content Negotiation Using Variants 6. Defining Content Negotiation Using Variants
To be usable with Variants, proactive content negotiation mechanisms To be usable with Variants, proactive content negotiation mechanisms
need to be specified to take advantage of it. Specifically, they: need to be specified to take advantage of it. Specifically, they:
o MUST define a request header field that advertises the clients o MUST define a request header field that advertises the clients
preferences or capabilities, whose field-name SHOULD begin with preferences or capabilities. Often, its field-name will begin
"Accept-". with "Accept-", but this is not required.
o MUST define the syntax of an available-value that will occur in o MUST define the syntax of an available-value that will occur in
Variants and Variant-Key. Variants and Variant-Key.
o MUST define an algorithm for selecting a result. It MUST return a o MUST define an algorithm for selecting a result. It MUST return a
list of available-values that are suitable for the request, in list of available-values that are suitable for the request, in
order of preference, given the value of the request header order of preference, given the value of the request header
nominated above (or null if the request header is absent) and an nominated above (or null if the request header is absent) and an
available-values list from the Variants header. If the result is available-values list from the Variants header. If the result is
an empty list, it implies that the cache cannot satisfy the an empty list, it implies that the cache cannot satisfy the
request. request.
Appendix A fulfils these requirements for some existing proactive Appendix A fulfils these requirements for some existing proactive
content negotiation mechanisms in HTTP. content negotiation mechanisms in HTTP.
7. IANA Considerations 7. Implementations
This section is to be removed before publishing as an RFC.
There is a prototype implementation of the algorithms in this
document at <https://github.com/mnot/variants-toy>.
8. IANA Considerations
This specification registers the following entry in the Permanent This specification registers the following entry in the Permanent
Message Header Field Names registry established by [RFC3864]: Message Header Field Names registry established by [RFC3864]:
o Header field name: Variants o Header field name: Variants
o Applicable protocol: http o Applicable protocol: http
o Status: standard o Status: standard
o Author/Change Controller: IETF o Author/Change Controller: IETF
o Specification document(s): [this document] o Specification document(s): [this document]
o Related information: o Related information:
This specification registers the following entry in the Permanent This specification registers the following entry in the Permanent
Message Header Field Names registry established by [RFC3864]: Message Header Field Names registry established by [RFC3864]:
o Header field name: Variant-Key o Header field name: Variant-Key
skipping to change at page 17, line 25 skipping to change at page 17, line 37
o Applicable protocol: http o Applicable protocol: http
o Status: standard o Status: standard
o Author/Change Controller: IETF o Author/Change Controller: IETF
o Specification document(s): [this document] o Specification document(s): [this document]
o Related information: o Related information:
8. Security Considerations 9. Security Considerations
If the number or advertised characteristics of the representations If the number or advertised characteristics of the representations
available for a resource are considered sensitive, the Variants available for a resource are considered sensitive, the Variants
header by its nature will leak them. header by its nature will leak them.
Note that the Variants header is not a commitment to make Note that the Variants header is not a commitment to make
representations of a certain nature available; the runtime behaviour representations of a certain nature available; the runtime behaviour
of the server always overrides hints like Variants. of the server always overrides hints like Variants.
9. References 10. References
10.1. Normative References
9.1. Normative References
[I-D.ietf-httpbis-header-structure] [I-D.ietf-httpbis-header-structure]
Nottingham, M. and P. Kamp, "Structured Headers for HTTP", Nottingham, M. and P. Kamp, "Structured Field Values for
draft-ietf-httpbis-header-structure-13 (work in progress), HTTP", draft-ietf-httpbis-header-structure-19 (work in
August 2019. progress), June 2020.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006, Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September
<https://www.rfc-editor.org/info/rfc4647>. 2006, <https://www.rfc-editor.org/info/rfc4647>.
[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,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[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,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
skipping to change at page 18, line 33 skipping to change at page 19, line 5
[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,
<https://www.rfc-editor.org/info/rfc7234>. <https://www.rfc-editor.org/info/rfc7234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 10.2. Informative References
[I-D.ietf-httpbis-client-hints] [I-D.ietf-httpbis-client-hints]
Grigorik, I., "HTTP Client Hints", draft-ietf-httpbis- Grigorik, I. and Y. Weiss, "HTTP Client Hints", draft-
client-hints-07 (work in progress), March 2019. ietf-httpbis-client-hints-15 (work in progress), July
2020.
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998, in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998,
<https://www.rfc-editor.org/info/rfc2295>. <https://www.rfc-editor.org/info/rfc2295>.
[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,
<https://www.rfc-editor.org/info/rfc3864>. <https://www.rfc-editor.org/info/rfc3864>.
9.3. URIs
[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
[2] https://httpwg.github.io/
[3] https://github.com/httpwg/http-extensions/labels/variants
[4] https://github.com/mnot/variants-toy
Appendix A. Variants for Existing Content Negotiation Mechanisms Appendix A. Variants for Existing Content Negotiation Mechanisms
This appendix defines the required information to use existing This appendix defines the required information to use existing
proactive content negotiation mechanisms (as defined in [RFC7231], proactive content negotiation mechanisms (as defined in [RFC7231],
Section 5.3) with the Variants header field. Section 5.3) with the Variants header field.
A.1. Accept A.1. Accept
This section defines variant handling for the Accept request header This section defines variant handling for the Accept request header
(section 5.3.2 of [RFC7231]). (section 5.3.2 of [RFC7231]).
skipping to change at page 23, line 9 skipping to change at page 23, line 25
It is also a generalisation of a Fastly VCL feature designed by It is also a generalisation of a Fastly VCL feature designed by
Rogier 'DocWilco' Mulhuijzen. Rogier 'DocWilco' Mulhuijzen.
Thanks to Hooman Beheshti, Ilya Grigorik, Leif Hedstrom, and Jeffrey Thanks to Hooman Beheshti, Ilya Grigorik, Leif Hedstrom, and Jeffrey
Yasskin for their review and input. Yasskin for their review and input.
Author's Address Author's Address
Mark Nottingham Mark Nottingham
Fastly Fastly
Prahran
Australia
Email: mnot@mnot.net Email: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
 End of changes. 36 change blocks. 
67 lines changed or deleted 67 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/