![[DigitalPoint] App for Cloudflare®](/community/data/resource_icons/8/8750.jpg?1692633961){kind=icon}
Client error: GET https://api.cloudflare.com/client/v4/zones/*****/rulesets/phases/http_request_cache_settings/entrypoint resulted in
a 404 Not Found response: { "result": null, "success": false, "errors": [ { "message": "could not find entrypoint ruleset in the h (truncated...) /
{"result":null,"success":false,"errors":[{"message":"could not find entrypoint ruleset in the http_request_cache_settings phase"}],"messages"
:null}
It only applies to guests... so if you click around your site in an Incognito window (not as a logged in user), and you have DevTools open, you can look at the response headers in the HTTP request and look for the cf-cache-status header. It will show "HIT" if it's being served from cache, or "MISS" if it wants to serve it from cache, but it's not cached currently (a subsequent request will turn into HIT after a MISS).
If you look in your normal Cloudflare dashboard, do Cache Rules show up for you in there (under Caching settings)?
Cache XenForo guest pages and Cache XenForo CSS but they are configured for Cache XenForo image proxy. all these three are setup by the addon. is this how it is supposed to be? or guest and css rules also need image proxy type config for ttls?
Yep, that's how it's supposed to be. The reason is for guest pages and CSS, you are just telling Cloudflare to respect the existing headers coming down from XenForo. Image proxy you are telling it to NOT respect the existing headers and override them.
hit on the network tab. kind of fascinating. i imagine this should negate the need for xenforo's own guest caching. i did stop using it a while ago. now wondering if i should stop using redis caching as well as i probably never got it working properly in the first place.
I have no cache rules set up at the moment. Only the following in Page Rules...
****/css.php?css=*
Browser Cache TTL: a year, Edge Cache TTL: a month, Origin Cache Control: OnDigging into their dev documentation as we speak, and I think I finally found the culprit buried...
Yep, that's normal... the new permissions are required to be able to control the settings.
Can you flush your browser cache, logout... and try again by chance (starting as a guest)? There was something I changed a few hours ago that might cause what you are seeing if you somehow visited the site as a guest between 2 and 6 hours ago. In theory it should be sorted now though, but you might have stale cache in your browser.
GET https://api.cloudflare.com/client/v4/zones/snipdigits/rulesets/phases/http_request_cache_settings/entrypoint resulted in a 404 Not Found response: { "result": null, "success": false, "errors": [ { "message": "could not find entrypoint ruleset in the h (truncated...) / {"result":null,"success":false,"errors":[{"message":"could not find entrypoint ruleset in the http_request_cache_settings phase"}],"messages":null}
Tested in an incognito tab as well as entirely different browsers (that were never used to access the site) - exact same result.
max-age=21600, and the fixed/new versions are max-age=1,s-maxage=21600. There should be nothing that is missing the s-maxage portion now unless it was from a stale cached version.
