13180 2011-07-07 21:41:12 +0000 [Editorial] Causes that lead to failing the WebSocket connection, which results in an error event, should be more clearly specified 2011-08-06 00:47:49 +0000 1 1 1 Unclassified WebAppsWG WebSocket API (editor: Ian Hickson) unspecified All All RESOLVED WONTFIX P2 normal --- 1 adrianba ian art.barstow brian.raymor ian mike public-webapps public-webapps-bugzilla oldest_to_newest 50798 0 adrianba 2011-07-07 21:41:12 +0000 The reasons for failing the WebSocket connection are spread throughout the spec. It would be helpful to implementers to gather these together in a section that describes the error event. There are a limited number of cases where this occurs based on my reading: * There is a failure to establish a websocket connection * The connection is closed before it is opened * The WebSocket is “disappeared” before it is opened 51253 1 brian.raymor 2011-07-19 04:55:30 +0000 Are there additional "Fail the WebSocket Connection" cases from the protocol specification that should surface in an error event? The current client-related list includes: 4.2. Base Framing Protocol RSV1, RSV2, RSV3: 1 bit each MUST be 0 unless an extension is negotiated which defines meanings for non-zero values. If a nonzero value is received and none of the negotiated extensions defines the meaning of such a nonzero value, the receiving endpoint MUST _Fail the WebSocket Connection_. Opcode: 4 bits Defines the interpretation of the payload data. If an unknown opcode is received, the receiving endpoint MUST _Fail the WebSocket Connection_. 5.1. Client Requirements 1. The components of the WebSocket URI passed into this algorithm (/host/, /port/, /resource name/ and /secure/ flag) MUST be valid according to the specification of WebSocket URIs specified in Section 3. If any of the components are invalid, the client MUST _Fail the WebSocket Connection_ and abort these steps. 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. 5. If /secure/ is true, the client MUST perform a TLS handshake over the connection after opening the connection and before sending the handshake data [RFC2818]. If this fails (e.g. the server's certificate could not be verified), then the client MUST _Fail the WebSocket Connection_ and abort the connection. Server Responses: 2. If the response lacks an "Upgrade" header or the "Upgrade" header contains a value that is not an ASCII case-insensitive match for the value "websocket", the client MUST _Fail the WebSocket Connection _. 3. If the response lacks a "Connection" header or the "Connection" header contains a value that is not an ASCII case-insensitive match for the value "Upgrade", the client MUST _Fail the WebSocket Connection_. 4. If the response lacks a "Sec-WebSocket-Accept" header or the "Sec-WebSocket-Accept" contains a value other than the base64- encoded SHA-1 of the concatenation of the "Sec-WebSocket-Key" (as a string, not base64-decoded) with the string "258EAFA5-E914- 47DA-95CA-C5AB0DC85B11", but ignoring any leading and trailing whitespace, the client MUST _Fail the WebSocket Connection_ 5. If the response includes a "Sec-WebSocket-Extensions" header, and this header indicates the use of an extension that was not present in the client' handshake (the server has indicated an extension not requested by the client), the client MUST _Fail the WebSocket Connection_. (The parsing of this header to determine which extensions are requested is discussed in Section 9.1.) If the server's response does not conform to the requirements for the server's handshake as defined in this section and in Section 5.2.2, the client MUST _Fail the WebSocket Connection_. 7.2.1. Client-Initiated Closure Certain algorithms, namely during the opening handshake, require the client to _Fail the WebSocket Connection_. To do so, the client MUST _Fail the WebSocket Connection_ as defined in Section 7.1.7. If at any point the underlying transport layer connection is unexpectedly lost, the client MUST _Fail the WebSocket Connection_. Except as indicated above or as specified by the application layer (e.g. a script using the WebSocket API), clients SHOULD NOT close the connection. 8.1. Handling Errors in UTF-8 Encoded Data When an endpoint is to interpret a byte stream as UTF-8 but finds that the byte stream is not in fact a valid UTF-8 stream, that endpoint MUST _Fail the WebSocket Connection_. 9.1. Negotiating Extensions A client requests extensions by including a "Sec-WebSocket- Extensions" header, which follows the normal rules for HTTP headers (see [RFC2616] section 4.2) and the value of the header is defined by the following ABNF. Note that unlike other section of the document this section is using ABNF syntax/rules from [RFC2616]. If a value is received by either the client or the server during negotiation that does not conform to the ABNF below, the recipient of such malformed data MUST immediately _Fail the WebSocket Connection_. 54253 2 ian 2011-08-05 15:44:33 +0000 Assuming you mean the references to "fail the WebSocket connection", all those references are of things that happen on the protocol side, I believe. I don't really know how we could do anything in the API spec here. I recommend bringing this up with the hybi group. 54279 3 brian.raymor 2011-08-06 00:47:49 +0000 We're basically requesting minor editorial changes to help clarify the set of errors and how they're handled: 1. It would be helpful to organize the current set of "fail the websocket connection" (error) cases into one section for easier reference. Currently, the cases are scattered through the text. 2. Be more specific about whether these cases trigger onError since "fail the websocket connection" in the protocol draft indicates that onError behavior is a MAY: Certain algorithms and specifications require an endpoint to _Fail the WebSocket Connection_. To do so, the client MUST _Close the WebSocket Connection_, and MAY report the problem to the user (which would be especially useful for developers) in an appropriate manner. 3. What is the behavior for the other "fail the websocket connection cases related to the client in the protocol draft? For example, if a client receives an invalid UTF-8 byte stream and "fails the websocket connection" as required, does this also trigger onError?