In addition to fine-tuning cache freshness with the system's global HTTP timers as explained in Fine-Tuning Cache Freshness on Your Appliance, you can configure each proxy service to recognize custom headers in HTTP packets. Your Web server can then use these headers for transmitting caching instructions that only the configured appliance services will recognize and follow.
Only the accelerator service containing the custom header definition follows the cache policies specified in the custom headers.
All other caches, including the non-configured appliance caches, requesting browsers, and external proxy caches (transparent caches, client accelerators, etc.) do not recognize the custom headers and follow only the cache policies specified by the standard cache control headers.
This means that you have the following options for configuring your Web server:
This lets you offload request processing from the origin Web server while still requiring that users return to the site each time they request an object.
To implement custom cache control headers, you must do the following:
If the number is non-zero, the proxy server treats the reply as if it had the following headers:
If the number is zero (0), iChain Proxy Services treats the reply as if it had the following header: Cache-Control: no-cache
For example, you could do the following:
Custom Cache Control Headers override the following standard HTTP cache-control headers on the appliance but do not affect how browsers and external caches respond to them:
For example, you might do the following:
The appliance will now recognize FOOTTL as a custom cache control header on objects requested through the service you are configuring.
The appliance will recognize this header as overriding the standard HTTP cache-control headers listed above when objects are requested through the accelerator service you are configuring.
When your Web server sends an object with the FOOTTL header in response to an appliance request made through the accelerator service, your appliance recognizes the custom header and caches the object for 10 minutes. Requesting browsers cache the object for only two minutes. External caches do not cache the object.
Thus, the appliance offloads a processing burden from the Web server by caching the frequently requested objects for 10 minutes (the value you specified in Step 2). Browsers, on the other hand, must always access the appliance to get the objects if their previous requests are older than two minutes. And the objects in the appliance's cache are kept fresh due to their relatively brief time-to-live value.