< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/