Dated research · 1 Oct 2026

HTTP redirect caching and stale route targets

When a cache may reuse a redirect, why an old target can persist after a route change, and how to identify the redirect hop that supplied it.

Retrieved: 2026-10-01 06:17 UTC. Standards and official documentation were checked online. No endpoint, application, browser, provider, or live cache was tested. Analytics was unavailable.

Short answer

Protocol rule: a redirect is an HTTP response to the requested URI at that hop. A matching HTTP cache can reuse that stored response while fresh, when stale reuse is permitted, or after successful validation. The response supplies its Location for the next request. This does not cache the later target resource's body as the same response. The next URI may be redirected or cached independently.

Inference for a route migration: an old destination may remain visible if a browser or intermediary reuses an older redirect for the starting URI, a later redirect still points to the old route, or history/application state restores a prior view without a new HTTP request. A new response policy does not recall a copy already stored elsewhere. The final URL alone does not identify which case occurred.

HTTP cache reuse is optional. The RFCs define when storage or reuse is permitted, not that each implementation stores, exposes, retains, or reuses every eligible redirect. See RFC 9111 §2 and §6.

A response for U0 can carry an old U1 target even when U1 has changed. Or U0 can be current while a later hop still carries an old target. Record every response.

Redirect semantics and cacheability

The table covers the redirecting response, normally a GET during navigation. Storage and reuse still depend on the request method, directives, matching rules, and cache implementation. No status promises that a cache will store the response or that a client will follow it in every situation.

Status	Meaning and follow-up method	Baseline cache rule
301 Moved Permanently	Permanent move. A user agent may change POST to GET for the next request; do not assume method preservation.	Heuristically cacheable under RFC 9110 §15.4.2. Without explicit expiration, a cache may choose an implementation-dependent heuristic lifetime.
308 Permanent Redirect	Permanent move. A user agent must not change the request method.	Heuristically cacheable under RFC 9110 §15.4.9; heuristic lifetime is implementation-dependent without explicit expiration.
302 Found	Temporary move. For historical reasons, a user agent may change POST to GET.	Not heuristically cacheable by default. An applicable explicit cacheability signal can allow storage under RFC 9111 §3.
303 See Other	Indirect response; the follow-up is a retrieval (GET or HEAD), not an equivalent URI for the original request.	Not heuristically cacheable by default. Explicit cacheability can allow storage; it is generally not a permanent or temporary route-move code.
307 Temporary Redirect	Temporary move. A user agent must not change the request method.	Not heuristically cacheable by default. An applicable explicit cacheability signal can allow storage under RFC 9111 §3.

Normative status semantics are in RFC 9110 §15.4; see also MDN's redirect guide for a practical summary (guidance, not a substitute for the RFC).

Cacheability detail: RFC 9110 marks 301 and 308 as heuristically cacheable. RFC 9111 permits storage when a status is heuristically cacheable or an applicable explicit signal exists, such as max-age, Expires, or a relevant public directive. For 302, 303, and 307, “not heuristically cacheable by default” does not mean “never storable.” Explicit permission without an explicit lifetime may still leave heuristic freshness in play. Use an explicit max-age or Expires when a bounded lifetime matters; add s-maxage for a separate shared-cache lifetime. no-store prohibits HTTP cache storage for that exchange. no-cache allows storage but requires validation before reuse. See RFC 9111 §3, §4.2.1, §4.2.2, and §5.2.2.

Location identifies the URI reference for a follow-up request. It does not make the target representation the same as the redirect response. A cache's minimum key includes the method and target URI of the request that fetched the stored response; Vary may further constrain reuse. Thus U0 and U1 are separate cache candidates with independent headers and freshness. See RFC 9110 §10.2.2 and RFC 9111 §2.

Why an old target can persist

A fresh redirect remains stored at the first hop. An eligible 301 or 308 may have heuristic freshness; a redirect can also be explicitly stored. A matching request may reuse its earlier Location without contacting the route that now emits the response.
A later hop still points to the old route. The first response may be current while a response at U1 or a later URI is not. The final URL does not identify which earlier Location supplied it.
Validation may reuse the stored response. A 304 permits a cache to reuse its stored response after the specified update. A 304 is not itself a redirect to a newly migrated destination; inspect it together with the matching stored response and validators. See RFC 9110 §15.4.5 and RFC 9111 §4.3.
History or application state may restore a prior view. Browser history, back/forward cache, and application-managed caches are distinct from HTTP cache reuse. Record whether the user navigated, reloaded, or restored history. Do not call a restoration an HTTP redirect-cache hit without request evidence. See RFC 9111 §6.
A policy change does not purge prior copies. New Cache-Control governs the response that emits it; it does not broadcast removal of a stored response with an older policy. HTTP invalidation rules are narrow and do not make an ordinary migrated GET a global purge. no-store on a new response does not erase an older redirect. See RFC 9111 §4.4.

For a stored response reused without validation, RFC 9111 requires an Age value. Age estimates age over cache residence and transit; it does not name the cache that supplied a redirect. Missing or zero age at one observation point does not prove that no earlier hop or application state was involved. See RFC 9111 §4 and §4.2.3.

Bounded policy choices

Use case	Status	Freshness choice	Trade-off and limit
Stable permanent move	301 if method behavior is acceptable; 308 when method preservation matters.	If the route may need rollback, set an explicit lifetime chosen for the recovery window rather than leaving heuristic freshness to each cache. Add validators when future validation is useful.	A previous redirect may stay visible while fresh. No RFC-wide TTL guarantees when every cache evicts it.
Temporary or frequently changing target	302 when legacy POST-to-GET behavior is acceptable; 307 to preserve method/body; 303 only for an intentional retrieval/indirect result.	Set explicit short freshness appropriate to the change rate or require validation with `Cache-Control: no-cache`. Use `s-maxage` for a distinct shared-cache limit. Use `no-store` if the new exchange should not be stored.	Short freshness narrows future reuse; it does not remove an older response. Revalidation requires a reachable validator-aware upstream. `no-store` does not delete previous copies.

These are decision rules, not universal TTL values. Expiration does not change the server's route, and a policy update does not force every client to reload. See RFC 9111 §4.2 and §5.2.2.

Symptom-first checklist

Capture one record per redirect response, not only the final page. Use an authorized, fixed request. No live request was run for this report.

Starting request and navigation state: record the requested URI, method, time, browser/profile, and whether it was typed, clicked, bookmarked, reloaded, or reached through Back/Forward. Redact secrets. Note whether the view was an HTTP navigation or an application restore.
Every leg in order: for each hop, record request URI/method, status, raw Location, resolved URI, then the next request URI/method. This identifies the response carrying the old destination.
Cache metadata per response: capture Cache-Control, Expires, Date, Age, ETag/Last-Modified, Vary, Cache-Status if exposed, and Via or documented named-hop fields. Keep request conditionals and any returned 304 with the stored response.
Response identity: record the redirect response separately from the final response. A response marker may help if the operator provides one. Location is a target, not response identity.
Client state: compare a warm repeat, fresh profile, and revalidation/expired case. State where caches were disabled or cleared. Chrome DevTools' cache controls describe browser cache only, not history or shared caches; see Chrome's Network reference.
Named-hop evidence: RFC 9211 defines a participating cache's optional Cache-Status fields such as hit and fwd. A positive member is that named cache's account for that request. It does not establish what hidden hops or other users saw; a missing member does not prove no cache. See RFC 9211 §§2–2.4.
Stop at the evidence boundary: if only the final URL is known, report the source hop as unknown. If the old Location is visible but no cache-level signal exists, identify the redirect response but leave the supplying cache unknown.

MDN documents Response.redirected and the final Response.url, but those values do not by themselves show each intermediate status and Location. Treat them as final-URL guidance, not chain attribution: MDN Response.redirected.

Expected scenarios; not executed

The cases below are hypotheses for an authorized controlled test, not observations. U0, U1, and U2 are placeholders, not test URLs.

Scenario	Controlled sequence	Expected evidence	Limit
Cold client	Fresh profile requests U0 after migration; capture without following automatically where practical.	Record U0 status/Location and every following response, age/cache status, marker, and time.	Fresh profile reduces local browser state only. Intermediaries, application state, other hosts/paths, or history can remain.
Warm prior redirect	Before migration, populate the same profile with a redirect to old U1; after migration repeat the same URI, method, and variants.	If the stored response remains eligible and is reused, U0's redirect step may still carry old Location U1. Capture named cache status and origin contact if available.	Eligibility does not prove a client or intermediary stored or reused it. This is unobserved.
Expired or revalidated	Expire a controlled entry or validate it with a matching validator; capture the conditionals and full reply.	A 304 means inspect the stored response's Location and validator. A full new 3xx with changed Location is evidence for that responding hop.	A 304 has no new redirect target by itself. An incorrect validator may preserve an old mapping; that is a possibility, not a finding.
Multi-hop chain	Capture U0 → U1 → U2 leg by leg.	The first response whose Location names the old next URI identifies the redirect hop carrying it.	Without named cache evidence, the cache layer supplying the response may remain unknown.

Scope and uncertainty

Normative: RFC 9110 defines status, method, Location, 301/308 heuristic cacheability, and 304 semantics. RFC 9111 defines optional caching, storage/reuse, freshness, validation, invalidation, and the distinction from history/application caches. RFC 9211 defines diagnostic-field semantics for participating caches.
Guidance: MDN and Chrome documentation explain browser/API behavior and Chrome DevTools controls. They are not measurements of this pool or every implementation.
Observed: no route migration, endpoint, browser, cache, provider, origin, or analytics result was available or used. All scenario rows above are expected and unexecuted.
Unknown: status and policy for any real route; which clients or caches stored prior redirects; heuristic lifetime assigned by a given cache; whether history or application state was involved; actual user impact; and provider-specific purge behavior.

Source and retrieval ledger

All material below was accessed on 2026-10-01 06:17 UTC. RFCs are primary normative sources; MDN and Chrome are implementation guidance. None is evidence of this pool's live deployment.

RFC 9110 — HTTP Semantics, §§10.2.2, 15.4.1–15.4.5, 15.4.8–15.4.9. Normative. Location and redirect processing, status/method semantics, heuristic cacheability, and 304 meaning.
RFC 9111 — HTTP Caching, §§2–4, 4.2.1–4.2.4, 4.3–4.3.4, 4.4, 5.2.2, 6. Normative. Optional caches, storage and keys, reuse/freshness, validation, invalidation, age, and history/application-cache distinction.
RFC 9211 — The Cache-Status HTTP Response Header Field, §§2–2.4. Normative field semantics. Participating cache identifiers and optional hit, fwd, fwd-status, and ttl parameters; not every cache exposes the field.
MDN — Redirections in HTTP. Developer guidance. Practical status/method summary checked against RFC 9110.
MDN — Response.redirected. Web API guidance. Redirect indication and final URL; not per-hop cache proof.
Chrome DevTools — Network features reference. Chrome-specific guidance. Request log, Preserve log, and browser-cache controls; not exercised.

Related pool procedures: serving-layer attribution and the deployment and incident runbook. This report adds redirect-response semantics and does not replace those general procedures.