I am attempting this for dailylviv.com
. Even right away after clearing the cache, I am still getting Hit in a header and Age is not decreasing, instead increasing. But if I do the full cache flush, then it works as needed, only for the whole site and it is not doable over an API, therefore extremely inconvenient.
Update: this happens only on the root page of the domain.
This has suddenly started happening for me too in the last day or so with perchance.org - global purge works, but individual URL purges don’t work via GUI or API. Both GUI and API show success, but don’t actually work. It had been working fine for years before this.
Edit: Invalidation seems to be working for some pages, but not others. Here’s a URL that I’m unable to purge:
curl -I [problem solved, url removed]
I always get cf-cache-status: HIT no matter how many times I try to clear that URL via the GUI or the API.
@cf_evan there’s a bug with single-url cache purging that I can reliably reproduce here - just visit cache purge GUI and purge this URL: [problem solved, url removed] - and it doesn’t work:
curl -I [problem solved, url removed]
HTTP/2 200
date: Mon, 31 Jul 2023 22:27:51 GMT
content-type: text/html; charset=utf-8
cache-control: public, max-age=0, s-maxage=31104000
x-ratelimit-limit: 400
x-ratelimit-remaining: 399
x-frame-options: sameorigin
referrer-policy: no-referrer-when-downgrade
vary: Accept-Encoding
strict-transport-security: max-age=63072000; includeSubDomains; preload
x-content-type-options: nosniff
cf-cache-status: HIT
age: 3010
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=<unsure if safe to make this public so removed it>"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 7ef94565b8fc4b68-SIN
alt-svc: h3=":443"; ma=86400
If you’re the wrong person to ping (I remembered you previously helping with exactly the same issue a couple of years ago), could you CC the right person?
There’s a bug with single-url cache purging that I can reliably reproduce here - just visit cache purge GUI and purge this URL: [problem solved, url removed] - and it doesn’t work:
curl -I [problem solved, url removed]
HTTP/2 200
date: Thu, 03 Aug 2023 13:08:21 GMT
content-type: text/html; charset=utf-8
cache-control: public, max-age=0, s-maxage=31104000
x-ratelimit-limit: 400
x-ratelimit-remaining: 399
x-frame-options: sameorigin
referrer-policy: no-referrer-when-downgrade
vary: Accept-Encoding
strict-transport-security: max-age=63072000; includeSubDomains; preload
x-content-type-options: nosniff
cf-cache-status: HIT
age: 3
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=<not sure if it's safe to share this so I removed it>"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 7f0ec9f269fd3e5c-SIN
alt-svc: h3=":443"; ma=86400
I’ve also tried using the API directly and it’s the same result. The global “purge everything” works - it’s only a problem with specific single files (works for some, not others, no discernible pattern).
If anyone knows who to ping here, please do ping, since I’m not sure how long the above example will remain replicable (though it has been like this for several days now).
2 Likes
I am having the exact same issue, and even created a topic several days ago:
1 Like
Another user recently having this problem: API: purge cache by url - #4 by stiggpwnz
And another: Cache invalidation per URL is globally absent
@cf_evan @cbrandt do you know who could be tagged here? This bug didn’t exist before - it has only started happening in the last couple of weeks, and only for specific URLs. The example I gave in the first post of this thread is still reproducible as of my testing just now.
1 Like
Also running into the same issue. Seeing widespread report of it in the last ~2 weeks or so, and has always worked properly before.
My test URL was last updated in April (let’s call it v0), then updated today a few hours ago (v1), and updated again for testing just now (v2, ~30 min ago). I have purged through the API, and then subsequently manually via the dashboard. My browser is still seeing the April version (v0), sometimes showing the version from a few hours ago (v1) but then reverting back to the April version (v0) after a few minutes. I have never seen the correct latest version (v2) yet.
I have verified that my origin server which is returning latest version (v2), and it can be confirmed through a worker developer mode/panel (which seems to always bypass the cache and responds with a cache status of REVALIDATED) that the latest version is indeed latest (v2).
User reports seems to say that the cache will stay for at least a few hours, and usually clear after 12-24 hours.
1 Like
Does anyone know who to ping here? So many independent reports of this problem. My original example in the first post is still reproducible, so it’s not like there’s any uncertainty around whether this is a user problem vs a cloudflare problem. Seems like someone on the cloudflare team should be informed about this?
@simon do you know who to ping?
1 Like
Hi @joe35
Sorry for the issues you have been facing when trying to purge by URL, I have tried testing this but I have not been able to reproduce this - can I confirm if you are still facing issues here?
2 Likes
I am still able to reproduce this - I also have test URLs available if it helps with debugging.
Live right now at my test URL with browser cache disabled:
Cf-Cache-Status: HIT
Cf-Ray: 7f5230c40aefa21c-YYZ
Date: Fri, 11 Aug 2023 17:27:38 GMT
Last-Modified: Fri, 11 Aug 2023 17:24:44 GMT (Old version)
Worker devtool tested:
cf-cache-status: REVALIDATED
cf-ray: 7f523136b1cd3705-YYZ
Date: Fri, 11 Aug 2023 17:27:57 GMT
Last-Modified: Fri, 11 Aug 2023 17:25:11 GMT (New version)
URL is at:
https://publish-01.obsidian.md/access/be30b94fd5a67f7837046e4d96055c7d/Test.md
I seem to be getting various old versions as I refresh the URL:
Cf-Ray: 7f523eff69fc3703-YYZ
Date: Fri, 11 Aug 2023 17:37:21 GMT
Last-Modified: Fri, 11 Aug 2023 17:24:44 GMT (Old version)
Another refresh later:
Cf-Ray: 7f5240a71c7ea1f3-YYZ
Date: Fri, 11 Aug 2023 17:38:29 GMT
Last-Modified: Fri, 11 Aug 2023 17:18:28 GMT (Even older version now!)
Hi @SarahA yes, the example I gave in the first post in this thread is still reproducible. Please try running the curl command I gave to check the headers, and you’re welcome to access my account to test out the single-URL cache clear of that specific URL if you have that capability. You’ll observe that even after clearing that URL, you’ll get a ‘HIT’ response with a old cached version.
Note that what we’re experiencing here is only for single-URL cache clearing, and only for specific, seemingly arbitrary URLs. It’s not a problem in general - just for specific URLs.
@SarahA any update here? I really want to do a full cache purge on my site for a recent webapp version upgrade, but I’m holding out so that you and your team have a simple, easy to reproduce example.
(If I do a full cache purge it will correctly purge the cache for all URLs - it’s only single-URL cache purge that’s not working, and only for specific, seemingly arbitrary URLs. I.e. single-URL purge works fine for most URLs, but it doesn’t work at all for some.)
Hi there, thank you for your patience here. Sorry you are still facing issues.
Can you please share any example URLs where purge by URL is working as expected?
If these assets are cached by a Worker, I recommend checking your worker script to ensure you are purging the correct URL - you will need to purge the URL that is in the fetch request and not the eyeball URL (the URL seen by the user).
1 Like
In my example, the worker is not changing the URL (only removing the Origin header), so the URL should be identical to the eyeball URL.
I want to highlight again that our implementation has been in place for over two years unchanged with no issues until recently. Given the concurrent reports from other users, I find it unlikely that any of us are doing something wrong.
I suspect there has been a change internally at Cloudflare with the cache key, or purge policy, which causes the purge to not clear the appropriate cached resources. My hypothesis is that it’s now taking into account some previously ignored request header as part of the cache key.
@SarahA I’m not using workers and I want to stress that this is not a user mistake. It is a Cloudflare bug. I’m very confident about that.
Single-URL purge working: [problem solved, url removed]
Single-URL purge not working: [problem solved, url removed]
A full “purge everything” works fine. Single-URL purge works fine for most URLs, but randomly doesn’t work for some, as shown in the above 2 examples. Same behavior via the Cloudflare dashboard UI or via an API request.
I’d like to do a full purge early next week (at the latest), which will destroy this reproducible example, so please do escalate asap while it’s reproducible. You’re welcome to access my account and purge any perchance.org URLs as part of your testing, but note that if you do a full purge, it’ll “fix” that [problem solved, url removed] URL which may not be desirable until you’ve worked out what’s causing the issue.
1 Like
Hi SarahA, we are also not using workers and our individual pages are not being purged from the cache. This is happening for multiple pages on our websites.
We are currently sending the body as follows to the following endpoint https://api.cloudflare.com/client/v4 /zones/{identifier}/purge_cache.
{"files": [
"https://www.example.com/link1",
"https://www.example.com/link2",
]}
There doesn’t seem to be any mention of ‘files’ in your api documentation https://developers.cloudflare.com/api/operations/zone-purge?schema_url=https%3A%2F%2Fraw.githubusercontent.com%2Fcloudflare%2Fapi-schemas%2Fmain%2Fopenapi.yaml#purge-cached-content-by-url, do we need to update “files” to “prefixes” to fix this issue?
1 Like
Same here, this cached URL cannot be purged: https://feeds.listenbox.app/rss/1wAgRAx5FP-/audio.rss
See uncached origin URL https://api.listenbox.app/rss/1wAgRAx5FP-/audio.rss
This cached URL is purgable: https://feeds.listenbox.app/rss/1wAgRAx5FP-/video.rss
“Purge everything” works, but loads servers for the next ~5 hours
1 Like