Re: CONNECT, origins, and Alt-Svc

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/
>
>