ws_session_feed has two teardown branches that queue a close and return -1.
The inbound-cap one arms a lingering close, because the peer that overflowed the
cap is by definition still sending and its unread bytes turn the close into a
reset (#305). The permessage-deflate one does not:
#ifdef HAVE_HTTP_COMPRESSION
if (session->pmce_error) {
ws_session_mark_peer_closed(session);
return -1;
}
#endifpmce_error is latched where a compressed message overflows the per-message cap
or fails to inflate (src/websocket/ws_session.c, on_msg_recv), and it queues
CLOSE 1009. A peer sending a decompression bomb is sending, so the shape looks
identical to the 1013 case: the close is written, the transport is torn down
over bytes the peer has not read, and the reset discards it.
Not proved. No run of it has been made to fail, which is why #305 left it
alone rather than arming the drain on the resemblance. The two differ in one
way that could matter: a bomb overflows on a single message, so the peer may
have stopped sending by the time the close goes out, where the FIFO case needs a
peer that is still flooding.
Feedback loop
websocket/021-permessage-deflate-bomb covers the path but asserts the worker
survives, not that the client reads the code. The loop is a copy that reads the
close frame back, run outside run-tests so a failure on one run in two is not
hidden by the retry, on Windows where a reset is immediate. If the close arrives
on every run with the bomb sized to the cap and goes missing when the peer keeps
writing past it, the cause is the same one and the fix is the same call.
Found while fixing #305.
ws_session_feedhas two teardown branches that queue a close and return -1.The inbound-cap one arms a lingering close, because the peer that overflowed the
cap is by definition still sending and its unread bytes turn the close into a
reset (#305). The permessage-deflate one does not:
pmce_erroris latched where a compressed message overflows the per-message capor fails to inflate (
src/websocket/ws_session.c,on_msg_recv), and it queuesCLOSE 1009. A peer sending a decompression bomb is sending, so the shape looks
identical to the 1013 case: the close is written, the transport is torn down
over bytes the peer has not read, and the reset discards it.
Not proved. No run of it has been made to fail, which is why #305 left it
alone rather than arming the drain on the resemblance. The two differ in one
way that could matter: a bomb overflows on a single message, so the peer may
have stopped sending by the time the close goes out, where the FIFO case needs a
peer that is still flooding.
Feedback loop
websocket/021-permessage-deflate-bombcovers the path but asserts the workersurvives, not that the client reads the code. The loop is a copy that reads the
close frame back, run outside
run-testsso a failure on one run in two is nothidden by the retry, on Windows where a reset is immediate. If the close arrives
on every run with the bomb sized to the cap and goes missing when the peer keeps
writing past it, the cause is the same one and the fix is the same call.
Found while fixing #305.