As per the question raised here regarding to changes made in Vert.x 3.9.3 around websocket close handling.
In Vert.x 3.9.2, closing a websocket would result in a close frame being sent to the client (to instruct it to close). With version 3.9.3, this code seems to have changed significantly. We observed that when we do an abrupt server close , the close mechanism is now propagated to the client by just closing the websocket connection (or channel). Close frames are not sent from the server (or returned from the client).
By abrupt server close, I mean: httpServer.close();
Version
Vert.x 3.9.3
Context
I encountered an exception which looks suspicious while ...
As part of our product, we test proxying websocket data from a Vert.x client to a Vert.x server but not using a Vert.x websocket proxy. Previously, when frames were used, the server close message was propagated by the proxy to the client.
With version 3.9.3, the proxy receives the connection/ channel close but does not receive a close message. The proxy then cannot propagate the close to the client. The best it can do is close its own websocket connection to the client.
(Side-issue unrelated to Vert.x: In our test, propagating the close to the client is not as straightforward as you'd expect as the proxy is running in a Tomcat instance. Closing the websocket connection does not close the HTTP connection, so the client remains completely unaware of the close).
We do not see close frames being sent in either direction, as we did with Vert.x 3.9.2. We see only the FIN request from the server to the proxy and ACK in return.
Do you have a reproducer?
Julien indicated this wouldn't be necessary for now but I'm happy to provide it if it helps.
Steps to reproduce
Configure client and server with proxy between
Open websocket to proxy - which propagates websocket upgrade request to server.
101 is returned from server, via proxy to client
Abruptly close the server: httpServer.close()
Observe that the client waits (until idleTimeout) as it has not been made aware of the close notification.
Please see the attached images taken from WireShark, showing the relevant comms between the client -> proxy -> server:
proxy-392.jpg shows the comms using Vert.x 3.9.2 - and clearly shows the websocket close frames being sent prior to the FIN (commencing at packet no 15850).
proxy-393.jpg shows the comms using Vert.x 3.9.3 - and shows only the connection closure (FIN - beginning with packet no 207).
vietj
commented
3 years ago
Questions
As per the question raised here regarding to changes made in Vert.x 3.9.3 around websocket close handling.
In Vert.x 3.9.2, closing a websocket would result in a close frame being sent to the client (to instruct it to close). With version 3.9.3, this code seems to have changed significantly. We observed that when we do an abrupt server close , the close mechanism is now propagated to the client by just closing the websocket connection (or channel). Close frames are not sent from the server (or returned from the client).
By abrupt server close, I mean:
httpServer.close();Version
Vert.x 3.9.3
Context
I encountered an exception which looks suspicious while ...
As part of our product, we test proxying websocket data from a Vert.x client to a Vert.x server but not using a Vert.x websocket proxy. Previously, when frames were used, the server close message was propagated by the proxy to the client.
With version 3.9.3, the proxy receives the connection/ channel close but does not receive a close message. The proxy then cannot propagate the close to the client. The best it can do is close its own websocket connection to the client.
(Side-issue unrelated to Vert.x: In our test, propagating the close to the client is not as straightforward as you'd expect as the proxy is running in a Tomcat instance. Closing the websocket connection does not close the HTTP connection, so the client remains completely unaware of the close).
We do not see close frames being sent in either direction, as we did with Vert.x 3.9.2. We see only the FIN request from the server to the proxy and ACK in return.
Do you have a reproducer?
Julien indicated this wouldn't be necessary for now but I'm happy to provide it if it helps.
Steps to reproduce
httpServer.close()Please see the attached images taken from WireShark, showing the relevant comms between the client -> proxy -> server:
[client] --> [(8787) proxy] --> [(7878) server] arrangement:
Wireshark:
Extra