---
title: Caching Policy
slug: ps/help/en_us/vtm/userguide/caching-policy
docTags: 
createdAt: 2026-08-02T07:48:41.467Z
---

Not all Web content can be cached. Information in the HTTP request and the HTTP response drives the Virtual 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 Virtual 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 Virtual 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 Virtual 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:

```bash
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 Virtual Traffic Manager treats byte-ranges as a variant of a URL (for more information, see [Variants](docId\:t483_fBarGeOgTaDm89Tz)). 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 Virtual Traffic Manager caches the entire response for a URL, the Virtual 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 Virtual 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.