- From: Tommy Pauly <tpauly@apple.com>
- Date: Tue, 13 Feb 2024 19:48:45 -0800
- To: Ben Schwartz <bemasc@meta.com>
- Cc: David Schinazi <dschinazi.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-id: <0489428B-16E4-42AF-8224-9054122DD41A@apple.com>
> On Jan 26, 2024, at 11:19 AM, Ben Schwartz <bemasc@meta.com> wrote: > > David and I talked through those issues. I believe we have resolved most of them, but there are two that could use some more input. They are both related to details of the URI Template configuration string, not the protocol itself. > > "target_port" or "tcp_port": https://github.com/httpwg/http-extensions/pull/2720 > > "connect-udp" uses the URI Template variable "target_port" to specify the destination's UDP port number. In the current draft, "connect_tcp" uses the name "tcp_port" instead. This makes UDP, TCP, and UDP+TCP templates distinguishable by inspection (assuming that servers don't include extraneous variables for protocols they don't actually support). Is this useful? Or should we just use "target_port" in both cases, to reduce divergence? (No hats) 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. > > 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. Thanks, Tommy > > Thanks, > Ben Schwartz > From: David Schinazi <dschinazi.ietf@gmail.com <mailto:dschinazi.ietf@gmail.com>> > Sent: Wednesday, January 24, 2024 8:17 PM > To: Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>> > Cc: HTTP Working Group <ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>> > Subject: Re: WGLC for draft-ietf-httpbis-connect-tcp > > This Message Is From an External Sender > Hi, > > I just read through the draft. From my perspective, this document is not yet ready to proceed. I've opened 5 GitHub issues with specific concerns. > > Additionally, what is the implementation status of this draft? I haven't seen anyone mention on the list that they'd implemented this or achieved interop. > > David > > On Tue, Jan 23, 2024 at 9:40 AM Tommy Pauly <tpauly@apple.com <mailto:tpauly@apple.com>> wrote: > Hello HTTP! > > This email starts a working group last call for "Template-Driven HTTP CONNECT Proxying for TCP”, draft-ietf-httpbis-connect-tcp. > > The document can be found here: > https://www.ietf.org/archive/id/draft-ietf-httpbis-connect-tcp-02.html > https://datatracker.ietf.org/doc/draft-ietf-httpbis-connect-tcp/ > > This last call will last for 3 weeks, and end on Tuesday, February 13. Please respond to this email with your reviews and comments, and indicate if you think this document is ready to move along towards publication. > > Please file any issues you find here: https://github.com/httpwg/http-extensions/issues?q=label%3Aconnect-tcp > > Thanks, > Tommy
Received on Wednesday, 14 February 2024 03:49:11 UTC