vhost + socket.io #459

PhilWaldmann opened this Issue Jan 15, 2012 · 13 comments

8 participants



there is a problem with socket.io and connect vhosts. (or any other library which listen to the upgrade event).

all vhosts will receive request events, but no upgrade events!
I think all events should be emitted to the appropriate vhost, right?

You can reproduce the problem by creating a simple vhost and let socket.io listen on that vhost. It will take about 5 seconds to get socket.io connected, because it will fall back to xhr polling instead of websockets (which will timeout, because the vhost will never receive an upgrade event)


Hi guys

is there any news regarding this issue ?


Can someone post some code that demonstrates the problem? I can look at it sometime in the next couple of days and work the code in to a test.


An issue has been opened also on socket.io and someone has posted a repo with code that reproduce the problem


Hope it will help !


Thanks. Will take a look at it.


It looks like Connect only touches "request" events, pretty sure this is intentional. All that needs to happen is to have the main server instance emit the "upgrade" event to the appropriate socket.io instance.

In the example all you need to do is add this to app/app.js:

vhost.on('upgrade', function(client) {
  socket.emit('upgrade', client);

This doesn't include the integration, but it's a start.

I don't know if this is something Connect should be handling. TJ, do we want vhost to relay more then just "request" events to the vhosts?

Sencha Labs member
tj commented Jan 31, 2012

yeah sure we could expose upgrade as well. I know a lot of people have wanted some middleware to work for upgrade in general with socket.io (parsing cookies etc) so maybe for those we can come up with something nicer


Do we have a specific issue in mind with parsing cookies?

Sencha Labs member
tj commented Jan 31, 2012

for example socket.io's "authorization" callback people end up doing cookies = utils.parseCookie(cookie) and some other boilerplate to grab the session blah blah


Related: #61


Hey guys, can you offer some more clarity on a workaround? I'm run a Socket.IO app on a subdomain and it seems the only way I can get it working on the same port as my other apps is though express.vhost however this is creating issues with websocket timing out and inaccuracies when clients connect & disconnect. I wrote an SO post with more details. Any thoughts would be really appreciated. Cheers -Stephen


+1. I would love to see this issue get resolved. Having websockets on their own server (and subdomain) allow it to be scaled independent of the application server.


Here we are... not too bad, just undocumented. This is for engine.io, but it should be pretty easy to get it working for socket.io.


var express = require('express'),
    port = process.argv[2] || 8080,
    http = require('http'),
    vhost = express();

 * Create our server

var server = http.createServer(vhost);

 * Servers

var api = require('./api/api'),
    ws = require('./ws/ws'),
    app = require('./app/app');

 * Handle upgrades

server.on('upgrade', ws.handleUpgrade.bind(ws));

 * Configure the virtual hosts

vhost.use(express.vhost('api.localhost', api));
vhost.use(express.vhost('ws.localhost', ws.handleRequest.bind(ws)));
vhost.use(express.vhost('localhost', app));

 * Bind to a port

console.log('Express app started on port', port);


var engine = require('engine.io'),
    server = module.exports = new engine.Server(),

server.on('connection', function(socket) {
    // ...

connect isn't going to re-emit server events. just use http.createServer() like what matt is doing:

var server = http.createServer()
server.on('request', app)
server.on('checkContinue', function (req, res) {
  req.checkContinue = true
  app(req, res)
server.on('upgrade', ws.handleUpgrade.bind(ws))
@jonathanong jonathanong closed this Nov 2, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment