CONNECT, origins, and Alt-Svc

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
2) Query the HTTPS DNS RR and pretend that it applies to the proxy
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...