fix: deny the page cache on the header alone - #5
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 1.0.x #5 +/- ##
==========================================
+ Coverage 85.80% 85.86% +0.06%
==========================================
Files 9 9
Lines 486 481 -5
==========================================
- Hits 417 413 -4
+ Misses 69 68 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
Important Review skippedNo new commits to review since the last review. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
💤 Files with no reviewable changes (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthrough
ChangesConsumer cache policy
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to The change prevents header-identified requests from using the internal page cache while preserving correctly varying dynamic caching; no actionable merge-blocking risk remains after normal checks and review. Sequence Diagram(s)sequenceDiagram
participant Client
participant DenyOnConsumerHeader
participant SettingsEndpoint
participant ServerCache
Client->>DenyOnConsumerHeader: Request settings path with X-Consumer-ID
DenyOnConsumerHeader-->>Client: DENY page-cache reuse
Client->>SettingsEndpoint: Fetch consumer-specific settings
SettingsEndpoint->>ServerCache: Store response without shared reuse
Client->>SettingsEndpoint: Fetch without X-Consumer-ID
SettingsEndpoint->>ServerCache: Read anonymous response
ServerCache-->>Client: Return anonymous settings
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…ot be matched before routing
|
@coderabbitai review |
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai review |
|
Summary
The page cache request policy compared the request path to the JSON:API base path with
===, so any path prefix defeated it. Behind a language prefix, the internal page cache stored a consumer-specific response under a URL every consumer shares, and served it to requests that name no consumer.A first pass switched to a suffix match, and review found that was still not enough: a trailing slash, upper case and percent-encoding all leak too, because the router lowercases, decodes, trims slashes and follows aliases before it matches, while a request policy runs before routing and only sees the raw path. There is no reliable way to name "the settings resource" at that point, and each miss is a cached response served to the wrong consumer.
Changes
X-Consumer-IDnever uses the internal page cache, on any path. It keeps the dynamic page cache, which varies on the header correctly. This is the shape the policy had before the round-2 review narrowed it to the settings path.languageinstalled. For each spelling, requests the endpoint as a header-identified consumer, then anonymously, and asserts the anonymous response carries the global values and"consumer": null. The percent-encoded spelling is unit-only, the test client re-encodes the percent sign.Verified live on every spelling: all now answer
X-Drupal-Cache: UNCACHEABLE (request policy).Summary by CodeRabbit
Bug Fixes
Tests