You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Java version/vendor(use: java -version)
openjdk version "17.0.7" 2023-04-18 LTS
OpenJDK Runtime Environment Zulu17.42+21-CRaC-CA (build 17.0.7+7-LTS)
OpenJDK 64-Bit Server VM Zulu17.42+21-CRaC-CA (build 17.0.7+7-LTS, mixed mode, sharing)
OS type/version
Ubuntu 22.04.2 LTS
Description
Calling RemoteEndpoint.flushBatch() with batching enabled causes the FLUSH_FRAME to be propagated all the way to the client when "permessage-deflate" has been activated (and so PerMessageDeflateExtension is responsible for sending frames).
Here is the full listing of logs in Debug when using permessage-deflate (I send a text Frame then I basically call flushBatch). Note the reference for the BINARY Framed changed from BINARY@375b9d69 to BINARY@56bbfc33 thus escaping FLUSH_FRAME detection
I am not confident enough on the Jetty architecture to submit a proper patch since there is multiple fix possible for that (from "Create a proper FlushFrame object extending Frame to use 'equals' instead of '=='" to "having PerMessageDeflate to detect Flush frame"). But i'm willingful to help fix the problem and PR.
How to reproduce?
Start a websocket server
Start a websocket client with permessage-deflate extension activated
Send a Message from server to client
Use flushBatch()
Observe 2 messages (TEXT and BINARY) on Client side.
The text was updated successfully, but these errors were encountered:
Jetty version(s)
websocket-jakarta-server 11.0.15 (possibly 12.x)
Java version/vendor
(use: java -version)
openjdk version "17.0.7" 2023-04-18 LTS
OpenJDK Runtime Environment Zulu17.42+21-CRaC-CA (build 17.0.7+7-LTS)
OpenJDK 64-Bit Server VM Zulu17.42+21-CRaC-CA (build 17.0.7+7-LTS, mixed mode, sharing)
OS type/version
Ubuntu 22.04.2 LTS
Description
Calling RemoteEndpoint.flushBatch() with batching enabled causes the FLUSH_FRAME to be propagated all the way to the client when "permessage-deflate" has been activated (and so PerMessageDeflateExtension is responsible for sending frames).
WebSocketCoreSession injects a FrameFlusher.FLUSH_FRAME in the pipeline to force flushing, however this frame when used with the deflate extension ends up being sent to the client due to a chunk copy when Deflating. This new propagated Frame then fails the equlity test in FrameFlusher, and the resulting Frame ends being sent on the Network.
Here is the full listing of logs in Debug when using permessage-deflate (I send a text Frame then I basically call flushBatch). Note the reference for the BINARY Framed changed from BINARY@375b9d69 to BINARY@56bbfc33 thus escaping FLUSH_FRAME detection
I am not confident enough on the Jetty architecture to submit a proper patch since there is multiple fix possible for that (from "Create a proper FlushFrame object extending Frame to use 'equals' instead of '=='" to "having PerMessageDeflate to detect Flush frame"). But i'm willingful to help fix the problem and PR.
How to reproduce?
The text was updated successfully, but these errors were encountered: