Cache-Friendly Web Pagesby Jennifer Vesperman
There are a lot of HTTP caches out there. How long are they holding your pages? How long should they hold your pages? RFC 2616 (HTTP/1.1) specifies that caches must obey Expires and Cache-Control headers--but do your pages have them? How do you add them? What happens to your pages if you don't?
"The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases." RFC 2616
Advantages of cache-friendly pages
"HTTP caching works best when caches can entirely avoid making requests to the origin server. The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future, indicating that a response MAY be used to satisfy subsequent requests. In other words, a cache can return a fresh response without first contacting the server." RFC 2616
The RFC was written with the expectation that Web pages would include expiration headers. If the expiration times in the headers are chosen carefully, caches can serve stored pages without losing any meaning.
When origin servers don't provide expiration headers, caches use heuristics based on headers like "Last-Modified" to guess at a suitable expiration. Heuristic methods are inefficient compared to expiry dates set by humans who know a page's content and frequency of changes.
"Since heuristic expiration times might compromise semantic transparency, they ought to be used cautiously, and we encourage origin servers to provide explicit expiration times as much as possible." RFC 2616
Notes about caching
The HTTP/1.1 specification (section 13) has strict requirements for caches: It requires them to provide semantic transparency--returning a cached response should provide the same data as would be retrieved from the origin server; and it calls for them to read freshness requirements provided by origin servers and clients.
Caches must pass on warnings provided by upstream caches or the origin server, and they must add warnings if providing a stale response. A cache may provide a stale response in limited circumstances, mostly if the cache cannot connect to the origin server and the client has stated that it will accept a stale response.
If a cache receives a request for a stale page, it sends a validation request to ask the origin server if the page has changed. The most common validation tool is the last modification time. If there are two changes stored within one second, Last-Modified will be incorrect. Because of this, HTTP/1.1 offers strict validation using the Entity Tag header.
The simplest way to assist caching is to keep accurate time on your HTTP server and always send the Date and Last-Modified headers with your responses.
To be a really cache-friendly webmaster, though, include the cache headers in your pages.
Available cache headers
The Expires header is the quick and easy solution. This header states the time at which the page is considered no longer cacheable, after which any cache storing a copy of the page should contact the origin server rather than send the stored copy. The syntax is:
Expires: <date in RFC 1123 format>
Expires: Sun, 10 Feb 2002 16:00:00 GMT
To mark a response as "already expired" or "not cacheable", the header should be set to the time the response is sent. To mark a response as "never expires", the header should be set to one year in the future.
The other header is Cache-Control. Cache-Control includes elements to designate the maximum age of a page element, whether it can be cached, whether it can be transformed into a different storage type, and whether it can be stored on nonvolatile media.
This article uses Apache as an example for setting up headers and discusses the Cache-Control header in more detail during the example.
Setting up cache headers in Apache
Main method: Expires header
To use the Expires header, you will need to be running Apache 1.2 or later and have
mod_expires enabled. Uncomment the
expires_module line in the "Dynamic Shared Object Support" section of the httpd.conf file, then recompile Apache.
# # Dynamic Shared Object (DSO) Support # # LoadModule cern_meta_module /usr/lib/apache/1.3/mod_cern_meta.so LoadModule expires_module /usr/lib/apache/1.3/mod_expires.so
(If you are running Apache 1.3 or later and it is configured to load modules at runtime, you can edit httpd.conf and then restart Apache instead of recompiling.)
mod_expires calculates the Expires header based on three directives. The directives apply to document realms and are usable in any of the following realms: "server config", "virtual host", "directory", or ".htaccess".
Pages: 1, 2