Hacker News Reader

Comment by btilly | Hacker News Reader

What I really want is the exact opposite. I'd like to see a flush-before header to have a particular web page NOT pull older static resources.

The reason is simple. Websites have lots of static content that seldom changes. But you don't know in advance when it is going to change. However after the fact you know that it did. So you either set long expiry times and deal with weird behavior and obscure bugs after a website update, or set short ones and generate extra load and slowness for yourself.

Instead I'd like to have the main request send information that it does not want static resources older than a certain age. That header can be set on the server to the last time you did a code release, and a wide variety of problems involving new code and stale JS, CSS, etc go away.

View on HN

Then you should do what Facebook does (https://code.facebook.com/posts/557147474482256/this-browser...): content-addressed resources. Have a resource be available not at /resources/something.js, but at /resources/<sha1(something.js)>; whenever there is a new version of something.js, the sha1 changes and is put in your root document, and the browser will never again try to reach the older version, which you know is invalid now.

This is also the default in Rails with the asset pipeline since 4.0.

It's even older than that. Sprockets always have been content addressed, but in early versions it used to leave non digested aliases (by mistake actually), and some people relied on it.

But ever since 3.1 (Aug 2011) Rails defaulted to content addressed assets.

Content addressing of data is one of my favorite ideas in the field.

But what happens when you need to cache the actual page not just static resources? That's what the content-addressed resources trick doesn't address.

You cache the actual page with a much shorter cache timeout.

Then just cache the actual page. The cached version refers to some possibly old versions of the static resources, so your server needs to be able to serve old versions for a period of time.

And what if the resource in question is a dynamically generated minified thing? Do I have to dynamically generate it within the main html page to be able to figure out the sha?

These are big complex workarounds for a problem that is easily solved at another layer.

Typically these are shared resources and can be generated once and saved so your HTML page would simply be checking file metadata generated at the time the app was built.

If it was truly custom, you could either do cached on-demand generation or find some other portion of the cache key which reliably changes on updates – e.g. I've seen people use things like Git commit ID + feature flags.

> that it does not want static resources older than a certain age.

This already exists: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If...

You would need to use Service Workers to use that header the way OP wants it, since he wants to have the HTML page decide when the resources of that page need to become stale. Fingerprinting resources with the hash of the content works a lot better for that.

That sounds convenient, but using versioned URLs will already give you that. Except for when you bump the version without changing the resource I guess.

That is true in most cases, but versioned URLs are a hack that requires you to change document's address and then change a bunch of other documents just to fix an issue with HTTP. It's like changing file content and their names to fix something in FTP protocol.

Also, it doesn't cover all the cases properly, because the page with versioned URLs can be cached as well.

>Also, it doesn't cover all the cases properly, because the page with versioned URLs can be cached as well.

If even the page with the versioned URL is cached, what good would a "Flush-Before" header do you?

Versioned URLs have a couple of drawbacks.

If I have asset.v0.js, asset.v1.js, asset.v2.js then I am exposing some useful information in the sequence of filenames.

It is also a bit harder to keep track of versions across systems. With hashes, you don't need to know what the last version number was - just what the hash of the current file is. If you have multiple build machines building multiple branches, keeping versions in-line is thing unto itself. I've had problems with versioning in the past where careless merges caused issues - that doesn't happen with hashes.

The main drawback with hashed asset names is it can be a bit more tricky to determine what assets are currently in use and which can be safely deleted.

I just take the mtime of each file, apply an HMAC using a secret key, and use the first few letters of the resulting hash. So the URLs end up looking like asset.js?v=deadbeef. It's fully automated and exposes no useful information. (The web server sending a Last-Modified header is another question.)

If you don't like query strings, you can throw in some rewrite rules to make it part of the virtual filename, e.g. asset.deadbeef.js.

It is my opinion that the content of the file is a more reliable source for the hash than the modified time of the file.

For our build, with a large volume of assets and some very large sizes, it is more efficient to write the hash into the filename to save on time syncing to the CDN origin. We also need to maintain the ability to do quick rollbacks, so unique filenames per version help. That will not apply in all cases.

Other than those points, I think we agree? An automated hash based on some unique portion of the file is better than a sequential version.

Reply on news.ycombinator.com