Set Cache-Control: no-cache on responses #586
Conversation
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 I think this is the right thing to do. Note that as I understand it setting Does figwheel honor the |
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.
Yep.
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. |
perfect! |
This is great! Thanks @danielcompton. |
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
max-age=0
means that the response is always stale, andmust-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.