draft-ietf-httpbis-variants-05.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) March 25, 2019		Updates: 7234 (if approved) July 27, 2019
	Intended status: Standards Track		Intended status: Standards Track
	Expires: September 26, 2019		Expires: January 28, 2020
	HTTP Representation Variants		HTTP Representation Variants
	draft-ietf-httpbis-variants-05		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 September 26, 2019.		This Internet-Draft will expire on January 28, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 9, line 20 ¶		skipping to change at page 9, line 20 ¶
	4. Cache Behaviour		4. Cache Behaviour
	Caches that implement the Variants header field and the relevant		Caches that implement the Variants header field and the relevant
	semantics of the field-names it contains can use that knowledge to		semantics of the field-names it contains can use that knowledge to
	either select an appropriate stored representation, or forward the		either select an appropriate stored representation, or forward the
	request if no appropriate representation is stored.		request if no appropriate representation is stored.
	They do so by running this algorithm (or its functional equivalent)		They do so by running this algorithm (or its functional equivalent)
	upon receiving a request:		upon receiving a request:
	Given incoming-request (a mapping of field-names to lists of field		Given incoming-request (a mapping of field-names to field-values,
	values), and stored-responses (a list of stored responses suitable		after being combined as allowed by Section 3.2.2 of [RFC7230]), and
	for reuse as defined in Section 4 of [RFC7234], excepting the		stored-responses (a list of stored responses suitable for reuse as
	requirement to calculate a secondary cache key):		defined in Section 4 of [RFC7234], excepting the requirement to
			calculate a secondary cache key):
	1. If stored-responses is empty, return an empty list.		1. If stored-responses is empty, return an empty list.
	2. Order stored-responses by the "Date" header field, most recent to		2. Order stored-responses by the "Date" header field, most recent to
	least recent.		least recent.
	3. Let sorted-variants be an empty list.		3. Let sorted-variants be an empty list.
	4. If the freshest member of stored-responses (as per [RFC7234],		4. If the freshest member of stored-responses (as per [RFC7234],
	Section 4.2) has one or more "Variants" header field(s) that		Section 4.2) has one or more "Variants" header field(s) that
	skipping to change at page 9, line 49 ¶		skipping to change at page 9, line 50 ¶
	SHOULD be the most recent response, but MAY be from an older		SHOULD be the most recent response, but MAY be from an older
	one as long as it is still fresh.		one as long as it is still fresh.
	2. For each variant-axis in variants-header:		2. For each variant-axis in variants-header:
	1. If variant-axis' field-name corresponds to the request		1. If variant-axis' field-name corresponds to the request
	header field identified by a content negotiation		header field identified by a content negotiation
	mechanism that the implementation supports:		mechanism that the implementation supports:
	1. Let request-value be the field-value associated with		1. Let request-value be the field-value associated with
	field-name in incoming-request (after being combined		field-name in incoming-request, or null if field-name
	as allowed by Section 3.2.2 of [RFC7230]), or null if		is not in incoming-request.
	field-name is not in incoming-request.
	2. Let sorted-values be the result of running the		2. Let sorted-values be the result of running the
	algorithm defined by the content negotiation		algorithm defined by the content negotiation
	mechanism with request-value and variant-axis'		mechanism with request-value and variant-axis'
	available-values.		available-values.
	3. Append sorted-values to sorted-variants.		3. Append sorted-values to sorted-variants.
	At this point, sorted-variants will be a list of lists, each		At this point, sorted-variants will be a list of lists, each
	member of the top-level list corresponding to a variant-axis		member of the top-level list corresponding to a variant-axis
	skipping to change at page 11, line 13 ¶		skipping to change at page 11, line 13 ¶
	this-key and possible-keys.		this-key and possible-keys.
	4. Return possible-keys.		4. Return possible-keys.
	4.2. Check Vary		4.2. Check Vary
	This algorithm is an example of how an implementation can meet the		This algorithm is an example of how an implementation can meet the
	requirement to apply the members of the Vary header field that are		requirement to apply the members of the Vary header field that are
	not covered by Variants.		not covered by Variants.
	Given stored-response (a stored response):		Given incoming-request (a mapping of field-names to field-values,
			after being combined as allowed by Section 3.2.2 of [RFC7230]), and
			stored-response (a stored response):
	1. Let filtered-vary be the field-value(s) of stored-response's		1. Let filtered-vary be the field-value(s) of stored-response's
	"Vary" header field.		"Vary" header field.
	2. Let processed-variants be a list containing the request header		2. Let processed-variants be a list containing the request header
	fields that identify the content negotiation mechanisms supported		fields that identify the content negotiation mechanisms supported
	by the implementation.		by the implementation.
	3. Remove any member of filtered-vary that is a case-insensitive		3. Remove any member of filtered-vary that is a case-insensitive
	match for a member of processed-variants.		match for a member of processed-variants.
	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-09 (work in progress),		draft-ietf-httpbis-header-structure-10 (work in progress),
	December 2018.		April 2019.
	[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 33 ¶		skipping to change at page 18, line 33 ¶
	<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-06 (work in progress), July 2018.		client-hints-07 (work in progress), March 2019.
	[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. 9 change blocks.
	15 lines changed or deleted		17 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/