< draft-ietf-httpbis-targeted-cache-control-01.txt		draft-ietf-httpbis-targeted-cache-control-02.txt >
	HTTP S. Ludin		HTTP S. Ludin
	Internet-Draft Akamai		Internet-Draft Akamai
	Intended status: Standards Track M. Nottingham		Intended status: Standards Track M. Nottingham
	Expires: 24 March 2022 Fastly		Expires: 17 April 2022 Fastly
	Y. Wu		Y. Wu
	Cloudflare		Cloudflare
	20 September 2021		14 October 2021
	Targeted HTTP Cache Control		Targeted HTTP Cache Control
	draft-ietf-httpbis-targeted-cache-control-01		draft-ietf-httpbis-targeted-cache-control-02
	Abstract		Abstract
	This specification defines a convention for HTTP response header		This specification defines a convention for HTTP response header
	fields that allow directives controlling caching to be targeted at		fields that allow cache directives to be targeted at specific caches
	specific caches or classes of caches. It also defines one such		or classes of caches. It also defines one such header field,
	header field, targeted at Content Delivery Network (CDN) caches.		targeted at Content Delivery Network (CDN) caches.
	Note to Readers		Note to Readers
	_RFC EDITOR: please remove this section before publication_		_RFC EDITOR: please remove this section before publication_
	The issues list for this draft can be found at		The issues list for this draft can be found at
	https://github.com/httpwg/http-extensions/labels/targeted-cc		https://github.com/httpwg/http-extensions/labels/targeted-cc
	(https://github.com/httpwg/http-extensions/labels/targeted-cc).		(https://github.com/httpwg/http-extensions/labels/targeted-cc).
	The most recent (often, unpublished) draft is at https://httpwg.org/		The most recent (often, unpublished) draft is at https://httpwg.org/
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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 24 March 2022.		This Internet-Draft will expire on 17 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. Targeted Cache-Control Header Fields . . . . . . . . . . . . 3		2. Targeted Cache-Control Header Fields . . . . . . . . . . . . 3
	2.1. Cache Behavior . . . . . . . . . . . . . . . . . . . . . 3		2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.2. Cache Behavior . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Interaction with HTTP Freshness . . . . . . . . . . . . . 6		2.3. Interaction with HTTP Freshness . . . . . . . . . . . . . 6
	2.4. Defining Targeted Fields . . . . . . . . . . . . . . . . 7		2.4. Defining Targeted Fields . . . . . . . . . . . . . . . . 6
	3. The CDN-Cache-Control Targeted Field . . . . . . . . . . . . 7		3. The CDN-Cache-Control Targeted Field . . . . . . . . . . . . 7
	3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6.1. Normative References . . . . . . . . . . . . . . . . . . 8		6.1. Normative References . . . . . . . . . . . . . . . . . . 8
	6.2. Informative References . . . . . . . . . . . . . . . . . 9		6.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	Modern deployments of HTTP often use multiple layers of caching with		Modern deployments of HTTP often use multiple layers of caching. For
	varying properties. For example, a Web site might use a cache on the		example, a Web site might use a cache on the origin server itself; it
	origin server itself; it might deploy a caching layer in the same		might deploy a caching layer in the same network as the origin
	network as the origin server, it might use one or more Content		server, it might use one or more Content Delivery Networks (CDNs)
	Delivery Networks (CDNs) that are distributed throughout the		that are distributed throughout the Internet, and it might utilise
	Internet, and it might utilise browser caching as well.		browser caching as well.
	Because it is often desirable to control these different classes of		Because it is often desirable to control these different classes of
	caches separately, some means of targeting directives at them is		caches separately, some means of targeting directives at them is
	necessary.		necessary.
	The HTTP Cache-Control response header field is widely used to direct		The HTTP Cache-Control response header field (defined in Section 5.2
	caching behavior. However, it is relatively undifferentiated; while		of [HTTP-CACHING]) is widely used to direct caching behavior.
	some directives (e.g., s-maxage) are targeted at a specific class of		However, it is relatively undifferentiated; while some directives
	caches (for s-maxage, shared caches), targeting is not consistently		(e.g., s-maxage) are targeted at a specific class of caches (for
	available across all existing cache directives (e.g., stale-while-		s-maxage, shared caches), targeting is not consistently available
	revalidate). This is problematic, especially as the number of		across all existing cache directives (e.g., stale-while-revalidate).
	caching extensions grows, along with the number of potential targets.		This is problematic, especially as the number of caching extensions
			grows, along with the number of potential targets.
	Some implementations have defined ad hoc control mechanisms to		Some implementations have defined ad hoc control mechanisms to
	overcome this issue, but their interoperability is low. Section 2		overcome this issue, but their interoperability is low. Section 2
	defines a standard framework for targeted cache control using HTTP		defines a standard framework for targeted cache control using HTTP
	response headers, and Section 3 defines one such header: the CDN-		response headers, and Section 3 defines one such header: the CDN-
	Cache-Control response header field.		Cache-Control response header field.
	1.1. Notational Conventions		1.1. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 47 ¶
	However, it has a distinct field name that indicates the target for		However, it has a distinct field name that indicates the target for
	its directives.		its directives.
	For example:		For example:
	CDN-Cache-Control: max-age=60		CDN-Cache-Control: max-age=60
	is a targeted field that applies to Content Delivery Networks (CDNs),		is a targeted field that applies to Content Delivery Networks (CDNs),
	as defined in Section 3.		as defined in Section 3.
	2.1. Cache Behavior		2.1. Syntax
			Targeted fields are Dictionary Structured Fields (Section 3.2 of
			[STRUCTURED-FIELDS]). Each member of the dictionary is a cache
			response directive from the Hypertext Transfer Protocol (HTTP) Cache
			Directive Registry.
			Because cache directives are not defined in terms of structured data
			types, it is necessary to map their values into the appropriate
			types. Section 5.2 of [HTTP-CACHING] defines cache directive values
			to be either absent, a quoted-string, or a token.
			This means that cache directives that have no value will be mapped to
			a Boolean (Section 3.3.6 of [STRUCTURED-FIELDS]). When the value is
			a quoted-string, it will be mapped to a String (Section 3.3.3 of
			[STRUCTURED-FIELDS]), and when it is a token, it will map to a Token
			(Section 3.3.4 of [STRUCTURED-FIELDS]), an Integer (Section 3.3.1 of
			[STRUCTURED-FIELDS]) or a Decimal (Section 3.3.2 of
			[STRUCTURED-FIELDS]), depending on the content of the value.
			For example, the max-age directive (Section 5.2.2.1 of
			[HTTP-CACHING]) has an integer value; no-store (Section 5.2.2.5 of
			[HTTP-CACHING]) always has a boolean true value, and no-cache
			(Section 5.2.2.4 of [HTTP-CACHING]) has a value that can either be
			boolean true or a string containing a comma-delimited list of field
			names.
			Implementations MUST NOT generate values that violate these inferred
			constraints on the directive's value. In particular, string values
			whose first character is not alphabetic or "*" MUST be generated as
			structured Strings, so they are not mistaken for other types.
			Implementations SHOULD NOT consume values that violate these inferred
			constraints. For example, a consuming implementation were to coerce
			a max-age with a decimal value into an integer would behave
			differently than other implementations, potentially causing
			interoperability issues.
			Parameters received on directives are to be ignored, unless other
			handling is explicitly specified.
			If a targeted field in a given response is empty, or a parsing error
			is encountered, that field MUST be ignored by the cache (i.e., it
			behaves as if the field were not present, likely falling back to
			other cache control mechanisms present).
			2.2. Cache Behavior
	A cache that implement this specification maintains a _target list_ -		A cache that implement this specification maintains a _target list_ -
	an ordered list of the targeted field names that it uses for caching		an ordered list of the targeted field names that it uses for caching
	policy, with the order reflecting priority from most applicable to		policy, with the order reflecting priority from most applicable to
	least. The target list might be fixed, user-configurable, or		least. The target list might be fixed, user-configurable, or
	generated per request, depending upon the implementation.		generated per request, depending upon the implementation.
	For example, a CDN cache might support both CDN-Cache-Control and a		For example, a CDN cache might support both CDN-Cache-Control and a
	header specific to that CDN, ExampleCDN-Cache-Control, with the		header specific to that CDN, ExampleCDN-Cache-Control, with the
	latter overriding the former. Its target list would be:		latter overriding the former. Its target list would be:
	skipping to change at page 5, line 5 ¶		skipping to change at page 6, line 5 ¶
	Furthermore, they SHOULD implement other cache directives (including		Furthermore, they SHOULD implement other cache directives (including
	extension cache directives) that they support in the Cache-Control		extension cache directives) that they support in the Cache-Control
	response header field.		response header field.
	The semantics and precedence of cache directives in a targeted field		The semantics and precedence of cache directives in a targeted field
	are the same as those in Cache-Control. In particular, no-store and		are the same as those in Cache-Control. In particular, no-store and
	no-cache make max-age inoperative, and unrecognised extension		no-cache make max-age inoperative, and unrecognised extension
	directives are ignored.		directives are ignored.
	2.2. Syntax
	Targeted fields are defined as Dictionary Structured Fields
	(Section 3.2 of [STRUCTURED-FIELDS]). Each member of the dictionary
	is a cache directive from the Hypertext Transfer Protocol (HTTP)
	Cache Directive Registry.
	Because cache directives are not defined in terms of structured data
	types, it is necessary to map their values into the appropriate
	types. Typically, they are mapped into a Boolean (Section 3.3.6 of
	[STRUCTURED-FIELDS]) when the member has no separate value, a Token
	(Section 3.3.4 of [STRUCTURED-FIELDS]) for alphanumeric values, a
	String (Section 3.3.3 of [STRUCTURED-FIELDS]) for quote-delimited
	values, or an Integer (Section 3.3.1 of [STRUCTURED-FIELDS]) for
	purely numeric values.
	For example, the max-age directive (Section 5.2.2.1 of
	[HTTP-CACHING]) has an integer value; no-store (Section 5.2.2.5 of
	[HTTP-CACHING]) always has a boolean true value, and no-cache
	(Section 5.2.2.4 of [HTTP-CACHING]) has a value that can either be
	boolean true or a string containing a comma-delimited list of field
	names.
	Implementations MUST NOT generate and SHOULD NOT consume values that
	violate these inferred constraints on the directive's value (e.g.
	coerce a max-age with a decimal value into an integer). Parameters
	received on directives are to be ignored, unless other handling is
	explicitly specified.
	Sending implementations MUST generate valid Structured Fields.
	Receiving implementations SHOULD use a Structured Fields parser, but
	MAY reuse an existing parser for the Cache-Control field value
	(Section 5.2 of [HTTP-CACHING]). Those that do SHOULD implement the
	following constraints, to aid in a smooth transition to a full
	Structured Field parser and prevent interoperability issues:
	* Directive names are all lowercase (e.g., "MAX-AGE=60" is
	considered an error).
	* If a directive is repeated in the field value (e.g., "max-age=30,
	max-age=60"), the last value 'wins' (60, in this case).
	* Members of the directives can have parameters (e.g., "max-
	age=30;a=b;c=d"), which are ignored unless specified.
	If a targeted field in a given response is empty, or a parsing error
	is encountered, that field MUST be ignored by the cache (i.e., it
	behaves as if the field were not present, likely falling back to
	other cache control mechanisms present).
	2.3. Interaction with HTTP Freshness		2.3. Interaction with HTTP Freshness
	HTTP caching has a single, end-to-end freshness model defined in		HTTP caching has a single, end-to-end freshness model defined in
	Section 4.2 of [I-D.ietf-httpbis-cache]. When additional freshness		Section 4.2 of [HTTP-CACHING]. When additional freshness mechanisms
	mechanisms are only available to some caches along a request path		are only available to some caches along a request path (for example,
	(for example, using targeted fields), their interactions need to be		using targeted fields), their interactions need to be carefully
	carefully considered. In particular, a targeted cache might have		considered. In particular, a targeted cache might have longer
	longer freshness lifetimes available to it than other caches, causing		freshness lifetimes available to it than other caches, causing it to
	it to serve responses that appear to be prematurely (or even		serve responses that appear to be prematurely (or even immediately)
	immediately) stale to them, negatively impacting cache efficiency.		stale to them, negatively impacting cache efficiency.
	For example, a response stored by a CDN cache might be served with		For example, a response stored by a CDN cache might be served with
	the following headers:		the following headers:
	Age: 1800		Age: 1800
	Cache-Control: max-age=600		Cache-Control: max-age=600
	CDN-Cache-Control: max-age=3600		CDN-Cache-Control: max-age=3600
	From the CDN's perspective, this response is still fresh after being		From the CDN's perspective, this response is still fresh after being
	cached for 30 minutes, while from other caches' standpoint, this		cached for 30 minutes, while from other caches' standpoint, this
	skipping to change at page 9, line 8 ¶		skipping to change at page 8, line 48 ¶
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	semantics-19>.		semantics-19>.
	[HTTP-CACHING]		[HTTP-CACHING]
	Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Caching", Work in Progress, Internet-Draft, draft-ietf-		Caching", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-cache-19, 12 September 2021,		httpbis-cache-19, 12 September 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	cache-19>.		cache-19>.
	[I-D.ietf-httpbis-cache]
	Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Caching", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-cache-19, 12 September 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	cache-19>.
	[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/rfc/rfc2119>.		<https://www.rfc-editor.org/rfc/rfc2119>.
	[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/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
	[STRUCTURED-FIELDS]		[STRUCTURED-FIELDS]
End of changes. 13 change blocks.
	88 lines changed or deleted		78 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/