During HTTP Connect proxying, pingora does not pass data unmodified
Describe the bug
When doing an HTTP connect, responses from the server seem to be having a new line added to them
Pingora info
Please include the following information about your environment:
Pingora version: 0.3.0
Rust version: i.e. cargo --version
Operating system version: CentOS 9
Steps to reproduce
- Setup a simple HTTP proxy through pingora, with a single backend, and a middleware that adds an HTTP header
- Perform an HTTP connect over this proxy (pingora shouldn't participate after the request is started)
Expected results
The traffic should be passed through unchanged.
Observed results
Responses from the server will have an extra new line interspersed
Some log traces:
2024-10-05T01:05:15.792912Z DEBUG runtime.spawn{kind=task task.name= task.id=175 loc.file="third-party/rust/vendor/pingora-core-0.3.0/src/services/listening.rs" loc.line=169 loc.col=38}: pingora_proxy::proxy_h1: upstream event: Some(Body(Some(b"123\n"), false))
2024-10-05T01:05:15.792962Z TRACE runtime.spawn{kind=task task.name= task.id=175 loc.file="third-party/rust/vendor/pingora-core-0.3.0/src/services/listening.rs" loc.line=169 loc.col=38}: pingora_core::protocols::http::v1::body: Writing Body, size: 4
(which actually looks right) What I see on the wire (from the client):
4
123
It appears like it might be in chunked encoding mode? The server isn't in chunked encoding mode...
From lightly poking around, it appears like I have to implement a CONNECT proxy using this: https://docs.rs/pingora-core/0.3.0/pingora_core/upstreams/peer/struct.Proxy.html -- but, it only takes a UDS path, and not another TCP address....
- Is there an escape hatch?
- Why?
A full fledged CONNECT proxy is still work in progress.
This question has been stale for a week. It will be closed in an additional day if not updated.
This issue has been closed because it has been stalled with no activity.