Re: CONNECT, origins, and Alt-Svc

First, I really hope we don’t end up adding more PAC script verbs here…

I think the document we have proposed in INTAREA https://www.ietf.org/archive/id/draft-pauly-intarea-proxy-config-pvd-01.html (and discussed in MASQUE) could be helpful here. The point here is to have a way to, given a known proxy name (which could come from PAC or a manual UI) to learn from the proxy what other protocols it supports. So, you can interrogate a CONNECT proxy to see if it does connect-udp or connect-tcp.

So, what I’d personally suggest is:

- Get configured with a proxy name (from UI or PAC)
- Do a query to that proxy to discover if it supports “modern” templatized protocols
- If it supports connect-udp or connect-tcp (or similar), then race between HTTP/3 and HTTP/2

Or we could alternatively add something to the proxy config that explicitly says something about the protocols…

Tommy

> On Nov 6, 2023, at 12:03 PM, 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 <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...