The Cache-Status HTTP response header field indicates how caches have handled that response and its corresponding request. The syntax of this header field conforms to [STRUCTURED-FIELDS
Its value is a List. Each member of the List represents a cache that has handled the request. The first member represents the cache closest to the origin server, and the last member represents the cache closest to the user (possibly including the user agent's cache itself if it appends a value).
Caches determine when it is appropriate to add the Cache-Status header field to a response. Some might add it to all responses, whereas others might only do so when specifically configured to, or when the request contains a header field that activates a debugging mode. See Section 6
for related security considerations.
An intermediary SHOULD NOT
append a Cache-Status member to responses that it generates locally, even if that intermediary contains a cache, unless the generated response is based upon a stored response (e.g., 304 (Not Modified) and 206 (Partial Content) are both based upon a stored response). For example, a proxy generating a 400 response due to a malformed request will not add a Cache-Status value, because that response was generated by the proxy, not the origin server.
When adding a value to the Cache-Status header field, caches SHOULD
preserve the existing field value, to allow debugging of the entire chain of caches handling the request.
Each List member identifies the cache that inserted it, and this identifier MUST
be a String or Token. Depending on the deployment, this might be a product or service name (e.g., "ExampleCache" or "Example CDN"), a hostname ("cache-3.example.com"), an IP address, or a generated string.
Each member of the list can have parameters that describe that cache's handling of the request. While these parameters are OPTIONAL
, caches are encouraged to provide as much information as possible.
This specification defines the following parameters.
The value of "hit" is a Boolean that, when true, indicates that the request was satisfied by the cache; that is, it was not forwarded, and the response was obtained from the cache.
A response that was originally produced by the origin but was modified by the cache (for example, a 304 or 206 status code) is still considered a hit, as long as it did not go forward (e.g., for validation).
A response that was in cache but not able to be used without going forward (e.g., because it was stale or partial) is not considered a hit. Note that a stale response that is used without going forward (e.g., because the origin server is not available) can be considered a hit.
"hit" and "fwd" are exclusive; only one of them should appear on each list member.
"fwd", when present, indicates that the request went forward towards the origin; its value is a Token that indicates why.
The following parameter values are defined to explain why the request went forward, from most specific to least:
The cache was configured to not handle this request.
The request method's semantics require the request to be forwarded.
The cache did not contain any responses that matched the request URI.
The cache contained a response that matched the request URI, but it could not select a response based upon this request's header fields and stored Vary header fields.
The cache did not contain any responses that could be used to satisfy this request (to be used when an implementation cannot distinguish between uri-miss and vary-miss).
The cache was able to select a fresh response for the request, but the request's semantics (e.g., Cache-Control request directives) did not allow its use.
The cache was able to select a response for the request, but it was stale.
The cache was able to select a partial response for the request, but it did not contain all of the requested ranges (or the request was for the complete response).
The most specific reason known to the cache SHOULD
be used, to the extent that it is possible to implement. See also [HTTP-CACHING
The value of "fwd-status" is an Integer that indicates which status code (see [HTTP
]) the next-hop server returned in response to the forwarded request. The fwd-status parameter is only meaningful when fwd is present. If fwd-status is not present but the fwd parameter is, it defaults to the status code sent in the response.
This parameter is useful to distinguish cases when the next-hop server sends a 304 (Not Modified) response to a conditional request or a 206 (Partial Content) response because of a range request.
The value of "ttl" is an Integer that indicates the response's remaining freshness lifetime (see [HTTP-CACHING
]) as calculated by the cache, as an integer number of seconds, measured as closely as possible to when the response header section is sent by the cache. This includes freshness assigned by the cache through, for example, heuristics (see [HTTP-CACHING
]), local configuration, or other factors. It may be negative, to indicate staleness.
The value of "stored" is a Boolean that indicates whether the cache stored the response (see [HTTP-CACHING
]); a true value indicates that it did. The stored parameter is only meaningful when fwd is present.
The value of "collapsed" is a Boolean that indicates whether this request was collapsed together with one or more other forward requests (see [HTTP-CACHING
]). If true, the response was successfully reused; if not, a new request had to be made. If not present, the request was not collapsed with others. The collapsed parameter is only meaningful when fwd is present.
The value of "key" is a String that conveys a representation of the cache key (see [HTTP-CACHING
]) used for the response. Note that this may be implementation specific.
The value of "detail" is either a String or a Token that allows implementations to convey additional information not captured in other parameters, such as implementation-specific states or other caching-related metrics.
Cache-Status: ExampleCache; hit; detail=MEMORY
The semantics of a detail parameter are always specific to the cache that sent it; even if a details parameter from another cache shares the same value, it might not mean the same thing.
This parameter is intentionally limited. If an implementation's developer or operator needs to convey additional information in an interoperable fashion, they are encouraged to register extension parameters (see Section 4
) or define another header field.