4 ms·

Add a hash or version to your CSS/image URLs. Store them all on same CDN.

by _betty_ 9y ago

Klathmon 9y ago
Or better yet, have the hash be the filename.
- seanwilson 9y ago
  Is putting the hash/version in a query string generally recommended? Some CDNs have issues with it.
  - Klathmon 9y ago
    No, I'm saying don't put the hash or version in the query string, put it in the filename. Have your static files named a hex encoded sha1 hash of the contents, then never worry about cache expiration again.
    - seanwilson 9y ago
      I get it, I meant are there any advantages to this approach over using a query string? I guess one advantage of changing the filename is you can easily find all the places in your code that is referring to the filename without the hash. If you forget the query string for query string approach, the code will still look like it's working which is worse.
      - Klathmon 9y ago
        It's just allowed us to completely sidestep the whole "cache" and "version number" issues. our build system will generate the filenames, so that's not as much of a problem for me, but what is a problem is cache dates that are set incorrectly, or set correctly but I need to overwrite sometimes. And versioning which can easily "lie" whether intentionally or unintentionally. With a "content addressable web" style, you don't need to worry. If a filename is named `bde1ca6a5d7cefc8108c75fdaad29ed6.js` then you know that it will always be named `bde1ca6a5d7cefc8108c75fdaad29ed6.js` if it has those contents. If you break a build and need to roll back, you will get the same filename, you can ensure builds are fully reproducible, and you won't run into problems if you forget to bump a version one time, or you roll back to an older version but hotfix a bug and don't set the version number correctly, or even the "my cachebuster RNG gave me the same random number 2 times in a row and it caused a few users to error out" that I actually hit once. And of course it has the advantage of forcing you to use it, so like you said you can't include the file without it, or try to manually patch it in "just this once" (which always leads to more and just causes problems).
        fleitz 9y ago
        Yeah, I also recommend doing this for user generated content as well. Also, once you have this you can set infinite expiry, and remove the must-revalidate cache headers saving you a bunch of 304s <random garbage from user>-<sha256>.txt or if preserving the user's filename is important /<sha256>/<random garbage from user>.txt Your users will keep the same filename in different directories and randomly clobber your service for you.
  - acdha 9y ago
    I prefer the file name because it fails obviously: use the wrong value and you get a 404 whereas many implementations around the query string meant you’d get a different version than expected. I’ve seen that cause a lot of confusion because people would look and think that it was working correctly until they tested what the backend was actually serving. I like the approach of adding a hash to the file name (e.g. foo.<SHA>.css) so that cannot happen but related files are grouped together. Any decent environment should make that simple: your code references foo.css and it’s automatically replaced with the expanded value.
windowsworkstoo 9y ago
Yes, and that's the problem....think about the request flow between a canary deploy, that hits the canary home page html with a reference to a cdn subdomain with a new version string, but that CDN subdomain goes to the old, non-canary version....
- foota 9y ago
  I'm not sure I understand. Let's write it out: User 1 goes to homepage.com and gets served the canary html. User 1 sees they need the js file included on the homepage, identified by it's hash $hash, and so it requests the file $hash from cnd.homepage.com/$hash. User 1 gets $hash and everything loads fine. User 2 goes to homepage.com and does not get the canary, so their browser requests $old_hash, and gets the old version of the file from cnd.homepage.com/$old_hash, and everything is fine? Unless you are talking about rolling out a new version of the cdn server along with the main website I don't see what the issue is here?
luhn 9y ago
I recommend this to everyone regardless of whether they're using canary releases or not. Sidesteps a bunch of issues regarding static asset caching.

Add a hash or version to your CSS/image URLs. Store them all on same CDN.

Klathmon 9y ago

Or better yet, have the hash be the filename.

seanwilson 9y ago
Is putting the hash/version in a query string generally recommended? Some CDNs have issues with it.
- Klathmon 9y ago
  No, I'm saying don't put the hash or version in the query string, put it in the filename. Have your static files named a hex encoded sha1 hash of the contents, then never worry about cache expiration again.
  - seanwilson 9y ago
    I get it, I meant are there any advantages to this approach over using a query string? I guess one advantage of changing the filename is you can easily find all the places in your code that is referring to the filename without the hash. If you forget the query string for query string approach, the code will still look like it's working which is worse.
    - Klathmon 9y ago
      It's just allowed us to completely sidestep the whole "cache" and "version number" issues. our build system will generate the filenames, so that's not as much of a problem for me, but what is a problem is cache dates that are set incorrectly, or set correctly but I need to overwrite sometimes. And versioning which can easily "lie" whether intentionally or unintentionally. With a "content addressable web" style, you don't need to worry. If a filename is named `bde1ca6a5d7cefc8108c75fdaad29ed6.js` then you know that it will always be named `bde1ca6a5d7cefc8108c75fdaad29ed6.js` if it has those contents. If you break a build and need to roll back, you will get the same filename, you can ensure builds are fully reproducible, and you won't run into problems if you forget to bump a version one time, or you roll back to an older version but hotfix a bug and don't set the version number correctly, or even the "my cachebuster RNG gave me the same random number 2 times in a row and it caused a few users to error out" that I actually hit once. And of course it has the advantage of forcing you to use it, so like you said you can't include the file without it, or try to manually patch it in "just this once" (which always leads to more and just causes problems).
      - fleitz 9y ago
        Yeah, I also recommend doing this for user generated content as well. Also, once you have this you can set infinite expiry, and remove the must-revalidate cache headers saving you a bunch of 304s <random garbage from user>-<sha256>.txt or if preserving the user's filename is important /<sha256>/<random garbage from user>.txt Your users will keep the same filename in different directories and randomly clobber your service for you.
- acdha 9y ago
  I prefer the file name because it fails obviously: use the wrong value and you get a 404 whereas many implementations around the query string meant you’d get a different version than expected. I’ve seen that cause a lot of confusion because people would look and think that it was working correctly until they tested what the backend was actually serving. I like the approach of adding a hash to the file name (e.g. foo.<SHA>.css) so that cannot happen but related files are grouped together. Any decent environment should make that simple: your code references foo.css and it’s automatically replaced with the expanded value.

windowsworkstoo 9y ago

Yes, and that's the problem....think about the request flow between a canary deploy, that hits the canary home page html with a reference to a cdn subdomain with a new version string, but that CDN subdomain goes to the old, non-canary version....

foota 9y ago
I'm not sure I understand. Let's write it out: User 1 goes to homepage.com and gets served the canary html. User 1 sees they need the js file included on the homepage, identified by it's hash $hash, and so it requests the file $hash from cnd.homepage.com/$hash. User 1 gets $hash and everything loads fine. User 2 goes to homepage.com and does not get the canary, so their browser requests $old_hash, and gets the old version of the file from cnd.homepage.com/$old_hash, and everything is fine? Unless you are talking about rolling out a new version of the cdn server along with the main website I don't see what the issue is here?

luhn 9y ago

I recommend this to everyone regardless of whether they're using canary releases or not. Sidesteps a bunch of issues regarding static asset caching.