Decode compressed request bodies and upstream responses

[fylorn]

What

• Inbound: a request body sent with Content-Encoding: gzip, deflate or zstd is decoded in server::intake right after it is read, on every gateway route (messages, chat completions, responses, Gemini, count_tokens, passthrough). The header is removed from the request, so everything downstream sees an ordinary uncompressed request and nothing about the client's encoding reaches the upstream (the Codex backend path keeps its own zstd compression of the outgoing body).
• Size limit on the decoded size: decoding uses a bounded reader (max + 1 bytes); a small compressed body that inflates past the 256 MiB cap is refused with 413 like an oversized plain body, whatever the compressed data or Content-Length claims. (There is no 2 MiB rule any more: Core#295 removed axum's default extractor limit; the 256 MiB cap in intake is the only one, and its semantics are unchanged.)
• An unknown encoding (br, stacked encodings) is refused with 400 before the body is read; a body that does not decode is a 400 in the client's format.
• Upstream responses: the new tw_gateway::inflate module wraps the upstream body in a streaming decoder (gzip/deflate/zstd) and drops content-encoding and the stale content-length. SSE is decoded frame by frame, so streaming still arrives event by event. br is not decoded (no decoder in the tree) and passes through as before.
• The Bedrock refusal path, which replaces the body with the gateway's own sentence, now also drops content-encoding.

Why not reqwest's gzip/zstd features

The traffic counters (tw_gateway::traffic, shipped with Lite 2026.10.12) report wire bytes and are layered on the raw reqwest body; the module has a guard test (the_client_does_not_decompress) for exactly this. Enabling reqwest's automatic decompression would silently turn received_bytes into decoded bytes. The decoder is therefore the gateway's own layer, applied outside the meter in hop::dispatch. The gateway still does not send Accept-Encoding.

Tests

• server::intake unit tests: gzip/deflate/zstd decode, decoded-over-limit → 413 TooLarge, corrupt/truncated → 400, unknown and stacked encodings refused without reading the body, identity.
• inflate unit tests: frame-by-frame gzip SSE, zstd/deflate whole bodies, unknown encoding left alone, corrupt stream errors.
• New tests/compressed.rs end to end: gzip body on the passthrough route, zstd body on a converted route (chat → Anthropic), gzip count_tokens, corrupt body → 400 in the client's format with nothing reaching the upstream, br refused, upstream gzip JSON reaches the client decoded without content-encoding, upstream gzip SSE reaches the client decoded with the first event arriving before the upstream has finished sending.
• tests/traffic.rs: the zstd answer now reaches the client decoded while received_bytes stays the wire size (expectation updated; byte counting unchanged).
• crates/tw-api/msg-codes.txt regenerated.

Verified locally: cargo fmt --all --check, cargo clippy --workspace --all-targets -- -D warnings, env -u HTTP_PROXY -u HTTPS_PROXY -u http_proxy -u https_proxy cargo test -p tw-gateway (all green), cargo test --workspace (all green after regenerating the manifest).

New messages

• gw.request.unsupported_encoding (400): "The request body is encoded as {encoding}; the gateway decodes only gzip, deflate and zstd."
• gw.request.bad_encoding (400): "The request body could not be decoded as {encoding}: {detail}"
• gw.request.decoded_body_over_limit (413): "The request body is over the {max}-byte limit once decoded."

No protocol change.

🤖 Generated with Claude Code