5 ms·

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.

romaniv 10y ago
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.
- nemothekid 10y ago
  >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?
reggieband 10y ago
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.
- kijin 10y ago
  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.
  - reggieband 10y ago
    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.

romaniv 10y ago

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.

nemothekid 10y ago
>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?

reggieband 10y ago

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.

kijin 10y ago
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.
- reggieband 10y ago
  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.