Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Invalid
-
None
-
None
-
None
Description
On upgrading jetty to 9.4.x, the reflection was used to set maximum binary message size to 0 (unconstrained). The improved github request [1] was raised with jetty to relax WebSocketPolicy.setMax*MessageSize to allow setting of "maximum binary message size" to 0.
The github request was implemented but it was suggested to use streaming API instead. Here is the quotes form the reply:
joakime:
Setting the maxBinaryMessageSize at 0 would mean you never send a binary message payload (no length).
Jetty has traditionally not support unconstrained whole binary messages delivery.
It only supports unconstrained binary messages via the streaming APIs.
Internally, the maximum whole message size (or individual frame payload size) is Integer.MAX_VALUE.This is well below what the WebSocket protocol is capable of handling at the frame level.
But if you are attempting to set this for the frame level, know that efforts underway with WebSocket over HTTP2 will likely make the websocket frame maximum conform to the HTTP2 frame maximum (65k IIRC)
Also, with websocket extensions in play, the frame level maximums can also be constrained to small values.Know that there are 2 values when using the Jetty Native WebSocket API (message and buffer), but only 1 value when using JSR356 WebSocket API (buffer).
I'll relax the message size limit checks, but not the buffer size limits.
Know that you are opening yourself to many different classes of OutOfMemory errors if you do this.
It would be trivially easy for a websocket client to crash your server with a single short message with this kind of configuration.
Change applied.
But I would encourage you to either use the streaming APIs or set the max message size to something reasonable.
Some of the Streaming API examples are provided at [2]
[1] https://github.com/eclipse/jetty.project/issues/1569
[2] https://webtide.com/jetty-9-updated-websocket-api/