Cloudflare Worker fetch() global 不遵守 Cloudflare worker 路由
Cloudflare Worker fetch() global does not respect Cloudflare worker routes
我有一个由 Cloudflare 运行 在 hybrid-app.example
代理的 Web 应用程序
我正在使用 Cloudflare Worker Sites 模式在 hybrid-app.example/static-content/ 托管静态站点。该工作人员正在监听路由 *hybrid-app.example/static-content*。我可以通过导航到 https://hybrid-app.example/static-content/hello.html 并从我的静态站点查看正确的内容来验证此工作器是否已正确配置。
我还有第二个 Cloudflare worker，它使用 worker Router pattern 将 select 页面从静态站点代理到同一域上的虚 URL。特别是，这个 worker 被配置为监听路由 *hybrid-app.example/hello*。在内部，它执行以下操作：
return fetch('https://hybrid-app.example/static-content/hello.html')
但是当我导航到 https://hybrid-app.example/hello 时，我看到 GET 请求 /static-content/hello.html 命中了我的原始服务器。因此，当我在 Cloudflare worker 中调用 fetch 函数时，它似乎在解析请求时没有检查是否与任何其他 worker 路由匹配。我可以使用 Fetch API 的替代方法来强制一个 cloudflare worker 的请求在解析之前检查其他匹配的 CF worker 路由吗？
这是不可能的； Cloudflare worker 总是绕过 Cloudflare（包括将请求路由到 worker 的步骤）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.)
我有一个由 Cloudflare 运行 在 hybrid-app.example
我正在使用 Cloudflare Worker Sites 模式在 hybrid-app.example/static-content/ 托管静态站点。该工作人员正在监听路由 *hybrid-app.example/static-content*。我可以通过导航到 https://hybrid-app.example/static-content/hello.html 并从我的静态站点查看正确的内容来验证此工作器是否已正确配置。
我还有第二个 Cloudflare worker，它使用 worker Router pattern 将 select 页面从静态站点代理到同一域上的虚 URL。特别是，这个 worker 被配置为监听路由 *hybrid-app.example/hello*。在内部，它执行以下操作：
return fetch('https://hybrid-app.example/static-content/hello.html')
但是当我导航到 https://hybrid-app.example/hello 时，我看到 GET 请求 /static-content/hello.html 命中了我的原始服务器。因此，当我在 Cloudflare worker 中调用 fetch 函数时，它似乎在解析请求时没有检查是否与任何其他 worker 路由匹配。我可以使用 Fetch API 的替代方法来强制一个 cloudflare worker 的请求在解析之前检查其他匹配的 CF worker 路由吗？
这是不可能的； Cloudflare worker 总是绕过 Cloudflare（包括将请求路由到 worker 的步骤）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.)