Re: Proposal: add websocket close codes for server not found and/or too many websockets open
On 05/28/2012 04:03 AM, Takeshi Yoshino wrote: The protocol spec has defined 1015, but I think we should not pass through it to the WebSocket API. http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0437.html I think 1006 is the right code for all of WebSocket handshake failure, TLS failure and TCP connection failure. If the language in http://tools.ietf.org/html/rfc6455#section-7.4.1 is not good, we can add cannot be opened or before closed abnormally for clarification. I could certainly live with this. It would be nice to have it clarified in the W3C websocket spec that we won't be delivering 1015 (I assume it's too late to take it out of RFC 6455).And to have the additional language you suggest for 1006 (connection could not be opened or something like that) added somewhere (again I assume RFC 6455 isn't possible, but the IANA database and/or the W3C spec). best, Jason Mozilla
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 sim...@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
Proposal: add websocket close codes for server not found and/or too many websockets open
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.. 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'). 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). 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. Jason Duell Mozilla
Proposal: add websocket close codes for server not found and/or too many websockets open
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.. 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'). 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). 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. Jason Duell Mozilla
