CDN: Can cache outdated files

[dd32]

The mid-deploy cachebuster only applies for a maximum of 10 minutes.

The CDN cache uses part of the sha1sum of the file as the cache buster, this effectively means it changes whenever the file changes.

Unfortunately, when a deploy takes longer than the 10 minutes (As it did today), it's possible for the CDN to have that a file requested with the hash version, sans mid-deploy, and end up caching the old file in the slot for the new file.

When a deploy takes less than 10 minutes, and the mid-deploy cachebuster works, the cdn works great.

As we:

• Don't deploy static files first
• Don't verify that the requested hash matches the file hash
• Have the CDN set with a long-expiry
  the above results in a sticky situation.

There's no ability for us to clear that cdn cache by path.

I considered:

1. We could possibly include a static increment along with the file hash, however, this wouldn't work for fonts which have it defined in a .css file: Add versioning for fonts #424 This would also be a manual "ah crap, bump the cache" action.
2. We could include the existing version param, only appending the content Hash. This would mean the cache would bump more often, but at least it would clear when the plugin version changes.
3. We could include the date in the version param, again, same as above. Doesn't resolve the problem for right now.
4. We could change how it works, such that instead of hitting the CSS/JS files directly, it could go via PHP script that verified the hash matches, and only allow caching in that event. This would require systems changes, as a wp-(content|includes)/ path would bypass any existing PHP.. I guess it could be https://s.w.org/asset-(content|includes)/... but that's just a hacky workaround.
5. We could remove the CDN plugin, reverting the changes, and try again later.

I'm thinking a hybrid approach of 6+3 - Disable the CDN offload for now, and include the file hash in the cachebuster ?ver=.. param. This resolves the CDN issue, uses a consistent cache buster, and ensures that the caches bump even when the ?ver=.. field didn't update (as happens)

[dd32]

I'm thinking a hybrid approach of 6+3

But also, due to afk probably safer just reverting the changes for now.