When setting the `withCredentials` option to `true`, the Node.js client
will now include the cookies in the HTTP requests, making it easier to
use it with cookie-based sticky sessions.
Related: https://github.com/socketio/socket.io/issues/3812
This bug only exists for polling transport connections running on top
of uWS.
If the remote client abruptly disconnects (thus aborting the request)
while the server is waiting on an asynchronous operation such as
compression, the server may attempt to write a response via the aborted
response object. This causes an uncaught exception to be thrown.
We should reduce the scope of the "event" error in the next major
version, as it is overloaded today:
- it can be sent by the client (`socket.emit("error")`, which is a perfectly valid event name)
- it can be emitted when the connection encounters an error (an invalid packet for example)
- it can be emitted when a packet is rejected in a middleware (`socket.use()`)
Related: https://github.com/socketio/socket.io/issues/2047
A packet like '2[{"toString":"foo"}]' was decoded as:
{
type: EVENT,
data: [ { "toString": "foo" } ]
}
Which would then throw an error when passed to the EventEmitter class:
> TypeError: Cannot convert object to primitive value
> at Socket.emit (node:events:507:25)
> at .../node_modules/socket.io/lib/socket.js:531:14
History of the isPayloadValid() method:
- added in [78f9fc2](78f9fc2999) (v4.0.1, socket.io@3.0.0)
- updated in [1c220dd](1c220ddbf4) (v4.0.4, socket.io@3.1.0)
A specially crafted request could lead to the following exception:
> TypeError: Cannot read properties of undefined (reading 'handlesUpgrades')
> at Server.onWebSocket (build/server.js:515:67)
This bug was introduced in [1], released in version 5.1.0 and included
in version 4.1.0 of the `socket.io` parent package. Older versions are
not impacted.
[1]: 7096e98a02
In order to prevent issues like:
> error TS2345: Argument of type 'RequestHandler<ParamsDictionary, any, any, ParsedQs, Record<string, any>>' is not assignable to parameter of type 'Middleware'.
> Types of parameters 'req' and 'req' are incompatible.
> Type 'IncomingMessage' is missing the following properties from type 'Request<ParamsDictionary, any, any, ParsedQs, Record<string, any>>': get, header, accepts, acceptsCharsets, and 29 more.
>
> io.engine.use(sessionMiddleware);
~~~~~~~~~~~~~~~~~
Related: https://github.com/socketio/socket.io/issues/4644
We could also have use the RequestHandler type from the
@types/express-serve-static-core package, but that would add 5 new
dependencies.
See also: https://github.com/socketio/engine.io/issues/673
The class used to accumulate the response headers did not expose the
exact same API as its wrapped type, which could lead to the following
error in some rare cases:
> TypeError: Cannot read properties of undefined (reading 'end')
> at Polling.onDataRequest (build/transports-uws/polling.js:109:53)
> at Polling.onRequest (build/transports-uws/polling.js:47:18)
> at callback (build/userver.js:94:56)
> at uServer.verify (build/server.js:152:9)
Related: https://github.com/socketio/socket.io/issues/4643
This should (at least in theory) fix sync issues for the
`socket.io-adapter` package, which is imported by both the `socket.io`
and `@socket.io/cluster-adapter` packages:
- `socket.io@4.5.0` should resolve `socket.io-adapter@~2.4.0`
- `socket.io@4.6.0` should resolve `socket.io-adapter@~2.5.0`
