Controlling Content Caching Using TrafficScript
HTTP Request Processing
When the Virtual Traffic Manager receives a new HTTP request, it must determine whether it can serve a response directly from the Web cache, or whether it should forward the request on to a back-end server. The Virtual Traffic Manager executes all TrafficScript request rules on the request before it inspects the Web cache. Consequently, a TrafficScript request rule can modify a request and influence the Virtual Traffic Manager’s decision.
For example, a TrafficScript request rule could add a “Cache-Control: no-cache” header to a request to prevent the Virtual Traffic Manager from serving the response from the local Web cache.
HTTP Response Processing
Similarly, when the Virtual Traffic Manager receives an HTTP response from a back-end server node, it must decide whether or not to insert the response into the Web cache for future use. The Virtual Traffic Manager executes all TrafficScript response rules before making this decision, so a TrafficScript response rule can modify a response and influence this decision.
A TrafficScript response rule could add a “Cache-Control: no-cache” header to the response to prevent it from being cached, or a “Cache-Control: max-age=60” header to indicate that the response should be cached for 60 seconds.
Note that if a response is served from the Web cache, the TrafficScript response rules are not executed.
TrafficScript Cache Control Functions
Several cache control functions are available to facilitate the control of the Virtual Traffic Manager’s caching behavior. In most cases, these functions eliminate the need to manipulate headers in the HTTP requests and responses.
Function | Description |
|---|---|
http.cache.disable() | Invoking http.cache.disable() in a response rule prevents the Virtual Traffic Manager from caching the response. |
http.cache.enable() | Invoking http.cache.enable() in a response rule reverts the effect of a previous call to http.cache.disable(). It causes the Virtual Traffic Manager’s default caching logic to take effect. Note that it is not possible to force the Virtual Traffic Manager to cache a response that it deems to be uncacheable. |
http.cache.setkey() | The http.cache.setkey() function is used to differentiate between different versions of the same request, in much the same way that the Vary response header functions. It is used in request rules, but may also be used in response rules. It is more flexible than the RFC2616 Vary support, because it lets you partition requests on any calculated value – for example, different content based on whether the source address is internal or external, or whether the client’s “User-Agent” header indicates an IE or Gecko-based browser. |
http.cache.exists() | The http.cache.exists() function can be used in a request rule to check if a matching response exists at that instant in the cache. If the rule were to terminate without modifying any of the request parameters, the response would be served from the cache (unless it had expired in the intervening time). |
http.cache.respondIfCached() | This function can be called in a request rule. If a matching response exists in the Web cache, the rule terminates immediately and the response is sent back to the remote client. No further request (or response) rules are run. If a matching response does not exist, the function returns and rule processing continues. This can be used to support logic such as rate shaping, whereby you wish to rate-shape requests to back-end nodes, but do not need to apply a rate limit if you can serve the response directly from the Virtual Traffic Manager cache: http.cache.respondIfCached(); rate.use( "my rate limit" ); |
For more information and code samples, see the Virtual Traffic Manager: TrafficScript Guide available from the Ivanti Web site (www.ivanti.com).