HTTP Caching

The FIT Server provides several caching mechanisms to accelerate responses to recurring requests, to reduce the amount of transferred data, the number of TCP connections and HTTP requests, and to accelerate the user interactions.

FIT differentiates between two distinct scopes: controlling whether a response is cacheable by an intermediate proxy or requesting client, and caching of backend responses on the FIT server itself.

The ground rules that govern whether responses are considered cacheable are laid out in RFC 7234. The most relevant properties that are typically used to determine if a response can be cached or a previously stored response can be used to satisfy a request are the Cache-Control and Pragma request header fields, as well as the Vary, Cache-Control, Expires and Last-Modified response header fields.

See Understanding HTTP Cache, too.

Client Requests

FIT provides the following means to control the cacheability of its responses:

Backend Requests

The backend requests are requests from the FIT Server to backend source servers.

Unless explicitly disabled, FIT caches all responses from backends that it recognizes as publicly cacheable according to the HTTP response headers (see the HTTP Cache). Stored responses are used to satisfy any applicable subsequent requests, unless the client explicitly requested a fresh response via Pragma: no-cache or Cache-Control: no-cache request header fields.

In case it is deemed necessary to override the response headers from a backend and cache the response regardless, FIT provides the Interval Cache. The Interval Cache can be enabled on a host or paths basis in the conf/sources.xml.

For image, CSS and JS inlining to work, the resources to be inlined must be present in the FIT Server’s local cache and, for the HTTP cache, must not make use of Vary headers.

If a cacheable response from a backend server contains Set-Cookie HTTP header fields, FIT considers them to be valid only for the initial client request. All Set-Cookie HTTP header fields are removed from responses that are satisfied from the cache.

Updates

The HTTP cache supports revalidation using conditional requests.

If FIT receives a request for a resource in its HTTP cache that has expired, it attempts to revalidate that resource using a conditional request, as specified in RFC 7234. If the backend server supports revalidation, it may respond with a HTTP status code 304 (not modified) and omit the response body, thus saving time and bandwidth. The lifetime of the local cache entry is extended according to the headers of the 304 response. For further processing, a response with status code 200 is synthesized from the cache entry and the 304 response. Successful revalidations are recorded as REFRESH in the fit_request.log file.

If a client attempts to revalidate a resource using a conditional request, FIT will first check if it still has a cached response in its local cache and generate a 304 response itself, if appropriate. If necessary, FIT revalidates the local cached copy of the resource. If no valid cached copy is found, a suitable conditional request will be forwarded to the backend server. If the response has HTTP status code 304, it will be passed on to the client. Responses with other status codes are processed as if a non-conditional request had been sent.

Debugging

If you want to figure out if a response has been satisfied from the local cache, or why specific response headers have been set, consult the request and config channels in the debug output.

Note that re-loading content in a browser (e.g. via F5, Ctrl+R) typically adds Pragma: no-cache and Cache-Control: no-cache to the request. This may alter the behaviour of FIT and possibly backends significantly as compared to a client that just follows a link to the same URL.

Clearing the Cache

The cache used by FIT to store cacheable responses from backends can be cleared on the command line with fitadmin maintenance clearcache <myproject>.

Options allow you to clear only parts of the cache, e.g. adding --http will clear the HTTP cache only. See fitadmin maintenance clearcache --help for all available options.

In addition to the specifications in RFC 7234, the HTTP request cache uses a project-wide cache reference file /var/cache/fit14/<myproject>/remove-me-to-invalidate-request-cache to check whether a resource in the cache has expired. All cached resources that have been written before the cache reference file will be considered expired.

The command line fitadmin maintenance clearcache <myproject> with the option --http deletes only the reference file without removing the cached resources from the disk. This has several advantages:

  • Since only a single file has to be deleted from the disk, flushing the cache is practically instantaneous.
  • If a subsequent request requires an expired resource, the request system will attempt to revalidate the entry in the HTTP request cache using a conditional request as described in the “Updates” chapter above. If the source server supports 304 not modified responses, this can significantly reduce the amount of data transferred to rebuild the cache.

If you want to delete the cached resources from the disk, use the command line fitadmin maintenance clearcache <myproject> without any options. Note that all other caches (e.g. ImageScaler cache) will be deleted, too.