HTTP Caching and Conditional Requests

The fastest request is the one that never reaches the server, and the second fastest is the one the server can answer with "nothing has changed". HTTP gives an API both, through headers that tell caches what they may keep and validators that let a client ask whether its copy is still current. The same validators also solve a different problem: two clients editing one resource and silently overwriting each other.

The topic starts with who caches a response and the Cache-Control directives that govern them. Validators come next, ETag and Last-Modified, then a walkthrough of a conditional GET that ends in 304. A gotcha corrects what no-cache means, and Vary shows how one URL can hold several cached copies. The second half turns to writes: the lost update, the If-Match walkthrough that prevents it, and a gotcha about a shared cache that serves one user's data to another.

The safe and idempotent methods that caches rely on come from the first topic in this subject.

By the end you can choose Cache-Control for a response, trace a conditional GET to a 304, tell no-cache from no-store and a strong ETag from a weak one, spot a personal response a shared cache could leak, and prevent a lost update with If-Match.