Internet-Draft | Targeted HTTP Cache Control | September 2021 |
Ludin, et al. | Expires 24 March 2022 | [Page] |
This specification defines a convention for HTTP response header fields that allow directives controlling caching to be targeted at specific caches or classes of caches. It also defines one such header field, targeted at Content Delivery Network (CDN) caches.¶
RFC EDITOR: please remove this section before publication¶
The issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/targeted-cc.¶
The most recent (often, unpublished) draft is at https://httpwg.org/http-extensions/draft-ietf-httpbis-targeted-cache-control.html.¶
See also the draft's current status in the IETF datatracker, at https://datatracker.ietf.org/doc/draft-ietf-httpbis-targeted-cache-control/.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 March 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
Modern deployments of HTTP often use multiple layers of caching with varying properties. For example, a Web site might use a cache on the origin server itself; it might deploy a caching layer in the same network as the origin server, it might use one or more Content Delivery Networks (CDNs) that are distributed throughout the Internet, and it might utilise browser caching as well.¶
Because it is often desirable to control these different classes of caches separately, some means of targeting directives at them is necessary.¶
The HTTP Cache-Control response header field is widely used to direct caching behavior. However, it is relatively undifferentiated; while some directives (e.g., s-maxage) are targeted at a specific class of caches (for s-maxage, shared caches), targeting is not consistently available across all existing cache directives (e.g., stale-while-revalidate). 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 overcome this issue, but their interoperability is low. Section 2 defines a standard framework for targeted cache control using HTTP response headers, and Section 3 defines one such header: the CDN-Cache-Control response header field.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
A Targeted Cache-Control Header Field (hereafter, "targeted field") is a HTTP response header field that has the same semantics as the Cache-Control response header field ([HTTP-CACHING], Section 5.2). However, it has a distinct field name that indicates the target for its directives.¶
For example:¶
is a targeted field that applies to Content Delivery Networks (CDNs), as defined in Section 3.¶
A cache that implement this specification maintains a target list - an ordered list of the targeted field names that it uses for caching policy, with the order reflecting priority from most applicable to least. The target list might be fixed, user-configurable, or generated per request, depending upon the implementation.¶
For example, a CDN cache might support both CDN-Cache-Control and a header specific to that CDN, ExampleCDN-Cache-Control, with the latter overriding the former. Its target list would be:¶
[ExampleCDN-Cache-Control, CDN-Cache-Control]¶
When a cache that implements this specification receives a response with one or more of of the header field names on its target list, the cache MUST select the first (in target list order) field with a valid, non-empty value and use its value to determine the caching policy for the response, and MUST ignore the Cache-Control and Expires header fields in that response, unless no valid, non-empty value is available from the listed header fields.¶
Note that this occurs on a response-by-response basis; if no member of the cache's target list is present, valid and non-empty, a cache falls back to other cache control mechanisms as required by HTTP [HTTP-CACHING].¶
Targeted fields that are not on a cache's target list MUST NOT change that cache's behaviour, and MUST be passed through.¶
Caches that use a targeted field MUST implement the semantics of the following cache directives:¶
Furthermore, they SHOULD implement other cache directives (including extension cache directives) that they support in the Cache-Control response header 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 no-cache make max-age inoperative, and unrecognised extension directives are ignored.¶
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:¶
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).¶
HTTP caching has a single, end-to-end freshness model defined in Section 4.2 of [I-D.ietf-httpbis-cache]. When additional freshness mechanisms are only available to some caches along a request path (for example, using targeted fields), their interactions need to be carefully considered. In particular, a targeted cache might have longer freshness lifetimes available to it than other caches, causing it to serve responses that appear to be prematurely (or even immediately) stale to them, negatively impacting cache efficiency.¶
For example, a response stored by a CDN cache might be served with the following headers:¶
From the CDN's perspective, this response is still fresh after being cached for 30 minutes, while from other caches' standpoint, this response is already stale. See [AGE-PENALTY] for more discussion.¶
When the targeted cache has a strong coherence mechanism (e.g., the origin server has the ability to proactively invalidate cached responses), it is often desirable to mitigate these effects. Some techniques seen in deployments include:¶
This specification does not place any specific requirements on implementations to mitigate these effects, but definitions of targeted fields can do so.¶
A targeted field for a particular class of cache can be defined by requesting registration in the Hypertext Transfer Protocol (HTTP) Field Name Registry https://www.iana.org/assignments/http-fields/, listing this specification as the specification document. The Comments field of the registration should clearly define the class of caches that the targeted field applies to.¶
By convention, targeted fields have the suffix "-Cache-Control": e.g., "ExampleCDN-Cache-Control". However, this suffix MUST NOT be used on its own to identify targeted fields; it is only a convention.¶
The CDN-Cache-Control response header field is a targeted field (Section 2) that allows origin servers to control the behaviour of CDN caches interposed between them and clients, separately from other caches that might handle the response.¶
It applies to caches that are part of a distributed network that operate on behalf of an origin server (commonly called a Content Delivery Network or CDN).¶
CDN caches that use CDN-Cache-Control will typically forward this header so that downstream CDN caches can use it as well. However, they MAY remove it when this is undesirable (for example, when configured to do so because it is known not to be used downstream).¶
For example, the following header fields would instruct a CDN cache to consider the response fresh for 600 seconds, other shared caches for 120 seconds and any remaining caches for 60 seconds:¶
These header fields would instruct a CDN cache to consider the response fresh for 600 seconds, while all other caches would be prevented from storing it:¶
Because CDN-Cache-Control is not present, this header field would prevent all caches from storing the response:¶
Whereas these would prevent all caches except for CDN caches from storing the response:¶
(note that 'none' is not a registered cache directive; it is here to avoid sending a header field with an empty value, which would be ignored)¶
Please register the following entry in the Hypertext Transfer Protocol (HTTP) Field Name Registry defined by [HTTP]:¶
The security considerations of HTTP caching [HTTP-CACHING] apply.¶
The ability to carry multiple caching policies on a response can result in confusion about how a response will be cached in different systems, if not used carefully. This might result in unintentional reuse of responses with sensitive information.¶