Explicit Cache Controls - Calculating Heuristic Freshness

Example Use

A Cache-Control header can provide information for both requests to a server and responses from a server regarding how content should be cached for later retrieval.

Cache Request Directives

The following are examples to be used with a client, such as a web browser. Multiple directives can be set with a comma, Cache-Control: no-cache, no-store

  • Cache-Control: max-age=100

    • After 100 seconds this data will be considered expired.
  • Cache-Control: min-fresh=100

    • The client wants a response that will not expire for 100 seconds
  • Cache-Control: no-cache

    • The client will send a validation request to the server to see if new content exists. If new content exists, the server will return new content. Otherwise it will respond with a 304 telling the client to use the cached version.
  • Cache-Control: no-store

    • The client will not store a cache of the content.
  • Cache-Control: no-transform

Cache Response Directives

Official Definition

Since origin servers do not always provide explicit expiration times, a cache MAY assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field values (such as the Last-Modified time) to estimate a plausible expiration time. This specification does not provide specific algorithms, but does impose worst-case constraints on their results.

A cache MUST NOT use heuristics to determine freshness when an explicit expiration time is present in the stored response. Because of the requirements in Section 3, this means that, effectively, heuristics can only be used on responses without explicit freshness whose status codes are defined as cacheable by default (see Section 6.1 of [RFC7231]), and those responses without explicit freshness that have been marked as explicitly cacheable (e.g., with a "public" response directive).

If the response has a Last-Modified header field (Section 2.2 of [RFC7232]), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.

When a heuristic is used to calculate freshness lifetime, a cache SHOULD generate a Warning header field with a 113 warn-code (see Section 5.5.4) in the response if its current_age is more than 24 hours and such a warning is not already present.

Note: Section 13.9 of [RFC2616] prohibited caches from calculating heuristic freshness for URIs with query components (i.e., those containing '?'). In practice, this has not been widely implemented. Therefore, origin servers are encouraged to send explicit directives (e.g., Cache-Control: no-cache) if they wish to preclude caching.

Source: RFC 7234 Section 4.2.2