HTTP Immutable Responses
Extracted elements (13)
The immutable extension carries no arguments and has no effect when present in a request, deliberately keeping the extension minimal: the binary presence or absence of the directive in a response is sufficient to convey the server's guarantee.
The immutable extension was motivated by the 'versioned URL' design pattern in which sub-resources are published at new URLs when updated, making conditional revalidation requests wasteful. Without immutable, user-driven reloads generate hundreds of 304 responses for sub-resources that have not changed.
A proxy that uses the immutable extension to bypass conditional revalidation can choose whether to reply with a 304 or 200 response to its requesting client based on the request headers the proxy received.
Clients SHOULD ignore the immutable extension for resources that do not provide a strong indication that the stored response size is correct, such as responses delimited by connection close.
Clients SHOULD ignore the immutable extension from resources that are not part of an authenticated context such as HTTPS, because authenticated resources are less vulnerable to cache poisoning.
Clients SHOULD NOT issue a conditional request during an immutable response's freshness lifetime (e.g., upon a reload) unless explicitly overridden by the user (e.g., a force reload).
Force-reload mechanisms, typically indicated through no-cache request attributes, SHOULD ignore the immutable extension, to allow users to rectify interrupted loads and cache corruption.
If any arguments are present on the immutable extension, they have no meaning and MUST be ignored. The presence of an immutable Cache-Control extension in a request has no effect.
Proxies SHOULD skip conditionally revalidating fresh responses containing the immutable extension unless there is a signal from the client that a validation is necessary (e.g., a no-cache Cache-Control request directive).
Stale responses marked immutable SHOULD be revalidated as they normally would be in the absence of the immutable extension; the extension only applies during the freshness lifetime.
The `immutable` Cache-Control response extension indicates that the origin server will not update the representation of that resource during the freshness lifetime of the response. It takes no arguments; any arguments present have no meaning. Multiple instances are equivalent to one instance.
The `immutable` cache directive has been registered in the IANA 'Hypertext Transfer Protocol (HTTP) Cache Directive Registry' per the guidelines in Section 7.1 of RFC 7234, with reference RFC 8246.
The immutable mechanism acts as a form of soft pinning and creates a vector for amplification of cache corruption incidents, including cache-poisoning attacks. Three mitigations are recommended: restricting to authenticated (HTTPS) contexts, honoring force-reload, and ignoring immutable for responses without a reliable size signal.