I have a web application that is proxied by Cloudflare running at hybrid-app.example
I am using the Cloudflare Worker Sites pattern to host a static site at hybrid-app.example/static-content/. This worker is listening on the route *hybrid-app.example/static-content*. I can verify that this worker is configured correctly by navigating to https://hybrid-app.example/static-content/hello.html, and seeing the correct content from my static site.
I also have a second Cloudflare worker that uses the worker Router pattern to proxy select pages from the static site to vanity URLs on the same domain. In particular, this worker is configured to listen on the route *hybrid-app.example/hello*. Internally, it does the following:
return fetch('https://hybrid-app.example/static-content/hello.html')
But when I navigate to https://hybrid-app.example/hello, I see a GET request to /static-content/hello.html hit my origin server. So it appears that when I called fetch function in a Cloudflare worker, it is resolving the request without checking for matches against any other worker routes. Is there an alternative to the Fetch API I can use to force a request from one cloudflare worker to check for other matching CF worker routes before resolving?
This is not possible; Cloudflare workers always bypass Cloudflare (including the step where requests are routed to workers) for requests in the same zone:
Regarding worker composition (one worker invoking another worker): such request chaining isn’t possible on same-zone subrequests. Instead, we always send those to the origin. This limitation is in place to resolve an ambiguity: how do we know that a subrequest is “trusted” and should be sent directly to the origin, versus “untrusted” and should go in the front door, running all Cloudflare features (including Workers) from the start? (Note that this ambiguity doesn’t exist for cross-zone subrequests: such subrequests are obviously untrusted from the perspective of the other zone.)