- From: Ryan Sleevi <notifications@github.com>
- Date: Wed, 26 May 2021 10:03:28 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/1243/848949742@github.com>
CC’ing @letitz because the DNS discussion is also related to https://github.com/WICG/private-network-access/issues/51 My hope in avoiding is largely a proximity of the complexity it introduces, and because of the handwave “magic happens here” part of the composability of different protocol layers. * How to account for Happy Eyeballs behaviours (which vary across implementations, and may extend to racing connections and not just racing resolutions) * How to account for the different resolution layers and behaviours (DNS vs WINS/NETBIOS vs mDNS, etc) * How to account for other protocol races (e.g. for alternate protocols returned via DNS) I do think you’re right that we need some aspect of handwave to “turn this host into a collection of IP addresses”, which can then be accounted for in things like WebSockets or private network access, but specifying it in a way in which these differences continue to remain valid/opaque alternatives, and not accidentally specifying a linear sequence that MUST be followed, is the tricky part. That said, I think your proposed approach generally sounds workable. One bit of challenge for Chromium is that we don’t (generally) think of dedicatedness as an explicit input parameter. In general, we want a new connection, either with a particular protocol version (e.g. if an H/2 server wants to use TLS Client cert auth or NTLM/Negotiate and responds with HTTP_1_1_REQUIRED, or situations like WebSockets where H/2 may not be allowed widely), or explicitly reusing the current connection (e.g. completing the third leg of an NTLM/Negotiate handshake). While in the current proposal, I think the existing implementation would conform with your rough proposed language, I worry if there might end up being impedance mismatches if that parameter gets reused elsewhere. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/1243#issuecomment-848949742
Received on Wednesday, 26 May 2021 17:03:41 UTC