Hi @hero, @adaptive,
Regarding @hero’s original problem statement: it’s not clear to me whether the workers in question are part of the same zone or not. If they’re on the same zone, then the first worker’s subrequest would go to the “origin”, which doesn’t exist for workers.dev, explaining the 522 error. If they’re on different zones, then the first worker’s subrequest would invoke the second worker, and so we’d need to know what that worker’s behavior is, and how its origin, if any, is configured.
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.)
For example, consider a worker which just modifies request URL paths, and is deployed on
*example.com/*. Should its subrequests go to the origin, or to itself? It may actually have a legitimate recursive design, with a base case that should eventually go to the origin. But how do we know the difference between that base case and the general case?
One possibility might be to require users to explicitly disable workers on their routes that should pass through to the origin, and make recursion be the default. This would make worker configuration painfully complex – essentially broken by default – and does not address the more general question of what other Cloudflare features we should run.
Another possibility might be a policy of only allowing worker composition involving more than 1 worker script. This, too, feels like a footgun: we would have no way of expressing whether a user actually intends for two workers to interact like this or not.
Instead, it seems that we need some sort of support in the Fetch API itself to indicate whether a subrequest should be considered “trusted” and go to the origin, or “untrusted”, and go in the front door, running all Cloudflare features, including Workers. We’ve made progress on designing such a system internally, but it’s slow going.
Note that the lack of Worker composition on same-zone subrequests does not really mitigate an attack vector, because an attacker could just use two zones and accomplish the same thing.