Is CONNECT hop-by-hop?

Hello,

    Imagine two chained proxies. When a child proxy receives a CONNECT
request, and must go through the parent proxy, is the child supposed to
forward the end-to-end CONNECT headers (e.g., User-Agent and X-Foo)?

Different specs seem to imply different answers:

1. RFC 7231 section 4.3.6 and draft-ietf-httpbis-semantics say that the
child should be "forwarding the CONNECT request to the next inbound
proxy". So the answer to my question may be "yes" because, by default,
message "forwarding" implies forwarding end-to-end headers.

2. Mozilla documentation[1] says that CONNECT is a "hop-by-hop method".
While that phrasing may be using non-standard terminology, the implied
answer to my question is "no" because hop-by-hop things are not
forwarded by default.

3. RFC 7540 section 8.3 seems to prohibit chaining CONNECT tunnels
because it says that the CONNECT recipient `establishes a TCP connection
to the server identified in the ":authority" pseudo-header field`. If
"TCP connection" here is interpreted literally, then establishing that
TCP connection from the child proxy to an origin server is impossible
when there is a parent proxy involved. The answer to my question is,
hence, "undefined behavior".

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT


The correct answer probably depends on whether the CONNECT is a
hop-by-hop mechanism. Mozilla got it right if the CONNECT request is
meant specifically for the proxy at the next hop. HTTP/1 got it right if
CONNECT is meant for all proxies in the chain.

Should a compliant HTTP proxy forward regular end-to-end CONNECT headers
to the next proxy?


Thank you,

Alex.
P.S. I understand that the proxy may decide to send some of the received
CONNECT headers it knows about even if the compliant behavior is "hop by
hop". Such purposeful relaying/replicating does not violate the
hop-by-hop principle, of course. The question is essentially about the
end-to-end CONNECT headers that the proxy does not want to treat specially.

Received on Friday, 19 April 2019 20:20:55 UTC