Minor cleanups in HttpCache, especially centralize Date header fixup #22033
Conversation
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
This makes use of the fact that all requests to the backend go through this method. Backends should provide a Date header indicating the time at which the response was generated. But if (for whatever reason) they don't, we'll keep the time at which the response was received as the response Date. To-Do: Review the RFC; it probably suggests using the time at which the request was initiated, not the time the response was received.
|
Thanks for your contribution. 😄 Is it possible to add a test case that exposes this issue? |
|
I will add that once I have found/understood it. For now, this PR is intended as a refactoring that helps (at least me) to better follow execution paths through the |
|
#19390 added a check in the |
|
merging into master as this is not really a bug fix |
|
Thank you @mpdude. |
fabpot
added a commit
that referenced
this pull request
Mar 22, 2017
…header fixup (mpdude) This PR was submitted for the 2.8 branch but it was merged into the 3.3-dev branch instead (closes #22033). Discussion ---------- Minor cleanups in HttpCache, especially centralize Date header fixup | Q | A | ------------- | --- | Branch? | 2.8 | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | | License | MIT | Doc PR | I am trying to hunt some issues where the HTTP cache does not revalidate responses (or does not use a cached response?) in the edge case of having `s-maxage = 0` and possibly a backend that's slow to respond. I don't see yet what exactly my problem is there, but it must somehow be related with the `Date` header handling and/or age calculations in the `HTTPCache`. As a first step, I'd like to suggest this cleanup in `HTTPCache`. Especially, it would be helpful if we could make sure that there is just one place where we set the `Date` header if the backend does not send one (?). This makes sure we always have this header to base later age calculations on it. Commits ------- 30639c6 Minor cleanups in HttpCache, especially centralize Date header fixup
fabpot
added a commit
that referenced
this pull request
Mar 22, 2017
… (first?) test for it (mpdude) This PR was squashed before being merged into the 3.3-dev branch (closes #22043). Discussion ---------- Refactor stale-while-revalidate code in HttpCache, add a (first?) test for it | Q | A | ------------- | --- | Branch? | 2.8 | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | | License | MIT | Doc PR | I came up with this while trying to hunt a production bug related to handling of stale cache entries under the condition of a busy backend (also see #22033). It's just a refactoring to make the code more readable plus a new test. Commits ------- b14057c Refactor stale-while-revalidate code in HttpCache, add a (first?) test for it
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.
I am trying to hunt some issues where the HTTP cache does not revalidate responses (or does not use a cached response?) in the edge case of having
s-maxage = 0and possibly a backend that's slow to respond.I don't see yet what exactly my problem is there, but it must somehow be related with the
Dateheader handling and/or age calculations in theHTTPCache.As a first step, I'd like to suggest this cleanup in
HTTPCache. Especially, it would be helpful if we could make sure that there is just one place where we set theDateheader if the backend does not send one (?). This makes sure we always have this header to base later age calculations on it.