webpack-dev-server icon indicating copy to clipboard operation
webpack-dev-server copied to clipboard

localhost is applying port to the URL provided to `client-web-socket-url`

Open hobgoblina opened this issue 3 years ago • 6 comments

Bug report

My local port is wrongly being mapped onto the URL provided to the client-web-socket-url CLI parameter.

Actual Behavior

  1. I set client-web-socket-url to wss://example.com/ws and visit the webpage at localhost:8910.
  2. It attempts to establish a socket wss://example.com:8910/ws.

I can set the port that's provided to client-web-socket-url, and only 443 is getting overwritten. For example, the following works fine:

  1. I set client-web-socket-url to wss://example.com:80/ws and visit the webpage at localhost:8910.
  2. It attempts to establish a socket wss://example.com:80/ws.

But here the port gets overwritten:

  1. I set client-web-socket-url to wss://example.com:443/ws and visit the webpage at localhost:8910.
  2. It attempts to establish a socket wss://example.com:8910/ws.

Expected Behavior

localhost shouldn't be modifying the URL's port at all

How Do We Reproduce?

You'll need to be accessing an interface from localhost and set client-web-socket-url to a URL at 443 (unsure if it would still overwrite the port if webpack server was at a non-443 port).

I'm using a gitpod instance and gitpod's localhost companion to access the app at http://localhost:8910, with the client-web-socket-url set to the workspace's URL: https://gitpod.io/#https://github.com/redwoodjs/gitpod-starter/pull/32

Please paste the results of npx webpack-cli info here, and mention other relevant information

System: OS: Linux 5.15 Ubuntu 20.04.4 LTS (Focal Fossa) CPU: (16) x64 AMD EPYC 7B13 Memory: 37.35 GB / 62.81 GB Binaries: Node: 16.15.1 - ~/.nvm/versions/node/v16.15.1/bin/node Yarn: 3.2.0 - ~/.nvm/versions/node/v16.15.1/bin/yarn npm: 8.11.0 - ~/.nvm/versions/node/v16.15.1/bin/npm Monorepos: Yarn Workspaces: 3.2.0

hobgoblina avatar Jul 09 '22 00:07 hobgoblina

hm, we can't connect to https when you on http, you should use https everything, is localhost:8910 undert https?

alexander-akait avatar Jul 10 '22 19:07 alexander-akait

No, it's not. Why is that a limitation? Is there a way around it?

hobgoblina avatar Jul 10 '22 21:07 hobgoblina

@necropolina enable https via --https or use server: { type: 'https' }

snitin315 avatar Jul 11 '22 02:07 snitin315

Hmm, that's making the react app inaccessible (502s) for some reason.

hobgoblina avatar Jul 11 '22 04:07 hobgoblina

@necropolina

There are some questions:

  1. Do you need HTTPs for the all website or only for workers?
  2. Why you want to mix HTTP and HTTPS (and we don't be align with one protocol?)
  3. Why don't use /etc/hosts?

alexander-akait avatar Jul 11 '22 15:07 alexander-akait

This is for using Gitpod in which the dev workspace that hosts the webpack server is containerized, non-local, and created on the fly. When using gitpod, devs have a couple options for access ports/interfaces that are exposed in the workspace:

  1. Gitpod creates URLs for each exposed port (ie, port 3000 would be available at a URL that looks something like 3000-some-workspace-subdomain.gitpod.io). These URLs are served over https. When accessing interfaces via these URLs, I'm able to get webpack working simply by pointing client-web-socket-url at the right URL.
  2. Gitpod also has a "local companion" which establishes an SSH tunnel to the workspace and broadcasts the workspace's exposed ports on your localhost. (ie, that exposed port 3000 is available at localhost:3000 even though nothing is actually being hosted by your local machine) When using local companion, I can get webpack to work by just pointing it at the port that's exposed on my localhost.

I'm trying to come up with a single configuration that works for both use cases - so I'm hoping to use the workspace's URL when accessing the interface via localhost.

hobgoblina avatar Jul 11 '22 17:07 hobgoblina

Closing due to inactivity. Thanks! Feel free to feedback

alexander-akait avatar Apr 24 '24 14:04 alexander-akait