Follow-up from the post-merge review of #23.
Problem
The HTTP/1 rewriting path creates a tokio::sync::mpsc::unbounded_channel for request/response correspondence. rewrite_request_stream queues one RequestMeta before every forwarded request.
If an upstream continues reading requests but delays its responses, an unauthenticated client can pipeline requests indefinitely. The request pump continues adding metadata while the response pump cannot drain it, allowing per-connection memory growth without a defined bound.
This affects routes using HTTP header rewriting for X-Forwarded-For or JA3/JA4 forwarding.
Location
Acceptance criteria
- Replace the unbounded metadata channel with bounded backpressure or enforce a documented maximum number of outstanding pipelined requests.
- The request pump must stop advancing when the response side reaches that limit.
- Preserve correct correspondence for ordinary requests, HEAD, interim 1xx responses, Upgrade, and CONNECT.
- Add a test with an upstream that reads requests but withholds responses, proving queued metadata remains bounded.
- Include the exact 64 KiB request-header boundary in the test cleanup:
MAX_HEADER_SIZE + 1 must be rejected rather than relying on the current 70 KiB case.
Follow-up from the post-merge review of #23.
Problem
The HTTP/1 rewriting path creates a
tokio::sync::mpsc::unbounded_channelfor request/response correspondence.rewrite_request_streamqueues oneRequestMetabefore every forwarded request.If an upstream continues reading requests but delays its responses, an unauthenticated client can pipeline requests indefinitely. The request pump continues adding metadata while the response pump cannot drain it, allowing per-connection memory growth without a defined bound.
This affects routes using HTTP header rewriting for X-Forwarded-For or JA3/JA4 forwarding.
Location
src/http_proxy.rs:proxy_http1_rewriting,rewrite_request_streamAcceptance criteria
MAX_HEADER_SIZE + 1must be rejected rather than relying on the current 70 KiB case.