fix(cache): add response delay to corrected age value - #5659
Open
RaphaelFakhri wants to merge 1 commit into
Open
fix(cache): add response delay to corrected age value#5659RaphaelFakhri wants to merge 1 commit into
RaphaelFakhri wants to merge 1 commit into
Conversation
RFC 9111 section 4.2.3 computes a stored response's initial age from response_delay = response_time - request_time corrected_age_value = age_value + response_delay corrected_initial_age = max(apparent_age, corrected_age_value) CacheHandler captured a single timestamp at response-header time and computed max(apparentAge, resAge), so response_delay was always zero and corrected_age_value reduced to the bare Age the origin sent. The delay matters because the Age an origin reports is already out of date by the time the response finishes arriving. Dropping it stores a slow response as younger than it is, and a response near its freshness boundary is then served after it has actually expired. Against an origin reporting Age: 100 that takes 3 seconds to respond, the cache served an age of 100 where the RFC requires at least 103. onRequestStart now records the request time, and the correction adds the resulting delay. The field resets on every onRequestStart so a retried or redirected request measures its own delay. A missing Age is treated as age_value = 0 per the same section, so a slow response without one is still aged by the delay.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RFC 9111 section 4.2.3 defines a stored response's initial age as:
CacheHandlercaptured a single timestamp at response-header time and computedmax(apparentAge, resAge). There is norequest_time, soresponse_delaywas alwayszero and the
corrected_age_valueterm reduced to the bareAgethe origin sent.The delay matters because the Age an origin reports is already out of date by the time the
response finishes arriving. Dropping it stores a slow response as younger than it is, and a
response near its freshness boundary is then served after it has actually expired.
Reproduction
Origin sends
Cache-Control: public, max-age=600,Age: 100, and delays 3 seconds:The understatement scales with upstream latency, so it is largest exactly where caching
matters most.
Change
onRequestStartrecords the request time, andcorrected_age_valueadds the resultingdelay. The field is reset on every
onRequestStart, so a retried or redirected requestmeasures its own delay rather than the first attempt's.
Tests
test/interceptors/cache-corrected-age.js, three cases:Ageheader is aged by at most the response delay itself, sincesection 4.2.3 treats a missing
Ageasage_value = 0max-ageis not reusedCases 1 and 3 fail on main and pass with this change. Case 2 passes on both and is there to
pin the bound on responses that carry no
Age.npm run test:cache-interceptorpasses 76/76, and lint is clean.