Add no-cache header to figwheel server

[tonsky]

I had an issue when Edge used stale js files instead of checking for new ones. I think it's reasonable to add no-cache just to make sure. I've tested that locally and it solved my problem with Edge

[kommen]

I think I just ran into the same issue with Chrome. Had some really strange issues until I disabled caches in the Chrome dev tools and then everything worked as expected.

[frickm]

just had the same issue - it shows itself when you reload and get old stuff, but after making an arbitrary change to the source the latest js-files get pushed to the browser and everything looks correct.

[pesterhazy]

I'm seeing the same symptoms in Chrome 59. If I make a change, figwheel injects it correctly. But after hitting reload, I see the old stale file before the change. To fix this, I need to Shift-click on the Reload button.

In the Network Tab I see "200 OK (from memory cache)" or "200 OK (from disk cache)". In fact it looks like chrome has changed recently and caches more aggressively these days.

I think adding no-cache headers as @tonsky proposes would be a great solution for this. @bhauman are you not seeing this issue in Chrome?

[danielcompton]

I see this behaviour often in Chrome also as another datapoint.

[bhauman]

OK so I'm assuming that this is happening for several reasons:

Chrome Devtools no caching is enabled and Devtools is not open OR Devtools/Chrome has a hard time disabling caching for <script> tags that are injected by google closure in certain circumstances.

Also Figwheel more than likely isn't setting the Last-Modified or Etag headers correctly when it serves static assets.

We need to check to see if this is the case and then fix that first.

Why I don't want to enable no-cache for everything:

The ratio of files that change to files that don't change is very very small especially for medium and larger sized projects. Forcing "no-cache" on everything can create an unbearable load times for some projects because under optimizations none there are a large number of files loaded that don't change ever.

[pesterhazy]

I just tried reproducing this in a fresh lein new figwheel project and couldn't. The "reload" button seems to work fine here. So I think you're right that this happens only in certain circumstances.

FWIW, the problems I've had were with compiled output, not static assets. And it does look like the Last-Modified header is set.

My take on this is that Chrome's behavior was changed recently to cache resources (especially scripts?) if no explicit caching headers were sent. Surprisingly, it may not even attempt to revalidate the files if they're in cache locally.

Quoting from https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.4:

Unless specifically constrained by a cache-control (section 14.9) directive, a caching system MAY always store a successful response (see section 13.8) as a cache entry, MAY return it without validation if it is fresh, and MAY return it after successful validation.

This Chrome blog post may be relevant:

To improve the stale content use case, Chrome now has a simplified reload behavior to only validate the main resource and continue with a regular page load. This new behavior maximizes the reuse of cached resources and results in lower latency, power consumption, and data usage.

Maybe part of the solution is to specify the "must-revalidate" header?

https://stackoverflow.com/questions/34761700/does-chrome-violate-the-standards-in-caching

[pesterhazy]

... of course a foolproof variant would be to append a date/version number/hash to each js filename (query string?), but not sure if that's something you'd consider

[reitzensteinm]

This is a frequent source of bugs for me in Chrome. I definitely support appending a truncated file hash to name proposal; it's the only foolproof way to ensure you've got a clean version of the latest code, no matter what kind of badly implemented cache is sitting between the javascript engine and the files on disk.

[bhauman]

When I say "static assets" I mean the compiled js/html etc, as these don't change in the deployed application.

Appending a hash would require a compiler change and that is a tall order.

[bhauman]

So maybe we should set Cache-Control: must-revalidate, if the last-modified is being set correctly, and see if that alleviates this problem.

[tonsky]

My vote goes for hash in filename (if possible) or for completely disabling cache. Browser has to re-validate files anyways, it doesn’t have all the necessary information to cache intellegently on its own. Maybe I don’t understand something, but is going for file, reading its content to calculate its ETag and sending back Not modified faster than fetching the file anew? Given that it all happens locally? We have 11kloc project with 85 CLJS files and I always keep my cache disabled, haven’t noticed any problems. Fighting another non-issue caused by stale cache doesn’t simply worth it for me. If it can be done fast and right (hashes for filename, force to reload), I’m in for it. If it can’t be done, I’m for “right” approach (disabling cache) over “fast but sometimes wrong”

[bhauman]

I'll take an updated PR for Cache-Control: must-revalidate if that sounds good. Thanks for chasing down those resources @pesterhazy.

[bhauman]

Oh yeah, I'm not thinking about must-revalidate correctly.

[pesterhazy]

Digging in some more, it looks like Cache-control: no-cache might actually be what we're looking for. Despite the name what this does is to force server-side revalidation. If a cached copy exists, the User Agent sends a network request to validate the resource (using the If-Modified-Since header). If the resource is still valid, the server will respond "304 Not Modified" and the UA will use the locally cached version.

This is different from Cache-control: no-store, which actually prevents local caching. Confusing names for sure. [This link] explains it well (section "mutable content, always server-revalidated"). Chrome 58's behavior seems to be to assume that, unless otherwise specified, non-entry resources are immutable, which is not correct for Figwheel.

So if that's true, Cache-control: no-cache, must-revalidate should be safe. (Not sure about the "Expires" header mentioned in the PR.)

[danielcompton]

For those following along, I've made a fresh PR in #586 which sets Cache-Control headers to force revalidation always.

[pesterhazy]

This PR can be closed now that #586 is merged I think