I put together a presentation on HTTP and Caching. I think this should give a good overview of HTTP cache behaviors, and provide some useful tips for application server developers who want to take advantage of HTTP web caches.

This presentation was pretty heavily inspired by Mark Nottingham’s excellent web caching tutorial, but I believe my presentation is briefer, more visual, and more targeted to web application developers.

Other useful caching introductions and references are at the very end of the presentation.

Spoiler Alert: Scroll down to see some possible answers to the exercises.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Exercise 1: A low-effort approach would be to set Date, Age, and Cache-Control: max-age headers on all static files. Max-age would have to be some reasonable compromise based on how often files are expected to be deployed. Something like five minutes would give enough time for files to be reused between most page loads but still give fast updates on redeployment.

Exercise 2: 

• “/users/me” (presumably a short-hand to get the current user as identified by a session) could be changed to a more unique endpoint (for example, “/users/sam”).
• The user’s set of “recent_reports” may change more frequently than the contents of the reports change, and the report contents could potentially be large. The resource representation could be modified so that the “recent_reports” property could be a set of links pointing to URLs for report resources. The report resources could then be fetched as-needed and cached with a different TTL than the user resource.

Exercise 3: Setting the ETag response header for the cSV files allows caches to validate cached files, saving the client from having to download a large CSV file if no changes have been made.

Exercise 4: This was an actual high-stakes deployment situation that I struggled through. The root problem was that the static javascript files were deploying to the two origin servers at different rates. When a user-agent attempted to use the application mid-deployment, the client would direct the user-agent to download files from the new version, but the origin server answering the request may not have the new version file deployed and available. To compound the problem, the origin servers were returning a 200 “OK” response with HTML describing a “resource not found” error, so the CDNs happily cached this “error page” response as a valid response. Changing the response code to 404 in the case of file not found effectively fixed the problem.