Current behaviour
What is actually happening?
When one connects to a different namespace with multiplexing enabled such as
let one = io.connect('/one', {
'force new connection': false,
query: { param: 'one' }
});
let two = io.connect('/two', {
'force new connection': false,
query: { param: 'two' }
});
the updated query is not parsed correctly on the server. The server side code
let one = io.of('one').on('connection', socket => {
let { query } = socket.handshake;
console.log('one', query.param, query.param === 'one');
});
let two = io.of('two').on('connection', socket => {
let { query } = socket.handshake;
console.log('two', query.param, query.param === 'two');
});
logs
one one true
two one false
When multiplexing is explicitly disabled by setting
{ 'force new connection': true }
the server logs
one one true
two two true
as expected.
Steps to reproduce
Fork https://github.com/sebamarynissen/socket.io-fiddle. Run npm start, open up a browser and go to http://localhost:3000.
Expected behaviour
The query object should be the same, regardless of whether multiplexing is enabled or not.
Setup
- OS: Windows 10
- browser: Chrome
- socket.io version: 2.3.0
Other information
When I open up the WS network tab in Chrome devtools, it logs that
is sent to the server, so it seems that at least the client sends the correct query to the server. Hence I guess that this is a server related issue.
Current behaviour
What is actually happening?
When one connects to a different namespace with multiplexing enabled such as
the updated query is not parsed correctly on the server. The server side code
logs
When multiplexing is explicitly disabled by setting
the server logs
as expected.
Steps to reproduce
Fork https://github.com/sebamarynissen/socket.io-fiddle. Run
npm start, open up a browser and go tohttp://localhost:3000.Expected behaviour
The query object should be the same, regardless of whether multiplexing is enabled or not.
Setup
Other information
When I open up the WS network tab in Chrome devtools, it logs that
is sent to the server, so it seems that at least the client sends the correct query to the server. Hence I guess that this is a server related issue.