Closed Choraden closed 2 months ago
I think that we lost the ability to set the connect headers with this patch.
The only place where d.ProxyConnectHeader
is set is in.
if id := req.Header.Get(p.RequestIDHeader); id != "" {
h := make(http.Header)
h.Set(p.RequestIDHeader, id)
d.ProxyConnectHeader = h
}
Please add an e2e test for this flag.
I think that we lost the ability to set the connect headers with this patch.
Yes, we did and I did it on purpose. It turns out we can't reuse regular RequestHeaders as they contain basic auth and some other modifiers that should not apply to dialvia's CONNECT request. In order to do that we would need to add some extra logic, which would definitely increase complexity. The primary reason to modify proxy connect headers was to add request-id which now we do. At this point I'm wondering if trading code simplicity and readability for having this feature is worth it.
WDYT? @mmatczuk
AFAIMC the only mussing bit is to copy the processed headers if any to dialvia in martian.
--connect-header
flag ~I'm not sure, if we really need to support case nr 2.~ As you can see in tests it really takes effort to achieve it. One needs to send http request with X-Forwarded-Proto
header explicitly set to https
.
EDIT: MITM is a valid use case. After the tls is terminated, forwarder receives https requests that issue CONNECTs via http.Transport.
I agree that --connect-headers are better name can we have --proxy-headers as deprecated alias for backwards compatibility.
LGTM
This patch:
--proxy-header
to--connect-header
as it was confusingFixes #782