Hacker News Reader

Comment by bpicolo | Hacker News Reader

Cache-control headers. Browsers won't cache indefinitely unless you ask them to.

Am I insane or are cache-control headers unreliable? I always set cache-control: no-cache on my S3 files but still get complaints about people getting old versions with broken pages as result.

Some CDNs don't always listen to those (I've noticed cloudflare especially has a problem with them if I don't add the files to the ignore list in their control panel), maybe that's it?

I don't rely on them. We set query parameters on new JS code to definitively bust caches.

src="foo.js?v=1", then src="foo.js?v=2", etc.

I'm sure people consider this a hack, so I'm open to hearing other suggestions.

It's not a hack at all for resources you control - in fact, it's encouraged to do so in order to use very long lived Expires headers while still being able to deploy new versions of your app.

It doesn't work for unversioned library code though where you want to automatically upgrade all users of your code as is the case with Twitter it looks like.

Problem with these is that many caching proxies consider all resources with a query string to be dynamically generated and won't cache them at all, which in the case of js/css/etc is bad

Sure, but that's easily solvable by versioning assets in the filename itself. That's how the `filerev` task works for both Grunt and Gulp.

I use this as well, works like a charm.

you are either insane, using them wrong, or following some bloggers guide instead of reading actual specs.

Reply on news.ycombinator.com