Wrong protocol for socket url's in a local environment

[micacardillo]

• Operating System: Mac OS Sierra 10.12.6
• Node Version: 6.5.0
• NPM Version: 3.10.3
• webpack Version: 3.8.1
• webpack-dev-server Version: 2.9.4

• This is a bug
• This is a feature request
• This is a modification request

Code

Relevant webpack setting:

devServer: {
  disableHostCheck: true,
 },   

Expected Behavior

When running a webpack dev server on localhost in a development environment, I need the protocol for socket messages to be http, not https even if the location.protocol from the browser is https. In my usecase, an Nginx proxy resolves https requests for a particular host (https://my-domain.com) to the appropriate services (http://localhost:3000, http://localhost:3012, etc). I would then expect socket requests to be http://localhost:3012/sockjs-node/info?t=1510792203948 not https://localhost:3012/sockjs-node/info?t=1510792203948. Note the former is http and the latter is https. The expected behavior for the protocol is 'http' in my usecase.

Actual Behavior

In webpack-dev-server, the browser's protocol, if available, takes precedence over the local protocol. This causes webpack features relying on sockets such as hot module reloading to fail in my environment.

For Bugs; How can we reproduce the behavior?

For Features; What is the motivation and/or use-case for the feature?

I would like to figure out some clean way of setting the protocol to http without necessarily breaking the "security by default" approach that is currently implemented. Is there a way I could solve this without having to shepard PR requests down the food chain (webpack-dev-server --> webpack --> nwb).

The relevant code is client/index.js, line 188 - 190:

if (hostname && (self.location.protocol === 'https:' || urlParts.hostname === '0.0.0.0')) {
  protocol = self.location.protocol;
}

If I submitted a pull request with something like:

if (hostname && (self.location.protocol === 'https:' || urlParts.hostname === '0.0.0.0')) {
  protocol = self.location.protocol;
} else if (hostname) {
  protocol = 'http';
}

is that probably going to break other people's setups? If so, do we take more of a configuration approach where I could set a string? Something like devServer.protocol = 'http' in webpack settings.

[shellscape]

@micacardillo thanks for checking in and for the thorough explanation of what you're looking to have changed. at the moment the core maintainers aren't doing any work involving sockjs for one important reason - we've removed sockjs in favor of native WebSocket in version 3. we would however, welcome and review a pull request to tackle this.

[micacardillo]

I don't think this particular problem is is happening in the socket module. client/index.js seems fairly decoupled from socket implementation. Is there a branch with the sockjs --> WebSocket progress I can take a look at?

[shellscape]

Yes, the beta branch contains those changes. It's not the socket module at issue; it's the configuration of sockjs in the client. Removing sockjs has removed the need to use a long-polling solution like sockjs, and thus the need/concern for a url tied to the socket, as all websockets use the ws:// protocol.

[ProductivePerson]

@micacardillo Did you find a workaround in the meantime? I have the exact same issue and am looking for a short-term solution that can be implemented either in nginx or webpack-dev-server configurations.

Glad to hear this is getting patched out in future versions, looking forward to 3.0!

[ghost]

I have the same problem

[micacardillo]

@ProductivePerson @calepsol No solution yet. The browser sees the sockjs requests as a CORS violation if you change it to http.

[shellscape]

@ProductivePerson "when it's ready." generally speaking, asking about release dates is kind of taboo for most projects. we've got the milestone in the issues here so you can get a real-time view of what is left to do and what has already been done. coupled with the commit history on the branch, you can get a really good idea of where things are. not to pile on you, but this definitely isn't the right forum for that question. you always have the option to pop into the webpack gitter, or even ping one of the folks in the project on twitter. best to allow issues to stay focused on the original topic.

[ProductivePerson]

@shellscape Noted and understand. Thanks for the cultural explanations as well. I'll remove the previous question to clear up the thread.

[AnthonyPaulO]

@shellscape I'm confused by everything I've read regarding the move away from socks as I've been having a similar issue as the OP and have been debugging an issue in webpack-dev-server 3.1.0 and it always seems to want to connect to /socksjs-node/... Has version 3 really migrated away from socks? If so, why do I see what the op is seeing in 3.1.0? Is socks by default and I have to set a flag somewhere to enable websocket support?

[alexander-akait]

/cc @micacardillo Problem still exists?

If somebody has problem please report here about this, any reproducible test repo welcome, thanks!

[alexander-akait]

Closing due to inactivity. Please test with latest version and feel free to reopen if still regressions. Thanks!

[dizel3d]

I have the problem! Do have a solution?

[alexander-akait]

Please don't write "I have a problem", please describe what problem you have (minimum reproducible test repo welcome)

[dizel3d]

@evilebottnawi I'm sorry. But the issue initiator described my problem exactly.
Anyway, I made a reproducible repo.
Thank you!

[alexander-akait]

@dizel3d can you open new issue

[koziarskim]

I can reproduce this as well. I am running vue app locally (http) with nginx proxy also locally (https). I just started debugging it but somehow socksjs is picking up the protocol from publicPath (but not host). I can modify host with socksHost property in dev server, but not protocol. Any progress on this??? Also, I am confused with not using socksjs by devServer. If it's using WebSocket could there be an option to disable sockjs? Seems like it's not needed anyway. Please, give some solution.

[ptixed]

Can you reopen this? I think the best solution would be to make protocol configurable in the same way as host, port and url are. Or is there a reason for this inconsistency?