RFC 9875

HTTP Cache Groups

📅 published October 2025, from ietf

RFC 9875: HTTP Cache Groups 💖

okay bestie, this is the IETF Standards Track doc that gives HTTP caches a way to group related stored responses 🦋 It was written by Mark Nottingham at Cloudflare, it's dated October 2025, and it's ISSN 2070-1721. The header doesn't say it obsoletes or updates anything, so it's its own thing ✨

Here's the full doc, with all the details kept 💅

Internet Engineering Task Force (IETF)                     M. Nottingham
Request for Comments: 9875                                    Cloudflare
Category: Standards Track                                   October 2025
ISSN: 2070-1721

Abstract ✨

This spec adds a way to describe how stored responses in HTTP caches are related, grouping them by linking each stored response to one or more strings 🎀

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9875.

Copyright Notice ©️

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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents 🗺️

1.  Introduction
  1.1.  Notational Conventions
2.  The Cache-Groups Response Header Field
  2.1.  Identifying Grouped Responses
  2.2.  Cache Behaviour
    2.2.1.  Invalidation
3.  The Cache-Group-Invalidation Response Header Field
4.  IANA Considerations
5.  Security Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Author's Address

1. Introduction 🌸

okay so HTTP caching [HTTP-CACHING] works at the level of one resource. Whether one stored response is fresh has no effect on the others 🙈 That granularity can make caching more efficient, like when a page is built from lots of assets that each need different caching rules.

But there are also cases where the relationship between stored responses could make caches more efficient 💅

For example, you often need to invalidate a whole set of related resources. Maybe a state-changing request has side effects on other resources, or maybe it's just admin convenience, like "invalidate this part of the site" 🧚 Grouping responses gives you a dedicated way to say these relationships exist, so you don't have to rely on stuff like URL structure.

On top of sharing invalidation events, the relationships that grouping shows can also help caches run better (like informing how cache eviction algorithms work) ✨

Section 2 introduces a way to describe the relationships between stored responses in HTTP caches, by linking those responses to one or more groups that reflect those relationships. It also explains how caches can use that info to apply invalidation events to members of a group 💜

Section 3 brings in one new source of those events: an HTTP response header field that lets a state-changing response trigger a group invalidation 🔥

These mechanisms work inside a single cache, across the stored responses tied to a single origin server (see Section 2.1). They don't handle syncing state between multiple caches (like in a hierarchy or mesh), and they don't help link stored responses from different origins 🙅‍♀️

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.

This spec uses these terms from [STRUCTURED-FIELDS]: List, String, and Parameter.

2. The Cache-Groups Response Header Field 🍓

The Cache-Groups response header field is a List of Strings (Sections 3.1 and 3.3.3 of [STRUCTURED-FIELDS]). Each member of the List is a value that identifies a group the response belongs to. These Strings are opaque. They might mean something to the server that creates them, but the cache has no insight into their structure or content (beyond uniquely identifying a group) 🔍

HTTP/1.1 200 OK
Content-Type: application/javascript
Cache-Control: max-age=3600
Cache-Groups: "scripts"

The order of members doesn't matter. Unrecognised Parameters are to be ignored 🫶

Implementations MUST support at least 32 groups in a field value, with up to at least 32 characters in each member. Generic limits on HTTP field lengths may constrain the size of this field value in practice, so keep that in mind 👀

2.1. Identifying Grouped Responses 🧩

Two responses stored in the same cache count as being in the same group when all of these conditions are met:

They both contain a Cache-Groups response header field that contains the same String (in any position in the List), when compared character-by-character (case sensitive).
They both share the same URI origin (per Section 4.3.1 of [HTTP]).

2.2. Cache Behaviour 💅

2.2.1. Invalidation ⚡

A cache that invalidates a stored response MAY invalidate any stored responses that share groups (per Section 2.1) with that response. Note that a grouped invalidation doesn't set off further grouped invalidations. In other words, this mechanism does not cascade 🙅‍♀️

Cache extensions can explicitly strengthen the requirement above. For example, a targeted cache control header field [TARGETED] might specify that caches processing it are required to invalidate such responses 💖

3. The Cache-Group-Invalidation Response Header Field 🔥

The Cache-Group-Invalidation response header field is a List of 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 invalidates, per Section 2.2.1 ✨

For example, say a POST request has side effects on two cache groups. The response can say that stored responses in either or both of those groups should be invalidated with:

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Group-Invalidation: "eurovision-results", "australia"

The Cache-Group-Invalidation header field MUST be ignored on responses to requests that have a safe method (e.g., GET; see Section 9.2.1 of [HTTP]). Reading this as "safe requests can't trigger invalidations" is a vibe check you can trust 🛑

A cache that receives a Cache-Group-Invalidation header field on a response to an unsafe request MAY invalidate any stored responses that share groups (per Section 2.1) with any of the listed groups 🧹

The order of members doesn't matter. Unrecognised Parameters are to be ignored 🫶

4. IANA Considerations 🧚

IANA has added the following entries to the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

Field Name:  Cache-Groups
Status:  permanent
Reference:  RFC 9875

Field Name:  Cache-Group-Invalidation
Status:  permanent
Reference:  RFC 9875

5. Security Considerations 🚨

🚨 Serious security alert, bestie 🚨 This mechanism lets resources that share an origin invalidate each other. Because of that, origins that represent multiple parties (sometimes called "shared hosting") might let one party group its resources with other parties' resources, or send signals that have side effects on them. That's a real risk, so be careful 💀

Shared hosts that want to lower these risks can control access to the header fields defined in this specification 🔐

6. References 📚

6.1. Normative References

[HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
           Ed., "HTTP Semantics", STD 97, RFC 9110,
           DOI 10.17487/RFC9110, June 2022,
           <https://www.rfc-editor.org/info/rfc9110>.

[HTTP-CACHING]
           Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
           Ed., "HTTP Caching", STD 98, RFC 9111,
           DOI 10.17487/RFC9111, June 2022,
           <https://www.rfc-editor.org/info/rfc9111>.

[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/info/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/info/rfc8174>.

[STRUCTURED-FIELDS]
           Nottingham, M. and P. Kamp, "Structured Field Values for
           HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
           <https://www.rfc-editor.org/info/rfc9651>.

6.2. Informative References

[TARGETED] Ludin, S., Nottingham, M., and Y. Wu, "Targeted HTTP Cache
           Control", RFC 9213, DOI 10.17487/RFC9213, June 2022,
           <https://www.rfc-editor.org/info/rfc9213>.

Acknowledgements 💜

Thanks to Stephen Ludin for his review and suggestions 🫶

Author's Address 🦋

Mark Nottingham
Cloudflare
Melbourne
Australia
Email: mnot@mnot.net
URI:   https://www.mnot.net/

📦 where this page comes from

ietf: rfc9875 2025-10
💖 girlified by claude-haiku-5-5 on 2026-10-19: a language model's rewrite of the original, under its terms