Keen to understand the routing of a request invoked by a worker
I am fairly new to CloudFlare and interested in understanding the flow of my requests when workers are involved.
My current understanding is as follows:
* I have a proxied DNS record (CNAME) for a route in my domain
* As it's proxied, a bunch of CloudFlare rules etc. will be run on my request before being sent to the origin (AWS)
* At the end of this chain, my worker will be invoked - just one worker, based on the most specific matching path (?)
* If my worker then calls
fetch(request) without doing anything else - what happens? The origin that the worker sees is my public-facing CloudFlare URL, not my actual origin (AWS). So to avoid infinite loops for even the most basic of workers, I expect something clever is going on. I'm not sure if the clever thing is
(a) fetch within the worker runtime knowing to change the host to the origin configured in CF DNS (seems unlikely)
(b) Some metadata allowing CF to disable workers for this request, but re-running all other rules
(c) Some metadata allowing CF to disable workers and all other rules for this request
(d) Something else.
My current understanding is that (b) is happening - specifically because I have a transform rule changing the path of one of my requests, and when I try to fetch the request as provided in my worker - the path appears to be being modified again.
Thank you!8 Replies
I think the beta Trace feature might help you understand this better -> https://developers.cloudflare.com/fundamentals/basic-tasks/trace-request/
Cloudflare Docs
Trace a request | Cloudflare Fundamentals docs
Cloudflare Trace (beta) follows an HTTP/S request through Cloudflare’s reverse proxy to your origin. Use this tool to understand how different Cloudflare configurations interact with an HTTP/S request for one of your hostnames. If the hostname you are testing is not proxied by Cloudflare, Cloudflare Trace will still return all the configurations...
sounds cool! But I cannot see it as an option (I'm working on a client's Cloudflare account, so I suspect it's just not enabled)
It's below "Security Center" on my free account
And it was enabled by default
nice - that matches my experimental evidence 😄
Do you know if that's documented somewhere I've missed?
in terms of my actual next steps I've resigned myself to specifying the origin directly in the worker, which I don't especially like (as we're now configuring the origin twice, once in the DNS record and once in the worker) - but I like it more than undoing the transform rule in the worker to allow it to run through the rules again!
:zep_check: I will remind you in 3 days at Oct 26, 2024 at 12:22 UTC
In the last step of your original message, it starts the chain again but skipping the last step and then following the CNAME to your originah, but in the original chain for my request I have a transform rule appending
/updated-path to the path. So running through the rules a second time makes it /updated-path/updated-path
Id say try it and seeI've tried it, and while I haven't confirmed that the double path is happening, I'm seeing responses from AWS that are consistent with that occurring to conform the other assumption in my understanding:
just one worker, based on the most specific matching path (?)
Is this correct? It feels like what's happening, but I don't think I've read it explicitly anywhereaha, it is explicitly here https://developers.cloudflare.com/workers/configuration/routing/routes/
Cloudflare Docs
Routes | Cloudflare Workers docs
Routes allow users to map a URL pattern to a Worker. When a request comes in to the Cloudflare network that matches the specified URL pattern, your Worker will execute on that route.
Reminder for @Leo: add magic to https://developers.cloudflare.com/workers/runtime-apis/fetch/
Set <t:1729686165:R>