infinite XHR calls from sockjs-node when using HTTPS

[ghost]

Is this a bug report?

Yes it is.

Did you try recovering your dependencies?

Yes I did

npm --version : 5.4.0
yarn --version 1.3.2

Which terms did you search for in User Guide?

I have searched for 'HTTPS' and 'sockjs-node' in the docs.

Environment

node -v : v9.4.0
npm -v : 5.6.0
yarn --version: 1.3.2
I have ejected, webpack version is 3.8.1

OS : macOS High Sierra 10.13.2
browser : latest chrome or firefox

Steps to Reproduce

for now on, I've been using the dev server with HTTPS on (thanks to the explanations in the doc), with success. However, I have recently upgraded CRA.
Please note that I have ejected, so every once in a while I just scafold a new cra app, and merge the differences in my projet, I have done it twice so fare with success, this is the third time.
I haven't noted the previous cra version I've used, but from package.json I can see I've been from webpack 2.6.1 to 3.8.1

Now, I have no problems when HTTPS if false, but when HTTPS is true, my app is getting into an infinite loop of XHR requests coming from sockjs-node.

Of course, I've tested a freshly generated CRA app with HTTPS, and it works fine.
However, after copy/pasting my project inside, and installing all new packages using yarn. I run into this issue...

While I don't understand what triggers this problem, I have a feeling that the infinite loop comes from the live reload feature in webpackDevServer.config.js.
So of course, this problem won't happened when serving a production version of the app behing a SSL cert.

Expected Behavior

when developing using HTTPS with my application, there shouldn't be any infinite loops caused by the dev server.

Actual Behavior

Here is a GIF of the infinite XHR request

and the headers from one call

the preview

I am also always getting this message in the console

The development server has disconnected. Refresh the page if necessary.

and sometimes, I get this error in the console

htmlfile?c=_jp.amifsnd:8 Uncaught DOMException: Blocked a frame with origin "https://localhost:3000" from accessing a cross-origin frame. at https://localhost:3000/sockjs-node/723/dnduswa3/htmlfile?c=_jp.amifsnd:8:20

Reproducible Demo

I haven't been able to point out myself where the problem lies, so I don't want to copy paste you a huge project with lots of dependencies as it will be a waste of time for you.

However if this kind of issue rings a bell, or if you can point me in the right direction... I would appreciate it a lot!

[gaearon]

Hey, unfortunately we don't provide support for changes made after ejecting. It can be hard to "keep up" this way, and when something breaks it's not obvious what (which is exactly why "hiding" a bunch of dependencies behind a single one, and ensuring they work together is valuable).

I don't have a guess at what's going on. If you can provide an un-ejected minimal project that reproduces this then we could take a look.

[ghost]

Thank you for your time and your feedback,
I will come back to you if I can reproduce it with a non-ejected environment.

[jhchill666]

I've been suffering this for months, to the extent it locks up the browser. I'm also on https. Any revelations @Roma98 ?

[ghost]

hi @jamiehill , no I don't, I just found a way to not have to use https in dev mode.
I also have someone who contacted me via e-mail regarding the same issue, if it happened to you without ejecting cra, you should report the issue.

[jhchill666]

@Roma98 thanks for the heads up. Unfortunately am using a (minimally) modified fork, so suspect my cries for help will be ignored :|

[jhchill666]

Linking ticket from webpack-dev-server:

webpack/webpack-dev-server#1021 (comment)

[Timer]

Looks like this is a webpack dev server bug (from that linked issue).
I'm going to close this since it's out of our control, we're moving away from webpack-dev-server, and this change won't be easily accessible to you since you've ejected.

[kyriacos]

@Timer I'm also experiencing the same issue and i haven't ejected. I looked at the linked issue. Based on what i saw it's not something that accessible in a config. You mentioned moving away from webpack-dev-server. Is that part of the upcoming release?

Thanks

[komali2]

Sometimes, we can fix this issue if we can find a URL to paste into the browser that lets chrome trust sockjs.

Lately, that stopped being a solution, as the only URLs we can find are WSS ones.

EDIT: The url is something like https://localhost:8080/sockjs-node/info?t=1526582226022

[komali2]

@jamiehill that is not the same error.

[kael]

Getting the same issue, disabling service worker registration in index.js with serviceWorker.unregister(); helped to bypass the issue.

[kael]

There seems to be a loop in Service Worker registration, like window.location.reload() on window.addEventListener('load'), which then triggers XHR on reload. It'd make sense as Service Workers works only over HTTPS. Gotta look into.