I did follow the https://developers.cloudflare.com/workers/tutorials/configure-your-cdn in order to deploy the worker and it worked well. Without changing something at CF config or our backend the worker stoped to serve cf-cache-status headers… as a result, only local cache is working, but content isn’t stored at CF’s CDN… I rechecked the tutorials but it seems that nothing changed there… What can be the reason for such weird behaviour?
Looking into the code of the tutorial:
if (!response) {
response = await fetch(`${BUCKET_URL}${url.pathname}`)
const headers = { "cache-control": "public, max-age=14400" }
response = new Response(response.body, { ...response, headers })
event.waitUntil(cache.put(event.request, response.clone()))
}
Cache-control
header is added first. It means if the response returns own cache-control
it will override the one set in the code. Another preconditions you want to check are explained in the documentation.
Thanks for reply. I do understand. My point is that I suddenly stoped to get cf-cache-status
headers from cloudflare on the endpoint which are covered by worker. Though cache-control
(which is added in worker) is exist in response.
It’s hard to tell without more context, could you provide an example request?
curl -i "https://dev-api.assetbox.io/media/01EDX9FGNJJPE40TST64RC1Y0Q/preview?width=540&height=390"
gives no CF-related headers at all, but our worker configured to handle this url
you should provide file extension otherwise Cloudflare cache ignores it. https://support.cloudflare.com/hc/en-us/articles/200172516-Understanding-Cloudflare-s-CDN#h_a01982d4-d5b6-4744-bb9b-a71da62c160a
Mh… was there any update at cloudflare side recently? I am asking because our CDN setup (based on worker) was working for sure with the same URL I provided earlier
Moreover, I’d say the worker even isn’t triggered as cache-control
current value is passed by our backend… According to worker’s logic the value must be max-age=60000
but it’s max-age=2592000
(which is defined at our backend)
I am just trying to understand which infrastructural changes might have caused the worker to break…
I suggest raising a support ticket so the team will help you with diagnosing the exact problem.
This URL https://dev-api.assetbox.io/media/01EDX9FGNJJPE40TST64RC1Y0Q/preview?width=540&height=390
is not enabled for cloudflare at all. The dev-api.assetbox.io
hostname is not orange-clouded.
You’ll need to orange-cloud it in your DNS settings to have HTTP requests flow via Cloudflare - at that point any page rules or workers should execute as per your configuration.
Hi @simon, there is indeed one record (*.assetbox.io) which isn’t proxied but marked as DNS only… But how exactly should I change it? I can’t see any property to change it
If you have a wildcard DNS record, that cannot be orange-clouded. You’d need to define a new A record for dev-api
pointing to the same IP as the *
record and orange-cloud that.
This topic was automatically closed after 30 days. New replies are no longer allowed.