quarkus-http icon indicating copy to clipboard operation
quarkus-http copied to clipboard

Websocket connection kept alive when Netty channel was closed by responding to pings

Open hc42 opened this issue 3 years ago • 3 comments

Hello,

in the Websocket Undertow adoption when an underlying Netty channel is (half) closed it is still possible to receive Websocket messages. This is a known problem (see https://issues.redhat.com/browse/UNDERTOW-617) and the solution for messages passed on is to drop them in this case (fixed in https://github.com/quarkusio/quarkus-http/commit/f145e9c761196571761fb49def5ed2743dcc86c7).

However Ping messages are still responded to (See https://github.com/quarkusio/quarkus-http/blob/main/websocket/core/src/main/java/io/undertow/websockets/FrameHandler.java#L139). In this case the Websocket connection is kept alive by the response but the implementation here drops other messages leading to a broken inconsistent state.

To be consistent pings should not be responded to as well. I would propose a similar private handler method, that uses the same drop message mechanism. This way the behavior is consistent and a client may even detect broken connections.

hc42 avatar Feb 14 '22 16:02 hc42

P.S.One way to reproduce such a broken state is to send a TCP Reset on an established WS connection. This may occur in real live when a firewall, an API gateway or proxy server closes a connection.

hc42 avatar Feb 14 '22 16:02 hc42

@stuartwdouglas Does this issue also affects the implementation of https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/websockets/core/AbstractReceiveListener.java#L122 ?

astanik avatar Feb 15 '22 10:02 astanik

Made a solution proposal in https://github.com/quarkusio/quarkus-http/pull/100

hc42 avatar Feb 15 '22 14:02 hc42