1. Introduction
This page preserves the original RFC text for the section and adds navigation metadata for the documentation site.
Original RFC Text
1. Introduction
HTTP caching [HTTP-CACHING] operates at the granularity of a single
resource; the freshness of one stored response does not affect that
of others. This granularity can make caching more efficient -- for
example, when a page is composed of many assets that have different
requirements for caching.
However, there are also cases where the relationship between stored
responses could be used to improve cache efficiency.
For example, it is often necessary to invalidate a set of related
resources. This might be because a state-changing request has side
effects on other resources, or it might be purely for administrative
convenience (e.g., "invalidate this part of the site"). Grouping
responses together provides a dedicated way to express these
relationships, instead of relying on things like URL structure.
In addition to sharing invalidation events, the relationships
indicated by grouping can also be used by caches to optimise their
operation (e.g., to inform the operation of cache eviction
algorithms).
Section 2 introduces a means of describing the relationships between
stored responses in HTTP caches, by associating those responses with
one or more groups that reflect those relationships. It also
describes how caches can use that information to apply invalidation
events to members of a group.
Section 3 introduces one new source of such events: an HTTP response
header field that allows a state-changing response to trigger a group
invalidation.
These mechanisms operate within a single cache, across the stored
responses associated with a single origin server (see Section 2.1).
They do not address the issues of synchronising state between
multiple caches (e.g., in a hierarchy or mesh), nor do they
facilitate association of stored responses from disparate origins.