The Socket instance is only considered connected when the "connection"
event is emitted, and not during the middleware(s) execution.
```js
io.use((socket, next) => {
console.log(socket.connected); // prints "false"
next();
});
io.on("connection", (socket) => {
console.log(socket.connected); // prints "true"
});
```
Related: https://github.com/socketio/socket.io/issues/4129
Backported from 02b0f73e2c
Using an async operation with `io.use()` could lead to the creation of
several instances of a same namespace, each of them overriding the
previous one.
Example:
```js
io.use(async (nsp, auth, next) => {
await anOperationThatTakesSomeTime();
next();
});
```
Related: https://github.com/socketio/socket.io/issues/4136
Backported from 9d86397243
This reverts commit f78a575f66.
This commit contains a breaking change which deviates from semver,
which we try to follow as closely as possible. That's why this change
is reverted and we will rather suggest users to upgrade to v3.
Related: https://github.com/socketio/socket.io/discussions/3741
This follows #3187, with a slightly different API.
A dynamic namespace can be created with:
```js
io.of(/^\/dynamic-\d+$/).on('connect', (socket) => { /* ... */ });
```
Previously, the protocol was not taken in account, which caused the following behaviour:
```js
io.origins('https://foo.example.com:443'); // ok as a string
io.origins(['https://foo.example.com:443'); // not ok as an array
```
Fixes#3190
Using a middleware could previously lead to a connecting client
receiving a connect event from the server before the server triggers
its own connect event.
* fix(socket): Fixes socket.use error packet which drops nodejs due to nuances of Nodejs' EventEmitter
* fix(socket): Fixes missing error event on socket
* fix(socket): test fix, should listen for clientSocket instead of server socket
* minor update
Test 'should be able to close sio sending a port' defined a clientSocket
but didn't set 'reconnection: false'.
Now, the default behavior of a clientSocket is 'reconnection: true'.
As a result, the clientSocket was "leaked" from the test case
and seemed to intermittently connect to the servers in subsequent
test cases. This would cause other tests to timeout unexpectedly.
It's not clear to me why this would happen, since the test case
assigns a unique port number to the socket.
However, if you go into socket.io-client and assign and log
unique IDs to each socket, then you'll see that this clientSocket
shows up in other test cases if the reconnectionDelay strikes
unluckily.
The standard says that an ETag must be surrounded in double quotes:
https://tools.ietf.org/html/rfc7232#section-2.3
Although browsers tend to be lenient, omitting the quotes can confuse/break some kinds of proxies and other tools that demand compliant formatting. For example, Sandstorm.io enforces strict HTTP usage for security reasons and will block responses with invalid ETags.
