Re: [whatwg/fetch] Editorial: make WebSocket use obtain a connection (#1241)

@ricea commented on this pull request.



> @@ -7425,32 +7417,6 @@ fetch("https://www.example.com/")
 </div>
 
 
-<h3 id=websocket-connections>Connections</h3>
-
-<p>To <dfn id=concept-websocket-connection-obtain>obtain a WebSocket connection</dfn>, given a
-<var>url</var>, run these steps:
-
-<ol>
- <li><p>Let <var ignore>host</var> be <var>url</var>'s <a for=url>host</a>.
-
- <li><p>Let <var ignore>port</var> be <var>url</var>'s <a for=url>port</a>.
-
- <li><p>Let <var ignore>secure</var> be false, if <var>url</var>'s <a for=url>scheme</a> is
- "<code>http</code>", and true otherwise.
-
- <li><p>Follow the requirements stated in step 2 to 5, inclusive, of the first set of steps in
- <a href=http://tools.ietf.org/html/rfc6455#section-4.1>section 4.1</a> of The WebSocket Protocol

I think the only choice is to make it work per-partition. That's unfortunate if an attacker can manage to use many partitions at the same time, but I think we generally assume that is unlikely.

Moving the logic here rather than delegating to the RFC would let us make that unambiguous.

How it essentially works is you have a per-_ip:port_ queue, where only the WebSocket at the front of the queue is permitted to be in a connecting/handshake state. WebSockets are removed from the queue when the handshake succeeds, fails, or is cancelled.

What's troublesome is that you need to do a DNS lookup to work out which queue a WebSocket belongs in. And if there are multiple IP addresses you might need to try multiple queues before you find one that connects.

Dealing with proxies is awful and Chromium does it completely wrong.

Now that I say all this I think there's definite value is specifying this in the Fetch standard (or in the WebSocket standard, whichever comes first).

-- 
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/pull/1241#discussion_r639768467