Understanding HTTP Cache

For an origin response to be considered cacheable by the FIT Server, the following general requirements must be fulfilled:

  • Only GET requests may be cacheable.
  • At least one of the following HTTP header fields must be present and valid in the response:
    • Cache-Control
    • Pragma
    • Expires
    • Last-Modified
    • Date
    • ETag
    • Age
  • Response HTTP status code must be one of (see RFC 7231) or the Cache-Control HTTP header field must contain public and max-age or s-maxage directives:
    • 200 OK
    • 203 Non-Authoritative Information
    • 204 No Content
    • 300 Multiple Choices
    • 301 Moved Permanently
    • 404 Not Found
    • 405 Method Not Allowed
    • 410 Gone
    • 414 URI Too Long
    • 501 Not Implemented

Cacheability and cache lifetime of an origin response are determined in the following order.

1. Evaluation of the Vary HTTP header field

If present, the HTTP header field Vary must not contain the * directive. Otherwise the response is immediately marked as not cacheable.

2. Evaluation of the Cache-Control HTTP header field

If present, the HTTP header field Cache-Control

  • must not contain private or no-store directives
  • if present, the no-cache directive
    • must not contain any values (e.g. Cache-Control: no-cache) or
    • the value must be equal to set-cookie (e.g. Cache-Control: no-cache="set-cookie")
  • otherwise the response is immediately marked as not cacheable

If one of the following directives is present, the evaluation continues with 5. (see below):

  • no-cache
  • must-revalidate
  • proxy-revalidate

If max-age or s-maxage directive is present, the values of these derectives are used for calculation of the cache lifetime. Other HTTP header fields are ignored. The s-maxage directive has priority over the max-age.

If the HTTP header field Cache-Control is present and understood, HTTP header fields Expires and Pragma are ignored.

3. Evaluation of the Pragma HTTP header field

If present and not ignored (see 2. above), the HTTP header field Pragma must not contain the no-cache directive. Otherwise the response is immediately marked as not cacheable.

4. Miscellaneous calculations

If none of the following HTTP header fields (combinations) are present, the evaluation continues with 5. (see below):

  • Date + Expires
  • Date + Last-Modified
  • Age

4.1. Calculating of the cache lifetime from Date and Expires

If Expires is after Date, the response is valid until Expires.

4.2. Calculating Heuristic Freshness from Date and Last-Modified

If Last-Modified is before Date, the response expires after 10% of the time difference between Date and Last-Modified.

4.3. Calculating Heuristic Freshness from Age

If 20% of Age are more than 24 hours, the response expires in exactly 24 hours. Otherwise the response expires after 20% of Age.

5. Caching of already expired responses

If storing the response is not explicitly prohibited, but the response provides ETag or Last-Modified HTTP header fields, the response is cached, but immediately marked as expired.

This enables the FIT Server to revalidate the payload via conditional request as specified in RFC 7234. If the origin server supports revalidation, it may respond with a HTTP status code 304 Not Modified and omit the response body, thus saving time and bandwidth.