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

Here's a sketch for resolve a domain:

> To resolve a domain, given a domain _domain_ and a network partition key _key_, perform an implementation-defined operation to turn _domain_ into a set of one or more IP addresses. If this operation succeeds, return the set of IP addresses. If it fails, return failure. The results of this operation may be cached. If they are cached, _key_ must be used as part of the cache key.
> 
> Note: typically this operation would involve DNS. The particulars (apart from the cache key) are not tied down as they are not pertinent to the system the Fetch Standard establishes. Other documents ought not to build on this primitive without having a considered discussion with the Fetch Standard community first. [DNS]

Picking an IP address from this set to obtain a connection from can be done in an implementation-defined manner. I suppose the WebSocket connection steps would compare each IP address against existing WebSocket connection IP addresses.

@sleevi how does WebSocket obtain a new-or-existing connection in Chromium with that setup then? We have the dedicated parameter for WebTransport. It seems like WebSocket needs it as well, though in a more limited way. I'm not aware of anything else needing it.

@ricea thanks! I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1713748 to track that in Firefox. My proposal is that we use the network partitioning key, but the way Chrome defines that key it would be far less successful at avoiding the DOS concerns this cache was meant to address, I think. Not sure to what extent that's a problem.

-- 
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-852005747