Setting Cache Controls | HTTP: The Definitive Guide

7.10 Setting Cache Controls

Different web servers provide different mechanisms for setting HTTP cache-control and expiration headers. In this section, we'll talk briefly about how the popular Apache web server supports cache controls. Refer to your web server documentation for specific details.

7.10.1 Controlling HTTP Headers with Apache

The Apache web server provides several mechanisms for setting HTTP cache-controlling headers. Many of these mechanisms are not enabled by defaultyou have to enable them (in some cases first obtaining Apache extension modules). Here is a brief description of some of the Apache features:

mod_headers

The mod_headers module lets you set individual headers. Once this module is loaded, you can augment the Apache configuration files with directives to set individual HTTP headers. You also can use these settings in combination with Apache's regular expressions and filters to associate headers with individual content. Here is an example of a configuration that could mark all HTML files in a directory as uncachable:

  <Files *.html>

  Header set Cache-control no-cache

 </Files>

mod_expires

The mod_expires module provides program logic to automatically generate Expires headers with the correct expiration dates. This module allows you to set expiration dates for some time period after a document was last accessed or after its last-modified date. The module also lets you assign different expiration dates to different file types and use convenient verbose descriptions, like "access plus 1 month," to describe cachability . Here are a few examples:

 ExpiresDefault A3600

 ExpiresDefault M86400

 ExpiresDefault "access plus 1 week"

 ExpiresByType text/html "modification plus 2 days 6 hours 12 minutes"

mod_cern_meta

The mod_cern_meta module allows you to associate a file of HTTP headers with particular objects. When you enable this module, you create a set of "metafiles," one for each document you want to control, and add the desired headers to each metafile.

7.10.2 Controlling HTML Caching Through HTTP-EQUIV

HTTP server response headers are used to carry back document expiration and cache-control information. Web servers interact with configuration files to assign the correct cache-control headers to served documents.

To make it easier for authors to assign HTTP header information to served HTML documents without interacting with web server configuration files, HTML 2.0 defined the <META HTTP-EQUIV> tag. This optional tag sits at the top of an HTML document and defines HTTP headers that should be associated with the document. Here is an example of a <META HTTP-EQUIV> tag set to mark the HTML document uncachable:

 <HTML>

 <HEAD>

 <TITLE>My Document</TITLE>

 <META HTTP-EQUIV="Cache-control" CONTENT="no-cache">

 </HEAD>

...

This HTTP-EQUIV tag was originally intended to be used by web servers. Web servers were supposed to parse HTML for <META HTTP-EQUIV> tags and insert the prescribed headers into the HTTP response, as documented in HTML RFC 1866:

An HTTP server may use this information to process the document. In particular, it may include a header field in the responses to requests for this document: the header name is taken from the HTTP-EQUIV attribute value, and the header value is taken from the value of the CONTENT attribute.

Unfortunately, few web servers and proxies support this optional feature because of the extra server load, the values being static, and the fact that it supports only HTML and not the many other file types.

However, some browsers do parse and adhere to HTTP-EQUIV tags in the HTML content, treating the embedded headers like real HTTP headers ( Figure 7-17 ). This is unfortunate, because HTML browsers that do support HTTP-EQUIV may apply different cache-control rules than intervening proxy caches. This causes confusing cache expiration behavior.

Figure 7-17. HTTP-EQUIV tags cause problems, because most software ignores them

figs/http_0717.gif

In general, <META HTTP-EQUIV> tags are a poor way of controlling document cachability. The only sure-fire way to communicate cache-control requests for documents is through HTTP headers sent by a properly configured server.