Served From Cache

## Why it matters

This flag breaks the most common redirect debugging deadlock: "I fixed the redirect but it still happens." Your browser is replaying a cached redirect; the server has moved on. Or the opposite: "It works on my machine" because your cache is old. Knowing whether a hop touched the network tells you if you're fixing the server or your own cache. Different solutions.

From-cache is not an error; it's working caching. Your browser is following the server's Cache-Control directive correctly. For auditing, though, it's old information. You need to know if the response shows what the server does now, or what it did last time.

## How it works

When a request would fetch a URL, the browser checks its HTTP cache first. If the cached response is still fresh (according to Cache-Control and expiration headers), the browser uses it without touching the network.

Chrome's DevTools network panel shows "from disk cache" or "from memory cache". That's what Chrome reports in the request metadata. Scalpel surfaces this information so you can see which hops in your chain are replays and which actually hit the network.

A cached redirect is not invalid. The browser is following the server's own instructions (the Cache-Control header told it to cache for N seconds). But on a second visit, the server may have changed the redirect, and the browser does not know because it never asked.

## What does not matter

A from-cache hop does not mean the server is down. It means the browser has a fresh answer stored locally and trusts it, which is correct caching behaviour. A from-cache hop can still represent the server's current behaviour if the cache was recently populated and nothing has changed on the server.

The cache tiers (memory vs disk) matter for persistence across browser restarts, but both are "from cache" for audit purposes. A memory-cached redirect is just as stale as a disk-cached one if the server has changed.

## Code example

The same chain traced twice. First visit (network):

GET https://example.com/old-url HTTP/1.1

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-url
Cache-Control: max-age=3600

GET https://example.com/new-url HTTP/1.1

HTTP/1.1 200 OK
Copy

Second visit, minutes later (cached):

GET https://example.com/old-url HTTP/1.1
(browser does not send this; the 301 is served from cache)
-> 301 from disk cache

GET https://example.com/new-url HTTP/1.1
HTTP/1.1 200 OK
Copy

In the second trace, the first hop is marked from-cache. If the server has changed the redirect in the meantime, the cached version is now stale and the user is following old instructions.

DevTools screenshot showing "from disk cache" status:

Request URL: https://example.com/old-url
Status: 301 from disk cache
Copy

## How Scalpel shows it

Scalpel Redirects flags any hop that Chrome reports as cached. That badge tells you the response is a replay, not a fresh network hit. When you've fixed something on the server, a from-cache badge on the same hop proves your fix is live, just not yet visible to this browser's cache.

## Workflow: comparing cached vs live

To confirm the server's current behaviour differs from your cached chain:

1. Record the chain normally (you will likely see cached hops).
2. Hard-reload the page (Shift+Ctrl+R or Shift+Cmd+R) to bypass the cache.
3. Record the chain again.
4. Export both and compare.

The difference tells you whether the server has changed or your cache was correct all along.