webpack-dev-server: [2.7.0] Recursive SockJS Errors
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
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 34
- Comments: 51 (24 by maintainers)
Commits related to this issue
- avoid webpack-dev-server 2.7.0 https://github.com/webpack/webpack-dev-server/issues/1021 — committed to jraller/Vote by jraller 7 years ago
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.
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.
@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.To summarize it for myself: There are two usecases, right?
localhost:xxxx
and have set your publicpath toyyyy
. Desired behavior: serve atlocahost:xxxx/sockjs-node/
www.zzzz.com/yyyy
tolocalhost:xxxx/
Desired behavior: serve atwww.zzzz.com/yyyy/sockjs-node
so in factlocalhost:xxxx/sockjs-node/
Did I summarize correctly and which scenario is currently possible to achieve (with or without options)?
It appears indeed that downgrading
webpack-dev-server
to 3.1 resolves this issue, however it appears thatwebpack-cli
has removed something between versions that breaks the whole setupIn order to resolve this I had to downgrade
webpack-cli
to matching minor version.So, this ended up being the winning combination. For now.
Is
webpack-dev-server
really relying on some specific file inwebpack-cli
(aka another project) to be available?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.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
+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 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:The two key changes were to
historyFallbackAPI
andsocksjsPrefix
. I’m not sure if folks were overzealous in pushing this forward given this comment, but it appears some incompatibility whenhistoryFallbackAPI
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.We’ve resorted to forking it https://github.com/SMARTeacher/webpack-dev-server
Alternatively I heard that webpack-serve might work
@nealoke see my previous comment. doesn’t look like the same issue.
@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 intomaster
given how different the two branches have become, but it’s safe to say that a fix will be available in the near future.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?
@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
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.
I got a similar problem too.
With
publicPath: 'http://localhost:8080/packs/'
HMR is trying to loadhttp://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