Hacker News new | past | comments | ask | show | jobs | submit login

The browser would cache a copy.

I've seen proposals to add hashes to links. This way, a browser might see a link to some JS on a new URL, but with the hash, it might find it already has that JS file in its cache from when it downloaded it at a different URL.




That's what Etag is for.


No it's not. Etag is completely different. It's a tag that the webserver sends together with the response and which the browser sends to the server which can then return a 304 status code to indicate that the resource has not changed and the browser can use the cached copy.

What the parent spoke about is adding some attribute to an anchor tag which specifies the hash of the resource so the browser can do safe cross domain caching without needing to do any request whatsoever.


Just what we need... More ways to shoot our own feet off while trying to improve performance.


First I don't immediately see how to shoot your feet off with this but maybe you can elaborate a bit on why you think so.

And secondly, am I getting this right that you are in favor of dumbing everything down while also sacrificing performance on the way because someone could break something?


I'm hardly in favour of dumbing things down, or sacrificing performance. I'm just frequently exposed to issues that are 'magically fixed' by purging the entire browser cache. And I'm just unnerved by the idea of this hash link scheme, we have enough bugs and gaps in the existing system without additional complexity, and that system is pretty damn simple conceptually, yet the bugs remain.

Anecdotally, I used to ship jQuery from a CDN for one project, I had to stop for that project I forget why... But I do remember that to my surprise, it turned out that when I shipped my own version of jQuery from my own domain, I got 10% less client side errors reported back to me in Sentry. The world is full of ways to shoot off your own foot, some of them even start out with someone showing you how they don't shoot their foot off.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: