rfc9875v1.txt   rfc9875.txt 
Internet Engineering Task Force (IETF) M. Nottingham Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 9875 September 2025 Request for Comments: 9875 Cloudflare
Category: Standards Track Category: Standards Track October 2025
ISSN: 2070-1721 ISSN: 2070-1721
HTTP Cache Groups HTTP Cache Groups
Abstract Abstract
This specification introduces a means of describing the relationships This specification introduces a means of describing the relationships
between stored responses in HTTP caches, "grouping" them by between stored responses in HTTP caches, grouping them by associating
associating a stored response with one or more strings. a stored response with one or more strings.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
skipping to change at line 81 skipping to change at line 81
For example, it is often necessary to invalidate a set of related For example, it is often necessary to invalidate a set of related
resources. This might be because a state-changing request has side resources. This might be because a state-changing request has side
effects on other resources, or it might be purely for administrative effects on other resources, or it might be purely for administrative
convenience (e.g., "invalidate this part of the site"). Grouping convenience (e.g., "invalidate this part of the site"). Grouping
responses together provides a dedicated way to express these responses together provides a dedicated way to express these
relationships, instead of relying on things like URL structure. relationships, instead of relying on things like URL structure.
In addition to sharing invalidation events, the relationships In addition to sharing invalidation events, the relationships
indicated by grouping can also be used by caches to optimise their indicated by grouping can also be used by caches to optimise their
operation; for example, it could be used to inform the operation of operation (e.g., to inform the operation of cache eviction
cache eviction algorithms. algorithms).
Section 2 introduces a means of describing the relationships between Section 2 introduces a means of describing the relationships between
stored responses in HTTP caches, by associating those responses with stored responses in HTTP caches, by associating those responses with
one or more groups that reflect those relationships. It also one or more groups that reflect those relationships. It also
describes how caches can use that information to apply invalidation describes how caches can use that information to apply invalidation
events to members of a group. events to members of a group.
Section 3 introduces one new source of such events: an HTTP response Section 3 introduces one new source of such events: an HTTP response
header field that allows a state-changing response to trigger a group header field that allows a state-changing response to trigger a group
invalidation. invalidation.
skipping to change at line 113 skipping to change at line 113
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification uses the following terminology from This specification uses the following terminology from
[STRUCTURED-FIELDS]: List, String, and Parameter. [STRUCTURED-FIELDS]: List, String, and Parameter.
2. The Cache-Groups Response Header Field 2. The Cache-Groups Response Header Field
The Cache-Groups HTTP Response Header is a List of Strings (Sections The Cache-Groups response header field is a List of Strings (Sections
3.1 and 3.3.1 of [STRUCTURED-FIELDS]). Each member of the list is a 3.1 and 3.3.3 of [STRUCTURED-FIELDS]). Each member of the List is a
value that identifies a group that the response belongs to. These value that identifies a group that the response belongs to. These
strings are opaque -- while they might have some meaning to the Strings are opaque -- while they might have some meaning to the
server that creates them, the cache does not have any insight into server that creates them, the cache does not have any insight into
their structure or content (beyond uniquely identifying a group). their structure or content (beyond uniquely identifying a group).
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/javascript Content-Type: application/javascript
Cache-Control: max-age=3600 Cache-Control: max-age=3600
Cache-Groups: "scripts" Cache-Groups: "scripts"
The ordering of members is not significant. Unrecognised Parameters The ordering of members is not significant. Unrecognised Parameters
are to be ignored. are to be ignored.
skipping to change at line 152 skipping to change at line 152
2. They both share the same URI origin (per Section 4.3.1 of 2. They both share the same URI origin (per Section 4.3.1 of
[HTTP]). [HTTP]).
2.2. Cache Behaviour 2.2. Cache Behaviour
2.2.1. Invalidation 2.2.1. Invalidation
A cache that invalidates a stored response MAY invalidate any stored A cache that invalidates a stored response MAY invalidate any stored
responses that share groups (per Section 2.1) with that response. responses that share groups (per Section 2.1) with that response.
Note that further grouped invalidations are not triggered by a Note that further grouped invalidations are not triggered by a
grouped invalidation; i.e., this mechanism does not "cascade". grouped invalidation; i.e., this mechanism does not cascade.
Cache extensions can explicitly strengthen the requirement above. Cache extensions can explicitly strengthen the requirement above.
For example, a targeted cache control header field [TARGETED] might For example, a targeted cache control header field [TARGETED] might
specify that caches processing it are required to invalidate such specify that caches processing it are required to invalidate such
responses. responses.
3. The Cache-Group-Invalidation Response Header Field 3. The Cache-Group-Invalidation Response Header Field
The Cache-Group-Invalidation response header field is a List of The Cache-Group-Invalidation response header field is a List of
Strings (Sections 3.1 and 3.3.1 of [STRUCTURED-FIELDS]). Each member Strings (Sections 3.1 and 3.3.3 of [STRUCTURED-FIELDS]). Each member
of the list is a value that identifies a group that the response of the List is a value that identifies a group that the response
invalidates, per Section 2.2.1. invalidates, per Section 2.2.1.
For example, following a POST request that has side effects on two For example, following a POST request that has side effects on two
cache groups, the corresponding response could indicate that stored cache groups, the corresponding response could indicate that stored
responses associated with either or both of those groups should be responses associated with either or both of those groups should be
invalidated with: invalidated with:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/html Content-Type: text/html
Cache-Group-Invalidation: "eurovision-results", "australia" Cache-Group-Invalidation: "eurovision-results", "australia"
skipping to change at line 262 skipping to change at line 262
Control", RFC 9213, DOI 10.17487/RFC9213, June 2022, Control", RFC 9213, DOI 10.17487/RFC9213, June 2022,
<https://www.rfc-editor.org/info/rfc9213>. <https://www.rfc-editor.org/info/rfc9213>.
Acknowledgements Acknowledgements
Thanks to Stephen Ludin for his review and suggestions. Thanks to Stephen Ludin for his review and suggestions.
Author's Address Author's Address
Mark Nottingham Mark Nottingham
Prahran Cloudflare
Melbourne
Australia Australia
Email: mnot@mnot.net Email: mnot@mnot.net
URI: https://www.mnot.net/ URI: https://www.mnot.net/
 End of changes. 8 change blocks. 
13 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.48.