Caching settings #1146
Merged
Caching settings #1146
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
All static assets are asked for under the `/dist` prefix and handled by the `expressStaticGzip` handler.
This commit (building on top of #1126) enforces that index.html is never cached, as it gets recreated when auspice rebuilds and the src for the main JS bundle changes accordingly. This may not be strictly necessary, as the max-age was 0 and the ETag changes as the file changes, but setting this explicitly is good practice. JS bundles, which use hashes to facilitate cache busting, are served with a 30d cache lifetime. Note that this is not enough to _force_ browsers to not revalidate within the 30d (i.e. 304 response) -- see [this post](https://stackoverflow.com/questions/26166433/how-to-prevent-request-that-returns-304/26339940#26339940) for context. Revalidation during the 30d lifetime will return a 304 which is no worse than the current situation we have.
jameshadfield
force-pushed
the
caching-settings
branch
from
5c3aa62 to
3a795d1
Compare
jameshadfield
added a commit
to nextstrain/nextstrain.org
that referenced
this pull request
May 29, 2020
See nextstrain/auspice#1146 for rationale for these changes. Depending on how gatsby is creating assets, we could improve the cache-control for those in a future PR.
jameshadfield
added a commit
to nextstrain/nextstrain.org
that referenced
this pull request
May 29, 2020
See nextstrain/auspice#1146 for rationale for these changes. Depending on how gatsby is creating assets, we could improve the cache-control for those in a future PR.
|
I tested this both with Chrome with cache on and off, and with cUrl to simulate revalidation. Chrome cache works as expected, and 304s are returned correctly as well both for So all looks good as far as I can tell @jameshadfield . |
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.
This PR builds on #1126 and enforces that
index.htmlis never cached, as it gets recreated when auspice rebuilds and the src for the main JS bundle changes accordingly. This may not be strictly necessary, as the max-age was 0 and the ETag changes as the file changes, but setting this explicitly is good practice.JS bundles, which use hashes to facilitate cache busting, are served with a 30d cache lifetime. Note that this is not enough to force browsers to not revalidate within the 30d (i.e. 304 response) -- see this post for context. Re-validation during the 30d lifetime will return a 304 which is no worse than the current situation we have.
@salvatore-fxpig would you mind double checking this?