Cache Header Lab
Place an initial GET/200 response and a later GET in the same cache. Calculate whether storage and reuse are possible, how Vary and Age affect freshness, and which conditional headers a validation request would carry.
Key features
- Distinguish no-store, private and Authorization storage rules for private or shared caches
- Calculate age and freshness from Date, Age, max-age, s-maxage and Expires
- Select a reusable representation with URL and Vary request headers
- Generate ETag or Last-Modified conditional headers and check a hypothetical 304 validator
- Run fixed fresh, stale, no-store and Vary mismatch examples without network requests
How to use
- Enter initial GET headers, 200 response headers and the UTC time the response arrived.
- Select a private or shared cache, elapsed seconds, whether the URL is the same and later GET headers.
- Optionally assume a 304 or 200 origin response and enter the 304 validator headers.
- Run the simulation and inspect storage, freshness, conditional headers and the timeline.
Use cases
- See why max-age=60 becomes stale at exactly 60 seconds
- Estimate remaining freshness when an upstream Age is already 20 seconds
- Review why a shared cache cannot store private or unpermitted Authorization responses
- Reproduce a cache miss when Accept-Language changes under Vary
Frequently asked questions
Does this send a real request?
No. It calculates only the supplied headers and times in browser memory. It cannot confirm CDN configuration, service workers, browser policy or a real origin response.
Are no-cache and no-store equivalent?
No. In this model no-store prevents storage. A response with no-cache can be stored but needs origin validation before reuse. A later no-cache request also requires validation even for a fresh stored response.
How are Age and Date combined?
Initial age at receipt is the larger of the Age field and apparent age from Date to receipt time. Elapsed seconds are then added. Network transit and detailed multi-cache timing are assumed to be zero.
Does a displayed 304 prove that the origin content is unchanged?
No. You choose a hypothetical 304, and reuse is shown only if its ETag or Last-Modified matches the stored response. The tool does not contact the origin or merge all 304 metadata.
Which cache behavior is excluded?
Only one GET/200 and one later GET are modeled. Heuristic freshness, stale extensions, Range/206, redirects, preexisting conditional request fields, browser partitioning and post-304 metadata merging are excluded. Unsupported Cache-Control directives are rejected.
Privacy
Input is processed only in this browser tab's memory; no URL is fetched and no header is uploaded or saved. Avoid real Authorization or personal values. A conditional request preview can show an ETag you entered.
Comments & questions