Appendix D. Caching in Action
As we’ve seen, there are quite a few moving parts involved with HTTP caching. To illustrate how everything works together, let’s take a look at a common scenario involving two clients, an HTTP cache and the origin server. For the sake of brevity the body and all headers are not shown in the responses.
First, Client A does an initial request, as shown in Figure D-1.
The cache receives the request, and seeing that it is a
GETrequest checks whether it has a cached response. It doesn’t, so the cache forwards it on to the origin server.
The origin server generates a response, including
The cache receives the response and caches the result using a hash of the request URI and the
The cache then returns the response, including an additional
AGEheader to inform the client of the age of the representation.
Client A receives the representation and stores the
Fifteen minutes later, Client B makes a request to the same resource, as shown in Figure D-2.
- The cache receives the request and checks whether it has a copy of the representation.
It sees from the matching on the URI and
Acceptthat the representation is there and it is still fresh (based on the expiration), so it returns it immediately with the updated age.
Client B receives the representation and stores the
An hour later, Client A does a conditional
GET request back to the same resource, including the
If-None-Match header, as shown in Figure D-3.
The cache receives the request and checks whether it has a copy of the representation. It finds the representation and sees that it is no longer fresh. It then forwards on the conditional
GETrequest to the origin server to see if the copy it has is still valid.
The origin server receives the request and determines that the
ETAGis still valid. It returns a
304 Not Modifiedwith a new
The cache receives the request and returns the
304to the client, along with an updated age calculation.
Time passes, and Client B does a conditional
PUT against the contact resource, updating its state as shown in Figure D-4.
The cache receives the request and seeing that it is a
PUT, checks its cache to see if a copy exists for that resource, and if the
ETagmatches. Finding the copy, it invalidates the
ETagfor future requests. It then forwards on the request verbatim to the origin server.
The server applies the update and generates a new response with an updated
- The cache receives the response and caches it. It then returns the response to Client B.
Client A comes along 10 minutes later and tries to also do a conditional
PUT on the same resource as shown in Figure D-5.