{"author":"Stefan Eissing","author_email":"stefan@eissing.org","author_time":1735832092,"commit_time":1737062347,"committer":"Jay Satiro","committer_email":"raysatiro@yahoo.com","hash":"02edae54e8b3953b8aeb0ff91be86d5db2169670","message":"websocket: fix message send corruption\n\n- Fix a bug in EAGAIN handling when sending frames that led to a\n  corrupted last byte of the frame sent.\n\n- Restore sanity to curl_ws_send() behaviour:\n\n  - Partial writes are reported as OK with the actual number of\n    payload bytes sent.\n\n  - CURLE_AGAIN is only returned when none of the payload bytes\n    (or for 0-length frames, not all of the frame header bytes)\n    could be sent.\n\n  - curl_ws_send() now behaves like a common send() call.\n\n- Change 'ws-data' test client to allow concurrent send/recv\n  operations and vary frame sizes and repeat count.\n\n- Add DEBUG env var CURL_WS_CHUNK_EAGAIN to simulate blocking\n  after a chunk of an encoded websocket frame has been sent.\n\n- Add tests.\n\n\nPrior to this change data corruption may occur when sending websocket\nmessages due to two bugs:\n\n1) 3e64569a (precedes 8.10.0) caused a data corruption bug in the last\n   byte of frame of large messages.\n\n2) curl_ws_send had non-traditional send behavior and could return\n   CURLE_AGAIN with bytes sent and expect the caller to adjust buffer\n   and buflen in a subsequent call. That behavior was not documented.\n\n\nReported-by: na-trium-144@users.noreply.github.com\n\nFixes https://github.com/curl/curl/issues/15865\nFixes https://github.com/curl/curl/issues/15865#issuecomment-2569870144\nCloses https://github.com/curl/curl/pull/15901\n\n","parents":["86f5653721865fc9c0dbab2f30e3b8040af957cd"],"tree_hash":"9e329fbbb85321e5dc0f78519d77b74c3cc115ea"}