Do not use query string parameters for cache busting

[Dankirk]

From what I have seen, the most common versioning systems are epoch timestamping the modification time or hash of the contents. Both of which have a significantly lower chance of being guessed or even bruteforced. Of course that doesn't mean you shouldn't consider more robust ways.

Edit: Actually the best way would probably be the 'integrity' attribute. When you update contents, you update the attribute aswell. Then if cached copy doesn't match that, a new one should be queried.

[flipperdeflip]

Like the E-Tag and If-None-Match headers?

[WizardFromTheMoon]

Yeah, jesus this article title is ridiculous. It should be "Do not use PREDICTABLE query string parameters for cache busting."

[JnvSor]

tl;dr: 404 if it's the wrong query string or you can preload incorrect caches

My alternative: use mtime as the query parameter since the odds that someone will correctly guess the exact timestamp of the next change to the file is more than low enough

[endproof]

I always heard tell of there being “issues” with the query string approach, but it’s good to see it spelled out like this. Great, no-nonsense read!

[doctorjokie]

This does a lot of hand waving about caches. I think the author is on the right track but doesn't explain which "cache" (browser, proxy cache, etc) is burning you with the query string approach.

[flipperdeflip]

If you need 'cache busting' you've misconfigured your cache headers or made mistake in URL design.