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) August 6, 2024 | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: May 5, 2020 | Expires: February 7, 2025 | |||
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 February 7, 2025. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 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 | |||
(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/ |