Problem with Enforcing WebSocket Host and Server Host Match

[evaera]

• Operating System: Windows 10
• Node Version: 8.10.0 LTS
• NPM Version: 5.6.0
• webpack Version: 4.1.1
• webpack-serve Version: 0.2.0

This issue is for a:

• bug
• feature request
• modification request

Code

CLI Command

  $ webpack-serve

webpack.config.js

module.exports = {
  port: 9090,
  host: '0.0.0.0',
  content: '../../assets',
  clipboard: false,
  hot: {
    port: 9091,
    host: 'localhost'
  }
}

Expected Behavior

When run from a Docker container, webpack-serve must be bound on 0.0.0.0 in order for the server to be accessible at localhost on the parent machine. However, hot-client must be set to host localhost in order for the container to receive the connection.

Actual Behavior

An error was thrown while starting webpack-serve.
   Error: webpack-serve: The `hot.host` property must match `host` option.

When the hot.host option is omitted, hot-client attempts to connect to an invalid address.

WebSocket connection to 'ws://0.0.0.0:9091/' failed: Error in connection establishment: net::ERR_ADDRESS_INVALID

How Do We Reproduce?

• Install webpack-serve inside of a Docker container, use the above configuration.
• Attempt to start webpack-serve from inside the container. The above error will appear.

New Feature Use Case

The ability to configure where the emitted bundle tries to connect via WebSocket will enable many use cases beyond just Docker. Since this is a tool for development, it's important to be flexible and not disrupt workflow with needless red tape when this could just be a base option.

[shellscape]

Thanks for the issue 🍺

Unfortunately this looks like it's a problem with your environment, rather than with webpack-serve, as that scenario works perfectly fine using 0.0.0.0 as the host.

[evaera]

On Windows 10, I am unable to directly connect to the address 0.0.0.0, no matter what is listening on that host. I don't believe that 0.0.0.0 is intended to be used as a loopback address, but rather to indicate that a server should bind to all interfaces. To clarify, when connecting to the container, the address in the URL bar is http://localhost:9090, but webpack-serve is bound to the host 0.0.0.0 only inside the container so that it's visible externally.

Even if this is only a problem on Windows machines, maybe it is still worth making the requirements less strict on that rule? If that check was changed to make room for this case, then it would work as expected. The problem is only that the library is checking if the hosts match instead of trusting the developer. 🙂

[shellscape]

There's a lengthy discussion on 0.0.0.0 and how it's a completely valid address for development here: webpack-contrib/webpack-hot-client#30. Looks like you'll have to use a host other than 0.0.0.0 in docker/Windows and setup some proper routing in your container.

[evaera]

Would it not be more user friendly to add a special exception for those who cannot use 0.0.0.0 as a loopback address during development? It's standard practice to use 0.0.0.0 when you want to listen on all interfaces. Having to do something special here just because of one line of code in the package feels like it will waste a lot of development time in the long run.

Webpack-serve is only listening to sockets that originate from localhost (inside the container) if you do not tell it to bind on 0.0.0.0. I am not sure how to tell webpack-serve to listen on other interfaces without doing that. And if I do that, then it breaks the code that's sent in the bundled file, because it's trying to connect to 0.0.0.0 which is not valid on Windows.

I don't think I can fix that unless I use a reverse-proxy inside the container to capture requests and then pass them on to the local instance of webpack-serve. That seems like a lot of extra steps just for a tool that's meant to be used in development. Would you reconsider, please?

[shellscape]

Would it not be more user friendly to add a special exception

More user-friendly for the very few people who need that capability, yes. More technical debt and maintenance for the project, also yes. You have an edge case. You'll have to find a way to make it work in your specific environment since your environment behaves in a way that doesn't match spec.

Webpack-serve is only listening to sockets that originate from localhost

That's not actually true. webpack-hot-client is responsible for that.

Would you reconsider, please?

No, sorry. There are reasonable workarounds, and alternatives (like old crusty webpack-dev-server), if you need support in a wonky env.

[evaera]

Using Docker containers in development to ensure that the environment is as close to production as possible doesn't seem to be that uncommon. I don't believe that my environment is wonky; it's just plain old Windows 10. I haven't changed anything in my network settings.

The reason I came to this project was because the webpack-dev-server repository has a notice that says that this project is a fast alternative because that project is not receiving feature updates.

Could you shed a little light on why the host setting must match the hot.host setting? It's possible I don't understand fully what the hot.host setting affects.

If it's just related to the output, perhaps changing the error to a warning could enable even more use cases that are beyond just this. If a developer wants to change the settings and knows what they are doing, why not let them?

[evaera]

If the hot.host setting is related to more than just the output bundled file, what would you think about adding a new config option that allows the developer to change the host that the outputted js connects to via WebSocket?

More power to the developer is always great. 😄

[shellscape]

I'll leave this issue open for discussion for a while in the event other users would like to talk about how to solve this on the user-side of things. You asked me if I would reconsider that change and I gave my answer. At this point more comments aren't going to change that direction. Glad you found this project useful, but it seems you need more customization that the project can provide at this point, and should probably pursue an alternative like webpack-dev-server. I think I've been accommodating in discussing the issue, even though you didn't get the answer you were after, and will be leaving it at that for the time being.

[amokrushin]

webpack-dev-server allow to set public different from host, but has issue with hard coded /sockjs-node for over the years.
Now the same issue was migrated to webpack-serve in another guise named:

The hot.host property must match host option.

[Cweili]

@shellscape Thanks for your nice job here.

Our team is facing similar problems.

We are developing a mobile web app based on a Chinese application platform called Wechat. It's used very widely in China. But services based on it have to use the https protocol on the Internet for secure.

We coding on Windows 10 and using mobile phones to debug our pages in company's internal network. But we also need to visit the pages from Internet through ngrok which forwarding public URL to localhost server.

We add entry webpack-dev-server/client?/ and setting webpack-dev-server to listen on 0.0.0.0 before, so both internal network IP address and localhost works well.

But now we will see:

WebSocket connection to 'ws://0.0.0.0:8081/' failed: Error in connection establishment: net::ERR_ADDRESS_INVALID

[gponsu]

To work within docker, you must expose the WebSocket Server port (8081). For example, my docker-compose.yml:

version: '3'
services:
  app:
    image: node:9.8.0
    working_dir: /usr/local/app
    command: npm start
    ports:
      - 8080:8080
      - 8081:8081
    volumes:
      - ./:/usr/local/app
      - node_modules:/app/node_modules

volumes:        
  node_modules:

I think that will solve your problem, although the hot reloading does not work because of this issue: webpack-contrib/webpack-hot-client#26

[evaera]

The problem is because the outputted JS tries to connect to the bind address, but this doesn't work because the network inside the container isn't the same as on the host machine. The correct ports are exposed, that's not the problem.

Inside the container, we bind on 0.0.0.0 so that the HTTP server can accept connections from outside the container. But the code in the browser on the host machine still tries to connect to that exact address (0.0.0.0), which is incorrect. We need an option to configure the address the bundled JS connects to.

[gponsu]

It's working for me.

By default, Docker exposes container ports to the IP address 0.0.0.0 and how webpack-hot-client is running inside of the container, you need publish the port 8081. It's easy.

[evaera]

0.0.0.0 is not a valid loopback address on all platforms, and according to all resources I can find online when Googling. It doesn't work for me and others on Windows 10. 0.0.0.0 is generally considered to be a listen-only address, and the ability to connect to this address varies by platform and is not standardized.

See:
https://en.wikipedia.org/wiki/0.0.0.0
https://superuser.com/questions/949428/whats-the-difference-between-127-0-0-1-and-0-0-0-0
https://www.lifewire.com/four-zero-ip-address-818384

0.0.0.0 is a non-routable meta-address used to designate an invalid, unknown or non applicable target (a no particular address placeholder).

[amokrushin]

@gponsu, in general issue not in 0.0.0.0, but in unconfigurable public address of websocket

webpack-dev-server has required option, webpack-serve not

I believe this picture can clarify the situation

As discussed above, case 1 do not work on Windows 10. Case 2 do not work nowhere.

[evaera]

^ Yeah, it's important to keep the general application of this issue in mind. Even if I could connect to 0.0.0.0 on my device, this would still be a problem because testing on other devices like phones and tablets is a valid use case. Not possible to do that without a configuration option to tell the browser where to connect to.

0.0.0.0 means "bind on all interfaces" in this context, so there is no way to just automatically guess where the browser should point. The host option and where the browser should connect to are just fundamentally different configuration points, and that should be reflected in the code.

This is a small change that would vastly expand the flexibility of the project. It's a shame that @shellscape won't hear us out.

[gponsu]

Then it is a problem with your environment and I understand that @shellscape is not going to do anything. If you think it's a small change, you should create a pull request. Although I think it will be better if you configure your environment correctly.

[evaera]

This is not a problem with anyone's environment. This is a limitation of this project. I don't see what all the fuss about; letting the developer control their development tool to fit their needs seems like a no-brainer. Right now, this project is making assumptions about where to connect; what is proposed just allows the developer to specify if they wish.

I'm not going to spend my time acquainting myself with a code base I'm completely unfamiliar with and creating a pull request if it's just going to get declined.

[shellscape]

@evaera you might find the legacy webpack-dev-server more to your liking, or you can roll a simple koa/express server setup using webpack-hot-client and webpack-dev-middleware, for your particular devops scenario. you might find the latter to be a better use of energy.

[evaera]

Alright, I give up. I don't understand the reason behind not letting the developer control this when there are valid use cases and people who want this functionality popping up in just a few days, probably more people who didn't even think to check the issues section, but I don't think the community can convince the managers otherwise, so I'm just going to close this issue and try to find another solution that is more accommodating to its developers.

[nmschulte]

@evaera webpack-contrib/webpack-hot-client#34

[jonesnc]

I also would like to see this feature. Developing on a Mac with docker-machine requires me to be able to set the server host to 0.0.0.0, and the client host to whatever IP address happens to be assigned to the docker-machine VM's IP address (e.g., 192.168.64.7).

[jonesnc]

@nmschulte I tried passing a client and server host with the following webpack config

serve: {
    host: {
        client: '192.168.64.7', // IP Address of my docker-machine VM
        server: '0.0.0.0'
    },
    port: '8081'
}

but webpack-serve doesn't honor my port config option.

⚠ ｢hot｣: `options.host.client` does not match `options.host.server`. This can cause unpredictable behavior in the browser.
ℹ ｢hot｣: webpack: Compiling...
ℹ ｢serve｣: Project is running at http://[object Object]:35383
⚠ ｢serve｣: Failed to copy server URI to clipboard. Use logLevel: 'debug' for more information.
ℹ ｢hot｣: WebSocket Server Listening at 0.0.0.0:45995

[evaera]

@jonesnc I'm seeing that too, I think you should open a new issue for that though

[nmschulte]

This must be a webpack-serve issue, using webpack-hot-client directly shows it works as advertised.

[jonesnc]

@evaera @nmschulte I created a new issue regarding this behavior: #89. If you could add any details you have found, I would really appreciate it!

[czerasz]

@jonesnc the issue seems to be resolved with this #34.

I use "webpack-serve": "^0.3.1" in the package.json:

{
  "name": "app",
  "version": "1.0.0",
  "private": true,
  "scripts": {
    "start": "LOCAL_IP=`hostname -i` webpack-serve --config ./webpack.config.js --mode 'development'",
    ...
  },
  "devDependencies": {
    ...
    "webpack-serve": "^0.3.1"
  },
  ...
}

with the following webpack.config.js:

module.exports = {
  ...
  serve: {
    host: '0.0.0.0',
    hot: {
      host: {
        server: '0.0.0.0',
        client: process.env.LOCAL_IP
      }
    }
  },
  ...
}

And it works!

[amokrushin]

@czerasz #90 too