[2.7.0] Recursive SockJS Errors #1021

skipjack · 2017-08-08T14:16:23Z

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 · 2017-08-08T14:23:54Z

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 #911

robmoorman · 2017-08-08T14:24:33Z

Same issue over here 2.7.0 seems to be broken

the-spyke · 2017-08-08T14:28:20Z

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

shellscape · 2017-08-08T15:11:19Z

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 · 2017-08-08T15:47:47Z

+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 · 2017-08-08T16:00:37Z

@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 · 2017-08-08T16:26:40Z

@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 · 2017-08-08T16:29:09Z

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 · 2017-08-08T16:34:47Z

@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.

yocontra · 2017-08-08T16:39:06Z

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 · 2017-08-08T16:41:57Z

@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.

yocontra · 2017-08-08T16:45:05Z

@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 · 2017-08-08T16:48:08Z

@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 · 2017-08-08T16:53:52Z

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

shellscape · 2017-08-08T16:58:28Z

@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 · 2017-08-08T17:00:42Z

@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 · 2017-08-08T17:01:57Z

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

bdwain · 2017-08-08T17:04:06Z

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

kellyrmilligan · 2017-08-08T17:58:54Z

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 · 2017-08-08T17:59:26Z

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

shellscape · 2017-08-08T18:02:52Z

@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 facebook/create-react-app#1887 until we find a solution.

kellyrmilligan · 2017-08-08T18:03:24Z

yeah, fair enough.

shellscape · 2017-08-08T18:13:06Z

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 · 2017-08-08T18:23:33Z

I can confirm that it fixed the issue I encountered!

kellyrmilligan · 2017-08-08T18:48:21Z

@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 · 2017-08-09T00:05:30Z

@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.

shellscape · 2017-10-22T14:09:36Z

@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 · 2017-10-22T18:13:54Z

@shellscape ops, sorry. Thanks for the pointer 👍

nealoke · 2017-11-28T19:58:50Z

@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 · 2017-11-28T20:10:14Z

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

nealoke · 2017-11-28T20:25:15Z

@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 · 2017-11-28T21:00:13Z

@nealoke well I think that your issue is likely closer in relation to #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 · 2017-11-29T08:23:56Z

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

You start Webdevserver at localhost:xxxx and have set your publicpath to yyyy.
Desired behavior: serve at locahost:xxxx/sockjs-node/
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 · 2017-11-30T15:58:16Z

@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 · 2018-01-11T11:12:39Z

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 · 2018-01-20T04:20:42Z

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

webpack-dev-server/client-src/live/index.js

Line 88 in 3aa15aa

socket('/sockjs-node', onSocketMsg);

cheapsteak · 2018-01-22T03:29:46Z

I opened a PR that should solve the same problem as #911 while also not result in the same bugs that were reported here

tylercloke · 2018-06-20T20:35:39Z

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 · 2018-06-20T20:47:05Z

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

Alternatively I heard that webpack-serve might work

ehsanul · 2018-11-21T23:22:18Z

The new PR is here: #1553

dmitrizzle · 2019-04-27T00:01:14Z

I think I have a related issue that surfaced with everything newer than webpack-dev-server@3.1.14. 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 · 2019-05-16T06:38:27Z

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.

npm install webpack-dev-server@3.1 webpack-cli@3.1 --save-dev

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

estellederrien · 2020-08-11T11:30:47Z

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 webpack-dev-server@3.1 webpack-cli@3.1 --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'])

renchap mentioned this issue Aug 8, 2017

The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. rails/webpacker#624

Closed

renchap mentioned this issue Aug 8, 2017

Sockjs prefix config #911

Merged

jraller added a commit to jraller/Vote that referenced this issue Aug 8, 2017

avoid webpack-dev-server 2.7.0 webpack/webpack-dev-server#1021

3cdd7c7

shellscape added the type: bug label Aug 9, 2017

shellscape mentioned this issue Oct 27, 2017

Web-socket poxy settings #1165

Closed

3 tasks

shellscape added type: refactor and removed X8: in progress labels Oct 31, 2017

abkrim mentioned this issue Nov 17, 2017

webpack-dev-server version not found spatie/spoon#3

Closed

cheapsteak mentioned this issue Jan 22, 2018

feat: add sockPath option (options.sockPath) #1289

Closed

5 tasks

jhchill666 mentioned this issue Mar 16, 2018

infinite XHR calls from sockjs-node when using HTTPS facebook/create-react-app#3947

Closed

michael-ciniawsky added scope: ws(s) and removed scope: ws(s) severity: 2 (regression) severity: 3 (broken) type: bug type: refactor labels Aug 23, 2018

michael-ciniawsky closed this as completed Aug 23, 2018

[2.7.0] Recursive SockJS Errors #1021

[2.7.0] Recursive SockJS Errors #1021

Comments

skipjack commented Aug 8, 2017

renchap commented Aug 8, 2017

robmoorman commented Aug 8, 2017

the-spyke commented Aug 8, 2017

shellscape commented Aug 8, 2017 • edited

karolyi commented Aug 8, 2017 • edited by shellscape

jaredLunde commented Aug 8, 2017 • edited

shellscape commented Aug 8, 2017 • edited

Grafikart commented Aug 8, 2017 • edited

shellscape commented Aug 8, 2017 • edited

yocontra commented Aug 8, 2017

shellscape commented Aug 8, 2017

yocontra commented Aug 8, 2017 • edited

shellscape commented Aug 8, 2017

kellyrmilligan commented Aug 8, 2017

shellscape commented Aug 8, 2017

bdwain commented Aug 8, 2017

shellscape commented Aug 8, 2017

bdwain commented Aug 8, 2017

kellyrmilligan commented Aug 8, 2017

kellyrmilligan commented Aug 8, 2017

shellscape commented Aug 8, 2017

kellyrmilligan commented Aug 8, 2017

shellscape commented Aug 8, 2017

renchap commented Aug 8, 2017

kellyrmilligan commented Aug 8, 2017

shellscape commented Aug 9, 2017

shellscape commented Oct 22, 2017 • edited

rgo commented Oct 22, 2017

nealoke commented Nov 28, 2017

Safari 10.1

Safari 11

shellscape commented Nov 28, 2017

nealoke commented Nov 28, 2017

shellscape commented Nov 28, 2017

valoricDe commented Nov 29, 2017 • edited

kellyrmilligan commented Nov 30, 2017

r7l commented Jan 11, 2018 • edited

cheapsteak commented Jan 20, 2018 • edited

cheapsteak commented Jan 22, 2018

tylercloke commented Jun 20, 2018

cheapsteak commented Jun 20, 2018 • edited

ehsanul commented Nov 21, 2018

dmitrizzle commented Apr 27, 2019

mikkotikkanen commented May 16, 2019

estellederrien commented Aug 11, 2020 • edited

shellscape commented Aug 8, 2017 •

edited

karolyi commented Aug 8, 2017 •

edited by shellscape

jaredLunde commented Aug 8, 2017 •

edited

shellscape commented Aug 8, 2017 •

edited

Grafikart commented Aug 8, 2017 •

edited

shellscape commented Aug 8, 2017 •

edited

yocontra commented Aug 8, 2017 •

edited

shellscape commented Oct 22, 2017 •

edited

`Safari 10.1`

`Safari 11`

valoricDe commented Nov 29, 2017 •

edited

r7l commented Jan 11, 2018 •

edited

cheapsteak commented Jan 20, 2018 •

edited

cheapsteak commented Jun 20, 2018 •

edited

estellederrien commented Aug 11, 2020 •

edited