mirror of
https://github.com/rustdesk/hbb_common.git
synced 2026-10-20 07:34:35 +00:00
rustdeskandClaude Fable 5.1
f0f1548ba3
The two WebSocket tests both stopped at max_frame_size: a header over the cap and a single large frame after the cap is lifted. Dropping max_message_size from set_max_packet_length left both passing, and that line is what refuses two frames each under the cap that reassemble to a message over it - the other way a peer buys the allocation. A test now sends exactly that, 12 KiB and a 12 KiB continuation against a 16 KiB cap, and fails when the line is dropped. The doc on Stream::set_max_packet_length claimed that lowering the bound never discards a message already being reassembled. That is the TCP codec, which checks only on the header; WebRTC and a fragmented WebSocket message re-check the bound on every fragment and end the message once it passes. The doc now promises only what holds everywhere: set it before the first read, and do not lean on lowering it to constrain a message in progress. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab