Re: [hybi] Clarify the role of closing handshake

Brodie Thiesfield <> Fri, 11 February 2011 13:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B98C3A6A16 for <>; Fri, 11 Feb 2011 05:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0MJnMqYx7FXB for <>; Fri, 11 Feb 2011 05:59:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CB3293A69FF for <>; Fri, 11 Feb 2011 05:59:13 -0800 (PST)
Received: by bwz12 with SMTP id 12so3519639bwz.31 for <>; Fri, 11 Feb 2011 05:59:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V8oFZ2NV8NlR0I0M2QqjnZAu/BZ0le6XcLEHDBM3/fw=; b=kJhmKop2j7RWJPg57wOzo1/roXuQc223jnK2X7D0btAy5y4Xm2omIZb0tZ0r/1C1oT RtFufY1GaZgX/QEm4tp8xyFl4SKAGpRFn1g5xKQ90GRf9bC9fa+8ZfYSaPoAB60foxlp e9EMAnvVJtS5hNf8aEq7rSXOvSwlVDH+p/TAg=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LPTbMB1K05qQ5wdCX4nY8pXCpqYLkTAY76qC3iaB/q9cWKd+zdV9mj+ylMWOsNWXf2 KxRtg/2PdetBpeTk/Mdwk/vNW8go6RSmqDKE6CTHNtKn2mWJpE3J4wsC7RZetdXef43V WgetlpDs7YiTZMwtQnJ9XGTeDT0sPpzMoqdKQ=
MIME-Version: 1.0
Received: by with SMTP id b14mr322900muq.20.1297432767693; Fri, 11 Feb 2011 05:59:27 -0800 (PST)
Received: by with HTTP; Fri, 11 Feb 2011 05:59:27 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Fri, 11 Feb 2011 22:59:27 +0900
Message-ID: <>
From: Brodie Thiesfield <>
To: Greg Wilkins <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, Gabriel Montenegro <>
Subject: Re: [hybi] Clarify the role of closing handshake
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Feb 2011 13:59:15 -0000

On Fri, Feb 11, 2011 at 10:37 AM, Greg Wilkins <> wrote:
> On 11 February 2011 12:14, Brodie Thiesfield <> 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?

200 normal

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:

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

* overloaded / service unavailable
* not supported

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