Guide · bounded stale serving

When stale HTTP content is allowed

Use four gates to decide whether old bytes are an allowed stale response, an ordinary revalidation path, or an unexplained copy at another layer.

Dated follow-up · 25 Sep 2026 · documentation-only; no live URL, browser, provider, origin, purge, or invalidation result is claimed.

The four gates

Storage: the response must be storable by this cache. no-store blocks ordinary HTTP-cache storage; private blocks a shared cache. Stale directives do not grant storage permission.
Freshness: private caches normally use max-age; shared caches use s-maxage before max-age and Expires.
Stale permission: a supporting cache may use stale-while-revalidate during background validation or stale-if-error during a defined error, within the extra bound.
Validation: otherwise validate or replace the entry. If-None-Match wins over If-Modified-Since; 304 reuses stored bytes at its recipient but does not identify the hop.

Portable rule: do not assume stale extensions override no-cache, must-revalidate, proxy-revalidate, or shared s-maxage revalidation semantics. A different result is a named implementation fact.

Expected timing example

This arithmetic example is expected and unexecuted: max-age=60, shared s-maxage=300, stale-while-revalidate=120, and stale-if-error=600. It assumes matching keys, correct validators, and no provider override.

Age at the cache	Browser/private	Shared cache	Interpretation
`0–59`	Fresh under `max-age=60`.	Fresh under `s-maxage=300`.	Reuse may be possible; no client display or residency is guaranteed.
`60–179`	Candidate SWR window: old bytes may be returned while validation runs.	Still fresh.	“May” is not “will”; browser/provider support is untested.
`180–299`	Candidate SWR window ended; ordinary validation.	Still fresh.	Separate caches can be in different states.
`300+`	Candidate SIE can apply only during an error through age `660`.	Stale; strict RFC 9111 reading requires validation before shared reuse.	A shared stale result needs named-provider documentation and an authorized test.

Choose by symptom

Healthy origin, old body

Capture the exact URL, request variant, Age, Cache-Status, Via, provider fields, validators, and body marker. fwd=stale; fwd-status=304 supports stale-then-validated reuse at that named cache. Without positive named evidence, the producer is unknown.

Next hop errors

Record the error and the final status. fwd=stale; fwd-status=503 shows the named forwarding/error sequence; it does not alone prove stale-if-error was used. Combine directives, configuration, and the stale body.

Revalidation in progress

Capture the conditional request. A 304 keeps stored bytes; a 200 should replace them. A stale browser/service-worker/history copy can remain even when a shared cache has revalidated.

Do not use stale as a privacy or purge strategy

For personalized or sensitive content, choose no-store when retention is unacceptable, or private, no-cache when browser retention with validation is acceptable. A stale extension does not repair a bad key, make a user-specific body public, clear a browser/service worker, or delete an old URL. Version changed assets; use a named-provider purge only for its documented scope.

Continue with the deployment and incident runbook for the broader key, downstream, versioning, and containment sequence.

Evidence boundaries

Signal	Can support	Cannot prove
`Age`	A stored-response path at some cache.	Which cache inserted it or why stale was allowed; absence is unknown.
`Cache-Status`	The named cache's `hit`, `fwd=stale`, status, or TTL reasoning.	That the next hop was origin or that omitted members do not exist.
`Via`	A visible forwarding proxy/gateway.	Hit, freshness, complete topology, or direct origin contact.
304 / origin marker	Conditional equivalence at the recipient; a correlated origin ID proves origin receipt.	Application freshness, global update, or origin contact from a stable marker alone.

Read the complete dated follow-up

The report includes the directive matrix, full timing table, three diagnostic paths, named-hop evidence limits, private/public/versioned guardrails, versioning versus purge boundaries, an authorized-only test matrix, a claim ledger, and direct RFC/MDN/Chrome links.

Open “When stale HTTP content is allowed” →