Make http error cache control behavior configurable. #444
Conversation
This file contains 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
| @@ -31,6 +32,7 @@ def __init__( | |||
| """ | |||
| super().__init__(app) | |||
| self.cachecontrol = cachecontrol | |||
| self.cachecontrol_http_code_range = cachecontrol_http_code_range | |||
There was a problem hiding this comment.
I'm not sure about the name of the parameter. To me if we say Range I'm assuming the input to be a sequence (min, max), while here in reality we want the upper value of status_code.
what do you think about cachecontrol_max_http_code ?
vincentsarago
approved these changes
Mar 3, 2022
|
I may revisit this a bit later @vincentsarago I'm still not fully sure of the Cloudfront behavior between |
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.
What I am changing
While implementing edge caching for a titiler deployment we have a case where underlying source COGs are continually added in real time. Currently a request that results in
404No assets found for tilehas the sameCache-Controlheader as a200response and is maintained by the edge cache for the same duration. In our case we would prefer404responses to have a shorter duration in the edge cache so that requests are passed to the origin (where new assets may now be available). This PR makes the upper range or http codes which include aCache-Controlheader configurable so that edge caches can exert finer control on error response cache duration.How I did it
Extended
core/middlewareto support a configurable upper bound for response codes which include aCache-Controlheader rather than the hardcoded500value.How you can test it
Via the project's
toxtesting entrypoint.