allow custom cache control settings for requests #13
+7
−3
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
Currently, the publisher server only allows for three options when setting cache-control settings: extended (one year), never (no-store), and null, which skips setting the cache-control header. At the same time, the implementation for serving local content prevents mutation of the backend response after receiving it (e.g., to add a custom cache-control header based on a path), as the act of catching the response to modify it strips the original Response headers. This is contrary to the documentation[1] which indicates the headers can be mutated in this fashion. (i.e., by passing beresp.body through `pipeThrough`) with a transform stream. From my testing, it's not possible to mutate the headers along with (or without) the content. This change modifies the serveRequest method to add an optional cache parameter which allows the user to set a custom cache-control string. Although there are other ways to solve this (such as allowing serveRequest to accept arbitrary headers which will be appended/merged, or figuring out if the broken example is the result of a bug or old documentation), this method solves my current needs. [1] https://www.fastly.com/documentation/guides/compute/javascript/#parsing-and-transforming-responses Signed-off-by: Neil Hanlon <neil@shrug.pw>
|
looking at this again, I think the 'right' thing to do is accept a CacheOveride like the js-runtime does. will look at that in the morning |
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.
Currently, the publisher server only allows for three options when setting cache-control settings: extended (one year), never (no-store), and null, which skips setting the cache-control header.
At the same time, the implementation for serving local content prevents mutation of the backend response after receiving it (e.g., to add a custom cache-control header based on a path), as the act of catching the response to modify it strips the original Response headers. This is contrary to the documentation[1] which indicates the headers can be mutated in this fashion. (i.e., by passing beresp.body through
pipeThrough) with a transform stream. From my testing, it's not possible to mutate the headers along with (or without) the content.This change modifies the serveRequest method to add an optional cache parameter which allows the user to set a custom cache-control string. Although there are other ways to solve this (such as allowing serveRequest to accept arbitrary headers which will be appended/merged, or figuring out if the broken example is the result of a bug or old documentation), this method solves my current needs.
[1] https://www.fastly.com/documentation/guides/compute/javascript/#parsing-and-transforming-responses