Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QWebSocketClient close() leads to TCP reset instead proper disconnection
I'm running the Echo server example together with the Echo client example on Ubuntu 18.04 x64 with Qt 5.14.0 and encountering a strange problem: When the client calls
close(), I'd expect a proper shutdown sequence (TCP FIN > FIN ACK > ACK).
What instead happens is:
- The client sends a Websocket FIN (packet 11)
- The client sends a TCP FIN (packet 12)
- The server responds with a Websocket FIN (packet 13)
- The client sends a TCP RST which aborts the connection (packet 14)
I'd expect the packet 11 as unneeded, as the Websocket FIN was already given in packets 9 and 10. Unfortunately, now all goes wrong and the server does not respond with a TCP FIN ACK.
That really smells like a bug - am I missing something?
Kent-Dorfman last edited by
From what I understand there are differing session semantics, depending upon which http version being used. For 1.1 who closes the session depends upon who sends the header/response "Connection: close". You might play with that to see if the behaviour changes and get a better idea what's going on.
I've had the same problem when running the client against ws://echo.websocket.org and created QTBUG-81084 to track that.
Thanks and regards