My backend server always sets the “Access-Control-Allow-Origin” header for this request. But it seems that when going through CloudFlare the fact that I didn’t use to have this header set is cached.
This is not the case. The cache key includes the Origin request header, and you need to use the API to purge assets with such Headers. This is so that your origin server can evaluate the Origin header, and set the correct Access-Controlled-Allowed-Origin response header.
Important! A single-file purge performed through your Cloudflare dashboard does not clear objects that contain:
That seems suboptimal. I recognize that you are just saying how it is, but why is it this way?
It seems like a clear bug to me. If I Purge Cache on a URL in the UI, what possible intent could I be having except to purge all variants of this URL.
Purge Everything seems like a needlessly large hammer, but this is what I’m going to have to use if I’m not already set up with APIs and keys and such.
Why is it not the obviously right thing to purge all permutations of subcachekeys when I enter that I want to purge a URL?
I agree it would be useful, but I suspect it is because the cache cannot be “searched” for cache keys that sort of match a given parameter. It is going to be very expensive on CPU, unless you have prepared the “subcachekeys” in advance. There are cache purging features that are reserved for Enterprise plans that would do what you are looking for, but probably because they have such a high CPU cost making them available to Free plans just would not scale.
Given that you can deploy a relatively trivial worker to manage CORS headers, I do not expect there to be any changes in the cache behaviour to deal with cache fragmentation caused by CORS.
There are only two hard things in Computer Science: cache invalidation, naming things and off by one errors.