[hybi] Error handling in hybi-03 framing

Yuta Kitamura <yutak@google.com> Mon, 13 December 2010 09:13 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; b=E8ah/ijT23OJcjr2wILzpNyp2jdICboZ+yR6fSQ6MbHSUrB0zU/U8CyAleQkxWphc0 s+dvzxAHfzMROlXivEHw==
MIME-Version: 1.0
Date: Mon, 13 Dec 2010 18:14:35 +0900
Message-ID: <AANLkTimNZiHp0VA09eFfx64LYNh1uy86bd2XUwic9fH=@mail.gmail.com>
From: Yuta Kitamura <yutak@google.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary="00163630fd77f869f804974721a9"
Subject: [hybi] Error handling in hybi-03 framing
Precedence: list

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

[hybi] Error handling in hybi-03 framing Yuta Kitamura
Re: [hybi] Error handling in hybi-03 framing Simon Pieters
Re: [hybi] Error handling in hybi-03 framing Greg Wilkins