Dropped requests when run through reverse proxy

[kasvtv]

• Operating System: W10
• Node Version: 8.9.3
• NPM Version: 6.1.0-next.0
• webpack Version: 4.10.2
• webpack-dev-server Version: 3.1.4

• This is a bug
• This is a modification request

Code

https://github.com/kasvtv/webapck-dev-server-issue

Expected Behavior

When behind a reverse proxy, devServer reliably serves files and the sockjs-node requests are sent through either the host + protocol of the devServer itsself or through the host + protocol of the reverse proxy

Actual Behavior

First of all, great plugin, HMR makes my days at the office so convenient and I can imagine many others'. DevServer has a little weird behaviour behind a reverse proxy though. It randomly drops requests when accessed through a reverse proxy! Especially when a handful of medium-sized files are transferred, this issue shows itself more often, but in the small example it does happen with at least 25% of all page loads for me. When the request finally times out (10s in the example), it seems to reattempt and it does work.

Furthermore, the sockjs-node calls are sent through the protocol that the proxy uses (HTTPS) instead of the devServer itsself (HTTP), which wouldn't be a problem, if it weren't that they go to the port number of the devServer and not of the remote proxy through which I visit the page with my browser.

Before and after:

For Bugs; How can we reproduce the behavior?

Clone my repository. Set up NGINX with included config file. Hit npm i npm run dev. Open localhost through Chrome 67. I have to say that it happens on a multitude of browsers, module versions and NGINX versions.

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

I'm a front-end dev and I run a local development instance that needs to connect to a remote staging back-end. Because of our fragmented microservice architecture and strict resource sharing policies, I must use a reverse proxy that routes requests from https://localhost/api to https://stage.domain.com/api with the same rules as the remote would do internally. Currently, this gives me the above problems and is hard to work with. It does eventually load after the timout finishes, but this slows me down in my work since I can't set the timeout too low.

[martyanov]

The very same problem. I've updated Webpack and related dependencies to the latest versions, the result is the same.

Versions:

webpack-dev-server: 3.1.4
webpack: 4.13.0

Options we use:

proxy: {
        '/api/*': {
            target: util.format('http://%s:%s', apiHost, apiPort),
            secure: false
        },
        '/ws/*': {
            target: util.format('http://%s:%s', websocketHost, websocketPort),
            secure: false,
            ws: true
        }
    }

There are a lot EHOSTUNREACH errors.

[wtho]

My hacky workaround: edit/fork webpack-dev-server and modify the if-clause in client/index.js to:

const dynamicSocksPort = true;
if (!urlParts.port || urlParts.port === '0' || dynamicSocksPort) {

Would be great if that would be some dev-server parameter!

The __resourceQuery-parameter is hardcoded as the domain webpack-dev-server listens to, although this might not be the domain the app targets primarily (e. g. behind a proxy, as mentioned above).

[kasvtv]

OP here. For my dev environment I ended up dropping my NGINX reverse proxy altogether and use the reverse proxying feature of the webpack dev server instead. Obviously this solves the problem of dropped requests, but it's still a sub-optimal solution as this is now yet another point at which my dev environment is going to differ from production.