`maxHttpBufferSize` should be communicated to client during handshake

[yujiang]

Summary
The current implementation of maxHttpBufferSize only validates message size on the server side. When a client sends a payload larger than this limit, the server closes the connection, often without a clear reason presented to the client. This silent failure causes confusion and makes debugging difficult.

---

Proposal
It would be significantly more robust if maxHttpBufferSize were communicated from server to client during the handshake phase, allowing the client to:

• Proactively validate outgoing messages before sending
• Provide clearer feedback to developers or users (e.g., “Payload too large; server limit is X bytes”)
• Avoid unexpected disconnections caused by accidental oversize messages

This pattern is common in network protocols, such as:

• WebSocket extension negotiation (e.g., permessage-deflate)
• HTTP/2 SETTINGS frame
• QUIC's transport parameter exchange

---

Background & Motivation
In our project, we encountered a difficult-to-debug issue where the connection was silently dropped when sending a large payload. It took months to trace the root cause to maxHttpBufferSize, as the server did not provide sufficient logging or feedback to the client.

In fact, it was an AI assistant that eventually traced the issue to the server-side buffer limit—a frustrating and time-consuming debugging process that could have been avoided with better feedback mechanisms.

For context, in our C++ socket servers, we always transmit the negotiated maxBufferSize, encryption policy, and compression mode during handshake. This pattern has proven to be effective and intuitive.

---

Suggestions

1. Include maxHttpBufferSize in the handshake response or as a config frame
2. Expose the value to the client API
3. Optionally emit a specific client-side error (e.g., payload_too_large) instead of silently dropping

---

Benefits

• Easier debugging
• Better developer experience
• Prevents data loss due to silent connection closure
• Aligns Socket.IO closer to established protocol design best practices

---

Environment

• Socket.IO version: [fill in]
• Client: [Browser / Node.js]
• Use case: [Brief description of your application if relevant]

[darrachequesne]

Hi!

This is already the case since socket.io@4.5.0. The maxPayload field (named after the maxPayload option of the ws server) is sent during the handshake by the server:

{
  "sid": "FSDjX-WRwSA4zTZMALqx",
  "upgrades": ["websocket"],
  "pingInterval": 25000,
  "pingTimeout": 20000,
  "maxPayload": 1000000
}

References:

• socketio/engine.io@088dcb4
• https://socket.io/docs/v4/server-options/#maxhttpbuffersize

[yujiang]

Thank you for the replay.

maxPayload Defaults to 100 MB
maxHttpBufferSize Defaults to 1 MB

I feel something evil