Locating the serving layer

Context only: HTTP caching basics baseline, validator follow-up, and cache-key/privacy follow-up. This report does not repeat their freshness, validator-precedence, or key/privacy tutorials.

1 · Layer boundaries

RFC 9111 §6 explicitly separates browser history and other application caching from HTTP-cache requirements. The Fetch Standard’s layer description likewise distinguishes API, service-worker, and network/cache layers. A worker calling fetch() does not make the eventual response an HTTP-cache hit; it only means another layer still needs to be inspected.

2 · Controlled path (planned, not executed)

Exact lab target and topology

Use a reserved, non-production test name and synthetic data only:

Client:  GET https://probe.example.test/layer-probe
         method = GET; target URI exactly /layer-probe; Host/SNI = probe.example.test
Edge path: client -> named test reverse proxy/cache `edge-test` -> origin
Direct control: same URL/Host/SNI, resolved to the authorized origin address with --resolve;
               no edge hop
Redirect policy: expected 200 with no redirect; do not follow an unexpected 3xx in the
                 attribution run; save status and Location, then test the new target separately.
Client state: no cookies, no Authorization, no extensions, fixed Accept, no query string,
             no request-body variation; use a fresh browser profile for cold-client runs.

probe.example.test and ORIGIN_IP below are placeholders for an operator’s authorized lab; they were not contacted. The origin must expose an out-of-band phase switch or deployment toggle. It must not derive the marker from the URL, a cookie, an identity, or a request header. For phase A and then phase B, keep method, URI, host, redirect behavior, response policy, and response shape constant; change only the origin phase.

The controlled origin response should contain a redacted test marker such as X-Variant-Marker: A (then B) and a body/log record such as phase=A; origin_counter=17; request_id=<redacted>. The counter is a server-side observation, not a user-visible identity. Log, in UTC, the request ID, method, host, exact path, response phase, status, and counter; never log credentials or personal data. The test response may use a fixed, explicitly documented public test policy such as Cache-Control: public, max-age=60; capture it but do not treat policy as proof that any layer stored the response.

Capture, at the intended hop and in the direct-origin control, the status/redirect chain and the response fields Cache-Control, Age, Cache-Status, Via, and X-Variant-Marker. Also save the body marker, origin counter/log line, client state, UTC timestamp, and edge/POP identifier if the deployment documents one. A provider-specific field is useful only with that provider’s current documentation; this run selected no vendor field.

Warm-up and comparison order

1. Clear the named edge test cache or record a known cold key; reset the origin counter and set phase A.
2. Request the direct-origin control once. Record that it returns A and increments the origin counter; this does not warm the edge.
3. Request the edge URL once from a normal client. Record the cold response, edge diagnostics, and the matching origin log entry. This is the only warm-up for the edge key.
4. Flip only the origin phase to B out of band. Do not change URL, host, method, redirects, policy, or client inputs.
5. Repeat the edge URL in the same client. Record whether a browser request occurred, worker state, marker, all captured headers, and the origin counter.
6. Repeat from a fresh client/profile with no service-worker registration. This removes the first client’s browser HTTP cache/history state but intentionally does not clear the edge.
7. Request the same URL with a direct-origin route using the same Host/SNI. Record B and the origin counter. Compare this control only with the edge response from the same phase and timestamp.
8. Run the service-worker and history/bfcache subtests below as separate runs, after clearing their own state. Do not combine an uncontrolled worker, back navigation, and an edge warm-up in one A/B test.

Unexecuted direct-client template

curl is absent here. If an authorized lab supplies it, these are copyable templates; replace ORIGIN_IP and the lab phase switch, and do not print bodies containing anything sensitive.

URL='https://probe.example.test/layer-probe'
ORIGIN_IP='203.0.113.10'                 # authorized lab address only
OUT="/tmp/layer-probe-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$OUT"

# R1: cold edge, origin phase A (no redirect following)
curl -sS --noproxy '*' --max-redirs 0 -D "$OUT/edge-A.headers" -o "$OUT/edge-A.body" "$URL"

# Flip only the origin phase from A to B, then R2: same edge client/URL.
curl -sS --noproxy '*' --max-redirs 0 -D "$OUT/edge-B-repeat.headers" \
  -o "$OUT/edge-B-repeat.body" "$URL"

# R3: direct origin, same URL and Host/SNI, bypassing the edge and any proxy.
curl -sS --noproxy '*' --resolve "probe.example.test:443:$ORIGIN_IP" --max-redirs 0 \
  -D "$OUT/origin-B.headers" -o "$OUT/origin-B.body" "$URL"

# Print only non-sensitive status/diagnostic fields.
awk 'BEGIN{IGNORECASE=1} /^(HTTP\/|cache-control:|age:|cache-status:|via:|x-variant-marker:|location:)/ {print FILENAME ": " $0}' \
  "$OUT"/*.headers
printf '\nBody hashes:\n'; sha256sum "$OUT"/*.body

No live response, marker, Age, Cache-Status, Via, or origin counter was captured by this run. A direct client is not a browser and does not reproduce browser history, service-worker control, browser cache partitioning, or the user’s proxy path.

3 · Expected outcome matrix Not measurements

The following is the deterministic expected interpretation of the controlled path. It is not a claim about any particular CDN or browser.

4 · Required comparison matrix

5 · Reader-ready decision procedure

What this proves: a positive, instrumented observation can identify a layer for one client, URL, request, time, and topology; a controlled origin log can establish receipt; a named Cache-Status can establish the named cache’s own report; a pageshow.persisted/lifecycle record can separate history restoration from an HTTP-cache request; a worker log can establish its own Cache API decision.

What this does not prove: a missing request is automatically a browser HTTP-cache hit; a missing Age/Cache-Status means origin contact; a DevTools source label is a cross-browser standard; a direct curl path equals a browser/CDN path; one clean A/B excludes leakage; a 200, 304, old body, or Via alone identifies the producer; a marker absent from a response means the marker was not stripped or rewritten.

6 · Small diagnostic/probe checklist

• Use synthetic A/B markers and a server-side counter; never put credentials or personal data in the probe body, URL, logs, or headers.
• Freeze method, exact target URI, host/SNI, redirects, request headers, cookies/auth state, client profile, and POP as far as the deployment permits.
• Record whether a request occurred before interpreting a browser source label; keep back/forward, reload, worker, and HTTP-cache cases as separate tests.
• At the intended intermediary, capture Cache-Status, Age, Via, status, redirect chain, marker, and any documented edge/POP field.
• Correlate the edge result with a direct-origin route and UTC origin counter/log, but do not treat the direct route as the production topology.
• Run serialized and concurrent cases separately; request collapsing can make an origin count lower than client request count without proving a hit.
• Repeat at a fresh client and, where possible, another POP or partition. A clean result at one path does not prove the absence of leakage elsewhere.

7 · Claim classification

8 · Header-example check

All concrete header examples in this report were checked against the pool’s primary-documentation workflow on 16 Sep 2026 UTC. Direction and context are explicit.

The marker values and edge-test name are local test labels, not vendor claims. The Cache-Status examples use the RFC’s standardized parameter meanings; a production field is useful only when emitted by the intended cache and retained through the path.

9 · Limits and unresolved edge cases

• Absent Age or Cache-Status: RFC 9111 requires Age when a stored response is used without validation, but expressly says lack of Age does not imply origin contact. RFC 9211 says caches decide when to add Cache-Status; omission is not evidence of absence.
• DevTools “Disable cache”: the Chrome control disables the browser cache while DevTools is open; it changes the experiment. It is not a global bypass for service workers, Cache API, history/bfcache, an intermediary, another profile, or another POP.
• Service-worker/Cache API keys: named Cache objects are not the HTTP cache. Their Cache.match request/options and script policy can select a response independently; a worker’s delegated fetch() can then hit another layer.
• History/bfcache: a no-request old display, even with an old marker, is not HTTP-cache evidence. It can be a restored document/state; the pageshow signal identifies a browser lifecycle path, not the original response source.
• Direct-client topology: direct curl, a fresh browser, and a user’s browser can differ in DNS, proxy, TLS termination, HTTP version, cookies/auth state, cache partition, connection reuse, and POP. Same URL text is not the same path.
• Redirects: a cached redirect or a service-worker response can move the effective request to a different URL/host. The planned run expects no redirect; any 3xx must be recorded as its own response and the follow-up target tested separately.
• Partitioning: browsers and managed intermediaries can partition storage by site, top-level context, tenant, or POP. A fresh profile or one client does not test every partition.
• Request collapsing: concurrent requests can share one forward. An origin counter lower than client request count does not by itself mean a hit; inspect a named collapsed diagnostic if available and run serialized and concurrent cases separately.
• Other POPs/hops: a positive edge observation applies only to the named cache instance/path. A clean result at one POP cannot rule out an old entry at another POP, an enterprise proxy, or a different route.
• One A/B test cannot prove absence of leakage: a marker mismatch is a strong failure for the exact tested path. A correct B response only says that this one key, client state, time, and topology produced B. It does not test alternate query/redirect/resource keys, concurrent races, cache partitions, other POPs, or uninstrumented layers.
• Marker integrity: a custom marker may be removed, rewritten, or generated by an application layer. Preserve a body marker and origin log, and treat marker absence as unknown rather than proof of a miss.
• Worker/lifecycle races: registration activation, clients.claim(), a page becoming controlled, cache population, reload, and back/forward restoration are asynchronous. Record registration state and run each subtest from a fresh, known state.

Sources and retrieval ledger

Retrieved/cross-checked 16 Sep 2026 UTC; primary standards are listed first. No vendor documentation was used for a universal claim. A named provider’s field/configuration should be added only when that provider and deployment are identified.

Primary standards

• RFC 9111 — HTTP Caching §2, §4, §4.2.3, §5.1, §6.
• RFC 9211 — Cache-Status §2, especially §§2.1–2.6.
• RFC 9110 — HTTP Semantics §7.6.3, Via.
• Fetch Living Standard — layer division and HTTP-network-or-cache fetch, retrieved as the 2026-09-02 living revision shown by the source.
• Service Workers Nightly — §4.5 Handle Fetch and §5 Caches / §5.2 lifetimes.
• HTML Living Standard — §7.4.3 reloading and traversing, §7.4.6.5 persisted history entry state, §7.2.7.6 PageTransitionEvent, and document lifecycle/bfcache.

Browser-facing cross-checks (Chrome-specific)

• Chrome DevTools Network panel: logging requests and request columns.
• Chrome DevTools Network features reference: Disable cache, Clear browser cache, service-worker timing phases, and sanitized HAR handling.
• Chrome DevTools Application panel: service workers, Cache Storage, storage, and bfcache tools.
• Chrome DevTools bfcache test: bfcache is distinct from browser/HTTP cache and how Chrome tests it.
• MDN HTTP caching: developer-facing cross-check for private/shared and browser/intermediary terminology; not used to override the RFCs.
• MDN Cache-Control: developer-facing cross-check for the test policy; not a layer-attribution proof.

Remaining questions

• Which authorized CDN/reverse-proxy product and POP topology should supply the named intermediary in the next live run?
• Can that deployment expose RFC 9211 Cache-Status and an origin request ID without exposing credentials or personal data?
• Which browser/version is in scope for the first browser capture, and can its DevTools export be sanitized?
• Does the target application install a worker, use navigation preload, or prerender pages that require separate control cases?

← Serving-layer diagnosis · Report shelf · Research history