HTTP Cache-Control

What it means

The HTTP Cache-Control response field describes constraints on storage and reuse of a response. max-age=60 supplies a freshness lifetime; s-maxage can override that lifetime for a shared cache. private restricts shared-cache storage, no-cache requires validation before reuse, and no-store forbids storage under the applicable rules. These are not interchangeable. In particular, no-cache does not literally mean “do not store,” and a newly configured no-store value does not erase every old copy already cached elsewhere.

Try it

Simulation — decide store, reuse or validate. Compare private and shared cache with max-age=60, then set age to exactly 60 seconds to see the freshness boundary. Choose max-age=60, s-maxage=300 at age 120: private is stale and shared is fresh. Try no-cache, no-store and private. The result shows storage permission, freshness and next action as separate rows. Reset restores the example.

How the mechanism works

Freshness calculation considers the response's apparent age and applicable explicit lifetime, with the simplifying assumptions declared in this exercise. A fresh response may be reused when all other cache-selection rules permit it. no-cache permits storage but requires successful validation before reuse. With no-store, the new response must not be stored under the relevant rule; existing copies elsewhere do not vanish automatically. private blocks storage in shared intermediaries but does not mean the response is encrypted or inaccessible to software running in the user's environment.

A shared cache can use s-maxage, which overrides max-age for its freshness decision. must-revalidate constrains reuse of stale responses after failed validation, not storage of a fresh response. Real caching includes request directives, validators, Vary, Authorization, cache keys, heuristic freshness, stale extensions and other restrictions not implemented in this small model.

Primary protocol documentation provides the underlying rules; the interactive state is only a synthetic illustration.

In practice

When debugging an unexpected stale page, inspect the exact response headers and Age for the specific resource at the browser and any CDN/edge layers. Separate storage from freshness and validation. Confirm any configuration change in a nonproduction environment with explicit request sequences and cache keys. Stop if the route can carry personalized or sensitive content under a shared-cache rule; review the complete application authorization semantics first. Roll back using the previous tested response policy, not an assumption that one directive purges existing content.

Limits and common mistakes

This is a simple 200 GET fixture with no Vary, Authorization or heuristic freshness. Its “fresh” result is conditional on those assumptions and is not a direct probe of a browser or CDN. Cached copies may persist for different durations in other contexts.

Key takeaways

First ask whether a response may be stored; then whether it is still fresh; then whether validation is required for reuse. no-store is not a retroactive purge, while no-cache permits storage but requires validation. Shared caches have different rules for private and s-maxage; s-maxage also includes proxy-revalidate, so a stale shared copy cannot be reused without successful origin validation. At the freshness boundary, equal age is stale.