-
Notifications
You must be signed in to change notification settings - Fork 213
Pass through backend cache headers #1059
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| map $cache_strategy $cache_header_cache_control { | ||
| "immutable" "max-age=31536000"; | ||
| "revalidate" "no-cache"; | ||
| "passthrough" ""; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I verified that if there's no value set for a header, that header isn't set by nginx.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see a PR to update nginx docs: "The add_header directive will not generate a header if the value provided is an empty string." except if it is multi-value header
| default "single-use"; | ||
| } | ||
| map $cache_strategy $cache_header_cache_control { | ||
| "immutable" "max-age=31536000"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be public, max-age=31536000, immutable otherwise we don't know if intermediary caches will cache.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense
| } | ||
| map $cache_strategy $cache_header_cache_control { | ||
| "immutable" "max-age=31536000"; | ||
| "revalidate" "no-cache"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above, I think we can/should add public.
sadiqkhoja
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. However, we should add one or two tests in test-nginx.js
| default "single-use"; | ||
| } | ||
| map $cache_strategy $cache_header_cache_control { | ||
| "immutable" "max-age=31536000"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense
|
@sadiqkhoja please verify the tests and either open a PR to fix or send me some comments if they're not right/complete! |
* Update assertions: Header object doesn't have headers as properties, we have to use .has() * Update mock-http-server to return cache headers for a sample API * Add test to assert that backend cache headers are passed through
* Update assertions: Header object doesn't have headers as properties, we have to use .has() * Update mock-http-server to return cache headers for a sample API * Add test to assert that backend cache headers are passed through
* Update assertions: Header object doesn't have headers as properties, we have to use .has() * Update mock-http-server to return cache headers for a sample API * Add test to assert that backend cache headers are passed through
* Update assertions: Header object doesn't have headers as properties, we have to use .has() * Update mock-http-server to return cache headers for a sample API * Add test to assert that backend cache headers are passed through
Closes #1048
What has been done to verify that this works as intended?
Put it on the dev server. Verified that there's exactly one
Cache-Controlheader and that it's set as expected.Why is this the best possible solution? Were any other approaches considered?
We could also set the headers here to
private, no-cache, etc. But then we'd be setting duplicate headers which could drift between nginx and backend. I think it's clearer to make caching headers clearly the backend's responsibility.Note that this does not set the
Pragmaheader for backend. I think we could do away with it altogether because it has been deprecated for a long time.How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Backend responses should be cached in private caches. We should get 304s.
Does this change require updates to documentation? If so, please file an issue here and include the link below.
No.
Before submitting this PR, please make sure you have:
nextbranch OR only changed documentation/infrastructure (masteris stable and used in production)