Subject: [hybi] Comments on Section 5.1 Req #2 and Sec-WebSocket-Protocol

From: Matthew Cox <[email-masked]>
Date: Tue, 10 May 2011 01:21:02 +0000

Section 5.1 req #2 specifies that no more than one connection can be in CONNECTING state to the same IP address/same host.  I think that this should be removed, or at the very least the language be changed to not require it.  This is an artificial limit to address a JavaScript concern that would be better addressed by the calling application/protocol since a client may not have the same concerns as JavaScript.

Sec-WebSocket-Protocol - Can it be added to the text that the protocols are in preferred order in Section 5.1 like it is in Section 5.2?  Specifically in the requirements for the handshake #10

        If present, this value indicates the subprotocol(s)the client wishes to speak.

Could be changed to

        If present, this value indicates the subprotocol(s)the client wishes to speak ordered by preference.

Thanks,

Matthew

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 11 May 2011 18:17:51 +0200

2011/5/10 Matthew Cox <[email-masked]>:
> Section 5.1 req #2 specifies that no more than one connection can be in
> CONNECTING state to the same IP address/same host.  I think that this should
> be removed, or at the very least the language be changed to not require it.
> This is an artificial limit to address a JavaScript concern that would be
> better addressed by the calling application/protocol since a client may not
> have the same concerns as JavaScript.

I'm agree. Which is the real reason for such artificial requeriment?
If that is the behavior of JavaScript clients in webbrowsers, please,
don't assume all the WebSocket clients are JavaScript.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 12 May 2011 12:10:11 +1000

> don't assume all the WebSocket clients are JavaScript.

It is there to prevent browsers from being used as very simple denial
of service attack generators.

Currently there is no limit on the number of ws connections that a
browser can create, so the potential is still there for an attacker to
create many many websockets to a host, but the idea of only allowing a
single connection outstanding is that will at least slow the attack
down and give the server a chance to reject connections.

I think this is pretty weak protection, as intermediaries will often
mask the source of the connection, so a server cannot tell if it is
one attacker or just a traffic spike from many browsers.

The real solution is to have a MUX extensions that browsers will use
so that a single browser will always only have a single connection per
host.

cheers