Webpack-dev-server: devServer.public does not use window.location

[dantodev]

• Operating System: Ubuntu 16.04.03 LTS
• Node Version: 8.14.0
• NPM Version: 6.7.0
• webpack Version: 4.28.4
• webpack-dev-server Version: 3.1.14

• [x] This is a bug
• [ ] This is a modification request

Code

// webpack.config.js
{
    // ...
    devServer: {
        host: '0.0.0.0',
        port: 9000,
        compress: true,
        inline: true,
        hot: true,
        clientLogLevel: 'info',
        disableHostCheck: true,
        historyApiFallback: {
            index: '/',
        },
        headers: {
            "Access-Control-Allow-Origin": "*",
            "Access-Control-Allow-Methods": "GET, POST",
            "Access-Control-Allow-Headers": "X-Requested-With, Content-Type, Authorization, Accept, Cookie"
        },
        overlay: true,
    },
    // ...
}

Expected Behavior

devServer.public is not set. The docs say that in this case window.location will be used.

It will try to guess the URL of the server based on window.location

Actual Behavior

I am running webpack-dev-server behind nginx with multiple possible domain names. It does not seam like window.location is used. window.location.hostname is one of the domains nginx would forward to webpack-dev-server but sockjs websocket is connecting to an ip instead of the hostname.

See also #1312.

For Bugs; How can we reproduce the behavior?

Use webpack-dev-server behind nginxand dont define devServer.public in webpack configuration.

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

[alexander-akait]

You should don't use nginx, it is expected, where sockjs should get your domain? Please provide minimum reproducible test repo otherwise issue was closed

[dantodev]

Maybe this is not even a bug, but rather a mistake in the docs like the issue #1312 says:

It looks like if public is not specified it reverts to http://localhost:8080.

At least the webpack generates /* WEBPACK VAR INJECTION */}.call(exports, "?http://localhost:8080")) for the webpack-dev-server client.

I also could not find any relevant traces of window.location in the source code.

The issue #1312 has been close because it did not used the issue template. My issue does.

[alexander-akait]

Please create minimum reproducible test repo

[alexander-akait]

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

Feel free to feedback too

[joelmukuthu]

@evilebottnawi here's a minimum reproduction https://github.com/joelmukuthu/webpack-dev-server-public-bug

[Jokero]

The problem is here https://github.com/webpack/webpack-dev-server/blob/v3.11.0/client-src/default/utils/createSocketUrl.js#L46-L48:

/*
 * Gets socket URL based on Script Source/Location
 * (scriptSrc: URL, location: URL) -> URL
 */
function getSocketUrl(urlParts, loc) {
  const { auth, query } = urlParts;
  let { hostname, protocol, port } = urlParts;

  if (!port || port === '0') { // <-------------- this
    port = loc.port;
  }

  // check ipv4 and ipv6 `all hostname`
  // why do we need this check?
  // hostname n/a for file protocol (example, when using electron, ionic)
  // see: https://github.com/webpack/webpack-dev-server/pull/384
  if (
    (hostname === '0.0.0.0' || hostname === '::') &&
    loc.hostname &&
    loc.protocol.indexOf('http') === 0
  ) {
    hostname = loc.hostname;
  }

window.location.port (loc.port) will be used only when port is not defined or === '0'. However, webpack-dev-server client is included this way ./node_modules/webpack-dev-server/client/index.js?http://0.0.0.0:8000 so port is always present.

Possible fix is to check hostname as well (hostname === '0.0.0.0' || hostname === '::') and if this condition passes use loc.port.

@evilebottnawi what do you think?

[Jokero]

@joelmukuthu I actually found that the change I proposed was implemented some time ago (https://github.com/webpack/webpack-dev-server/pull/1664) and it ruined different devServer use cases 🤦. So maybe solution can be implemented by using some new boolean flag (like useLocationForSock/sockUseLocation=true)

[joelmukuthu]

I think @evilebottnawi, with better knowledge of the other use cases, would know better how to fix this. For now, it would be nice to re-open this task as it's still an issue and update the docs because they're misleading.