Disconnected and looping in latest chrome

[rmanuel200]

"webpack-dev-server": "2.4.1",

Using these configurations:
devServer: {
historyApiFallback: true,
stats: 'minimal',
https: true,

---

module.exports = webpackMerge(commonConfig, {
devtool: 'cheap-module-eval-source-map',
//devtool: 'inline-source-map', //fix for IE sourcemaps 404??

Browser console.error:
client?fc09:45 [WDS] Disconnected!

Bug:
[WDS] Disconnected! happens multiple times when historyApiFallback = true
and host is not set.

This will happen about 5 times or more when the ng2 spa is refreshed either through browser or code edit in latest chrome. The server starts fine.

I'm on windows 10 pro v1607 build 14393.953

[rmanuel200]

Actually the fix may have been to add a host:

host:"10.0.....",

but https://localhost:3000 will spin a lot after [WDS] Disconnected!. This problem seems to be somewhat project specific but I can't narrow down what it is outside of webpack-dev-server 2 using inline. For instance I removed proxy:{..., vpn, route guards etc. Setting wds option inline:false also fixes the problem but we want the page refreshes on code change.

[rmanuel200]

[SpaceK33z]

Does updating to 2.4.2 fix your issue? If not this might be a dupe of #848.

[rmanuel200]

Upgrading 2.4.2 didn't fix it. I don't have hot module enabled but it may be the same problem, it seems similar. I ran one of angular's seed projects and it worked fine but the project is simplistic. Not sure why binding to a specific host does the trick. BTW my chrome was updated by IT remotely and I just upgraded to latest webpack and started using localhost so there are many changes occuring at once.

[joewood]

I'm seeing this also. Just since the latest Chrome. Spins a few times "recompiling" and eventually settles down.

[rmanuel200]

I made a project skeleton that demos the issue. https://github.com/rmanuel200/testwds

[cwharris]

I'm having this issue as well on webpack-dev-server@2.4.2. The webpack-dev-server client code fails to establish a websocket connection or the websocket is disconnected unexpectedly. Refresh ensues, whole processes starts over and repeats indefinitely. The issue only seems to occur with https enabled. Setting --host localhost per #592 did not resolve the issue.

[joewood]

I think I resolved this because I was using - - watch on the command line, but also using a watch plug-in. I dropped the command argument.

[stevexy]

the same on Chrome 58.0.3029.110 (64-bit)。
webpack-dev-server version 2.4.5。
windows 7。

[langshu]

Have the same issue here on Chrome 59.0.3071.86 (32-bit)
webpack-dev-server is the latest version - 2.4.5
OS - Win 7

[laizimo]

have the same issue here on Chrome 59.0.3071.86 (32-bit)
webpack-dev-server is the latest version - 2.5.1
OS - win 10

[Sayan751]

Have the same issue here on Chrome 59.0.3071.115 (64-bit)
webpack-dev-server version - 2.5.1
webpack version - 2.7.0
OS - Win 10

[SofiyaNiaz]

Any updates on the issue @Sayan751 posted? Facing the same issue for the same configurations

[izziewong]

Having same issue as well, any updates?

chrome version is: 59.0.3071.115 (Official Build) (64-bit)
webpack version is: 2.6.1
webpack-dev-server version is: 2.4.5
OS is: macOS

[ywzhaiqi]

[WDS] Disconnected all the same In Chrome 59, Chrome 58, Firefox 54, webpack no compile.

webpack: 3.4.1
webpack-dev-server: 2.6.1

[shellscape]

If anyone can post a link to a simple repo using current dependencies/versions, with vanilla js and without using a framework, that consistently reproduces these symptoms, we'll be happy to take a look and attempt triage. At present none of our tests or examples reproduce this behavior.

We're going through issues to try and get the number of them under control so we can more effectively help folks. Closing this one due to age and lack of ability to reproduce, but the discussion is still open. If someone can provide that sample repo, we'd be happy to reopen.

[lirongfei123]

just add this code to your hosts file, everything will be ok
127.0.0.1 localhost

[madaz]

having same problems in Chrome 60.0.3112.113 64bit/Windows10

webpack-dev-server --open --inline --hot --content-base dist/ --config ./config/webpack.config.js --env.dev --env.serve

    "webpack": "^3.5.5",
    "webpack-dev-server": "^2.7.1"

webpack.config.js

      devServer: {
        headers: {
          'Access-Control-Allow-Origin': '*',
        },
      },

However it works in Firefox

[Reverbe]

I also have this issue in Chrome Version 61.0.3163.91 (Official Build) (64-bit) (Win 10).

webpack 3.5.6
webpack-dev-server 2.7.1

[madaz]

The work around with Chrome and windows 10 is to create your own self signed certificate and install that as a trusted certificate. Then use that certificate with webpack-dev-server. I used the self signed certificate that came with IIS/IIS Express by exporting as pfx. There are articles on the web on how to trust that certificate.

…

On 15 Sep. 2017 21:04, "Reverbe" ***@***.***> wrote: I also have this issue in Chrome Version 61.0.3163.91 (Official Build) (64-bit) (Win 10). webpack 3.5.6 webpack-dev-server 2.7.1 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#851 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABFkvUQTLmKsb1msYWSikWdapuHYkPgVks5silmlgaJpZM4MhKqR> .

[lukace]

We resolved this on Chrome/Win10/IIS/https by removing the script tag from the page, and instead use the inline:true flag in the webpackdevserver config. Your mileage may vary.

[dennisoelkers]

Which script tag?

[lukace]

WORKAROUND

"webpack-dev-server": "^2.8.2"

Specifically for the infinite refresh issue ([WDS] Disconnected) - I believe the issue is this (after deeper review):

the request for a websocket can timeout (transport). webpack-dev-server/client/socket.js sock.onclose eventhandler calls for a reload if this was the "first" connection attempt (retries == 0), when I think we just want to reconnect.

for a temproary fix, I manually changed these blocks in the webpack-dev-server/client/socket.js code:

  sock.onclose = function onclose({ code }) { //catch the code from the event
    //bypass the abort if the code is the transporttimeout
    //likely should just be: retries > 10, but didn't verify and didn't review cases for retries ===0
    if(code !== 1006 && retries === 0) { handlers.close(); };  

    if(code === 1006) {
      timedout = true; //defined private @filelevel
    }
    // Try to reconnect.
    sock = null;

    // After 10 retries stop trying, to prevent logspam.
    if (retries <= 10) {
      // Exponentially increase timeout to reconnect.
      // Respectfully copied from the package `got`.
      // eslint-disable-next-line no-mixed-operators, no-restricted-properties
      const retryInMs = 1000 * Math.pow(2, retries) + Math.random() * 100;
      retries += 1;

      setTimeout(function cb() {
        socket(url, handlers);
      }, retryInMs);
    }
  };

  sock.onmessage = function onmessage(e) {
    // This assumes that all data sent via the websocket is JSON.

    const msg = JSON.parse(e.data);

    //special handling for this case, as it triggers a reload. 
    if(timedout && msg.type == 'ok') {
      timedout = false;
      handlers['ok'](true);
    }
    else if (handlers[msg.type]) { handlers[msg.type](msg.data); }

  };

and this in webpack-dev-server/client/index.js

ok: function msgOk(to) {
    sendMsg('Ok');
    if (useWarningOverlay || useErrorOverlay) overlay.clear();
    if (to || initial) return initial = false; // eslint-disable-line no-return-assign
    reloadApp();
  },

These changes fix my particular issue

[dennisoelkers]

Your snippet is missing the definition of timedout, probably happening in the same scope as sock?

[lukace]

You got it (outside of the function "socket")

[jonaskello]

@shellscape Here is a minimal repro of this issue: https://github.com/jonaskello/wds-disconnect-loop-repro

[Rouche]

Had this problem for a while and solved it in a odd way.

Dev server starts with 2 adress:

  App running at:
  - Local:   https://localhost:8085/
  - Network: https://192.168.0.151:8085/

I was using https://localhost:8085/ in browser, but the sock was connecting with Network.

Request URL: https://192.168.0.151:8085/sockjs-node/info?t=1535198535563
[WDS] Disconnected!

When i used https://192.168.0.151:8085 in browser instead of localhost, chrome shown the window to accept certificate and proceed.
Now everything is ok, on both localhost, and ip.

No need for flag. It was not working when i tryed.
I never bothered to try Network adress.. /bonk. This was too simple.

[blackshadev]

@Rouche This wasn't the case for me. My sockjs is connecting to locahost. Moreover my webpack-dev-server doesn't even listen on an ipaddress besides localhost.

Even if it would, that work-around wouldn't work for me, because I use an external service which has a CORS header for a local development setup, but this doesn't work with the IP address because multiple devs (with other IPs connect to it) and a CORD wildcard doesn't work because Chrome just drops CORS wildcards with SSL .

[ckarcz]

using 127.0.0.1 instead of localhost fixed this for me 🤷‍♂️

[dvakatsiienko]

I have fixed this issue by switching to webpack-serve instead of webpack-dev-server. pretty neat package btw

[simardo]

@ckarcz, running webpack-dev-server with --https --host 127.0.0.1 fixed the problem for me as well.
I can even access my site with https://localhost without problems.

//cc: @Rouche

[Rouche]

Today after chrome update bang!
Self signed certificate altName is now mendatory.
No choice to use host.

With vue-cli3 config:

module.exports = {
...
    devServer: {
        open: process.platform === 'darwin',
        host: 'localhost',
        port: 8444,
        https: true,
        hotOnly: false,
    },
}

Yo @simardo 👍

[WellspringCS]

I tried many of the above suggestions, and I could very much have gotten some things wrong, but here's what worked for me. (I call this "guns a'blazin" mode, where you try anything, out of desperation....)

(And note that the following efforts are not listed chronologically. I'm not sure I was sane during the last two days since this issue benighted my life.)

I started on Angular 6, ended up Angular 7.0.0-rc1 ---> WDS disconnect still there.
I started on webpack-dev-server I.don't.know and ended up on 3.1.5 ---> WDS disconnect still there.
I started on sockjs-client I.don't.know and ended up on 1.1.5 ---> WDS disconnect still there.
I tried all the above IP solutions. ---> WDS disconnect still there.

And by there, I mean endless looping. Quoth the raven: Disconnected!

Finally out of sheer desperation, the country bunkin tried brain surgery using the manual. I have NO idea what I did, but I did exactly what @lukace said he/she did, modifying socket.js and index.js.

And....

It worked.

What I would like to know is whether the code @lukace modified should be considered a bug to be fixed. For my project, EVERYTHING works now, and it didn't before. All my project was trying to do was redirect to an OAuth2 server to get a security token, and all I was getting was endless looping.

All that to say, my project was dead in the water, using all the latest releases. I don't think I had a bug, but this fix was required for my Angular project to work with OAuth2 security.

For the sake of the next soul, I log these reflections, but am wondering if an issue should be opened somewhere. Is this a sockjs-client bug? webpack-dev-server bug? @lukace I'm sure what you said was enough to go on, but I'm not a brain surgeon, so I can't discern whether your fix is a global good for all or just a good workaround that has its downsides for other users. As for me I think it's REQUIRED, but hey, I might be biased.

I end with these words of gratitude: @lukace you saved my bacon. I'll name my next dog after you. If my wife ever lets me buy one.

[mayacoda]

We have a Vue app using webpack-dev-server and encountered the same issue (using version 2.11.3, but it persisted with newer versions as well). After a lot of digging, turns out our problem was multiple websocket connections, specifically SockJS instances, spawning on application load and causing each other to time out and disconnect. The SockJS documentation even points out this problem:

An important SockJS limitation is the fact that you're not allowed to open more than one SockJS connection to a single domain at a time. This limitation is caused by an in-browser limit of outgoing connections - usually browsers don't allow opening more than two outgoing connections to a single domain. A single SockJS session requires those two connections - one for downloading data, the other for sending messages. Opening a second SockJS session at the same time would most likely block, and can result in both sessions timing out.

The cause as a badly configured html-webpack-plugin which created dummy JS files instead of loading CSS. Still not entirely sure why/how this happened, though. The way I caught it was by adding a console.trace to webpack-dev-server/client/socket.js right under the line sock = new SockJS(url); and then tracing what files created new SockJS instances during runtime.

[alexander-akait]

Somebody can create minimum reproducible test repo?

[silvenon]

Not sure when this started happening, but it seems to happen in every browser. Here's a repro.

[c80609a]

Works for me, webpack.confg.js:

module.exports = {
  devServer: {
    headers:          { 'Access-Control-Allow-Origin': '*' },
    https:            false,
    disableHostCheck: true
  },
  [...rest]
}

[silvenon]

Works for me when I downgrade to 3.1.10, without any additional options. #1604 (comment)

[panzelva]

@c80609a's solution worked for me - actually simply adding disableHostCheck: true to devServer options worked.

[monteiz]

In our case the issue was due to a mismatch between the host name that webpack-dev-server was using to serve the asset, and the host name the application was running from.

Specifically, our local application was running from https://dev.resumize.me, but webpack-dev-server was serving the asset from 127.0.0.1.

You can control the host name used by webpack-dev-server with the option --host. So in our case, we had to launch it with:

webpack-dev-server.js --host dev.resumize.me --https

Hope this helps.

[laryssamagalhaes]

On chrome works, but I've the same problem on the firefox (64.0) 😢

[chowdam]

issue resolved after adding below in polyfills.ts file:
import 'core-js/es7/object';
import 'core-js/es7/array';

[TSMMark]

What worked for me was adding config for allowedHosts https://webpack.js.org/configuration/dev-server/#devserverallowedhosts

[alexander-akait]

Issue has a lot of post with difference issue, please confirm what issue exists and provide minimum reproducible test repo, thanks!

[alexander-akait]

Issue was closed due a lot of difference issues in one, also problem should be solved in latest version, anyway feel free to open new issue with reproducible test repo, thanks!