Re: CONNECT, origins, and Alt-Svc

HTTPS RRs do apply to HTTP CONNECT proxy connections.  See https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-12.html#section-9.6-2

HTTPS RR queries do include a port number (but it's omitted if the port number is 443).

So I would definitely recommend your Option 2.  Of course, that doesn't preclude the other options.

--Ben Schwartz
________________________________
From: David Schinazi <dschinazi.ietf@gmail.com>
Sent: Monday, November 6, 2023 6:03 AM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: 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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
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<http://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...