3 ms·
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
by 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 agoYeah, 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.