Re: [whatwg/fetch] Refactoring WebSocket connections (#1243)

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