W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

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

From: Simon Pieters <simonp@opera.com>
Date: Mon, 21 May 2012 12:37:53 +0200
To: public-webapps@w3.org, "Jason Duell" <jduell.mcbugs@gmail.com>
Message-ID: <op.wenmhfzhidj3kv@simons-macbook-pro.local>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC