Member-only story
HTTP Caching Explained: What Cache-Control, ETag and 304 Actually Do, Measured
no-cache doesn’t mean “don’t cache”, a response with no caching headers gets cached anyway, and one public header let a shared cache hand one user’s session cookie to the next. Twelve rules, each run against a counting origin.
Three requests for the same URL, through a cache, and what the origin server saw:
Cache-Control: no-cache client saw [200, 200, 200] origin saw 3: ['plain', 'INM', 'INM']
Cache-Control: no-store client saw [200, 200, 200] origin saw 3: ['plain', 'plain', 'plain']Both headers sent three requests to the origin, so they look the same from far away. They aren’t. With no-cache, the cache stored the response, and the second and third requests carried If-None-Match, the cache asking "I have this version, is it still current?" The origin answered 304 Not Modified with no body. With no-store, the cache kept nothing and downloaded the whole response every time.
Most developers read no-cache as "don't cache this". It actually means "cache this, but check with me before every use". That one misreading explains a lot of slow pages and a few data leaks. HTTP caching is not one setting. It is two separate questions, freshness and validation, plus a third about who may share a stored copy, and each header answers…
