mirror of
https://github.com/oven-sh/bun
synced 2026-02-16 13:51:47 +00:00
a68393926b
## Summary - Fix WebSocket client pong frame handler to properly handle payloads split across TCP segments, preventing frame desync that could cause protocol confusion - Add missing RFC 6455 Section 5.5 validation: control frame payloads must not exceed 125 bytes (pong handler lacked this check, unlike ping and close handlers) ## Details The pong handler (lines 652-663) had two issues: 1. **Frame desync on fragmented delivery**: When a pong payload was split across TCP segments (`data.len < receive_body_remain`), the handler consumed only the available bytes but unconditionally reset `receive_state = .need_header` and `receive_body_remain = 0`. The remaining payload bytes in the next TCP delivery were then misinterpreted as WebSocket frame headers. 2. **Missing payload length validation**: Unlike the ping handler (line 615) and close handler (line 680), the pong handler did not validate the 7-bit payload length against the RFC 6455 limit of 125 bytes for control frames. The fix models the pong handler after the existing ping handler pattern: track partial delivery state with a `pong_received` boolean, buffer incoming data into `ping_frame_bytes`, and only reset to `need_header` after the complete payload has been consumed. ## Test plan - [x] New test `websocket-pong-fragmented.test.ts` verifies: - Fragmented pong delivery (50-byte payload split into 2+48 bytes) does not cause frame desync, and a subsequent text frame is received correctly - Pong frames with >125 byte payloads are rejected as invalid control frames - [x] Test fails with `USE_SYSTEM_BUN=1` (reproduces the bug) and passes with `bun bd test` - [x] Existing WebSocket tests pass: `websocket-client.test.ts`, `websocket-close-fragmented.test.ts`, `websocket-client-short-read.test.ts` 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Bot <claude-bot@bun.sh> Co-authored-by: Claude <noreply@anthropic.com>