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

Set Cache-Control: no-cache on responses #586

Merged
merged 3 commits into from Jul 25, 2017

Conversation

Projects
None yet
5 participants
@danielcompton
Contributor

danielcompton commented Jul 24, 2017

Cache-Control: no-cache tells the browser that it may cache the response, but it must always revalidate the cached response with the server, before using it. This is equivalent to setting

Cache-Control: max-age=0, must-revalidate

max-age=0 means that the response is always stale, and must-revalidate means that the client must always revalidate stale resources.

Expires: -1 is not needed, all modern browsers support Cache-Control. IE8 (and below?) treat 'Cache-Control: no-cache' as 'no-store', meaning that they will never cache files. That seems a small price to pay for the simpler reasoning about caching by only using Cache-Control.

Chrome dev site has good information on the current state of the art for HTTP caching.
Jake Archibald has a good explanation of exactly the caching pattern that we are looking
to employ.

See also https://stackoverflow.com/a/19938619/826486 for more discussion on Cache-Control: no-cache.

Based on @tonsky's work on #464, but fixes merge conflicts, and removes Expires: -1.

Fixes #546.

tonsky and others added some commits Jul 26, 2016

Set Cache-Control: no-cache on responses
Cache-Control: no-cache tells the browser that it may cache the
response, but it must always revalidate the cached response with the
server, before using it. This is equivalent to setting

Cache-Control: max-age=0, must-revalidate

max-age=0 means that the response is always stale, and must-revalidate
means that the client must always revalidate stale resources.

Expires: -1 is not needed, all modern browsers support Cache-Control.
IE8 (and below?) treat 'Cache-Control: no-cache' as 'no-store', meaning
that they will always revalidate the cache. That seems a small price to
pay for the simpler reasoning about caching by only using Cache-Control.

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
has good information on the current state of the art for HTTP caching.
https://jakearchibald.com/2016/caching-best-practices/#pattern-2-mutable-content-always-server-revalidated
has a good explanation of exactly the caching pattern that we are
looking to employ.

See also https://stackoverflow.com/a/19938619/826486 for more discussion
on Cache-Control: no-cache.

Based on #464, but fixes merge conflicts, and removes Expires: -1.

Fixes #546.

@danielcompton danielcompton changed the title from Set Cache-Control: no-cache on responses Cache-Control: no-cache tells the browser that it may cache the response, but it must always revalidate the cached response with the server, before using it. This is equivalent to setting to Set Cache-Control: no-cache on responses Jul 24, 2017

@pesterhazy

This comment has been minimized.

Contributor

pesterhazy commented Jul 24, 2017

@danielcompton I think this is the right thing to do. Note that as I understand it setting no-cache doesn't completely disable caching, it only disables blindly avoiding the network roundtrip. The cached resource will still be used if caching headers are returned.

Does figwheel honor the If-None-Match and If-Modified-Since headers so browsers get a more efficient 304 Not Modified resource?

Return 304 when files haven't been modified
Figwheel will generate the response for the static file, and then the
wrap-not-modified middleware checks the response to see if the request
headers show that the client already has this version of the file. If
so, it will return a 304, rather than sending the whole file again.
@danielcompton

This comment has been minimized.

Contributor

danielcompton commented Jul 24, 2017

Note that as I understand it setting no-cache doesn't completely disable caching

Yep.

Does figwheel honor the If-None-Match and If-Modified-Since headers so browsers get a more efficient 304 Not Modified resource?

Figwheel doesn't send an Etag for files so it won't get an If-None-Match (though that might be a good future improvement). AFAICT it didn't return a 304 for If-Modified-Since, I think static files are served from https://github.com/danielcompton/lein-figwheel/blob/1c5fb829b59230bf03bc1f565be103543ecd41c0/sidecar/src/figwheel_sidecar/components/figwheel_server.clj#L163-L174.

I've just added another commit which checks the If-Modified-Since header. I checked this now, and verified that before the wrap-not-modified addition, Chrome requested the files every reload, and got a 200 every time. After adding wrap-not-modified, we get pleasing 304's for everything after initial load.

@bhauman bhauman merged commit 751b8c9 into bhauman:master Jul 25, 2017

@bhauman

This comment has been minimized.

Owner

bhauman commented Jul 25, 2017

perfect!

@Sophia-Gold

This comment has been minimized.

Sophia-Gold commented Jul 25, 2017

This is great! Thanks @danielcompton.

@danielcompton danielcompton deleted the danielcompton:cache-control branch Jul 26, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment