fix: remove 64MB camouflage body cap that terminates HTTP/3 downloads#118
Closed
Itsusinn wants to merge 2 commits into
Closed
fix: remove 64MB camouflage body cap that terminates HTTP/3 downloads#118Itsusinn wants to merge 2 commits into
Itsusinn wants to merge 2 commits into
Conversation
End-to-end test that spawns: - a one-shot HTTP/1.1 backend serving an 80 MiB body - tuic-server with [camouflage] enabled - an h3 client (h3 + h3-quinn + crates.io quinn 0.11 dev-deps) and asserts the full 80 MiB arrives. Verified to fail when the old MAX_RESPONSE_BODY_SIZE = 64 MiB cap is reintroduced (truncates at ~64 MiB with a "response body too large" error). The dev-deps use crates.io quinn 0.11 for the client side, separate from the forked quinn 0.12 that tuic-server itself uses — different Rust types but they interoperate over the QUIC wire. Assisted-by: Claude:claude-opus-4-7
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.
Summary
Fixes #117 — when
tuic-serveris used as an HTTP/3 camouflage reverse proxy, browser downloads (and video streams) over QUIC are interrupted at exactly 64 MB.Root cause is not QUIC
receive_window(the maintainer's initial guess) — it's a hard-codedMAX_RESPONSE_BODY_SIZE = 64 MiBconstant intuic-server/src/camouflage.rs. After accumulating 64 MB of forwarded response bytes,forward_requestreturnsErr, which finishes the H3 stream prematurely. From the browser's side this looks like a terminated QUIC connection.A symmetrical 16 MB cap (
MAX_REQUEST_BODY_SIZE) on the request side fully buffered request bodies in memory and rejected larger uploads.Changes
MAX_RESPONSE_BODY_SIZEandMAX_REQUEST_BODY_SIZEconstants.body_sizeaccumulator/check; chunks now stream end-to-end without an artificial cap. QUIC stream flow control (stream_receive_window,send_window) still bounds memory.read_request_body(which read the whole body into aVec<u8>) with a streamingreqwest::Body::wrap_streamadapter built onfutures::stream::unfoldover the H3 receive half. Large uploads now also pass through.forward_requestto take ownership ofRequestStreamandsplit()it; the 502-on-backend-failure path moved insideforward_requestsince the stream is consumed there.No new config fields. Users wanting to tune memory/throughput already have
[quic].receive_windowand[quic].send_window.Out of scope: the maintainer's separate suggestion to swap
quinnforquiche/boringsslfor fingerprint reasons.Test plan
cargo build -p tuic-servercargo test -p tuic-server --lib— 120 passed, 0 failedcargo clippy -p tuic-server --all-targets— clean[camouflage]with a backend serving a >100 MB file, download via an HTTP/3 browser (Edge/Chrome withalt-svc), confirm completion past the previous ~64 MB cutoffcurl --http3 -X POST --data-binary @largefile ...against an echo backend with body > 16 MBAssisted-by: Claude:claude-opus-4-7