Using Custom Cache Control Headers

In addition to fine-tuning cache freshness using 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.

An Overview of How Headers Work

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. They 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:

• You can specify that browsers and/or external caches cannot cache the objects, but the accelerator can.

  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.

• You can also specify separate cache times for browsers, external caches, and the accelerator you are defining.

Implementing Custom Cache Control Headers

To implement custom cache control headers, you must do the following:

• Enter a header string, such as MYCACHE, in the Custom Cache Control Header dialog box.
• Configure the Web server to send an HTTP header containing the defined string and the time in seconds that the object should be retained in cache (MYCACHE: 60, for example).

  If the number is non-zero, Excelerator treats the reply as if it had the following headers:

  Cache-Control: public

  Cache-Control: max-age=number

  If the number is zero (0), Excelerator treats the reply as if it had the following header:

  Cache-Control: no-cache

• Ensure that the Web server continues to send standard HTTP cache-control headers so that browsers and external caches follow the caching policies you intend them to.

  For example, you could do the following:

  • Use an Expires or Cache-Control: Max-Age header to specify that browsers should cache an object for two minutes.
  • Use a Cache-Control: Private header to prevent external caches from caching the object at all.
  • Use a custom cache control header, such as MYCACHE: 1800, to indicate that the accelerator should cache the object for 30 minutes.

Custom Cache Control Headers override the following standard HTTP cache-control headers on the appliance, but they do not affect how browsers and external caches respond to them:

Cache-Control: no-store

Cache-Control: no-cache

Cache-Control: max-age=number

Cache-Control: private

Cache-Control: public

Pragma: no-cache

Expires: date

An Implementation Example

For example, you might do the following:

1. While configuring a Web server accelerator service, you insert a string in the Custom Cache Control Header list with the value of FOOTTL.

   The appliance will now recognize FOOTTL as a custom cache control header on objects requested through the service you are configuring.

2. You then configure the accelerated Web server to send FOOTTL: 600 in the headers of objects you want to be cached at the appliance.

   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.

3. Finally, you ensure that the Web server continues to send the following standard HTTP cache-control headers:
   • Cache-Control: Max-Age headers that cause browsers to cache objects for no longer than two minutes
   • Cache-Control: Private headers that cause external caches to not cache the objects

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, and external caches do not cache the object.

Thus, the appliance off-loads 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.