High Performance Web Sites

Proxy Caching

The configuration described so far works fine when the browser talks directly to the web server. The web server determines whether to compress the response based on Accept-Encoding. The browser caches the response, whether or not it has been compressed, based on other HTTP headers in the response such as Expires and Cache-Control (see Chapter 5).

When the browser sends the request through a proxy it gets more complicated. Suppose that the first request to the proxy for a certain URL comes from a browser that does not support gzip. This is the first request to the proxy, so its cache is empty. The proxy forwards that request to the web server. The web server's response is uncompressed. That uncompressed response is cached by the proxy and sent on to the browser. Now, suppose the second request to the proxy for the same URL comes from a browser that does support gzip. The proxy responds with the (uncompressed) contents in its cache, missing the opportunity to use gzip. The situation is worse if the sequence is reversed: when the first request is from a browser that supports gzip and the second request is from a browser that doesn't. In this case, the proxy has a compressed version of the contents in its cache and serves that version to all subsequent browsers whether they support gzip or not.

The way around this problem is to add the Vary header in the response from your web server. The web server tells the proxy to vary the cached responses based on one or more request ...