Re: Is CONNECT hop-by-hop?

On 20/04/2019 14:51, Amos Jeffries wrote:
> On 20/04/19 8:20 am, Alex Rousskov wrote:
>> 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)?
>>
> ...
>>
>> Should a compliant HTTP proxy forward regular end-to-end CONNECT headers
>> to the next proxy?
>>
> 
> I think this is incorrectly mixing two independent principles here.
> 
> The method hop-by-hop (or not) refers to the HTTP-message. Which can be
> just the request-line or status-line values. That is the minimal
> HTTP-message per RFC7230 section 3.
> 
> 
> RFC 7230 section 3.2.1 is what you/we need to be using as the definitive
> default forward/remove guidance on "regular" headers. Except where the
> headers own more-specific definition overrides that with a requirement
> about forwarding or removal.
> 
> This section 3.2.1 requirements do not rely on the hop-by-hop (or not)
> nature of CONNECT, but on whether there is any next-hop HTTP-message to
> relay the relevant end-to-end headers on.
> 
> 
> So IMO the issue is not whether CONNECT is hop-by-hop, but whether the
> intermediary is mapping the CONNECT to TCP directly or to another
> HTTP-message. If it is to another HTTP-message (eg CONNECT to a peer)
> the end-to-end headers still apply to that (non-)payload sent to the
> next-hop, the hop-by-hop headers do not.

Reading from the perspective of "how does RFC8441 'CONNECT upgrade'" fit 
into this, that sounds right.

When using CONNECT to upgrade an h2 stream to another protocol, it's 
definitely not hop-by-hop since it's informing the endpoint, and anyone 
inbetween that might care, that it wants to change the stream protocol 
in an arbitrary way... an intermediary cannot eat and conceal from 
downstream nodes say a change from http to ws, they are too different.

What Willy says sounds right too... downstream intermediaries may not 
participate in the same auth scheme as the proxy the peer initially 
connects to.

Is it enough to say that CONNECT is end-to-end except if an intermediary 
assertively recognizes hop-to-hop related headers aimed at itself it 
should snip?

-Andy

> Amos
>

Received on Saturday, 20 April 2019 07:07:02 UTC