Webpack-dev-server: [2.7.0] Recursive SockJS Errors

[skipjack]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

Start the dev server with HMR enabled. Here's my dev server configuration:

    devServer: {
        hot: true,
        port:8084,
        inline: true,
        compress: true,
        historyApiFallback: true,
        contentBase: 'dist/',
        overlay: {
            errors: true,
            warnings: true
        }
    }

I start getting the following errors:

Which then cause other errors in the application and seems to recurse back causing to the same set of errors to continually fire.

What is the expected behavior?

No errors. With v2.6.1 of this package everything works fine.

If this is a feature request, what is motivation or use case for changing the behavior?

N/A

Please mention your webpack and Operating System version.

OSX 10.12.5
Webpack 3.5.1

[renchap]

I got a similar problem too.

With publicPath: 'http://localhost:8080/packs/' HMR is trying to load http://localhost:8080/packs/sockjs-node/info?t=1502201588847 which returns a 404 error. `http://localhost:8080/sockjs-node/info?t=1502201588847 returns the expected value.

This is caused by https://github.com/webpack/webpack-dev-server/pull/911

[robmoorman]

Same issue over here 2.7.0 seems to be broken

[the-spyke]

Not need for enabling HMR by the way. It doesn't work even without it.

[shellscape]

We're in a pickle because the updates to socksjs passed all of the tests we presently have before it was merged, and it was reviewed. So it wasn't a bug that was willfully introduced. If anyone can create a small example that devs can use to reproduce, that would be immensely helpful.

_Update: I've run through a slew of the examples with no errors. We're definitely going to need an example app that we can reproduce the errors with._

[karolyi]

+1

_(Please don't drop +1 comments on issues. It interrupts the flow of the discussion. Instead, use the reactions button on the original post in this thread to add a 👍)_

[jaredLunde]

@shellscape It's maybe not the simplest example but here's a failing app: https://github.com/jaredlunde/webpack-dev-server-failure-example/tree/master

[shellscape]

@jaredlunde thanks, that at least got us moving forward. I modified your server options in server.js and was able to stem the tide of websocket errors:

new WebpackDevServer(webpack(config), {
  publicPath: config.output.publicPath,
  sockjsPrefix: '/assets',
  historyApiFallback: {
    disableDotRule: true
  },
  disableHostCheck: true,
  quiet: true,
  inline: true,
  compress: true
})

The two key changes were to historyFallbackAPI and socksjsPrefix. I'm not sure if folks were overzealous in pushing this forward given this comment, but it appears some incompatibility when historyFallbackAPI is set to true does in fact exist. We could put some logical checks in there to account for the scenarios and force some default values, but I'm open to suggestion from the community.

[Grafikart]

I confirm the symptoms. If I rollback to the 2.6.1 everything works as expected (without changing anything in my configuration).

With the 2.7.0 the generated code looks for

http://localhost:8080/{publicPath}/sockjs-node/info?t=1502209431225

But the file is still served at the root

http://localhost:8080/sockjs-node/info?t=1502209431225

To fix the issue (keeping the 7.0) I have to add

sockjsPrefix: '/dist', // My public path without the ending /

This is a bit confusing for new comers (since it's not documented yet). Maybe sockjsPrefix should have the publicPath value by default or the previous behaviour should be restored.

[shellscape]

@Grafikart see previous comment.

Taking my previous comment a bit further I removed the property for historyFallbackAPI entirely, and only added the sockjsPrefix property, which resulted in a successful run. I removed the property and things started failing immediately. So it would seem that when publicPath is set, the code is assuming sockjsPrefix has been set.

[contra]

Same issue, 2.7.0 was a big breaking change. If this was intended it should have been a 3.0 release, not a minor.

[shellscape]

@contra That's an incorrect statement; 2.7.0 was not a breaking change. It inadvertently introduced a bug that got through several reviewers and tests. "me too" replies aren't helpful, please hold off on those in the repo in the future. At best you're distracting from the discussion around the actual cause of this.

[contra]

@shellscape If it wasn't intentional that's fine, you should roll it back (push the last working version as 2.7.1, then deprecate 2.7.0) so when people update their deps they aren't having issues. No need to be rude, I'm not "me too"ing but actually suggesting a temporary fix so people's code doesn't break between now and when the bug is fixed.

[shellscape]

@contra I must disagree; there was no rudeness and "same issue" is essentially "me too." The webpack team is presently discussing the best course of action in the mean time. You're welcome to join the webpack gitter to discuss the logistics further, but I'd like this topic to get back on track to discovery and resolution of the issue at hand.

[kellyrmilligan]

@shellscape please let me know how I can help with this. sounds like there are some cases I didn't account for.

[shellscape]

@kellyrmilligan thanks much. Check out @jaredlunde 's example app and how those different options affect the errors in the devtools console. It looks like there's a discrepancy between the actual location of the sockjs-node file and where the client thinks it is. FWIW this only seems to affect apps which set publicPath.

[bdwain]

@shellscape i have this issue without public path.

  let child = spawn('webpack-dev-server', ['--config', argv.config, '--progress', '--colors',
   '--hot', '--inline', '--port', argv.port,'--history-api-fallback', '--content-base',
   './devdist/', '--host', '0.0.0.0', '--disable-host-check'], {env});

[shellscape]

@bdwain thanks for sharing that. out of curiosity, when you also set disableDotRule to true, can you reproduce?

[bdwain]

hm that option doesn't seem to be available via the CLI, so i'm not sure i can test it.

[kellyrmilligan]

so yes, right now it is assuming that if public path exists, the sockjs shoudl be mounted under that path, hence the option set. should we make it so that if public path is set it and sockjsprefix isn't set that it assumes public path?

[kellyrmilligan]

or inject the sock prefix as a variable similar to webpack_public_path so the client can use it?

[shellscape]

@kellyrmilligan right now the sockjs path doesn't know whether or not the option has been set, it assumes that public path is always the prefix. What we really should do is make the entire options object available in some way to future proof against code needing to assume or derive options from other data, and specifically to provide the prefix option to the client. That's what I've been looking into, while continuing to discuss the issue with the webpack folks. I'm open to suggestion as to how to implement that.

It looks like we're getting pushback from NPM on unpublishing 2.7.0 so we'll likely issue 2.7.1 to roll back that commit. (+@TImer) That will likely block you on facebookincubator/create-react-app#1887 until we find a solution.

[kellyrmilligan]

yeah, fair enough.

[shellscape]

OK 2.7.1 has been published sans the sockjs changes. That should get everyone back to normal while we try and solve the issue.

[renchap]

I can confirm that it fixed the issue I encountered!

[kellyrmilligan]

@shellscape please let me know how I can help get a solution across the line that can encapsulate sockjs. I apologize for not noticing this underlying assumption in my PR.

[shellscape]

@kellyrmilligan no worries, you're definitely not the only one that missed this. We basically need to get to a place where we can pass/inject the WDS config/options into the client bundle. That's the goal I think we need to aim for, then there's no extrapolating options based on other property values. It'll be pretty implicit.

[d3viant0ne]

I would be that other one that missed this :/

@kellyrmilligan - @shellscape has a viable plan to make all of this work via a small loader to facilitate getting the needed configuration to the client side bundle & a small modification to the original PR to encapsulate the optional sockjs configuration option.

I'll stick a note in the create-react-app PR regarding the approach just to make sure nobody on that side of the house has an issue with the addition of a small loader.

[kellyrmilligan]

Awesome. This and the corresponding PR will solve a good chunk of issues. I was wondering yesterday, for this particular change, what if public path and the mount point were the same? I'm trying to think of a case where you would want them to be different? When you use hmr, you generally want the URL you put in the app entry point to have the public path at the end of it anyway to match things up. I think I was trying to make this a minor update but maybe its speed for a breaking change release? When is 3.0?

[skipjack]

@shellscape @kellyrmilligan -- and anyone else I missed -- thank you for jumping on this so quickly!

🎉 🎉 🎉

[AleshaOleg]

Updated to 2.8.1 today - I have ReferenceError: Can't find variable: SockJS for Safari browser. Chrome works ok.

UPD. Back to 2.8.0 - also didn't work for me.
Now I'm under 2.7.1. Everything fine.

[abergs]

I receive this on 2.7.1 (and 2.8.2 and 2.6.1). Believe it got introduced with us adding https.
Any known workarounds?

[abergs]

Clarification: I receive the infinite loop of xhr, xhr_streaming and eventsource when using webpack-dev-server with https. It only triggers after a manual browser refresh (causing a sockjs disconnect?), after that i'm in the infinite loop och doing xhr_streaming and eventsource GET/POSTs and Node starts consuming about 40%.

Dropping the HTTPS flag makes it work, but is not acceptable for us.
Tested with 2.8.2, 2.7.1 and 2.6.1 - same behavior on all of them.

[shellscape]

@abergs thanks for checking in. we've confirmed the issue a while back and have a plan to address it. for anyone else that would like to confirm their experience of the issue, please use the reaction buttons on the original post in the thread to do so :)

[rgo]

Using 2.8.2 with Safari 10.0.2 I have ReferenceError: Can't find variable: SockJS
But it works with Safari 11.0

[shellscape]

@rgo that's not the same issue, not even close I'm afraid. yours is likely more similar to #1090.

@ all - during work on v3 we've identified a way to use DefinePlugin to inject the devserver options into the bundles. It's gonna be tricky to back-port that into master given how different the two branches have become, but it's safe to say that a fix will be available in the near future.

[rgo]

@shellscape ops, sorry. Thanks for the pointer 👍

[nealoke]

@shellscape I'm facing multiple errors which occur on different browsers at run time only (builds fine). Is this the same issue?

Safari 10.1

Safari 11

[shellscape]

@nealoke see my previous comment. doesn't look like the same issue.

[nealoke]

@shellscape didn't notice the remark about version 3. Any idea on when this will be released? Or do you recommend using webpack-dev-server@next?

[shellscape]

@nealoke well I think that your issue is likely closer in relation to https://github.com/webpack/webpack-dev-server/issues/1090, and I think there's a few closed issues with the same description as well. that being said, I'm hoping to have 3.0.0-rc1 on the next tag this week. full release will likely be Jan-Feb.

[valoricDe]

To summarize it for myself: There are two usecases, right?

1. You start Webdevserver at localhost:xxxx and have set your publicpath to yyyy.
   Desired behavior: serve at locahost:xxxx/sockjs-node/
2. You use a proxy server which redirects path www.zzzz.com/yyyy to localhost:xxxx/
   Desired behavior: serve at www.zzzz.com/yyyy/sockjs-node so in fact localhost:xxxx/sockjs-node/

Did I summarize correctly and which scenario is currently possible to achieve (with or without options)?

[kellyrmilligan]

@valorize from what I understand, folks want to be able to proxy several apps running webpack dev server locally. currently it will always request /sockjs-node, and if it is an app under the root, /subpath, then the desired behavior is to have it request /subpath/sockjs-node. I thought in v3 the team is just using native websockets, so I am guessing it may be different.

[r7l]

Coming from another Issue (#1165) that was closed due to this one ...

This issue here is quite long and i could not figure if there has any progress been made. I am running an Nginx Reverse Proxy setup and SocketUrl failed me for port reasons. Since i couldn't find any option to deal with this issue, i've simply hacked the value in webpack code itself (which is bad bad and dirty). Can you please add an option for people like me, so the webpack-dev-server can run with port X while SocketUrl runs its requests with a different port?

My current SocketUrl code:

const socketUrl = url.format({
  protocol,
  auth: urlParts.auth,
  hostname,
  port: 443,
  pathname: urlParts.path == null || urlParts.path === '/' ? '/sockjs-node' : urlParts.path
});

Thanks allot for all your effort with this.

[cheapsteak]

Apologies, what does "waiting on upstream" mean? In this case, what is upstream?
Edit: I think upstream refers to webpack?

---

I was able to sort of hack around the error but needed to locally patch the webpack-dev-server client code

In webpack-dev-server/client/index, I replaced this line

var socketUrl = url.format({
  protocol: protocol,
  auth: urlParts.auth,
  hostname: hostname,
  port: urlParts.port,
-   pathname: urlParts.path == null || urlParts.path === '/' ? '/sockjs-node' : urlParts.path
+  pathname: '/sockjs-node'
});

Which is where it's being served out of from Server.js

Obviously not a great solution since I do want the prefix to still be there

I've also tried going the other way and adding my prefix to the line in server.js

sockServer.installHandlers(this.listeningApp, {
-      prefix: '/sockjs-node'
+      prefix: '/myprefix/sockjs-node'
    });

The initial request goes through, but subsequent requests are still sent to the root (/sockjs-node) instead of /myprefix/sockjs-node)

POST https://xxx/sockjs-node/471/3ualep1h/xhr_streaming?t=1516421732965 404 (Not Found)
eventsource:1 GET https://xxx/sockjs-node/471/tskyrma3/eventsource 404 (Not Found)
main.023582b7.js:36715 GET https://xxx/sockjs-node/iframe.html 404 (Not Found)
main.023582b7.js:36715 GET https://xxx/sockjs-node/iframe.html 404 (Not Found)

If I go to https://xxx/myprefix/sockjs-node/471/tskyrma3/eventsource instead, the stream _is_ there.
Why does it get sent to the root? Would that be something in WDS or sockjs?

Update: looks like it's due to live.js always using a hardcoded path to a root /sockjs-node

https://github.com/webpack/webpack-dev-server/blob/3aa15aa619e1b54cc8ddb8ea2be897d4266527bb/client-src/live/index.js#L88

[cheapsteak]

I opened a PR that should solve the same problem as https://github.com/webpack/webpack-dev-server/pull/911 while also not result in the same bugs that were reported here

[tylercloke]

Looks like the above PR never merged? I'm still seeing this issue. Is there any progress here? Any workarounds that don't involve manually patching webpack?

[cheapsteak]

We've resorted to forking it
https://github.com/SMARTeacher/webpack-dev-server

Alternatively I heard that webpack-serve might work

[ehsanul]

The new PR is here: https://github.com/webpack/webpack-dev-server/pull/1553

[dmitrizzle]

I think I have a related issue that surfaced with everything newer than [email protected]. I am getting infinite loops with SockJS errors with all versions past 3.3.0 and browser console warnings in 2.2.0 and 2.2.1 versions. Downgrading fixed everything immediately. I am not using HTTPS with localhost.

[mikkotikkanen]

It appears indeed that downgrading webpack-dev-server to 3.1 resolves this issue, however it appears that webpack-cli has removed something between versions that breaks the whole setup

Error: Cannot find module 'webpack-cli/bin/config-yargs'
````

In order to resolve this I had to downgrade `webpack-cli` to matching minor version.

So, this ended up being the winning combination. For now.

```bash
npm install [email protected] [email protected] --save-dev

Is webpack-dev-server really relying on some specific file in webpack-cli (aka another project) to be available?

[nicolas15000]

Hi, I have the same problem, please help me :

https://stackoverflow.com/questions/63357106/socksjs-infinite-loop-with-vue-js

Forwarded vue.js 8080 dev environnement axios to port 80 with the vue.config.js , cause my python flask server is always running on port 80, waiting for web services calls.

module.exports = {
    outputDir: "dist",

    // relative to outputDir
    assetsDir: "static"   ,
    devServer: {
        proxy: 'http://localhost:80'
      }
};

Tried the mikkotikkanen
npm install [email protected] [email protected] --save-dev with no luck , it doesnt start

This is what my flask server says .

127.0.0.1 - - [11/Aug/2020 13:45:33] "POST /read_linear_solution HTTP/1.1" 200 -
127.0.0.1 - - [11/Aug/2020 13:46:01] "GET /sockjs-node/431/zdywjeka/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:01] "GET /51dd9e53682edb0eb794.hot-update.json HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:03] "GET /sockjs-node/237/4wb3z0q5/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:03] "GET /sockjs-node/668/qtakz5fb/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:07] "GET /sockjs-node/499/5o21b5og/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:08] "GET /sockjs-node/592/qxymyqpx/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:11] "GET /sockjs-node/393/prj3mzm2/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:13] "GET /sockjs-node/806/fbmgjbpi/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:16] "GET /sockjs-node/338/woi2vspk/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:18] "GET /sockjs-node/373/g4ugwyqg/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:21] "GET /sockjs-node/594/yg4wvr2k/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:23] "GET /sockjs-node/804/xdkewox1/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:26] "GET /sockjs-node/252/ns4grojm/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:28] "GET /sockjs-node/593/qlwee33j/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:31] "GET /sockjs-node/188/2nw3c1zv/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:33] "GET /sockjs-node/680/1gx14vun/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:36] "GET /sockjs-node/056/etdfga4d/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:38] "GET /sockjs-node/876/azu0vru3/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:41] "GET /sockjs-node/885/ydnrbfvp/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:43] "GET /sockjs-node/029/tysutf4v/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:45] "GET /sockjs-node/127/l0ywlxzk/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:48] "GET /sockjs-node/528/3tx4mqx2/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:50] "GET /sockjs-node/205/rhdyjtsy/websocket HTTP/1.1" 404 -
127.0.0.1 - - [11/Aug/2020 13:46:53] "GET /sockjs-node/973/jubctvhd/websocket HTTP/1.1" 404 -

And what my vue.js console says

Proxy error: Could not proxy request /sockjs-node/186/ceoss1vu/websocket from localhost:8080 to http://localhost:80/.
See https://nodejs.org/api/errors.html#errors_common_system_errors for more information (ECONNREFUSED).

Proxy error: Could not proxy request /sockjs-node/083/1skssa1x/websocket from localhost:8080 to http://localhost:80/.
See https://nodejs.org/api/errors.html#errors_common_system_errors for more information (ECONNREFUSED).

Proxy error: Could not proxy request /sockjs-node/209/ya0wckal/websocket from localhost:8080 to http://localhost:80/.
See https://nodejs.org/api/errors.html#errors_common_system_errors for more information (ECONNREFUSED).

Proxy error: Could not proxy request /sockjs-node/538/ozd0cqig/websocket from localhost:8080 to http://localhost:80/.
See https://nodejs.org/api/errors.html#errors_common_system_errors for more information (ECONNREFUSED).

Proxy error: Could not proxy request /sockjs-node/703/wy0f1tkc/websocket from localhost:8080 to http://localhost:80/.
See https://nodejs.org/api/errors.html#errors_common_system_errors for more information (ECONNREFUSED).

Proxy error: Could not proxy request /sockjs-node/163/kglrm2tu/websocket from localhost:8080 to http://localhost:80/.
See https://nodejs.org/api/errors.html#errors_common_system_errors for more information (ECONNREFUSED).

EDIT : Hey Guys, resolved with this code , simply write this in your vue.config.js at the root of the vue.js app, so the wrong sockjs-node queries will get ignored, only web services will be forwarded :

module.exports = {
  outputDir: "dist",

  // relative to outputDir
  assetsDir: "static",
  devServer: {
    proxy: {
      "/api": {
        target: "http://localhost:80"
      }
    }
  }
};

Then, do an axios query from vue.js like this :

const path = '/api/read_linear_solution';
            axios.post(path, this.form)

Then, in ur python or node server , the web service must look like this 👍
@app.route('/api/read_linear_solution', methods=['POST'])