W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

WebSocket API: close and error events

From: Tobias Oberstein <tobias.oberstein@tavendo.de>
Date: Mon, 24 Oct 2011 10:17:32 -0700
To: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <634914A010D0B943A035D226786325D42D0B036F51@EXVMBX020-12.exch020.serverdata.net>
I have two questions related to WebSocket API and close/error handling.

Sorry for the long post .. need to give context for the questions first.

==

The WebSocket protocol draft (Hybi-17)

http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17

defines a close code 1006

" 1006 is a reserved value and MUST NOT be set as a status code in a
Close control frame by an endpoint.  It is designated for use in
applications expecting a status code to indicate that the
connection was closed abnormally, e.g. without sending or
receiving a Close control frame."

Both Chrome (16.0.912.10 canary) and Firefox (10.0a1 (2011-10-24))
fire the onclose() event handler on the websocket object with code 1006
when the TCP connection to the target host of the WS cannot even be
established (host unreachable).

Firefox fires the onclose() event handler with 1006 also for WSS when
the server certificate is invalid.

Chrome currently does not check WSS server cert (unrelated beh./bug).

The WebSocket API document http://dev.w3.org/html5/websockets/ says

"
When the WebSocket connection is closed, possibly cleanly, the user agent must queue a task to run the following substeps:

    1. Change the readyState attribute's value to CLOSED (3).

    2. If the user agent was required to fail the websocket connection or the WebSocket connection is closed with prejudice, fire a simple event named error at the WebSocket object. [WSP]

    3. Create an event that uses the CloseEvent interface, with the event name close, which does not bubble, is not cancelable, has no default action, whose wasClean attribute is initialized to true if the connection closed cleanly and false otherwise, whose code attribute is initialized to the WebSocket connection close code, and whose reason attribute is initialized to the WebSocket connection close reason decoded as UTF-8, with error handling, and dispatch the event at the WebSocket object.
"

===

Q1:
Is executing step 2 above (fire "error") meant to cancel execution of step 3 (fire "close")?

Q2:
Specifically, which events should be fired when WS(S) connection establishment fails due to:

a) host unreachable (TCP could not even be established)
b) TLS handshake failed (thus TCP was there, but no TLS handshake, and thus no WS handshake also)
c) TLS handshake failed due to invalid server certificate
d) TLS handshake failed for other reasons (invalid client cert, non-acceptable ciphers, ..)

Practically, I am mostly interested in:

How can I detect "TLS failed due to invalid server cert" from JavaScript in the context of WSS.

===

I was on the Hybi list with similar questions, since I thought there might be a need for specific close codes for TLS failures, but was sent here.

Here is the thread:

http://www.ietf.org/mail-archive/web/hybi/current/msg09261.html

http://www.ietf.org/mail-archive/web/hybi/current/msg09286.html

and then:

http://www.ietf.org/mail-archive/web/hybi/current/msg09291.html

Am I on the right list here? ;)
Received on Monday, 24 October 2011 21:10:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT