Hacker News Reader

Comment by manigandham | Hacker News Reader

Judging by the comments here, there seems to be some confusion.

This is exactly like long-lived cache settings today. Right now browsers send a request on basic reloads and get back a 304 from the server which states that nothing has changed. All this setting does is let the server tell the browser to skip that check/roundtrip instead of wasting the time/bandwidth on confirming with a 304 after the initial load.

The browser is still completely in control here and can do a full reload or just reload all the time if it wants to. Web scrapers and other HTTP clients are unaffected.

View on HN

If you go back and read the RFC for http, don't we have the headers to do this already, and the browsers just don't behave that way? http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14...

If that is true wouldn't a "strict" cache control make a whole lot more sense?

Yes, technically browsers should just skip the revalidation if the header already has a max-age, since that's what the caching time is.

And yes, having more uniform and standardized approach to caching would be better.

Which is fantastic for "modern" web apps.

We use webpack and all filenames are just sha hashes of the contents in the production builds. There is no need for the browser to ever ask anything about that file again (unless its purged from the cache...).

Content addressable web! Love it!

It really works beautifully. One of our applications coming up needs to work offline, and we found that because of the naming we were using, appcache was almost completely work-free to implement.

If the appcache.manifest changes, it rechecks all files (or in my case, would only pointpessly re-check those which haven't changed, and download new ones), and the appcache.manifest will change the second a single byte anywhere in the program changes.

It's fantastic.

It's notable that appcache is now deprecated [0]

It's been replaced by Service Workers, but those can get reallly hard to deal with if they start caching themselves (!)

Chrome's devtools has ways to delete old service workers and such, but I've found that on Firefox it's next to impossible to debug.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Using_the_...

It's also notable that service worker adoption is only half way at best, whereas appcache is easier to deploy and supported in far more browsers.

Not to say service workers aren't the future, but implementing partially adopted features in web pages is poor practice.

http://caniuse.com/#feat=serviceworkers

We are aware and are ready to switch to a service-worker and appcache hybrid when that time comes that appcache is going to be removed.

But until then we wanted to keep it simple. Especially during development we don't want to have to deal with differences in SW and appcache.

This has been the standard way of serving assets in Rails for the last 5+ years. I don't think it was invented there, as if you are using a CDN it's basically required.

Invalidating edge caches takes time and/or is expensive (i.e. Cloudfront), so adding the content hash in the file name is a good trick to ensure users always get the correct version of the asset.

I didn't mean to imply it was invented by webpack or anything (and I used the scarequotes around modern because I'm not sure how long it's been widely used).

I was just pointing out how and with what I use it.

Why use hashes? Wouldn't UUIDs make more sense?

Hashes are generated from the contents of the files. You don't need to store UDIDs anywhere.

Frontend builds sometimes destroy the dist folder and rebuild all assets. Hash will result in the same name if it is unchanged.

Is there a write up on how this is implemented? I want to find out more about this model of delivering content.

Nevermind. I should have googled first. https://medium.com/@okonetchnikov/long-term-caching-of-stati...

Reply on news.ycombinator.com