CDN is broken for at least a couple of weeks

Performance
#1

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?

#2

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.

1 Like
#3

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.

#4

It’s hard to tell without more context, could you provide an example request?

#5

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

#6

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

#7

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

#8

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…

#9

I suggest raising a support ticket so the team will help you with diagnosing the exact problem.

#10

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.

3 Likes
#11

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

#12

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.

1 Like
#13

This topic was automatically closed after 30 days. New replies are no longer allowed.