Fix Windows proxy response loss on pipelined requests - #432
Merged
Merged
Conversation
The forward proxy serves one HTTP request per authenticated connection and deliberately never reads bytes the client pipelined after it. Dropping the socket while those bytes sit unread sends RST instead of FIN, and on Windows a reset discards data the peer has not read yet, so the client can lose the 200 response it was about to read. The `pipelined_request_and_chunk_trailers_never_reach_origin` test hit this intermittently on the Windows CI runner. After the origin's response is relayed, shut down the write side first and discard whatever the client sends until it closes, bounded to one second. The pipelined request still never reaches the origin. The test now also requires an orderly EOF after the response; that assertion fails with ECONNRESET on macOS without this change.
This was referenced Sep 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Behaviour
The preview forward proxy handles one HTTP request per authenticated connection and intentionally leaves pipelined bytes unread so they never reach the origin. Returning from the handler dropped the client socket with those bytes still in the receive buffer, which closes with RST rather than FIN. On Windows a reset discards data the peer has not read yet, so the client could lose the already-sent response. This is the
pipelined_request_and_chunk_trailers_never_reach_originfailure (Os { code: 10054, kind: ConnectionReset }atproxy.rs:83) seen on the Windows runner for main (cba07d3) and PR #430.After relaying the origin's response the proxy now shuts down its write side, then discards whatever the client sends until the client closes, capped at one second. The existing idle and shutdown watchdogs still bound the connection. CONNECT and upgrade tunnels already waited for both directions to finish and are unchanged.
Test contract
pipelined_request_and_chunk_trailers_never_reach_originnow also asserts that the client reads an orderly EOF after the response. Without the proxy change this assertion fails deterministically on macOS withECONNRESET; with it, the proxy test suite passes. The origin-side assertion that pipelined bytes never arrive is unchanged.Checks
cargo fmt --all --checkcargo clippy --workspace --all-targets --locked -- -D warningscargo test -p tcode-remote --test proxy(11 passed), including the strengthened test failing without the fix