HTTP                                                            S. Ludin
Internet-Draft                                                    Akamai
Intended status: Standards Track                           M. Nottingham
Expires: 27 January 24 March 2022                                            Fastly
                                                                   Y. Wu
                                                              Cloudflare
                                                            26 July
                                                       20 September 2021

                      Targeted HTTP Cache Control
              draft-ietf-httpbis-targeted-cache-control-00
              draft-ietf-httpbis-targeted-cache-control-01

Abstract

   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.

Note to Readers

   _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
   (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
   (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/ (https://datatracker.ietf.org/doc/draft-ietf-httpbis-
   targeted-cache-control/).

Status of This Memo

   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 27 January 24 March 2022.

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
   2.  Targeted Cache-Control Header Fields  . . . . . . . . . . . .   3
     2.1.  Cache Behavior  . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Parsing Targeted Fields  Syntax  . . . . . . . . . . . . . . . . . . . . .   4 . . . .   5
     2.3.  Interaction with HTTP Freshness . . . . . . . . . . . . .   6
     2.4.  Defining Targeted Fields  . . . . . . . . . . . . . . . .   5   7
   3.  The CDN-Cache-Control Targeted Field  . . . . . . . . . . . .   5   7
     3.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   6   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . .   7 . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8   9

1.  Introduction

   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), that 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 caches 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 CDN-
   Cache-Control response header field.

1.1.  Notational Conventions

   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.

2.  Targeted Cache-Control Header Fields

   A Targeted Cache-Control Header Field (hereafter, "targeted field")
   is a HTTP response header field that has the same syntax and semantics as the
   Cache-Control response header field
   [I-D.ietf-httpbis-cache], ([HTTP-CACHING], Section 5.2. 5.2).
   However, it has a distinct field name that indicates the target for
   its directives.

   For example:

   CDN-Cache-Control: max-age=60

   is a targeted field that applies to Content Delivery Networks (CDNs),
   as defined in Section 3.

2.1.  Cache Behavior

   A cache that implement this specification has 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 that 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 is occurs on a response-by-response basis; if no applicable
   targeted field 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
   [I-D.ietf-httpbis-cache].
   [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:

   *  max-age

   *  must-revalidate

   *  no-store

   *  no-cache

   *  private

   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. inoperative, and unrecognised extension
   directives are ignored.

2.2.  Parsing Targeted Fields  Syntax

   Targeted fields MAY be parsed are defined as a Dictionary Structured Field
   [RFC8941], and implementations are encouraged to use Fields
   (Section 3.2 of [STRUCTURED-FIELDS]).  Each member of the dictionary
   is a parser for
   that format in cache directive from the interests Hypertext Transfer Protocol (HTTP)
   Cache Directive Registry.

   Because cache directives are not defined in terms of robustness, interoperability and
   security.

   When an implementation parses structured data
   types, it is necessary to map their values into the appropriate
   types.  Typically, they are mapped into a targeted field as Boolean (Section 3.3.6 of
   [STRUCTURED-FIELDS]) when the member has no separate value, a Structured Field,
   each cache directive will be assigned Token
   (Section 3.3.4 of [STRUCTURED-FIELDS]) for alphanumeric values, a value.
   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's value is no-store (Section 5.2.2.5 of
   [HTTP-CACHING]) always has a boolean true, true value, and no-
   cache's 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 accept other 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).  Likewise, implementations
   SHOULD ignore parameters  Parameters
   received on directives, directives are to be ignored, unless otherwise other handling is
   explicitly specified.

   However, implementers

   Sending implementations MUST generate valid Structured Fields.
   Receiving implementations SHOULD use a Structured Fields parser, but
   MAY reuse a Cache-Control an existing parser for
   simplicity.  If they the Cache-Control field value
   (Section 5.2 of [HTTP-CACHING]).  Those that do so, they SHOULD observe implement the
   following points, 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) case).

   *  Members of the directives can have parameters (e.g., "max-
      age=30;a=b;c=d"), which should be are ignored unless specified.

   If a targeted field in a given response is empty, or a parsing error
   is encountered (when being parsed as a Structured Field), encountered, that field
   SHOULD MUST be ignored by the cache (i.e., it should behave
   behaves as if the field were not present, likely falling back to
   other cache control mechanisms present).

2.3.  Interaction with HTTP Freshness

   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:

   Age: 1800
   Cache-Control: max-age=600
   CDN-Cache-Control: max-age=3600

   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:

   *  Removing the Age header field

   *  Updating the Date header field value to the current time

   *  Updating the Expires header field value to the current time, plus
      any Cache-Control: max-age value

   This specification does not place any specific requirements on
   implementations to mitigate these effects, but definitions of
   targeted fields can do so.

2.4.  Defining Targeted Fields

   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/
   (https://www.iana.org/assignments/http-fields/), listing this
   specification as the specification document.  The Comments field of
   the registration SHOULD should clearly define the class of caches that the
   targeted field applies to.

   By convention, targeted fields SHOULD have the suffix "-Cache-
   Control": "-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.

3.  The CDN-Cache-Control Targeted Field

   The CDN-Cache-Control response header field is a targeted field
   Section 2
   (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 MAY will typically forward this
   header so that downstream CDN caches can use it as well.  However, doing so exposes
   its value to all downstream clients, which might be undesirable.  As
   a result, CDN caches that process this header field
   they MAY remove it when this is undesirable (for example, when
   configured to do so because it is known not to be used downstream).

3.1.  Examples

   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:

   Cache-Control: max-age=60, s-maxage=120
   CDN-Cache-Control: max-age=600

   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:

   Cache-Control: no-store

   CDN-Cache-Control: max-age=600
   Cache-Control: no-store

   Because CDN-Cache-Control is not present, this header field would
   prevent all caches from storing the response:

   Cache-Control: no-store

   Whereas these would prevent all caches except for CDN caches from
   storing the response:

   Cache-Control: no-store
   CDN-Cache-Control: none

   (note that 'none' is not a registered cache directive; it is here to
   avoid sending a header field with an empty value, because such a
   header might not which would be preserved in all cases)
   ignored)

4.  IANA Considerations

   Please register the following entry in the Hypertext Transfer
   Protocol (HTTP) Field Name Registry defined by
   [I-D.ietf-httpbis-semantics]: [HTTP]:

   *  Field Name: CDN-Cache-Control

   *  Status: permanent

   *  Specification Document: [this document]

   *  Comments: Cache-Control directives targeted at Content Delivery
      Networks

5.  Security Considerations

   The security considerations of HTTP caching [I-D.ietf-httpbis-cache] [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.

6.  References

6.1.  Normative References

   [I-D.ietf-httpbis-cache]

   [HTTP]     Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
              Semantics", Work in Progress, Internet-Draft, draft-ietf-
              httpbis-semantics-19, 12 September 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
              semantics-19>.

   [HTTP-CACHING]
              Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
              Caching", Work in Progress, Internet-Draft, draft-ietf-
              httpbis-cache-17, 25 July
              httpbis-cache-19, 12 September 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
              cache-17>.

   [I-D.ietf-httpbis-semantics]
              cache-19>.

   [I-D.ietf-httpbis-cache]
              Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
              Semantics",
              Caching", Work in Progress, Internet-Draft, draft-ietf-
              httpbis-semantics-17, 25 July
              httpbis-cache-19, 12 September 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
              semantics-17>.
              cache-19>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8941]

   [STRUCTURED-FIELDS]
              Nottingham, M. and P-H. Kamp, "Structured Field Values for
              HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
              <https://www.rfc-editor.org/rfc/rfc8941>.

6.2.  Informative References

   [AGE-PENALTY]
              Cohen, E. and H. Kaplan, "The age penalty and its effect
              on cache performance", March 2001,
              <https://dl.acm.org/doi/10.5555/1251440.1251447>.

Authors' Addresses

   Stephen Ludin
   Akamai

   Email: sludin@ludin.org

   Mark Nottingham
   Fastly
   Prahran
   VIC
   Australia

   Email: mnot@mnot.net
   URI:   https://www.mnot.net/
   Yuchen Wu
   Cloudflare

   Email: me@yuchenwu.net