concept / Delivery & performance
HTTP Cache-Control
A cache must first establish whether storing a particular response is permitted. If a stored response is eligible for reuse, its applicable freshness lifetime and current age determine whether it is fresh; equality with the lifetime means stale. Shared caches use applicable `s-maxage` in preference to `max-age`, and stale reuse may be forbidden even without a new network response. This is a local classification model, not a live cache inspection.
What it means
HTTP caching has three separate decisions: storage eligibility, freshness and permission to reuse after freshness expires. Calculating a generous lifetime does not override no-store, private/shared constraints or authorization conditions. no-cache generally permits storage subject to other rules but requires validation before reuse; it is not synonymous with no-store.
Try it
Cache storage decision before freshness
SimulationFrom the baseline, select the `stale_shared` preset.
Storage evidence remains permitted, cache type remains shared, `max-age` remains 60 seconds, `s-maxage` remains 120 seconds and `must-revalidate` remains true.
Selected scenario: baseline
fresh
- Storage permitted
- Yes
- Cache type
- shared
- Current Age (seconds)
- 119
- Freshness lifetime (seconds)
- 120
- Fresh
- Yes
- Validation required before modeled reuse
- No
- Stale reuse permission
- not applicable
- Effective directive
- s-maxage
Storage permission is supplied separately. The s-maxage lifetime is 120 seconds, and current Age is 119 seconds. Age is strictly below the lifetime, so this fixture is fresh; other reuse conditions remain out of scope.
No live HTTP, validation response, Authorization, stale-use exception or heuristic freshness. No stale response is automatically reusable.
Recent valid actions
The last ten valid changes in this local example. Reset clears this history.
No changes recorded.
Select Reset to return to the baseline: permitted storage, shared cache, current age 119 seconds, max-age 60, s-maxage 120 and must-revalidate true. Reset clears local errors, history, comparison, scenario selection and temporary input values. It leaves the FAQ and About this model open or closed as you had them, and changes no real external system.
About this model
This is a simulation, not a live HTTP cache. You supply storage evidence rather than having the model establish it. It does not send requests, perform validation, evaluate Authorization or model heuristic freshness and stale-use exceptions.
How it works
A private cache serves one user; a shared cache can serve multiple users. First establish storage eligibility for the particular cache and request, including any conditions associated with Authorization. Then, for the explicit lifetimes in this example, a shared cache uses s-maxage over max-age, while a private cache uses max-age. Compare the calculated current age with that lifetime: strictly below is fresh; equal to or above it is stale. The simulation's current age is a synthetic input, not necessarily the raw Age header.
must-revalidate restricts reuse once a response is stale. Shared-cache s-maxage also constrains stale reuse. Neither replaces the separate storage and Authorization checks. See RFC 9111, especially sections 3, 3.5, 4.2 and 5.2.2.
For this fixture, suppose a shared cache holds an eligible response with max-age=60, s-maxage=120 and current age 119. The shared lifetime is 120 and the response is fresh; at age 120 it is stale. The change from 119 to 120 does not itself trigger a network operation. Whether stale bytes may be served still depends on the applicable restrictions, validation and exceptional policies not fully represented here. A private cache can select a different lifetime for the same response.
A worked example
In the simulation's baseline, storage is supplied as permitted. With a shared cache, max-age=60, s-maxage=120, must-revalidate true and current age 119 seconds, the applicable lifetime is 120 seconds and the response is fresh. At age 120, with the other inputs unchanged, it is stale. The selected must-revalidate and shared-cache s-maxage restrictions require successful validation before modeled reuse. This is a synthetic classification, not a live request or validation.
What changes the conclusion
A conceptual comparison: suppose storage is permitted, max-age is 300 seconds and s-maxage is 60 seconds. A shared cache is fresh at current age 59 and stale at 60. A private cache using the 300-second max-age is still fresh at age 60. These values illustrate the rules; they are not a named preset.
In practice
For a real HTTP response you are authorized to inspect, start read-only: identify the cache as private or shared and examine the request and response headers, response status, and Authorization conditions. Establish storage eligibility before applying the freshness calculation. A stale or unexpected response can have several causes; the symptom alone does not identify which rule or cache produced it. Stop before changing configuration if storage permission, the relevant cache, or the observed behavior is unclear. A simulation result is not proof that a real service works.
A surprising stale response requires evidence from the specific cache, method and request/response pair. Identify Authorization, storage directives, effective age and any validators before calling a configuration wrong. Stop if storage permission is unknown; a numerical freshness classification without permission evidence would be misleading. A model Reset is not a real cache purge.
Limits and unknowns
If storage is prohibited, the simulation does not evaluate freshness. If storage evidence is unknown, it reports storage as unknown and freshness as not evaluated; that is not a confirmed prohibition or permission. Stop and correct a negative or invalid age rather than relying on a previous result. The model also excludes live validation, Authorization decisions, heuristic freshness and stale-use exceptions. A modeled fresh result does not establish that every real-world reuse condition is satisfied.
What to take away
Review cache observations in order: eligible storage, applicable shared/private freshness lifetime, current age, then stale reuse restrictions. Keep unknown eligibility and unobserved validation explicit. An age boundary classifies an existing response; it does not guarantee a fetch, purge or successful update.
Frequently asked questions
Editorial questions, supported by the references below.
Can a response be fresh by arithmetic but forbidden to store?
Yes. A simple age/lifetime comparison can be numerically fresh even when storage is disallowed for the specific cache or request. Storage eligibility is the first decision; this model does not infer it from max-age alone.
Does reaching the lifetime boundary automatically issue a network request?
No. Equality makes a response stale under the freshness calculation, but it does not automatically mean a request has been sent. Client/cache behavior and permission to reuse determine the next step.
Does no-cache mean the response must not be stored?
No. `no-cache` allows storage subject to the other rules but requires successful validation before reuse. `no-store` prohibits storing the relevant response under its defined scope; neither is a retroactive purge command.
Can a shared cache reuse stale content merely because must-revalidate is absent?
No. RFC 9111 restricts serving stale responses unless a permitted exception applies, and directives such as `s-maxage` or `must-revalidate` can require validation. Removing one explicit directive does not make every stale reuse legal.
Sources & model boundaries
The interactive is a local educational simulation, not a live check. Protocol references and WebsiteHosting.com operating rules are identified separately.
- CACHE01 — Protocol or bounded model reference
For a shared cache, s-maxage takes precedence over max-age in the explicit freshness lifetime calculation.
HQ reviewed targeted core claim; no complete current errata/updates audit or all-sentence factcheck
- RFC 9111 — RFC9111 §§3,3.5,4.2.1,5.2.2.10
Recorded targeted check: .
- CACHE02 — Protocol or bounded model reference
Freshness requires freshness_lifetime strictly greater than current_age; equality is stale.
HQ reviewed targeted core claim; no complete current errata/updates audit or all-sentence factcheck
- RFC 9111 — RFC9111 §§4.2,4.2.3
Recorded targeted check: .
- CACHE03 — Protocol or bounded model reference
must-revalidate affects use of stale responses; it should not be substituted for the entire shared-cache Authorization rule.
HQ reviewed targeted core claim; no complete current errata/updates audit or all-sentence factcheck
- RFC 9111 — RFC9111 §§3.5,5.2.2.2,5.2.2.10
Recorded targeted check: .
- CACHE04 — Protocol or bounded model reference
An unqualified no-cache response directive allows storage subject to the other rules but requires successful validation before reuse. A no-store response directive prohibits storage and reuse; the must-understand exception is separately specified.
Response directives, not request directives; no-cache is unqualified here. These directives are explained in prose, not additional controls in the bounded lab. Neither directive guarantees privacy.
- RFC 9111 — RFC9111 §§5.2.2.3–5 (response directives)
Recorded targeted check: .
Report an issue. Include the article URL and ID, not passwords or access keys.