Re: WGLC for draft-ietf-httpbis-connect-tcp

[David Schinazi <[e-mail]>]

Hi Ben, thanks for the PR - it looks good to me.

Regarding your point about client implementers, can you share more about
them? Who's implemented this so far? Who's depending on the address list
feature?

Thanks,
David

On Wed, Feb 14, 2024 at 1:59 PM Ben Schwartz <[e-mail]> wrote:

>
> On Feb 13, 2024, at 10:48 PM, Tommy Pauly <[e-mail]> wrote:
>
> On Jan 26, 2024, at 11:19 AM, Ben Schwartz <[e-mail]> wrote:
>
> ...
>
>
>    1. "target_port" or "tcp_port":
>    https://github.com/httpwg/http-extensions/pull/2720
>
>
> …
>
> As I’ve mentioned just now on the issue, the direction for configuration
> might be to be more explicit on the supported protocol, so that we don’t
> try to infer the protocol from the template. Based on that, I’d lean right
> now towards just having a target_port, instead of tcp_port.
>
>
> OK it sounds like the consensus favors this change, so I’ve opened
> https://github.com/httpwg/http-extensions/pull/2736.
>
>
>
>    1. Support for "target_host=192.0.2.1&target_host=2001:db8::1":
>    https://github.com/httpwg/http-extensions/pull/2719
>
>    To improve Happy Eyeballs and related behaviors, "connect-tcp" allows
>    the client to provide a list of IP addresses.  URI Templates have a
>    built-in notion of lists.  In URI Template Level 3 and below, list elements
>    are always joined by commas ("192.0.2.1,2001:db8::1").  However, in Level
>    4, templates can use the "explode modifier" to generate repeated key=value
>    assignments (as above), which are more idiomatic in some web frameworks.
>    Should we require clients to support Level 4 templates, or restrict proxies
>    to publishing Level 3 templates?
>
>
> In what I’ve seen, it’s usually best to have happy eyeballs be done by the
> proxy based on the DNS resolution the proxy itself has performed, not
> necessarily the addresses provided by the client. Before we make this too
> complex, I'd like to hear about who would exercise this capability.
>
>
> I agree that this is best practice.  (It’s even documented at
> https://datatracker.ietf.org/doc/html/rfc9460#section-3.2-2.)  However,
> I’ve heard a number of arguments from client implementors who felt that the
> client should be able to use its own DNS resolver, independent of the
> proxy, in which case this functionality seems valuable for Happy Eyeballs
> to work as intended.
>
> In the above pull request, I’ve simplified the syntax for this (reducing
> the URI Template requirement to Level 3) to minimize the burden on clients
> that don’t use the feature.
>
> —Ben
>