Re: Is CONNECT hop-by-hop?

On 4/19/19 4:06 PM, Lucas Pardue wrote:

> I think that the "open a TCP connection" view is the most accurate thing
> here. And so the final hop, from last proxy to origin will never have a
> way to express such "end-to-end" headers.

CONNECT ends at proxies, so, in this context, "end-to-end" (*if* it is
going to be confirmed as the right model) would mean
client-to-the-last-proxy, not client-to-origin. The second "end" is the
last proxy in the chain here, not the origin server. Thus, "end-to-end"
semantics can be considered valid/applicable.


> Proxies, in the role of
> client, that are configured to use a proxy would use their own user
> agent and authentication. 

Please note that HTTP authentication is a red herring in this context --
Proxy-Authenticate is already documented as a hop-by-hop mechanism.
Nothing we discuss here will change that.


> I'd considered the chaining case in HTTP/2 but just taken for granted
> that a proxy that has it's own *HTTP proxy* configured would attempt to
> use it when opening TCP connections to the indicated authority.

AFAICT, HTTP/2 specs prohibit such use (possibly accidentally). I agree
that such prohibition seems unnatural -- most people would probably
"take for granted" that chained tunnels are allowed and should be supported.


> Note that HTTP/3 also defines CONNECT to behave like RFC 7540.

Yes, both HTTP/2 and HTTP/3 give "undefined behavior" answers.


> This
> raises some challenges for tunnelling HTTP/3, which is one of the
> driving use cases in the HiNT I-D [1].
> [1] https://datatracker.ietf.org/doc/draft-pardue-httpbis-http-network-tunnelling/

Hopefully, if there is consensus regarding CONNECT forwarding on this
mailing list, then draft-ietf-httpbis-semantics, HTTP/3 [errata], and
your draft can express it.

Alex.

Received on Friday, 19 April 2019 23:43:06 UTC