- From: Ben Schwartz <bemasc@meta.com>
- Date: Thu, 15 Feb 2024 21:01:13 +0000
- To: David Schinazi <dschinazi.ietf@gmail.com>
- CC: Tommy Pauly <tpauly@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
> On Feb 15, 2024, at 2:34 PM, David Schinazi <dschinazi.ietf@gmail.com> wrote: > > 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? I’m referring to prior conversations where some people seemed to prefer leaving DNS resolution entirely in the client’s hands, e.g. [1]. In most cases, I think target_host should simply be a hostname. However, I do think there are some cases where passing an IP address is appropriate, and in those cases passing a list of N IPs is much more efficient than sending N requests with one IP each: * When the client feels that it is necessary to enforce DNSSEC validation of the A/AAAA responses. (This is an unusual threat model, but it is supported by platforms like iOS [2]). * When the client attempts to reduce connection setup latency by using an HTTPS record’s ipv4hint and ipv6hint SvcParams. * When the IP addresses were not delivered through DNS at all (e.g., ICE TCP in SDP [3]) —Ben [1] https://datatracker.ietf.org/doc/chatlog-115-masque-202211090930/#:~:text=In%20general%2C%20it%27s%20better%20for%20the%20proxy%20to%20do%20the%20final%20name%2D%3EIP%20resolution%2C%20whereas%20it%27s%20better%20for%20the%20client%20to%20do%20the%20HTTPS/SVCB%20lookup. [2] https://developer.apple.com/documentation/network/nwparameters/3952717-requiresdnssecvalidation [3] https://datatracker.ietf.org/doc/html/rfc6544#appendix-C > > Thanks, > David > > On Wed, Feb 14, 2024 at 1:59 PM Ben Schwartz <bemasc@meta.com> wrote: > >> On Feb 13, 2024, at 10:48 PM, Tommy Pauly <tpauly@apple.com> wrote: >> >>> On Jan 26, 2024, at 11:19 AM, Ben Schwartz <bemasc@meta.com> wrote: > ... >>> • "target_port" or "tcp_port": > >>> >>> • Support for "target_host=192.0.2.1&target_host=2001:db8::1": 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
Received on Thursday, 15 February 2024 21:01:25 UTC