Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proxying Websocket connections fails with "Connection closed before receiving a handshake response" #625

Closed
alp82 opened this issue May 16, 2015 · 10 comments · May be fixed by tobybellwood/govstrap#4

Comments

@alp82
Copy link

alp82 commented May 16, 2015

I use BrowserSync configured with the proxy setting to redirect all requests to my local webserver.

When opening the page, i get the following error message in Chrome (Version 42, Arch Linux):

WebSocket connection to 'ws://localhost:3000/ws/791/ori74537/websocket' failed:
Connection closed before receiving a handshake response

Due to this issue in the foxy project, there was indeed no working support for proxying websocket connections: shakyShane/foxy#2

But they pushed a fix in release 10.1.2 which is included as dependency in the current BrowserSync release 2.7.1. I tried using that version, but it did not change anything and i still get the same error.

Do you need more information? Can anyone confirm this issue?

@nathanmarks
Copy link

@alp82 I'm also having websocket related issues with browser sync along these lines and have had to not use browsersync proxying for now.

@vmakhaev
Copy link

vmakhaev commented Jul 4, 2015

I confirm this issue. browser-sync 2.7.13

@romanenko
Copy link

I have the same problem with my Ruby on Rails app, running at 3000 port with websocket-rails setup. I proxy all my requests through browsersync server, running at port 5000 but my websocket connection doesn't upgrade to ws, saying that:

WebSocket connection to 'ws://localhost:5000/websocket' failed: Connection closed before receiving a handshake response

If I go directly to my app directly at 3000 — everything works as expected.

@shakyShane
Copy link
Contributor

This is being actively worked on as we speak and a fix will be released as soon as possible.

@shakyShane
Copy link
Contributor

Ok, so I have this all fixed now - I need to test in more envs, but I'm pretty sure it's good to go.

For anyone interested - the problem was relating to the fact that Browsersync in proxy mode tries to use a single server/port to serve the client script, run the web sockets + proxy requests through to your server.

Well it turns out that of course socket.io is handling the upgrade event on the server for Browsersync's websockets - which means that it was simply not possible to also allow the proxy to pass through other websockets upgrades (for example, your app's chatroom or whatevs).

The solution is to simple boot a separate server to handle Browsersync's websocket connections when in proxy mode and pass through all of your own websockets via the proxy (as you'd expect).

@alp82
Copy link
Author

alp82 commented Jul 26, 2015

Your effort is very much appreciated. Thanks!

@romanenko
Copy link

This fixes issues for me. Great job! Thank you!

@hutber
Copy link

hutber commented Jan 21, 2017

Bit late to the party here, but could I grab an example of the proxy through browsersync by any chance?

@Boscop
Copy link

Boscop commented Aug 28, 2018

So what's the correct way to proxy websockets through browsersync?
In my case, websockets are served from the same port as the normal assets.
I'm using http-proxy-middleware to proxy /api calls to my server but how can I also proxy the websocket connection to my server?

@daniel-shuy
Copy link

The fix only fixes proxy mode, what about server mode? (see #780 and chimurai/http-proxy-middleware/issues/15)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants