WebsocketClient seems to wrongly detect connection drops

[roma-glushko]

I'm having a socket.io communication and websocket-client is being used under the hood in the python-socketio library. At some point of time, I have started to receive a massive amount of reconnections along the protocol.

Spending some time figuring out if there is any proxy on the connection way that could possibly be a reason of connection drops brings no evidence of such. The socket.io server is also reporting this drops as ones that were closed by the client (something along the lines of the client connection closed with the reason of transport close").

Digging deeper into the client side of things, I have realized that it's websocket-client library that decides that the connection is droped. It happens here:

websocket-client/websocket/_socket.py

Lines 121 to 123 in bd506ad

	if not bytes_:
	raise WebSocketConnectionClosedException(
	"Connection to remote host was lost.")

At some point, when a new message came, this function starts to read the header:

..using a two-bytes buffer. For some reason the first recv() call ends up reading zero bytes:

Which further leads to the following error:

Connection to remote host was lost

However, the connection seems to be okay and if I keep calling the function I could read three more chunks of data which in this case happened to be a socket.io's ping message:

I'm not sure why we are reading zero bytes for the first pass sometimes, but the error seems to be misleading a bit.
Could handle this case differently to account for such situations?

[engn33r]

@roma-glushko Some requests for more information:

1. which websocket-client release are you using?
2. are you setting any custom timeout values for the connection on the client side?
3. are you calling recv() directly in your code, or are you using run_forever() from WebSocketApp?
4. can you reliably recreate this issue?

This looks similar to #812 which involved a socketio connection, but I am confused why the first read is zero bytes. Can you share the sequence of messages received after this zero read, so I can understand what header is received and better understand where in the connection process the error happens? You may be encountering an unusual edge case at the start of a connection or the server communication may not proper the websocket RFC spec.