[
https://issues.apache.org/jira/browse/QPID-7805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7805:
-----------------------------
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:
{quote}
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.
{quote}
{quote}
Change applied.
But I would encourage you to either use the streaming APIs or set the max
message size to something reasonable.
{quote}
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/
was:
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 hubrequest was implemented but it was suggested to use streaming API
instead. Here is the quotes form the reply:
{quote}
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.
{quote}
{quote}
Change applied.
But I would encourage you to either use the streaming APIs or set the max
message size to something reasonable.
{quote}
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/
> [Java Broker] [Websocket] Utilize jetty streaming API in implementation of
> wesocket transport support
> -----------------------------------------------------------------------------------------------------
>
> Key: QPID-7805
> URL: https://issues.apache.org/jira/browse/QPID-7805
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Alex Rudyy
>
> 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:
> {quote}
> 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.
> {quote}
> {quote}
> Change applied.
> But I would encourage you to either use the streaming APIs or set the max
> message size to something reasonable.
> {quote}
> 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/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
