Re: Proposal: add websocket close codes for "server not found" and/or "too many websockets open"

> On Mon, 21 May 2012 12:28:16 +0200, Simon Pieters <simonp@opera.com> wrote:
>
>>   4.  If the connection could not be opened, either because a direct
>>       connection failed or because any proxy used returned an error,
>>       then the client MUST _Fail the WebSocket Connection_ and abort
>>       the connection attempt.
>>
>>  I'm also wondering if it would be useful to have a dedicated
>> error code for this case ("server not available').
>
> I believe it would be a security problem to expose to scripts detailed
> reasons about how it failed to connect.

Could you say more about why a simple "connection not available" would
be a security problem, Simon?  We already have a code for the special
case of TLS handshake failing: a code that encompasses every other
reason why the connection wasn't made doesn't seem obviously risky to
me (but I'm no security expert)..

>> Also:  I expect every browser that implements web sockets will have
>> some limit on the number of websockets it allows to be open at once
>> (to prevent DoS attacks if nothing else).
>
>
> The spec has a simple measure against DoS -- only allowing one socket in
> the connecting state at a time per host (or some such). But there can be
> platform-specific limitations.

True, but this doesn't protect against running out of file descriptors
for sockets, etc.  So while it's not an easy DoS vector, it's still a
possible scenario.  For now, Firefox is calling onerror and onclose
with 1011 in this case ("internal error", though it's a loose
application of the code, since its intended to be sent by the remote
endpoint rather than used for internal errors in the client).  I could
probably be persuaded to throw an exception instead--in fact, I'm
almost convincing myself of it as I type :)    (We made the decision
not to queue the connection, because WS's are long-lived and there's
thus no obvious wait time bounds).

Thanks for the feedback.

Jason Duell
Mozilla

Received on Wednesday, 23 May 2012 04:22:30 UTC