Caching and conditional requests
Cache-Control: no-cache, no-store and private
Do not guess caching behaviour from names.
Understand the concept
Caching reduces latency and transfer, but incorrect isolation can leak private data. no-store requests no storage. no-cache can allow storage but requires validation before reuse. private distinguishes user-specific storage from shared caches. max-age sets freshness; s-maxage addresses shared caches.
Use deliberate policies for sensitive account responses and never casually mark authenticated JSON public. Request no-cache does not purge all previous copies. Browser, service-worker, framework and CDN caches are separate layers.
Expired freshness requires validation or an explicitly permitted stale path. immutable suits versioned assets, not changing content under an unchanged URL. Correct keys and lifetimes are often better than disabling every cache.
Serve content quickly without losing correctness.
Assuming no-cache means never store.
One topic. Three levels of depth.
Cache-Control: no-storeA no-storage policy for sensitive content.
This page does not send requests to external servers. Messages are readable HTTP/1.1 illustrations, not HTTP/2 or HTTP/3 wire dumps. example.test is reserved for examples. Run commands and JavaScript only in your own test environment; never publish real tokens or cookies.
Try it yourself first.
Explain no-cache versus no-store.
Show the solution and explanation
Validate before reuse / do not storeno-cache requires validation; no-store requests no storage.