A way for the client to figure out if the payload is too large #1518
Comments
|
That sounds like a good improvement 👍 Currently, the HTTP request or the WebSocket connection get closed if any message is bigger than the
But the client indeed does not have the reason for the "transport close" error. |
|
Hi @darrachequesne, thanks for the input. What is your opinion about a proper way to improve this experience? Should this be a new |
The close event will now include additional details to help debugging
if anything has gone wrong.
Example when a payload is over the maxHttpBufferSize value in HTTP
long-polling mode:
```js
socket.on("close", (reason, details) => {
console.log(reason); // "transport error"
// in that case, details is an error object
console.log(details.message); "xhr post error"
console.log(details.description); // 413 (the HTTP status of the response)
// details.context refers to the XMLHttpRequest object
console.log(details.context.status); // 413
console.log(details.context.responseText); // ""
});
```
Note: the error object was already included before this commit and is
kept for backward compatibility
Example when a payload is over the maxHttpBufferSize value with
WebSockets:
```js
socket.on("close", (reason, details) => {
console.log(reason); // "transport close"
// in that case, details is a plain object
console.log(details.description); // "websocket connection closed"
// details.context is a CloseEvent object
console.log(details.context.code); // 1009 (which means "Message Too Big")
console.log(details.context.reason); // ""
});
```
Example within a cluster without sticky sessions:
```js
socket.on("close", (reason, details) => {
console.log(details.context.status); // 400
console.log(details.context.responseText); // '{"code":1,"message":"Session ID unknown"}'
});
```
Note: we could also print some warnings in development for the "usual"
errors:
- CORS error
- HTTP 400 with multiple nodes
- HTTP 413 with maxHttpBufferSize
but that would require an additional step when going to production
(i.e. setting NODE_ENV variable to "production"). This is open to
discussion!
Related:
- socketio/socket.io#3946
- socketio/socket.io#1979
- socketio/socket.io-client#1518
|
The socket.on("disconnect", (reason, details) => {
console.log(reason); // "transport error"
// in that case, details is an error object
console.log(details.message); "xhr post error"
console.log(details.description); // 413 (the HTTP status of the response)
// details.context refers to the XMLHttpRequest object
console.log(details.context.status); // 413
console.log(details.context.responseText); // ""
});Implemented in b862924 and included in version |
|
I know the issue is closed but , @darrachequesne Is there a way to log or retrieve, from the client side, the payload size we tried to send ? |
|
It would be good to know the payload size that triggered the disconnect, so that we can dynamically calculate a chunkSize and relay the data across. Without the payload size, it's not possible to make any calculations and keep the comms stable & reliable. Thanks in advance. |
|
@TechAkayy that's a good idea. We might even include it in the library, which might prevent the socket from disconnecting during a big emit. What do you think? |
Is your feature request related to a problem? Please describe.
I noticed the behavior when the client sends a large payload, which exceeds the server configured
maxHttpBufferSize. In this situation, the client will get disconnected and the reason supplied to the event handler istransport error.Any resilience mechanism which would try to reconnect and resend the message will be oblivious to the underlying
'Max payload size exceedederror and enter a costly (for both client and server) loop of retries.transport errorbeing generic enough to cover a set of error scenarios which are (eventually) recoverable, while the payload size being larger than configured would not.Describe the solution you'd like
errorevent raised in this situation instead of the disconnect, again with an object holding more information.Describe alternatives you've considered
A workaround would be possible for the client to know the
maxHttpBufferSizeconfiguration of the server, measure each message and self-govern its payload size. However, this is again costly, as messages are already measured in thesocket.iostack where another set of identical validations take place.Additional context
See this resilience behavior here. The server is configured with an impossible
maxHttpBufferSizevalue, which makes the client enter an endless loop of reconnects:The text was updated successfully, but these errors were encountered: