Caching Policy

Not all Web content can be cached. Information in the HTTP request and the HTTP response drives the Traffic Manager’s decisions as to whether or not a request should be served from the Web cache, and whether or not a response should be cached.

Requests

Only HTTP GET and HEAD requests are cacheable. All other methods are not cacheable.

The “Cache-Control” header in an HTTP request can force the Traffic Manager to ignore the web cache and to contact a back-end node instead.

Requests that use HTTP basic-auth are uncacheable.

Responses

The “Cache-Control” header in an HTTP response can indicate that an HTTP response should never be placed in the Web cache.

The header can also use the “max-age” value to specify how long the cached object can be cached for. This can cause a response to be cached for less than the configured webcache!time setting.

HTTP responses can use the “Expires” header to control how long to cache the response for. Note that using the “Expires” header is less efficient than using the “max-age” value in the Cache-Control response header.

The “Vary” HTTP response header controls how variants of a resource are cached, and which variant is served from the cache in response to a new request.

If a Web application wishes to prevent the Traffic Manager from caching a response, it should add a “Cache-Control: no-cache” header to the response.

To debug your cache behavior, set webcache!verbose to “Yes” in System > Global Settings > Cache Settings. If you enable this setting, the Traffic Manager adds a header named “X-Cache-Info” to the HTTP response to indicate how the cache policy has taken effect.

For further details about HTTP cache policies, see RFC 2616.

Variants

A URL can have multiple variants if:

•The response depends on additional request parameters, such as the Accept-Encoding or Accept-Language headers. The origin web server will indicate that this is the case by including a ‘Vary’ header in the response:

Vary: Accept-Language, Accept-Encoding

 

•The TrafficScript function http.cache.setkey() has been used to indicate the response content depends on other computed parameters.

Byte Ranges

Byte-ranges are used by some client software to request a portion of a document. For example, a PDF reader may download the first part of a PDF file (which contains an index of pages), and then issue a byte-range request to retrieve the pages the user wants to read.

The Traffic Manager treats byte-ranges as a variant of a URL (for more information, see Variants). Byte range responses are cached, and if another request for the same byte-range is received, the response is served directly from the cache.

If the Traffic Manager caches the entire response for a URL, the Traffic Manager serves all byte-range requests from that response.

ETags

ETags (entity tags) are used by Web servers to uniquely identify each version of a response. The Traffic Manager caches and honors ETags and will respond with a “304 Not Modified” response if the current cached version of a resource has the same ETag as the version cached by the remote client.