CacheHandler.onResponseStart deletes only the request URI's entry on a 2xx/3xx response to an
unsafe method (lib/handler/cache-handler.js:109-122). RFC 9111 §4.4 also says caches SHOULD
invalidate the URIs in the response's Location and Content-Location fields when they share
the request URI's origin — the classic POST /collection → 201 Location: /collection/123 flow
currently leaves a previously cached GET /collection/123 stale.
Repro: cache GET /target; POST /src returning Location: <origin>/target; GET /target
again → observed: served from cache (undici 8.7.0/main, Node 22); expected: refetched.
Fix sketch: in the invalidation branch, parse Location/Content-Location, same-origin check
against cacheKey.origin, and store.delete({origin, path, method: 'GET'}) for each (both
bundled stores key deletion on origin+path, so this is ~25-40 LOC + tests).
Found during an agent-assisted HTTP-caching review for @jeswr; every claim reproduced on undici 8.6.0 (repo) and 8.7.0 (npm) on Node 22.23.1. Fix PR to follow.
CacheHandler.onResponseStartdeletes only the request URI's entry on a 2xx/3xx response to anunsafe method (lib/handler/cache-handler.js:109-122). RFC 9111 §4.4 also says caches SHOULD
invalidate the URIs in the response's
LocationandContent-Locationfields when they sharethe request URI's origin — the classic
POST /collection→201 Location: /collection/123flowcurrently leaves a previously cached
GET /collection/123stale.Repro: cache
GET /target;POST /srcreturningLocation: <origin>/target;GET /targetagain → observed: served from cache (undici 8.7.0/main, Node 22); expected: refetched.
Fix sketch: in the invalidation branch, parse
Location/Content-Location, same-origin checkagainst
cacheKey.origin, andstore.delete({origin, path, method: 'GET'})for each (bothbundled stores key deletion on origin+path, so this is ~25-40 LOC + tests).
Found during an agent-assisted HTTP-caching review for @jeswr; every claim reproduced on undici 8.6.0 (repo) and 8.7.0 (npm) on Node 22.23.1. Fix PR to follow.