Resource cache stores no first-party assets — the blocker is `Set-Cookie` on every asset, not `Vary: Origin`

Inizia individuando getCachePolicy e tracciando il modo in cui vengono gestiti gli header Vary ripetuti e le risposte Set-Cookie. Riproduci i casi Vary uniti da newline descritti qui, quindi determina la policy prevista per i cookie sicuri e gli asset statici; il completamento dovrebbe includere la copertura del comportamento di parsing e cacheability senza indebolire le garanzie di sicurezza dei cookie.

Measured 2026-09-16: the blocker is Set-Cookie, not Vary

Re-measured against the live storefront with the deployed fleet config, counting every first-party
script/stylesheet response and the reason the cache would refuse each one:

The only Vary values present on first-party assets are "" and "Accept-Encoding" — both already
accepted. Not one response carries Vary: Origin.

What refuses them is the CDN stamping cookies on static asset responses:

AKA_GEO                   on 81 of 81 responses
AKA_SNB_STP               on 81 of 81
vpusq                     on 47 of 81
ksa-app-measurement-beta  on  7 of 81

and getCachePolicy refuses any response with Set-Cookie, before it ever looks at Vary:

if (headers['set-cookie']) return { cacheable: false, ttlMs: 0 };

So the fix this issue proposed — allow origin in the Vary allowlist, and key the entry by the
request's Origin — would cache one additional 0.06 MB file on the home page and nothing at all on a
product page. The original diagnosis does not hold on this deployment today.

This also confirms what c515d76's commit message reported in passing and this issue previously
argued against: "same-origin assets set cookies and are therefore never cached, so only third-party
CDN responses are exposed." That is exactly what the cache holds — see #108, measured the same day:
69 entries, 100% third-party, zero first-party.

What the real lever is, and what it is worth

If first-party bundles are to be cached, the thing to change is the Set-Cookie rule, not the Vary
allowlist. That rule is a correctness rule — a response that sets cookies cannot be shared between
renders — so it cannot simply be dropped. The defensible shape is an allowlist of cookie names known
to carry no per-render state (AKA_GEO and AKA_SNB_STP are edge geo/routing cookies stamped on
every response, identical for every render from a given pod), with the cookie stripped from the
stored copy.

Sizing, and the caveat that decides whether it is worth doing: ~53–81 requests and ~5.3–5.6 MB per
render. But 76 of 81 of those responses are edge HITs (server-timing: cdn-cache; desc=HIT), so
they are served by the CDN, not by the origin. Caching them locally would cut CDN egress and render-
pod network, not origin load — which means this is a cost/bandwidth lever, not a lever on the
origin-load goal it has previously been grouped with.

The cheaper fix may not be ours at all: asking the CDN to stop setting cookies on static asset
responses removes the blocker without any code, and is worth pricing against the allowlist.

Still true, and worth keeping

The Vary parser has a real bug even though it is not the blocker here. A response that sends
Vary twice — as two header lines, semantically identical to one comma-joined header — reaches us as
the two values joined with a newline, so splitting on , alone leaves "accept-encoding\norigin"
as a single unrecognised token. vary === '*' is an exact comparison that a newline-joined value
slips past for the same reason; vary.includes('*') is the safer test.

That newline-join has now been hit three times in production, twice on the replay path rather than the
policy path (9a401f8, c515d76 — both v1.24.0, both silent failures). Whoever touches this code
should treat the \n-joined form as the normal case, not an edge case.

Why the original measurement said otherwise

Left here so the discrepancy is not re-investigated: this issue's first measurement reported 117
first-party responses admitted once the split was /[,\s]+/ (against 62 before), which cannot be
reconciled with 81 of 81 now carrying Set-Cookie. Either the site began setting these cookies on
asset responses between 2026-08-18 and now, or the original count was taken over a different host set.
The current numbers are reproducible on both page types and are the ones to build against.