mirror of
https://github.com/rustdesk/hbb_common.git
synced 2026-10-11 19:23:59 +00:00
rustdeskandClaude Fable 5.1
e999dcea24
The cap's header-only refusal was tested on the TCP codec and its reassembly bound on WebRTC, but not on WebSocket, which is the transport where a frame header buys an allocation, and neither transport had a test that lifting the cap lets a large message through again - the half of the lifecycle a server runs at authorization, and the one a forgotten restore would break silently. Two WebSocket tests build a loopback from a raw TcpStream with no handshake, write server-to-client frames by hand, and check that a header declaring one byte over the cap is refused before any payload exists, and that a message refused under a low cap arrives once the cap is lifted. A WebRTC test does the same lift. Each fails when the corresponding half of set_max_packet_length is made a no-op. The doc on Stream::set_max_packet_length now says the one thing the bound does not do: lowering it applies from the next frame on and does not discard one whose decoding or reassembly has already begun, so it has to be set before the first read of untrusted data. That is how the server uses it; the note is there so nothing later treats it as a switch that can be thrown at any time. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab