| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
CacheHandler.onResponseStart only deleted the request URI's cache entry
on a successful (2xx/3xx) response to an unsafe method. RFC 9111 section
4.4 also says caches SHOULD invalidate the URIs in the response's
Location and Content-Location header fields when they share the request
URI's origin, so the classic "POST /collection -> 201 Location:
/collection/123" flow left a previously cached "GET /collection/123"
stale.
Repro (before): cache GET /target; POST /src returning "Location:
<origin>/target"; GET /target again is served from cache (1 origin hit).
After: the second GET /target is refetched (2 origin hits). Only
same-origin URIs are invalidated, per the RFC's security note.
This also turns the eight invalidate-{POST,PUT,DELETE,M-SEARCH}-{location,cl}
tests of the mnot cache-tests conformance suite from failed-optional
into passing in every test environment (220 -> 228 passed, 58 -> 50
failed-optional, 0 required failures).
Fixes nodejs#5509
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
lgtm
Sorry, something went wrong.
Codecov Report❌ Patch coverage is 92.45283% with 4 lines in your changes missing coverage. Please review.
@@ Coverage Diff @@
## main #5514 +/- ##
==========================================
- Coverage 93.44% 93.44% -0.01%
==========================================
Files 110 110
Lines 37328 37381 +53
==========================================
+ Hits 34881 34930 +49
- Misses 2447 2451 +4 ☔ View full report in Codecov by Harness.
|
Sorry, something went wrong.
…4/ubuntu) 'MockAgent - handle delays to simulate work' asserts elapsed >= 50ms on a 50ms setTimeout and measured 49ms (classic timer early-fire/rounding). Passes 10/10 locally on this branch and 15/15 on main; this PR only touches lib/handler/cache-handler.js, which MockAgent never loads. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
| Back | FazBrowse Home | New Git URL |
Fixes #5509
What
CacheHandler.onResponseStart deleted only the request URI's entry on a 2xx/3xx response to an unsafe method. RFC 9111 §4.4 also says caches SHOULD invalidate the URIs in the response's Location and Content-Location header fields when they share the request URI's origin — so the classic POST /collection → 201 Location: /collection/123 flow left a previously cached GET /collection/123 stale.
This adds a #deleteLocationHeaderEntries step to the existing invalidation branch: it resolves each header value against the request URI (relative references included), applies the same-origin check from the RFC's security note (invalidating cross-origin URIs could be abused for cache poisoning), and deletes the matching entry from the store.
Repro / evidence
Origin: GET /target served with Cache-Control: public, s-maxage=100; POST /src answers 201 with Location: <origin>/target.
Before (main @ cb4c2f1, Node 22):
After: step 3 goes back to the origin (2 hits), for both Location and Content-Location, absolute and relative forms. A Location pointing at another origin (even with a path that collides with a cached entry) does not invalidate — covered by the added test in test/interceptors/cache.js.
Tests
Notes
🤖 Generated with Claude Code