Summary

  • Cache-Groups lets a stored response declare one or more opaque, case-sensitive group identifiers.
  • Membership is meaningful only within the same cache and URI origin; it is not a cross-cache or cross-origin coordination protocol.
  • Cache-Group-Invalidation on a safe request must be ignored. On an unsafe request it may invalidate stored responses sharing the named groups.
  • Group invalidation is optional unless another cache extension strengthens it, and it does not cascade through groups newly related by an invalidated response.

RFC 9875 adds a naming and signalling layer to HTTP caching. A response may carry one or more group strings, allowing a cache to associate that response with other stored responses under the same origin. The identifiers are opaque: their meaning belongs to the parties operating the cache and origin, and their case matters. A group is therefore a control surface that needs ownership, namespace discipline, and an explicit authority model.

The cache boundary comes first. A group does not create a shared object between independent caches, nor does it associate responses from different URI origins. A reverse proxy, browser cache, intermediary, or other cache may have its own state and its own interpretation of the extension. RFC 9875 does not establish synchronization among them. Treating one cache's group state as a global purge ledger would turn a local signal into an unsupported operational assumption.

The invalidation boundary is equally important. Group invalidation is optional under the specification unless a separate cache extension makes it stronger. A response to an unsafe request may name groups whose stored responses can be invalidated. The same field on a safe request must be ignored, so the method classification is mandatory handling rather than a tuning preference. Invalidation also does not cascade: newly related groups are not recursively followed merely because one response was affected.

This creates two failure modes. If related responses remain stored, users may encounter stale representations after a state-changing operation. If identifiers are too broad, or authority is shared carelessly, an invalidation can affect another tenant's content. Shared-origin hosting makes that authority risk concrete: one party could group with or invalidate another party's resources unless the host controls access. Opaque names do not remove that governance problem; they make naming and issuance policy more important.

The practical decision is not whether one header can magically purge a site. It is whether a defined cache, origin, and authority can use group identifiers without confusing local behavior with distributed consistency. A service may choose to emit groups, ignore them, or rely on a strengthening extension, but it should document which behavior is expected and what remains outside the guarantee.

Sources