Re: CONNECT, origins, and Alt-Svc

Good enough as far as the h2 vs h3 connecting goes.  It's just a simple
application of all the upgrade specs we already have with nothing new going
on.

The one thing I can think that could possibly need a spec here would be a
clarification RFC that "yes, http proxies (CONNECT(-*)) have schemes and
origins".  But even better would be if somebody can point to something that
already makes that clear.

On Tue, Nov 7, 2023 at 8:57 AM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> Thanks everyone for the responses. Based on all this, I think that it's
> reasonable for us to pretend that CONNECT requests over HTTP/2 or HTTP/3
> have an implicit scheme of "https". With that, a straightforward strategy
> for connecting to proxy.example:1234 would be:
> * if my browser has HTTPS DNS RRs enabled, query the HTTPS RR for
> _1234._https.proxy.example. and use any Alt-Svc therein
> * otherwise, send the first CONNECT request over TLS/TCP and treat any
> received Alt-Svc as applying to the proxy
>
> Are we declaring this good enough or do we need to write this down in a
> spec?
> David
>
>
>
> On Tue, Nov 7, 2023 at 4:22 AM Mark Nottingham <mnot@mnot.net> wrote:
>
>>
>>
>> > On 6 Nov 2023, at 1:57 pm, Eric Orth <ericorth@google.com> wrote:
>> >
>> > Hmm.  I just double checked RFC9110#9.3.6.  I had thought the
>> switch-to-destination happened immediately after the status 200, but I had
>> remembered wrong.  The switch is "immediately after the response header
>> section".  So you're right. Headers are unambiguously from the proxy server.
>>
>> Correct. We could have been a bit more precise about this, but it's
>> unambiguous that the response headers are _not_ from the target.
>>
>> Cheers,
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>