Re: CONNECT, origins, and Alt-Svc

On Mon, Nov 6, 2023 at 7:42 AM Eric Orth <ericorth@google.com> wrote:

> 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.
>

It's certainly ambiguous for `GET http://example.com/whatever`. (Or rather,
I believe it's unambiguously from the destination, which is not helpful
here.) Is it actually ambiguous for CONNECT? I thought headers in the
CONNECT would always be from the proxy. But I don't actually know for sure.


> 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.
>