Repository navigation
Fetch ignoring port #1320
Description
🐛 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.portto 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.
Activity
stale commentedon Jan 9, 2022
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 commentedon Jan 9, 2022
Please keep this open
fix: add warning to `fetch()` calls that will change the requested po…
15 remaining items
caass commentedon Oct 16, 2022
@jfsiii has this been fixed?
Contextualist commentedon Jan 4, 2023
Recently,Custom port is respected only when fetch's URL shares the same second-level domain with the worker's custom domain.fetch()seems to start respecting custom port in deployment. Maybe they have fixed this in the runtime. Can anybody confirm?penalosa commentedon Jan 23, 2023
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
fetchrequests to a custom port within your own Cloudflare zone.codenoid commentedon May 26, 2023
"you should be able to make fetch requests to a custom port within your own Cloudflare zone"
sorry, but wdym by that?
parasdaryanani commentedon Jul 22, 2023
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 commentedon Feb 7, 2024
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 👍