Purge cache (single URL) is not working, neither on browser nor via API. It is only hapenning for some URLs.
For instance,
https://osp-assets.pn.vg/e42c2dd6-2e1a-48b4-8551-d47ce741a093.json
has the outdated version of my file, and if you add any query param (for instance, ?a=1), it will return the correct version of the file:
https://osp-assets.pn.vg/e42c2dd6-2e1a-48b4-8551-d47ce741a093.json?a=1
(one of the differences is that, in the correct one, it has the string “00:02”)
The curl I’m using (using both the URL and the json object is maybe unnecessary, but doing it either way won’t work):
curl --request POST \
--url https://api.cloudflare.com/client/v4/zones/<zone>/purge_cache \
--data '{
"files":
[
"https://osp-assets.pn.vg/e42c2dd6-2e1a-48b4-8551-d47ce741a093.json",
{
"url": "https://osp-assets.pn.vg/e42c2dd6-2e1a-48b4-8551-d47ce741a093.json",
"headers": {
"Origin": "https://www.lebiscuit.com.br/"
}
}
]
}'
Again, as a reminder, purging other URLs work normally. Only a few URLs aren’t working.
3 Likes
I have exactly the same problem with you. Purging is not working at some of my pages from a few days ago.I dont know the reason why.
1 Like
I have the same exact issue, can someone escalate this, please? It used to work perfectly so it seems some recent update affected this.
It works for some URL files but doesn’t for others. Here is one example where it doesn’t work:
https://static.personizely.net/370ae018b5.js
1 Like
Any updates to this issue?
Apparently, the issue has been resolved. If you purge your URLs and still face this issue, please open a ticket and share the ticket number here, as well as details such as the URL that is not purging and what kind of content we should be looking for that would assure the page isn’t purging.
It was not an issue with the purge as a whole, since other files could be purged normally – the bug only applies to a few URLs. The issue is still happening.
I posted here since we do not have the business plan and therefore can’t open tickets.
The problematic URL. Its content should have the string 00:02 in it:
https://osp-assets.pn.vg/e42c2dd6-2e1a-48b4-8551-d47ce741a093.json
If you add a query string to bypass the cache (any query string really), it will return the 00:02:
https://osp-assets.pn.vg/e42c2dd6-2e1a-48b4-8551-d47ce741a093.json?a=anything
Yes, I understand it. The Status page I linked to refers to an issue with single-page cache purging, so I thought that would have fixed your problem. Now I can see both the old and the new content.
What’s your cache config in Cloudflare for that URL? Do you have any cache-related Page Rule? A Cache Rule? Are you using R2 or APO for WordPress?
We do not have any special cache-related configuration for this URL – all other URLs are exactly the same in terms of config. We do not have any cache-related Page Rule or Cache Rule.
We are not using R2 or APO. This file is hosted in an AWS S3 bucket. An example where the single-file cache purge is working normally (the contents are the same):
https://osp-assets.pn.vg/07ac8f68-9a3b-47b0-9d4b-af4cb0c36f43.json
https://osp-assets.pn.vg/07ac8f68-9a3b-47b0-9d4b-af4cb0c36f43.json?a=anything
Though initially I was able to reproduce the issue, I now only see the updated version, on 4 browsers and 2 colos. Can you check whether if you reload the file (or load it in a separate browser tab) it will load the correct version?
You are correct, the version was updated. I’m terribly sorry, but we do not have full control of when these files will be updated, since they are not controlled directly by us.
I just uploaded the file again and did the single-file cache purge: (now the “old” file will have the 00:02, and the updated one will have the 00:00)
https://osp-assets.pn.vg/e42c2dd6-2e1a-48b4-8551-d47ce741a093.json
https://osp-assets.pn.vg/e42c2dd6-2e1a-48b4-8551-d47ce741a093.json?a=123
Do you mean other JSON files? Do they also carry the same Cache-Control header?
Yes, I mean other JSON files. They do carry the same Cache-Control header.
You said there’s no cache-related rule for these JSON files, but JSON is not one of the file extensions Cloudflare caches by default. The Cache-Control is passed on to the browser, and it does instruct caching for a month.
When you see a HIT on the cf-cache-status header, it’s not that the JSON file was cached, but rather that the 304 response (revalidation) was returned from Cloudflare. That’s why, it seems to me, purging cache for that URL won’t work by itself.
My guess at this point is that either a) your origin is somehow not returning the proper Last-Modified header; 2) not returning the proper Etag; or 3) not returning at least one of them every time there’s a request for the file from a browser. If that happens, Cloudflare’s Smart Edge Revalidation could be at play here IF the file was cacheable, but you say there’s no cache rule for it.
Do you have an URL for a JSON file that is behaving correctly?
You are correct, I meant that this specific JSON (all of them, actually) do not have a special page rule. All of them are cached in the same manner (basically, cache everything on osp-assets.pn.vg/*).
All of the other URLs for JSON files (or at least 99% of them, since we haven’t had any problems with others) behave correctly.
What the code basically does is that it uploads the JSON to an S3 bucket and purges cache of this specific single file. The process is the same for all of them – it works for all other JSON files.
Other examples of JSON files that are behaving correctly:
https://osp-assets.pn.vg/07ac8f68-9a3b-47b0-9d4b-af4cb0c36f43.json
https://osp-assets.pn.vg/e188a0b2-5cb6-4d85-93aa-6f5d324875a3.json
https://osp-assets.pn.vg/e8ce52e5-9648-45db-9a0b-3eda30d92bdf.json
If you have an URL for that file that would fetch it directly from the S3 bucket, you could write a script to fetch it every so many seconds and save the Last-Modified and Etag headers, see if you find any inconsistencies. The script would have to send the request headers If-Modified-Since and If-None-Match, to instruct the origin to respond with those headers.
You can try creating a Cache Rule for the problematic URL with the following settings:
Eligible for cache.
Edge Cache TTL: 10 seconds
Browser Cache TTL: Respect origin
Status Code 304 no-store
I have no means of testing whether this rule would work, it’s a trial and error attempt.
I might write the script to save the last-modified and etag headers, but I’m not entirely sure what would I do with the information.
By the way, the last-modified and etag headers are always being sent, without the If-Modified-Since and If-None-Match headers. They seem to be set correctly in the origin, being changed accordingly whenever the content is changed
The cache rule is a nice idea, but unfortunately I cannot implement it since I already used my three rules (I might at least test it later today)
Unlike Page Rules, Cache Rules has a limit of 10 rules in the Free Plan.
Right; just tested it and it does not work.
purging this cached URL does not work Listen Later
see uncached origin URL Listen Later