Keen to understand the routing of a request invoked by a worker

[storm forge]

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!

[wanton seal]

I think the beta Trace feature might help you understand this better -> https://developers.cloudflare.com/fundamentals/basic-tasks/trace-request/

[storm forge]

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)

[wanton seal]

It's below "Security Center" on my free account

And it was enabled by default

[raw glen]

Theres a lot of magic in fetch

eG workers subrequests ignore workers on the same zone to prevent the loops you mentioned

But those requests go through all the rules again afaik

[storm forge]

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!

[raw glen]

https://developers.cloudflare.com/workers/runtime-apis/fetch/#_top

It’s implied

Worker to Worker
Worker-to-Worker fetch requests are possible with Service bindings.

[raw glen]

Wdym?

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 origin

!remind 3d add magic to https://developers.cloudflare.com/workers/runtime-apis/fetch/

[agile marten]

I will remind you in 3 days at Oct 26, 2024 at 12:22 UTC

[storm forge]

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 origin

ah, 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

[raw glen]

Id say try it and see

You can also check in the transform rule if it already starts with /updated-path and then skip

Or do that in the worker too

[storm forge]

Id say try it and see

I'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

[storm forge]

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 anywhere

[storm forge]

aha, it is explicitly here https://developers.cloudflare.com/workers/configuration/routing/routes/