Lampooning the Cache-Control header is all fun and games, but remember it was designed in a time where Internet in big organisations often was behind a caching proxy like Squid. With that in mind, the explanations at https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ca... make good sense.
No, not really - those explanations are nothing more than what's in TFA, and they don't help it make any more sense. There's no reason in the world why no-cache should mean 'cache this please but with caveats', when we have all of the English language available to come up with an alternative header.
Caching in this context means “no need to ask the server for a new copy of this within the cache lifetime”. no-cache then does what it says: You can store it if you like, but you need to check with the server before reusing it.
That might be a little counter-intuitive, but if you read the definitions of the words, it does make sense.
no-cache: you MAY store this, but you MUST revalidate with the server before using it
must-revalidate: you MUST revalidate with the server before using this after it expires
They overlap but address different things; no-cache is for cacheability while must-revalidate is for validity. I don't think either of them are named very well.
The "no-cache" was a hint not about caching the content but about caching subsequent requests, and could optionally specify specific fields that would indicate that a new candidate request needed to be sent to the server as the content might be different. There's this reality that just to render content, the browser effectively must have a cached copy of the content, so the notion that the response wouldn't be cached wasn't really even in the cards. Whether you used the cache or not was a decision made at the time you were sending a request, not when you were consuming the response.
The "no-cache" directive meant, "hey, don't check for a cached copy of the content, just go fetch new content". It was often used by analytics pieces so that the server could count how often content was looked at.
Back in the day you had terrible latencies (particularly over dialup). You also had issues with horribly asymmetric bandwidth that meant the data you sent could become the bandwidth bottleneck (outbound bandwidth constraints would mean ACK packets would get queued up, delaying downloads even when you had plenty of download bandwidth), and of course HTTP requests weren't terribly compact, so this could really make a big difference.
Caching requests was a big deal. Performance could be improved significantly by "cheating" and just not sending a new request, and this lead to some very aggressive caching strategies. The, "check if the content really is different, and just use the original copy if they aren't" hack a pretty common one. If nothing else, it saved the browser the overhead of re-rendering the page and the accompanying annoying user experience of seeing the re-render.
The original protocol didn't have any notion of no-store, and specifically mentioned that "private" didn't really provide privacy, but more that the content should be "private" in the sense that only the browser itself should store the content. Again, there's an assumption that the browser is going to put everything it gets into a "cache", because it has to.
You could use "max-age", but a lot of caches would still shove the object in their cache and only expire it on a FIFO basis or when a new request was to be sent (and it was vulnerable to clock skew problems). Sounds dumb, but it was the kind of dumb that kept code simple and worked pretty well.
So now that the practices were in place, you need a new directive to say, "hold up, that old approach is NOT a good idea here". So they came up with "no-store" as a way to say, "don't even put it in the cache in the first place".
