Why a missing JavaScript file can stay missing after you deploy it

I built cachewhy around a small but costly HTTP cache mistake. Imagine a request for /missing.js that returns 404 with Cache-Control: public, max-age=2678400 . That lifetime is 31 days. A browser may reuse the missing response even after the file is deployed. Changing the server header helps new responses, but it does not automatically erase a copy the browser already holds. The command fetches a URL and explains the response that came back. It prints one row for a private browser cache and one for a shared cache, along with the header that drove the result. It follows redirects with a bound and cancels the response body after reading headers. The local fixture in the repository serves both the long lived 404 and a new response with no-store . npx --yes github:Arthur031221/cachewhy https://example.com The report uses http-cache-semantics for storage and freshness calculations, then accounts for Age, Date, and request delay. It distinguishes no-store from no-cache : the former prevents storing a new response, while the latter allows storage but requires validation before reuse. s-maxage changes the shared cache row. An ETag or Last-Modified value can help with revalidation once a response is stale. A remote probe has important limits. It cannot tell what is already in a particular browser's cache, whether a service worker intercepts the request, which cache key a CDN chose, or whether a provider rule overrides the visible headers. A CDN might serve the probe from its own cache. The output is a reading of the response received now, not a replay of every user's experience. I included tests for a cached 404, no-store, private responses, s-maxage, Age, stale revalidation, redirects, and timeouts. The fixture makes the main failure visible without depending on a live website. It is useful for debugging a specific URL and for attaching a compact explanation to an issue. The repository is MIT licensed: https://github.com/Arthur031221/cachewhy. I would value examples of real response headers where the explanation is too terse or reaches beyond what those headers establish. Top comments (0)