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