Re: CONNECT, origins, and Alt-Svc

On Mon, Nov 6, 2023 at 6:05 AM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> Howdy HTTP enthusiasts,
>
> As we're adding support for CONNECT-UDP in Chrome, we're having to answer
> the related question "ok I know which proxy I want to use, but do I use TCP
> or QUIC?".
>
> Right now, the only mechanisms we have to discover HTTP/3 support are
> Alt-Svc and the HTTPS RR. Both of these are defined in terms of origin*.
> CONNECT-UDP is defined in terms of origin so we're in good shape there.
> Same story for connect-tcp
> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-connect-tcp/>. But
> for CONNECT we're in a weird spot. In CONNECT, there is no origin (or if
> there is, it applies to the target destination, not to the proxy). So it
> doesn't quite feel right for a proxy to send the Alt-Svc header on the
> response to a CONNECT request. Similarly, I'm not sure that if I get an
> HTTPS RR for the proxy hostname I'm allowed to use it for CONNECT. So
> there's no great way to know that a CONNECT proxy supports HTTP/3. So if a
> PAC file tells the browser to use "HTTPS proxy.example.org:443" then it's
> not clear to me how the browser should figure out if it can use HTTP/3.
> Here are some options:
>
> 1) Send the first CONNECT over HTTP/1 or 2, pretend that use of Alt-Svc
> applies to the proxy
>

Alt-Svc is a bit awkward because it can be ambiguous whether such a header
would apply to the proxy or the destination.


> 2) Query the HTTPS DNS RR and pretend that it applies to the proxy
>

I don't understand the issues with this or why any "pretending" is
required.  The proxy server has a scheme, host, and port.  A PAC config
arguably doesn't contain a full origin because it doesn't contain a scheme,
but since we then go and open an http or https connection to the server, I
would argue that we've simply inferred the scheme.  We can open https://
connections to that proxy, and I assume that gets authenticated using the
proxy server origin (somebody correct me if I'm wrong and something funky
is happening there).  All the DNS queries before sending a CONNECT request
are pretty unambiguously querying information about the proxy server, not
the destination.


> 3) Send an OPTIONS * request to the proxy and look for Alt-Svc
> 4) Try HTTP/3 for the first CONNECT request and fallback to TCP if
> anything fails (happy eyeballs style)
> 5) Create a new PAC script verb that means connect-tcp/connect-udp
> 6) Create a new PAC script verb that means HTTP/3
>
> None of these feel like great solutions. Does anyone have thoughts?
> David
>
>
> *well sort of. The HTTPS RR query doesn't include the port...
>

I don't understand what you mean.  HTTPS queries prepend the port when
non-default, so no, HTTPS queries include the port.