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) April 1, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: May 5, 2020 Expires: October 3, 2020
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 Note to Readers
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 October 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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 44 skipping to change at page 2, line 44
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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 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 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).
skipping to change at page 16, line 24 skipping to change at page 16, line 24
[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
skipping to change at page 17, line 41 skipping to change at page 17, line 41
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 9. References
9.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 Headers for HTTP",
draft-ietf-httpbis-header-structure-13 (work in progress), draft-ietf-httpbis-header-structure-15 (work in progress),
August 2019. January 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. and M. Davis, "Matching of Language Tags",
BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006, BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006,
<https://www.rfc-editor.org/info/rfc4647>. <https://www.rfc-editor.org/info/rfc4647>.
skipping to change at page 18, line 36 skipping to change at page 18, line 36
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 9.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-10 (work in progress), February
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>.
 End of changes. 12 change blocks. 
17 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/