Websocket frames does not get throttled if the client sends compressed frames

[suksw]

Description:

Error

• The enforcer throws an InvalidFrameException if the client sends compressed frames. Therefore the frames do not get throttled and the backend continues to receive the frames.

  Due to

• At the enforcer, we decode the frame received from the router into a list of frames, to handle the scenario explained here https://github.com/wso2/product-microgateway/blob/fdc49ba4398cbb05a36e553100fea700d4a051ff/enforcer-parent/enforcer/src/main/java/org/wso2/choreo/connect/enforcer/websocket/WebSocketResponseObserver.java#L64
• For this, we use the class org.java_websocket.drafts.Draft_6455
• Currently, the library has an extension to handle the scenario https://github.com/TooTallNate/Java-WebSocket/blob/c2d0873f1ece5e5b4bbf2cfeb6cf02a14fed62ad/src/main/example/PerMessageDeflateExample.java#L30
• Yet, the method we use only support the default extension, since we are not using the class with the asServer or asClient methods
  • https://github.com/TooTallNate/Java-WebSocket/blob/c2d0873f1ece5e5b4bbf2cfeb6cf02a14fed62ad/src/main/java/org/java_websocket/drafts/Draft_6455.java#L565
  • https://github.com/TooTallNate/Java-WebSocket/blob/c2d0873f1ece5e5b4bbf2cfeb6cf02a14fed62ad/src/main/java/org/java_websocket/drafts/Draft_6455.java#L701

Steps to reproduce:

This occurs during the testcase WebSocketBasicTestCase added with https://github.com/wso2/product-microgateway/pull/2663 when the line WebSocketClientCompressionHandler.INSTANCE, in integration/test-integration/src/test/java/org/wso2/choreo/connect/tests/util/websocket/WsClient.java is not commented.

Affected Product Version:

Environment details (with versions):

• OS:
• Client:
• Env (Docker/K8s):

---

Optional Fields

Related Issues:

Suggested Labels:

Suggested Assignees:

[suksw]

• As per the comment at product-microgateway/enforcer-parent/enforcer/src/main/java/org/wso2/choreo/connect/enforcer/websocket/WebSocketResponseObserver.java, we convert the byte array of batched frames in to separate frames to get the actual count of frames.
• When converting into separate frame, the library also validates whether they are regular frames or compressed (RSV1 set to true).
• The compressed frames cannot be handled unless the correct extension is set (he "permessage-deflate" Extension).
• The library currently in use and the netty.io expect the negotiation of the extension (the extension that could validate compressed frames) to be done during the handshake. Therefore, setting the extension is done only by using private methods.

Possible workarounds

• get the frame count batched at router side
• decompress the frames at router side (but then we might be breaking the protocol)
• sending the frames one at a time to the enforcer
• consider a batched set of frames as one frame when getting the throttle count

@VirajSalaka I am not sure if the first three above are possible. Kept them as a note.

References

• "PMCEs use the RSV1 bit of the WebSocket frame header to indicate whether a message is compressed or not so that an endpoint can choose not to compress messages with incompressible contents." https://datatracker.ietf.org/doc/html/rfc7692#section-1
• https://github.com/TooTallNate/Java-WebSocket/wiki/PerMessageDeflateExample