websocket problems (browser-sync + http-proxy-middleware)

[jmls]

so, I'm trying to proxy a websocket within gulp, using http-proxy-middleware.

my backend server code is this

var app = require('express')();
var server = require('http').createServer(app);
var io = require('socket.io')(server,{ path: '/socket.io'});
io.on('connection', function(){ console.log("woot! connection")/* … */ });
server.listen(5000);

and my gulp code is this

  var server = {
    baseDir: baseDir,
    routes: routes
  };

  var proxies = [];

  proxies.push(proxyMiddleware('/socket.io', { target: 'http://localhost:5000/' , ws: true}));
  server.middleware = proxies;

  browserSync.instance = browserSync.init({
    startPath: '/',
    server: server,
    browser: browser
  });

on the console I see

woot! connection
[HPM] Upgrading to WebSocket
[HPM] Client disconnected

and the client console has

WebSocket connection to 'ws://mysite.io/socket.io/?EIO=3&transport=websocket&sid=5_BeDfck0LFYcYxPAAAA' failed: Error during WebSocket handshake: Unexpected response code: 502

Am I missing something ?

thanks

[chimurai]

Thank for reporting it.
I encountered the same issue while implementing the websocket proxy.

This issue only occurs when you use browser-sync; Don't have this issue with connect and express.

Which version of browser-sync are you using?

[jmls]

hey, thanks for the response.

2.7.12

[jmls]

any luck on this ? /me pushes his luck ...

[chimurai]

No luck unfortunately...
I tested it with the latest 2.8.2 version and I'm getting the same result.

I suspect it is an issue in browser-sync; A similar issue has been reported: BrowserSync/browser-sync#625 for their own proxy option.

They've solved it for browser-sync's option.proxy and websockets.

However, when you use browser-sync's option.server (just like your example) with http-proxy-middleware; it doesn't work if you need to proxy websockets too.

This issue might be related to what they have fixed for their option.proxy.

You might want to open a ticket @ BrowserSync. Hopefully they can verify if it actually is an issue in browser-sync's option.server.

[aaronchar]

I would have to agree, I am just getting back to this now and @chimurai I have to say this is great work on this module.

I found it easier to just switch from browserSync to express and be done with it.

[chimurai]

Thanks @DefunctExodus :)

Bumped into this issue since the day I started implementing support for WebSockets.
Hopefully it can be solved one day....

[jmls]

@DefunctExodus : could you explain how you moved from BrowserSync to plain express ? What issues did you face - does (for example) live reload work properly ?

[HereThereBeMonsters]

I am trying to work around this problem by using express in my Gulp serve task and opening an ad-hoc websocket proxy on a different port than BrowserSync.

So BrowserSync is running on port 8081. My backend (java) on port 8080. And the 'special' websocket proxy is running on 8082:

var wsProxy = express();
    wsProxy.use('/tango-ws', proxy({
        target: 'http://localhost:8080/tango-ws',
        changeOrigin: true,
        ws : true,
        prependPath: false,
        logLevel : 'debug'
    }));
    wsProxy.listen(8082);

My client makes tries to connect to the proxy on the port 8082, but I still get the same error:

VM61:35 WebSocket connection to 'ws://localhost:8082/tango-ws' failed: Connection closed before receiving a handshake response

Had anyone had any luck proxying websockets from a Gulp task ?

[julbra]

@HereThereBeMonsters I did have some luck.

I had an express instance running the backend AND serving the files. I then used the proxy option of browserSync directly and that worked like such:

browserSync.init({
        proxy: 'http://localhost:' + port,
        port: port + 1,
        ws: true,
        ui: {
            port: port + 3
        }
    });

Where port was the port of the express server.

Now when the backend and file server are separate I have zero luck.

[HereThereBeMonsters]

@julbra : thanks for the input. I need it with BrowserSync serving the files, so in "server" mode so it seems that I wont be able to do it. For now I will just hit the backend directly and I'll have to remove the same-origin check on the WebSocket endpoint.

[gustavodegeus]

Any update for this issue?

[Boscop]

Any update on this?