Re: CONNECT, origins, and Alt-Svc

[David Benjamin <[e-mail]>]

On Mon, Nov 6, 2023 at 6:05 AM David Schinazi <[e-mail]>
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
> 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?
>

(1) and (2) seem the most natural to me. It is a little weird that CONNECT
doesn't actually send a Host header for the proxy... it'd put us in a weird
place where the client is conceptually thinking of an origin, but doesn't
tell the server, so the server can't react accordingly. But I don't think
that's broken per se, just weird and a little limiting. I suppose we could
define a Proxy-Host (Sec-Proxy-Host?) header, or transition to connect-tcp,
if we really care.

It's also kind of weird in that (1) would be incompatible with a request
like `GET http://example.com/whatever` <http://example.com/whatever> (is
there a name for this mode?). Though I think this same "there is a proxy
origin, we just forgot to tell the server" theory would work for (2). I
could imagine a Proxy-Alt-Svc header, but I suspect there won't be enough
interest in defining that, so leaving that unsolved seems fine?

(3) seems unnecessarily annoying for clients to wrangle on the client.

(4) and (6) mean we're unable to pick up any SvcParamKeys that might
influence the HTTP/3 connection, which seems poorly aligned with where I
gather people want to go with HTTPS/SVCB.

(5) could also work, but since proxy types are configured outside PAC too,
I suspect it's quite a lot of systems to manually reconfigure before HTTP/3
works. So I think (1) and (2) would still be worthwhile, even if we decide
(5) is a good way to transition to connect-tcp.


> *well sort of. The HTTPS RR query doesn't include the port...
>

Not super important, but I think it does. It's just that HTTPS-RR (as
opposed to SVCB) special cases (https, *, 443) to go through an undecorated
query name.
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-12.html#section-2.3