SIGN IN SIGN UP

Fix WSClient.update dropping frames buffered in the SSL socket

WSClient.update() waits for the underlying socket to become readable
via poll()/select() before reading a frame. SSL sockets decrypt an
entire TLS record at a time, so when several websocket frames arrive
in one TLS record, the first recv_data_frame() call consumes the whole
record from the socket and the remaining frames sit decrypted inside
the SSLSocket's internal buffer, where poll()/select() cannot see
them. Those frames are only delivered once new data arrives on the
connection and are lost if it never does, which randomly truncates
large outputs read through the stream API.

Check SSLSocket.pending() before polling, mirroring what
PortForward._proxy() already does, so buffered frames are consumed
without waiting for socket readability.

The OPCODE_CONT handling suggested in the issue is not needed:
websocket-client reassembles continuation frames inside
recv_data_frame() and returns the opcode of the initial frame, so
update() never observes OPCODE_CONT. A regression test documents that
fragmented messages are delivered in full.

Signed-off-by: Jojin <jojin.kb@gmail.com>
J
Jojin committed
bc0b96f365399d4d421545ec83d625899bf00131
Parent: 5583fb5