Subject: [hybi] Error handling in hybi-03 framing

From: Yuta Kitamura <[email-masked]>
Date: Mon, 13 Dec 2010 18:14:35 +0900

Hi,

We are now implementing the new WebSocket framing into WebKit. During that
effort, we have found that the new framing specification lacks statements
describing how to handle erroneous frames.

Specifically, for client-side, I think we have to describe what a client
MAY/SHOULD/MUST do in the following events (as far as I can imagine):
- When a client receives a frame whose opcode is reserved (0x6 - 0xF).
- When a client receives a frame whose opcode is not supported (for example,
if the client does not support binary frames, maybe due to lack of WebSocket
API)
- When a client receives a frame with some reserved bits (rsv[1234]) on.
- When a client receives a non-continuation frame (including a control
frame) in the middle of continuation frames.
- When a client receives a long (>125 bytes) or fragmented control frame.
- When a client receives an unexpected pong frame.
- When a client cannot receive a frame because its payload is too long.
- When a client detects disconnection before it receives/sends a close
frame.
- (When a client cannot decode UTF-8 sequence of a text frame -> this is
already covered in section 6 (Error Handling))

The possible options for a client will look like the following:
- The client MAY/SHOULD/MUST abort the connection/ignore the error.
AND/OR
- The client MUST fire the onerror handler (a.k.a. "a WebSocket error is
detected").

Defining criteria for the latter is especially important in order to keep
inter-browser compatibility.

Of course, criteria for servers will also be needed, but I would like to
leave them to server implementors, as I do not have a good sense about
servers.

So, I would like to ask if it does make sense to define there error handling
behaviors. If an agreement is reached, then we will need to create a full
list of error conditions and error handling behaviors for clients and
servers.

Regards,
Yuta

---

From: "Simon Pieters" <[email-masked]>
Date: Mon, 13 Dec 2010 10:26:02 +0100

> list of error conditions and error handling behaviors for clients and

I agree that error handling must be defined, at least for clients.

However, rather than whack-a-mole listing all error conditions we can come  
up with, I prefer the -00 style state machine algorithm which makes it  
easy to reason that all possible cases are defined, and also makes it more  
well-defined that just a list of conditions (e.g. what if several  
conditions match?).

-- 
Simon Pieters
Opera Software

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 13 Dec 2010 10:59:01 +0100

I agree with Simon,

rather than identify every possible error condition, we would be
better off identifying our error handling possibilities and defining
general rules for when they should apply.

The options that we have for handling errors include:

 + ignore the frame
 + drop the frame and send a control frame indicating why (such frames
are not currently defined)
 + graceful shutdown of connection with error code sent
 + close connection without error code sent

I think ignoring a frame is a reasonable action for frames that cannot
be handled due to undefined codes, extensions etc..  They should not
be sent unless they have been negotiated, but I see no great need to
shutdown a connection or send an error if they are.

I think sending error control frames is very important for non framing
errors on operations that are likely to be repeated.  For example, if
a frame is too large to be handled, then silently dropping it or
closing the connection may just result in the other end resending.

Graceful shutdown with error code should be sent for all protocol
errors that do not violate basic framing. For example a fragmented
control frame indicates a non compliant participant, but basic framing
is still operational, thus a graceful shutdown can be sent.

Close the connection should be the catch all handling if one of the
other error cases does not apply.

cheers

On 13 December 2010 10:26, Simon Pieters <[email-masked]> wrote:
> up with, I prefer the -00 style state machine algorithm which makes it easy
> to reason that all possible cases are defined, and also makes it more
> well-defined that just a list of conditions (e.g. what if several conditions
> match?).
>
> --
> Simon Pieters
> Opera Software
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>