- 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>
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