Re: [hybi] Clarify the role of closing handshake

[Brodie Thiesfield <[e-mail]>]

On Fri, Feb 11, 2011 at 10:37 AM, Greg Wilkins <[e-mail]> wrote:
> On 11 February 2011 12:14, Brodie Thiesfield <[e-mail]> wrote:
>> I have been thankful many times for the amount of detail the http error
>> status and message can return to a client. Having both a rich code space as
>> well as a human readable message is invaluable for problem solving a
>> connection problem. This is part of the http protocol, we shouldn't punt
>> error condition reporting to the application level in websockets.
>
> There is indeed a great deal of goodness in 2xx/3xx for normal, 4xx
> for bad client and 5xx for bad server.
> If somebody could propose a similar nice error space for WS that would
> get broad agreement, then I'd certainly support it.
>
> But I don't want to get distracted with a prolonged discussion about a
> detailed error space.  Normal vs Abnormal gives us the major
> functional information we need, so I'm cautious about losing agreement
> about that in a wider debate.    But then, so far nobody has spoken
> out against such a status field.

Agreed. I certainly don't have any interest in discussing what codes
are necessary or not right now. That's why I suggest that we simply
reuse the HTTP status code format of 3 digits(but not the actual
status codes), allow an optional message (single space followed by a
free-form UTF-8 message). For the moment, if only normal or abnormal
exit is required, then only specify those two errors, but at least
allow for a textual description as to what is causing the abnormal
termination. I would suggest reusing the 2xx for normal, 4xx for
client error (or message sender error) and 5xx for server error (or
message receiver) form since they are already familiar. Disallow other
error ranges.

status = [245] [0-9] [0-9]
message = ' ' utf8_character+
close_body = status message?

Normal:
200 normal

Abnormal:
400 bad request
500 internal server error

This would allow servers to at least close connections on a client
that has sent a bad request and give the client an idea of if the
connection was closed due to their fault or something that happened in
the server.

Status codes that I could imagine would be useful as well as a few
codes to cover the list that Yuta mentioned:

4xx
* timeout
* invalid opcode
* invalid encoding
* unexpected
* too long

5xx
* overloaded / service unavailable
* not supported

But as I said, at the very least, the 200/400/500 + optional text message.

Regards,
Brodie