draft-ietf-httpbis-variants-03.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) July 1, 2018		Updates: 7234 (if approved) October 11, 2018
	Intended status: Standards Track		Intended status: Standards Track
	Expires: January 2, 2019		Expires: April 14, 2019
	HTTP Representation Variants		HTTP Representation Variants
	draft-ietf-httpbis-variants-03		draft-ietf-httpbis-variants-latest
	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 January 2, 2019.		This Internet-Draft will expire on April 14, 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 2, line 40 ¶		skipping to change at page 2, line 40 ¶
	4.2. Check Vary . . . . . . . . . . . . . . . . . . . . . . . 10		4.2. Check Vary . . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Example of Cache Behaviour . . . . . . . . . . . . . . . 11		4.3. Example of Cache Behaviour . . . . . . . . . . . . . . . 11
	5. Origin Server Behaviour . . . . . . . . . . . . . . . . . . . 12		5. Origin Server Behaviour . . . . . . . . . . . . . . . . . . . 12
	5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12		5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.1.1. Single Variant . . . . . . . . . . . . . . . . . . . 12		5.1.1. Single Variant . . . . . . . . . . . . . . . . . . . 12
	5.1.2. Multiple Variants . . . . . . . . . . . . . . . . . . 13		5.1.2. Multiple Variants . . . . . . . . . . . . . . . . . . 13
	5.1.3. Partial Coverage . . . . . . . . . . . . . . . . . . 14		5.1.3. Partial Coverage . . . . . . . . . . . . . . . . . . 14
	6. Defining Content Negotiation Using Variants . . . . . . . . . 14		6. Defining Content Negotiation Using Variants . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 15		8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.1. Normative References . . . . . . . . . . . . . . . . . . 16		9.1. Normative References . . . . . . . . . . . . . . . . . . 16
	9.2. Informative References . . . . . . . . . . . . . . . . . 16		9.2. Informative References . . . . . . . . . . . . . . . . . 16
	9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17		9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Appendix A. Variants for Existing Content Negotiation Mechanisms 17		Appendix A. Variants for Existing Content Negotiation Mechanisms 17
	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
	skipping to change at page 3, line 40 ¶		skipping to change at page 3, line 40 ¶
	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
	Transfer-Encoding: chunked		Transfer-Encoding: chunked
	[French content]		[English content]
	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
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 25 ¶
	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
	[French 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.
	Variants also works best when content negotiation takes place over a		Variants also works best when content negotiation takes place over a
	constrained set of representations; since each variant needs to be		constrained set of representations; since each variant needs to be
	listed in the header field, it is ill-suited for open-ended sets of		listed in the header field, it is ill-suited for open-ended sets of
	representations.		representations.
	skipping to change at page 11, line 19 ¶		skipping to change at page 11, line 19 ¶
	Note that implementation of the Vary header field varies in practice,		Note that implementation of the Vary header field varies in practice,
	and the algorithm above illustrates only one way to apply it. It is		and the algorithm above illustrates only one way to apply it. It is
	equally viable to forward the request if there is a request header		equally viable to forward the request if there is a request header
	listed in Vary but not Variants.		listed in Vary but not Variants.
	4.3. Example of Cache Behaviour		4.3. Example of Cache Behaviour
	For example, if the selected variants-header was:		For example, if the selected variants-header was:
	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
	skipping to change at page 15, line 10 ¶		skipping to change at page 15, line 10 ¶
	order of preference, given the value of the request header		order of preference, given the value of the request header
	nominated above and an available-values list from the Variants		nominated above and an available-values list from the Variants
	header. If the result is an empty list, it implies that the cache		header. If the result is an empty list, it implies that the cache
	cannot satisfy the request.		cannot satisfy the 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. IANA Considerations
	This specification registers two values in the Permanent Message		This specification registers the following entry in the Permanent
	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
			Message Header Field Names registry established by [RFC3864]:
	o Header field name: Variant-Key		o Header field name: Variant-Key
	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]
	skipping to change at page 16, line 43 ¶		skipping to change at page 16, line 46 ¶
	<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., "HTTP Client Hints", draft-ietf-httpbis-
	client-hints-05 (work in progress), January 2018.		client-hints-06 (work in progress), July 2018.
	[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. 11 change blocks.
	11 lines changed or deleted		14 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/