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
Pragma request header fields, as well as the
Last-Modified response header fields.
See Understanding HTTP Cache, too.
FIT provides the following means to control the cacheability of its responses:
advanced-cache-controlcan be used to improve the cache hit rate
set-headers Actionscan be used to set, modify or delete any of the relevant response header fields.
ai-scaling-cache, the images generated by Image Scaling are stored on disk in a separate cache and delivered to the clients with an expiry time of one year after their creation.
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
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
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
HTTP header fields are removed from responses that are satisfied from the cache.
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
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.
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
channels in the debug output.
Note that re-loading content in a browser (e.g. via
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.
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
clear the HTTP cache only. See
fitadmin maintenance clearcache --help for all
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:
304 not modifiedresponses, 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.