HTTP CACHE FIELD GUIDE

Cache headers.
Four clear answers.

A response can be stored, yet need validation.
It can be fresh in one cache, and stale in another.
Time is the missing part of the story.

Explore your headers

Offline lab · Open source · No account

One response. Different permissions as it ages.

SAME RESPONSE · TWO CACHES

How do max-age and s-maxage differ?

max-age sets an explicit freshness lifetime. For a shared cache, s-maxage takes priority over it and Expires. A private cache ignores s-maxage. RFC 9111 §5.2.2.10 ↗

Cache-Control: public, max-age=60, s-maxage=300

FreshTrace example · Age starts at 0 · 75 seconds after receipt

PRIVATE / BROWSER60s lifetimeStale · contact origin

SHARED / CDN300s lifetimeFresh · 225s remaining

In the model, a shared response with s-maxage also needs validation once stale. The cache labels describe roles; deployment configuration can change real behavior.

RECEIPT IS NOT A RESET

Why does max-age=60 leave only 15 seconds?

The Age header represents time already spent since generation or validation. FreshTrace adds time since receipt; with capture clocks, it also accounts for apparent age and response delay. RFC 9111 §4.2.3 ↗

Cache-Control: max-age=60
Age: 45

45sAlready old

15sAfter receipt

60sCurrent age · stale

This example assumes zero transit delay and apparent age, as the lab does without capture timestamps. At receipt, 15 seconds remain. At elapsed 15, the response reaches its freshness boundary. FreshTrace considers current age < lifetime fresh. Capture defaults and boundaries ↗

TWO DIFFERENT PERMISSIONS

Does no-cache mean “do not store”?

Unqualified no-cache requires successful validation before reuse. It can permit storage. no-store forbids storing the response for reuse. Storage and reuse are separate decisions. RFC 9111 §5.2.2.4 · §5.2.2.5 ↗

Validate before reuse

Cache-Control: no-cache, max-age=600
ETag: "version-1"

At age 10, FreshTrace allows storage but requires origin validation. The nominal 600-second lifetime does not bypass no-cache.

Do not store

Cache-Control: no-store

At age 10, FreshTrace blocks storage. The next request needs a network fetch; there is no stored response to reuse in this scenario.

Qualified field directives and successful 304 updates are outside this example. The lab models one unchanged stored response, not a sequence of refreshes.

FRESHNESS ENDS · PERMISSION MAY CONTINUE

When can a stale response still be served?

stale-while-revalidate permits stale reuse while validation runs in the background. stale-if-error permits stale reuse during a qualifying origin failure. Their allowances are measured from the freshness boundary. Support and use depend on the cache implementation. RFC 5861 §§3–4 ↗

Cache-Control: max-age=60, stale-while-revalidate=30,
               stale-if-error=120

FreshTrace example · Age starts at 0 · a matching stored response
Current age	Normal request	Qualifying origin error
75s	Background validation	Stale reuse on error
120s	Contact origin	Stale reuse on error
181s	Contact origin	Origin required · cannot reuse

In FreshTrace, SWR ends at age 90 (exclusive); SIE ends at age 180 (inclusive). The engine conservatively blocks stale allowances under no-cache, must-revalidate and, for shared caches, proxy-revalidate or s-maxage. A visible window never guarantees a cache hit. Model choices ↗

TURN THE QUESTION INTO A TIMELINE

Change one header.
See what changes over time.

Open the lab, paste an example, and move the elapsed-time slider.
Compare two policies under the same request context.

Try FreshTrace Explore the source ↗