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:

> On Wed, 16 May 2012 02:17:45 +0200, Jason Duell  
> <jduell.mcbugs@gmail.com> wrote:
>
>> So the Web Socket spec is a little vague on how JS is notified when
>> the targeted web socket server is down/nonexistent/etc.
>>
>> Firefox is firing an 'error' event when this happens, based on the
>> language here in the W3C spec:
>>
>>   "if the status code received from the server is not 101 (e.g. it is
>> a redirect), the user agent must fail the websocket connection"
>>
>> Chrome is not calling onerror for this, so we have a difference here.
>>  The language in the spec isn't really clear if this covers the
>> connection-never-happened case.
>>
>> Both Chrome and Firefox (haven't tested other browsers/clients) are
>> then calling close with code=1006, which seems the best code available
>> in RFC 6455, but the language there isn't great either:
>>
>>    "to indicate that the connection was closed abnormally, e.g.,
>> without sending or receiving a Close control frame."
>>
>> There's essentially no mention in either spec of what happens when
>> there never was any connection to the server..

    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.

_Establish a WebSocket Connection_ in rfc6455


>> It would be useful to be clear about whether onerror should be called
>> here.   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.
>
>
>> 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.
>
>
>>   I'm not sure of what the
>> right close code for this is.  Ideas?  Perhaps we could also use a
>> dedicated code for this case too.
>
> Or throw an exception? Or queue the connection? I've touched on this  
> subject before, but we didn't reach any conclusion as to what the right  
> thing to do is.
>
>
>> Jason Duell
>> Mozilla
>>
>
>


-- 
Simon Pieters
Opera Software

Received on Monday, 21 May 2012 10:38:37 UTC