Web Caching

Chapter 2. How Web Caching Works

What makes an object cachable or uncachable? How does a cache know when a request is a hit or when to revalidate a cached object? This chapter gives you some background on how web caches work. Many of the topics in this chapter are covered definitively in the HTTP/1.1 draft standard document, RFC 2616. The material here tells you what you need to know; for all the gory details, you’ll need to consult the actual RFC document.

To start, we’ll see what a typical HTTP request looks like and how it’s different when talking to a proxy. Next, we’ll see how caches decide if they can store a particular response. After that, we’ll talk about cache hits, stale objects, and validation techniques. I’ll explain how users can force caches to return an up-to-date response. Finally, we’ll see what happens when a cache becomes full and must choose to remove some objects.

HTTP Requests

Clients always use HTTP when talking to a caching proxy. This is true even when the client requests an FTP or Gopher URL, as we’ll see shortly. A client issues a slightly different request when it knows it is talking to a proxy server rather than to an origin server. Occasionally, requests to a cache are referred to as proxy HTTP requests.

Origin Server Requests

First, let’s examine a request sent to an origin server. In this example, the user is requesting the URL http://www.nlanr.net/index.html. When the client is not configured to use a proxy, it connects directly to the origin server ...