2026-09-04 · 6 min read · Rahul Chitturi
- http
- caching
- debugging
A 304 Not Modified response has no new representation body. It tells a cache to reuse a stored response after validating it with an ETag or modification date, so the visible stale data may come from an older cache entry rather than the 304 itself.
Unexpected results often appear when a deployment changes content without changing its validator, a proxy revalidates the wrong cache variant, or client code treats conditional headers as ordinary application metadata.
Trace one representation end to end
Record the request URL, method, relevant request headers, response status, ETag, Last-Modified, Vary, cache controls, and the age and identity of the body finally displayed. Inspect the browser, CDN, reverse proxy, and origin separately.
- Confirm the cache key includes every intended representation dimension
- Compare strong and weak validator behavior
- Check whether compression or localization changes the selected variant
- Verify a 304 updates only metadata allowed by the HTTP contract
Regenerate validators consistently
An ETag should describe the representation selected for that request according to a stable server policy. If middleware transforms content, decide whether the origin or the final delivery layer owns the validator and prevent both from making conflicting decisions.
Do not solve stale content by disabling caching everywhere. Fix validator generation, cache keys, purge behavior, or revalidation rules while retaining explicit freshness for assets that can be cached safely.
A Flashman workflow
Use the URL tool to compare request targets, hash to label synthetic representation bytes, timestamp converter to align cache events, and diff to review headers and decoded bodies across hops.
Test cold and warm caches, changed and unchanged bodies, weak validators, compression variants, localization, authorization boundaries, purge events, and clients with their own offline caches.