Re: CONNECT, origins, and Alt-Svc

On Mon, Nov 6, 2023 at 7:46 AM David Benjamin <davidben@chromium.org> wrote:

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

Hmm.  I just double checked RFC9110#9.3.6.  I had thought the
switch-to-destination happened immediately after the status 200, but I had
remembered wrong.  The switch is "immediately after the response header
section".  So you're right. Headers are unambiguously from the proxy server.


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