Java Beans-style configuration for a
CachingHttpClient. Any class
in the caching module that has configuration options should take a
CacheConfig argument in one of its constructors. A
CacheConfig instance has sane and conservative defaults, so the
easiest way to specify options is to get an instance and then set just
the options you want to modify from their defaults.
N.B. This class is only for caching-specific configuration; to
configure the behavior of the rest of the client, configure the
org.apache.http.client.HttpClient used as the "backend"
Cache configuration can be grouped into the following categories:
Cache size. If the backend storage supports these limits, you
can specify the
CacheConfig#getMaxCacheEntries as well as the
Public/private caching. By default, the caching module considers
itself to be a shared (public) cache, and will not, for example, cache
responses to requests with
Authorization headers or responses
Cache-Control: private. If, however, the cache
is only going to be used by one logical "user" (behaving similarly to a
browser cache), then you will want to
303 caching. RFC2616 explicitly disallows caching 303 responses;
however, the HTTPbis working group says they can be cached
if explicitly indicated in the response headers and permitted by the request method.
(They also indicate that disallowing 303 caching is actually an unintended
spec error in RFC2616).
This behavior is off by default, to err on the side of a conservative
adherence to the existing standard, but you may want to
Weak ETags on PUT/DELETE If-Match requests. RFC2616 explicitly
prohibits the use of weak validators in non-GET requests, however, the
HTTPbis working group says while the limitation for weak validators on ranged
requests makes sense, weak ETag validation is useful on full non-GET
requests; e.g., PUT with If-Match. This behavior is off by default, to err on
the side of a conservative adherence to the existing standard, but you may
Heuristic caching. Per RFC2616, a cache may cache certain cache
entries even if no explicit cache control headers are set by the origin.
This behavior is off by default, but you may want to turn this on if you
are working with an origin that doesn't set proper headers but where you
still want to cache the responses. You will want to
then specify either a
CacheConfig#getHeuristicDefaultLifetime() and/or a
CacheConfig#setHeuristicCoefficient(float). See Sections
13.2.4 of the HTTP/1.1 RFC for more details on heuristic caching.
Background validation. The cache module supports the
stale-while-revalidate directive of
RFC5861, which allows
certain cache entry revalidations to happen in the background. You may
want to tweak the settings for the
CacheConfig#getAsynchronousWorkersMax() number of background
worker threads, as well as the
CacheConfig#getAsynchronousWorkerIdleLifetimeSecs(). You can also control the
CacheConfig#getRevalidationQueueSize() used for
revalidations when there aren't enough workers to keep up with demand.