Cloudflare caches based on origin header?

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.

Seemingly cached:

curl -s -H'origin:' -I  | grep -i access

Unique origin, so not cached:

curl -s -H'origin:' -I  | grep -i access
access-control-allow-origin: *

I have purged the cache for using the cloudflare web UI. Is that not enough?

I’ll clear the whole cache for the domain now, to see if that takes effect.

Update: Yes, purging cache for the whole domain made the header always appear.

Is this working as intended? Seems to me that if I purge cache for a URL it should be purged no matter what the Origin header of a request is set to.

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:

You can purge objects with these characteristics using an API call

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.

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.