draft-ietf-httpbis-variants-02.txt   draft-ietf-httpbis-variants-03.txt 
HTTP M. Nottingham HTTP M. Nottingham
Internet-Draft Fastly Internet-Draft Fastly
Updates: 7234 (if approved) June 5, 2018 Updates: 7234 (if approved) July 1, 2018
Intended status: Standards Track Intended status: Standards Track
Expires: December 7, 2018 Expires: January 2, 2019
HTTP Representation Variants HTTP Representation Variants
draft-ietf-httpbis-variants-02 draft-ietf-httpbis-variants-03
Abstract Abstract
This specification introduces an alternative way to communicate a This specification introduces an alternative way to communicate a
secondary cache key for a HTTP resource, using the HTTP "Variants" secondary cache key for a HTTP resource, using the HTTP "Variants"
and "Variant-Key" response header fields. Its aim is to make HTTP and "Variant-Key" response header fields. Its aim is to make HTTP
proactive content negotiation more cache-friendly. 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 December 7, 2018. This Internet-Draft will expire on January 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 3, line 9 skipping to change at page 3, line 9
A.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 17 A.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.2. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 18 A.2. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 18
A.3. Accept-Language . . . . . . . . . . . . . . . . . . . . . 19 A.3. Accept-Language . . . . . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
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
Content-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
HTTP cache requires establishment of a secondary cache key HTTP cache requires establishment of a secondary cache key
([RFC7234], Section 4.1). Currently, the Vary header ([RFC7231], ([RFC7234], Section 4.1). Currently, the Vary header ([RFC7231],
Section 7.1.4) does this by nominating a set of request headers. Section 7.1.4) does this by nominating a set of request headers.
HTTP's caching model allows a certain amount of latitude in HTTP's caching model allows a certain amount of latitude in
normalising those request header field values, so as to increase the normalising those request header field values, so as to increase the
chances of a cache hit while still respecting the semantics of that chances of a cache hit while still respecting the semantics of that
skipping to change at page 7, line 33 skipping to change at page 7, line 33
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.
A more complex example involves listing multiple available-values in A more complex example involves listing multiple available-values in
a list member, to indicate that the response can be used to satisfy a list member, to indicate that the response can be used to satisfy
requests with any of those values. For example: requests with any of those values. For example:
Variants: Content-Encoding;gzip;br, Content-Language;en ;fr Variants: Accept-Encoding;gzip;br, Accept-Language;en ;fr
Variant-Key: gzip;identity, fr Variant-Key: gzip;identity, fr
indicates that this response can be used for requests whose Content- 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
Content-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.
This highlights an important aspect of Variant-Key; it is only used This highlights an important aspect of Variant-Key; it is only used
to indicate what request attributes are associated with the response to indicate what request attributes are associated with the response
containing it; this is different from headers like Content-Encoding, containing it; this is different from headers like Content-Encoding,
which indicate attributes of the response itself. which indicate attributes of the response itself.
3.1. Generating a Variant-Key List 3.1. Generating a Variant-Key List
This algorithm generates a list of normalised strings from Variant- This algorithm generates a list of normalised strings from Variant-
skipping to change at page 11, line 28 skipping to change at page 11, line 28
Variants: Accept-Language;en;fr,de, Accept-Encoding;gzip;br Variants: Accept-Language;en;fr,de, Accept-Encoding;gzip;br
and the request contained the headers: and the request contained the headers:
Accept-Language: fr;q=1.0, en;q=0.1 Accept-Language: fr;q=1.0, en;q=0.1
Accept-Encoding: gzip Accept-Encoding: gzip
Then the sorted-variants would be: Then the sorted-variants would be:
[ [
["fr", "en"] // prefers French, will accept English ["fr", "en"] // prefers French, will accept English
["gzip", "identity"] // prefers gzip encoding, will accept identity ["gzip", "identity"] // prefers gzip encoding, will accept identity
] ]
Which means that the sorted-keys would be: Which means that the sorted-keys would be:
[ [
'fr gzip', 'fr gzip',
'fr identity', 'fr identity',
'en gzip', 'en gzip',
'en identity' 'en identity'
] ]
skipping to change at page 13, line 5 skipping to change at page 13, line 5
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: image/gif Content-Type: image/gif
Content-Language: en Content-Language: en
Cache-Control: max-age=3600 Cache-Control: max-age=3600
Variants: Accept-Language;en;de Variants: Accept-Language;en;de
Variant-Key: en Variant-Key: en
Vary: Accept-Language Vary: Accept-Language
Transfer-Encoding: chunked Transfer-Encoding: chunked
Upon receipt of this response, the cache knows that two Upon receipt of this response, the cache knows that two
representations of this resource are available, one with a Content- representations of this resource are available, one with a language
Language of "en", and another whose Content-Language is "de". of "en", and another whose language is "de".
Subsequent requests (while this response is fresh) will cause the Subsequent requests (while this response is fresh) will cause the
cache to either reuse this response or forward the request, depending cache to either reuse this response or forward the request, depending
on what the selection algorithm determines. on what the selection algorithm determines.
So, if a request with "en" in Accept-Language is received and its So, if a request with "en" in Accept-Language is received and its
q-value indicates that it is acceptable, the stored response is used. q-value indicates that it is acceptable, the stored response is used.
A request that indicates that "de" is acceptable will be forwarded to A request that indicates that "de" is acceptable will be forwarded to
the origin, thereby populating the cache. A cache receiving a the origin, thereby populating the cache. A cache receiving a
request that indicates both languages are acceptable will use the request that indicates both languages are acceptable will use the
skipping to change at page 13, line 47 skipping to change at page 13, line 47
Content-Type: image/gif Content-Type: image/gif
Content-Language: en Content-Language: en
Content-Encoding: br Content-Encoding: br
Variants: Accept-Language;en;jp;de Variants: Accept-Language;en;jp;de
Variants: Accept-Encoding;br;gzip Variants: Accept-Encoding;br;gzip
Variant-Key: en, br Variant-Key: en, br
Vary: Accept-Language, Accept-Encoding Vary: Accept-Language, Accept-Encoding
Transfer-Encoding: chunked Transfer-Encoding: chunked
Here, the cache knows that there are two axes that the response Here, the cache knows that there are two axes that the response
varies upon; Content-Language and Content-Encoding. Thus, there are varies upon; language and encoding. Thus, there are a total of nine
a total of nine possible representations for the resource (including possible representations for the resource (including the identity
the identity encoding), and the cache needs to consider the selection encoding), and the cache needs to consider the selection algorithms
algorithms for both axes. for both axes.
Upon a subsequent request, if both selection algorithms return a Upon a subsequent request, if both selection algorithms return a
stored representation, it can be served from cache; otherwise, the stored representation, it can be served from cache; otherwise, the
request will need to be forwarded to origin. request will need to be forwarded to origin.
5.1.3. Partial Coverage 5.1.3. Partial Coverage
Now, consider the previous example, but where only one of the Vary'd Now, consider the previous example, but where only one of the Vary'd
axes (Content-Encoding) is listed in Variants: axes (encoding) is listed in Variants:
GET /bar HTTP/1.1 GET /bar HTTP/1.1
Host: www.example.net Host: www.example.net
Accept-Language: en;q=1.0, fr;q=0.5 Accept-Language: en;q=1.0, fr;q=0.5
Accept-Encoding: gzip, br Accept-Encoding: gzip, br
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
 End of changes. 12 change blocks. 
19 lines changed or deleted 19 lines changed or added

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