HTTP Cache Groups

Cache group membership is determined by string equality (case-sensitive) rather than URL structure or other resource relationships, providing a dedicated mechanism for expressing relationships that is independent of URL design choices.

http

Cache groups operate within a single cache and only across stored responses from the same origin server. The mechanism intentionally does not address synchronisation between multiple caches or association of responses from different origins.

http

Group strings are opaque to caches — the cache has no insight into their structure or content beyond using them to uniquely identify a group. This avoids requiring the cache to parse or interpret application-level semantics.

http

Grouped invalidation explicitly does not cascade: invalidating a group member does not trigger further group invalidations. This prevents potentially unbounded or unintended invalidation chains.

http

In addition to invalidation, group relationships can be used by caches to optimize operation such as informing cache eviction algorithms, making grouping useful beyond just explicit invalidation events.

http

Cache extensions can explicitly strengthen the MAY requirement for Cache-Group-Invalidation into a required obligation for caches that process those extensions, allowing targeted cache control to mandate invalidation.

http

Cache extensions (e.g., targeted cache control header fields per RFC 9213) can explicitly strengthen the MAY requirement for grouped invalidation into a stronger obligation for caches that process those extensions.

http

A cache that invalidates a stored response MAY invalidate any stored responses that share groups with that response. Grouped invalidations do not cascade — further grouped invalidations are not triggered by a grouped invalidation.

http

A cache that receives a Cache-Group-Invalidation header field on a response to an unsafe request MAY invalidate any stored responses sharing groups with any of the listed groups.

http

Group membership requires matching the same URI origin (per HTTP Section 4.3.1) in addition to matching the Cache-Groups string. Responses from different origins cannot share a group.

http

Implementations MUST support at least 32 groups in a Cache-Group-Invalidation field value, with up to at least 32 characters in each member.

http

The Cache-Group-Invalidation header field MUST be ignored on responses to requests that have a safe method (e.g., GET). Only unsafe request responses may carry meaningful Cache-Group-Invalidation signals.

http

The Cache-Group-Invalidation response header field is a List of Strings (Structured Fields). Each member identifies a group that the response invalidates, allowing a state-changing response to trigger invalidation of related cache groups.

http

The Cache-Groups response header field is a List of Strings (per Structured Fields). Each member identifies a group that the response belongs to. These strings are opaque to the cache and used solely to identify group membership.

http

Two stored responses belong to the same group when they both contain a Cache-Groups field with the same String (case-sensitive, character-by-character comparison) and both share the same URI origin.

http

IANA has added two permanent entries to the HTTP Field Name Registry: 'Cache-Groups' and 'Cache-Group-Invalidation', both referencing RFC 9875.

http, registry

This mechanism allows resources sharing an origin to invalidate each other. In shared hosting environments where one origin represents multiple parties, one party could group its resources with another party's resources or send Cache-Group-Invalidation signals that have side effects on them. Shared hosts can mitigate this by controlling access to these header fields.

http, security

Both Cache-Groups and Cache-Group-Invalidation are encoded as Structured Fields List of Strings. The ordering of members is not significant, and unrecognised Parameters are to be ignored.

http