demo · v138

Cart mutation invalidation

A real Shopify-style pattern: every cart mutation endpoint returns Clear-Site-Data: "prefetchCache", "prerenderCache". Watch what happens to speculative loads of /checkout when the cart changes underneath them.

What this simulates. A miniature storefront. The two pills below the cart show whether the browser still holds a prefetched or prerendered copy of the checkout page. Add or remove items: the default simulated /cart/add response carries Clear-Site-Data: "prefetchCache", "prerenderCache", which dumps both speculative caches so the next nav re-fetches a fresh cart total. Switch the response mode to isolate each token.

CART · / cart

response clears

SPECULATIVE LOADS · / checkout

prefetch: idle prerender: idle

not cleared by these tokens

the response that did the work

POST /cart/add HTTP/1.1
Content-Type: application/x-www-form-urlencoded

id=hat&quantity=1

HTTP/1.1 200 OK
Content-Type: application/json
Clear-Site-Data: "prefetchCache", "prerenderCache"

{ "ok": true, "items": 3 }

The header is scoped to the response origin. "cache", "cookies", and "storage" are deliberately omitted — we only want to drop the speculative copies of /checkout that were warmed against an out-of-date cart. The user's session cookie, auth, and HTTP cache are preserved.

when to clear which

Per the spec discussion: clear "prerenderCache" only when the rendered page has stale state but the prefetched HTML is still good (SPA re-fetches data on display). Clear "prefetchCache" when the HTML itself is stale. Clear both when the document and its derived rendered state are both wrong — the cart-mutation case. Use the response-mode radios above to see each tier survive or clear independently.

see also