Fetch ignoring port

[RihanArfan]

🐛 Bug Report

I'm having an extremely strange issue where Fetch() completely ignores any custom port when actually running in the deployed Worker but from the quick editor, it works as expected.

I've gotten the Worker as simplified as much as possible to try and debug this issue. To explain the test, I have Nginx running on 443 and another application on 4567.

Steps to reproduce

addEventListener('fetch', event => {
  event.respondWith(rewriteURL(event.request))
})
 
async function rewriteURL(request) {
  let urlWithPort = new URL("https://test.file.properties:4567/download/file")
  urlWithPort.port = 9055
  //return new Response(urlWithPort) - shows the port 9055 in the URL, as it should.
  const response = await fetch(urlWithPort, request)
  return response
}

What did you expect to see?

• When I test this code from the quick editor, I get 502 (expected) because I specified port 9055 and it's using that as I told it to
• When I test this code by visiting the deployed URL, I get an Nginx 404 page (so it's completely ignoring port 9055)
• If you change urlWithPort.port to 4567 (or remove it), the quick editor will successfully return it from the application running on port 4567 (expect some JSON error about processing the request because the application expects some headers and parameters)

I'm expecting the deployed Worker to use the custom specified port when doing Fetch() just like it does on the quick editor.

--
Wrangler wasn't used to create this worker, so I didn't specify any environment. I've entirely used the online quick editor.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 180 days. It will be closed if no further activity occurs in the next week. Please feel free to comment if you'd like it to remain open, and thank you for your contributions.

[RihanArfan]

Please keep this open

[threepointone]

Let's leave this open till we ship a fix in the runtime

[jfsiii]

@threepointone can you reopen this? I think the release notes closed it

[threepointone]

Whoops, reopening

[davidkarlsson]

I think maybe this fix broke running the wrangler dev server if you are using Yarn 3 PnP? From version 2.0.16 and onwards I now get the following error when I try to start the dev server with yarn wrangler dev:

X [ERROR] Could not read from file: D:\Code\Cloudflare\Test\.yarn\cache\wrangler-npm-2.0.16-25a529adf2-67d437092c.zip\node_modules\wrangler\templates\checked-fetch.js


X [ERROR] Build failed with 1 error:

  error: Could not read from file:
  D:\Code\Cloudflare\Test\.yarn\cache\wrangler-npm-2.0.16-25a529adf2-67d437092c.zip\node_modules\wrangler\templates\checked-fetch.js

[threepointone]

Good catch! Fix incoming.

[caass]

@jfsiii has this been fixed?

[Contextualist]

Recently, fetch() seems to start respecting custom port in deployment. Maybe they have fixed this in the runtime. Can anybody confirm? Custom port is respected only when fetch's URL shares the same second-level domain with the worker's custom domain.

[penalosa]

We're going to close this for now as it's dependent on internal Cloudflare changes. For now, fetch ignoring custom ports is considered behaviour as designed, but that may be revisited in the future. Of note—you should be able to make fetch requests to a custom port within your own Cloudflare zone.

[codenoid]

"you should be able to make fetch requests to a custom port within your own Cloudflare zone"

sorry, but wdym by that?

[parasdaryanani]

For whomever this may help:

I recently had this issue and ended up using AWS API Gateway as a http proxy to forward requests to the custom port origin. It took only a few clicks and meant that I could continue using workers as usual. It costs pennies per month and its Edge optimised as well.

[lrapoport-cf]

hi all 👋 we see this issue has been re-opened. however, we have discussed again internally and can confirm this behavior is a consequence of the interaction between the workers runtime and the rest of cloudflare's systems and isn't related to wrangler, so we are going to re-close the issue. however, there is an open internal ticket to track this: EW-1281. we note that there is not currently a timeline on this, and it's not on the immediate roadmap for the relevant team.

@codenoid in terms of a fetch to a custom port on your own cloudflare zone (see https://developers.cloudflare.com/fundamentals/setup/accounts-and-zones/#zones for reference), this won't work in wrangler dev, but will work when your worker is deployed to the cloudflare network 👍