spence Posts - Answer Overflow

spence

•Created by spence on 6/29/2023 in #workers-help

Making a fetch to a bound service gets "The script will never generate a response." error

I'm seeing this issue only when a new request is constructed, not when a request is constructed from another request. For example:

async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
  env.v1_API.fetch(new Request("https://foo.com/v1/toml/parse", request))

async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
  env.v1_API.fetch(new Request("https://foo.com/v1/toml/parse", request))

Succeeds, however

async email(initialEmail: ForwardableEmailMessage, env: Env, ctx: ExecutionContext) {
  return env.v1_API.fetch(new Request("https://foo.com/v1/toml/parse"))

async email(initialEmail: ForwardableEmailMessage, env: Env, ctx: ExecutionContext) {
  return env.v1_API.fetch(new Request("https://foo.com/v1/toml/parse"))

fails. The exact same failure comes within the context of the fetch handler if the original request object is not included in the constructor of the new request. Is this a bug?

2 replies

CDCloudflare Developers

•Created by spence on 5/30/2023 in #workers-help

Worker routing not behaving as expected, when the route route is a path below the root of the domain

Hi, I initially tried this in #🦀workers-rs but didn't get a response, so I'm trying again here. (Note: example.com is used instead of the domain). The tl;dr is my worker functions correctly if the trigger is at the domain root, i.e. .com/*. For triggers where the route is served from a path below the root, i.e. .com/v1/email/parse/*, I just get Not Found responses. More details below. As an experiment I have two triggers, as follows: https://api.example.com/* https://api.example.com/v1/email/parse/* And my worker has the following routes:

.post_async("/" [...]
.post_async("/text/" [...]
.get_async("/" [...]

.post_async("/" [...]
.post_async("/text/" [...]
.get_async("/" [...]

Curl has the following results:

# the following are all sent to https://api.example.com/*
curl https://api.example.com/                               # OK
curl https://api.example.com                                # OK
curl --data-binary @email.txt https://api.example.com/      # JSON of a parsed email
curl --data-binary @email.txt https://api.example.com/text/ # JSON of a parsed email

# But when I try to use https://api.example.com/v1/email/parse/*
curl https://api.example.com/v1/email/parse/                # Not Found
curl https://api.example.com/v1/email/parse                 # Not Found
curl --data-binary @email.txt https://api.example.com/v1/email/parse # Not Found
curl --data-binary @email.txt https://api.example.com/v1/email/parse/text/ # Not Found

# the following are all sent to https://api.example.com/*
curl https://api.example.com/                               # OK
curl https://api.example.com                                # OK
curl --data-binary @email.txt https://api.example.com/      # JSON of a parsed email
curl --data-binary @email.txt https://api.example.com/text/ # JSON of a parsed email

# But when I try to use https://api.example.com/v1/email/parse/*
curl https://api.example.com/v1/email/parse/                # Not Found
curl https://api.example.com/v1/email/parse                 # Not Found
curl --data-binary @email.txt https://api.example.com/v1/email/parse # Not Found
curl --data-binary @email.txt https://api.example.com/v1/email/parse/text/ # Not Found

Since I'm getting a Not Found response (instead of 522), I think that indicates that the requests are actually being routed to the correct place, and that the issue is not with the worker platform itself. Probably the underlying issue is either I'm not understanding something correctly or maybe a problem with the rust routing/pattern stuff? Does anyone have any suggestions? Thank you. P.S: maybe it has to do with the new custom domains for workers thing.

22 replies

Gaming

Programming