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.
GETrequest checks whether it has a cached response. It doesn’t, so the cache forwards it on to the origin server.
AGEheader to inform the client of the age of the representation.
Fifteen minutes later, Client B makes a request to the same resource, as shown in Figure D-2.
Acceptthat the representation is there and it is still fresh (based on the expiration), so it returns it immediately with the updated age.
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.
GETrequest to the origin server to see if the copy it has is still valid.
ETAGis still valid. It returns a
304 Not Modifiedwith a new
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.
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.
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.