4 ms·
You do not have absolute certainty that every old cached version of a file you have published has been purged by every third party cache, no. But the vast, _vas
by untog 6y ago
You do not have absolute certainty that every old cached version of a file you have published has been purged by every third party cache, no. But the vast, _vast_ majority do get purged very quickly. I've done this myself when in a bind many times and it's worked fine (and I've been able to verify that via error logging).
> There's a reason why "sdk-latest.js" is largely dead concept from a bygone era
Is it, though? From a quick check, it's what Google Maps does. It's what the Facebook SDK does. We already know it's what Twilio does.
> This argument is essentially: "I'm doing it wrong, and Subresource Integrity would stop that, so it is a non-starter."
Zero dispute with that characterisation from me. But it's how things already operate in the real world. I'll join you in shouting from the rooftops that people shouldn't be doing it, but that doesn't really get you any closer to actually stopping them. For a great many people the flexibility to quickly push up changes is a feature, not a bug.
- Someone1234 6y ago> it's what Google Maps does. Nope. Google Maps loads an uncachable JS file that itself points to version specific sub-files that are cache breaking. > It's what the Facebook SDK does. Nope, they have versions in the fbAsyncInit configuration. > We already know it's what Twilio does. Indeed, and if you want to copy a company that almost had a massive security problem then go right ahead.