Re: [hybi] WS close code equivalent to HTTP 500/Internal Server Error

Peter Thorson <webmaster@zaphoyd.com> Tue, 29 November 2011 14:54 UTC

Return-Path: <webmaster@zaphoyd.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FED221F8BC3 for <hybi@ietfa.amsl.com>; Tue, 29 Nov 2011 06:54:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7a2XCKlwpxKY for <hybi@ietfa.amsl.com>; Tue, 29 Nov 2011 06:54:57 -0800 (PST)
Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 74ECF21F8BB0 for <hybi@ietf.org>; Tue, 29 Nov 2011 06:54:57 -0800 (PST)
Received: from c-68-51-77-246.hsd1.il.comcast.net ([68.51.77.246]:42372 helo=[10.0.1.82]) by sh78.surpasshosting.com with esmtpa (Exim 4.69) (envelope-from <webmaster@zaphoyd.com>) id 1RVP58-0007xX-Pp; Tue, 29 Nov 2011 09:54:51 -0500
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="iso-8859-1"
From: Peter Thorson <webmaster@zaphoyd.com>
In-Reply-To: <4ED4E9CB.3040106@isode.com>
Date: Tue, 29 Nov 2011 08:54:50 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <2194D0DD-0E32-48D4-B538-69BB3596B063@zaphoyd.com>
References: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> <4ED4E9CB.3040106@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: Apple Mail (2.1251.1)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - zaphoyd.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: hybi@ietf.org
Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal Server Error
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Nov 2011 14:54:58 -0000

A quick search through the hybi list logs indicates code 1011 has only been mentioned in relation to this error condition.

On Nov 29, 2011, at 8:18 , Alexey Melnikov wrote:

> Peter Thorson wrote:
>> This issue came up while polishing up the error handling code for my WS implementation. There doesn't seem to be a websocket close code equivalent to HTTP 500/Internal server error.
>> 
>> I would like to handle situations where my endpoint catches an internal logic error and knows that continuing the connection will probably result in bad/unknown behavior but knows that it is safe enough to close the connection cleanly.
>> 
>> Example: I am a server and my handler for processing websocket messages is interpreted code and that code has a syntax error. The websocket server itself is fine and can safely close the connection but clearly cannot process messages until someone fixes the missing semicolon somewhere. In an HTTP server I would return 500/Internal Server error to indicate that something on the server end screwed up and that there is probably more information in the server log files to diagnose further.
>> 
>> None of the current close codes (except 1006/abnormal closure - which isn't allowed on the wire) really fit. I'd rather not just drop the connection uncleanly/send back empty close frame since that provides no information about what happened and makes figuring out whose logs I should be looking at as an end application developer difficult. Browsers only report the status code itself and not the reason so sending a normal/going away error code with a more specific reason is less helpful. What are other implementations doing in this case? Would another close code for internal server error make sense?
> Let's use 1011 for this (Unless I already suggested it be used for something else. Please correct me if I did.):
> 
> 1011
>      1011 indicates that a server is terminating the connection
>      because it has encountered an unexpected condition which prevented
>      it from fulfilling the request.
>