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

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 29 November 2011 14:18 UTC

Return-Path: <alexey.melnikov@isode.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 A99E721F8A7B for <hybi@ietfa.amsl.com>; Tue, 29 Nov 2011 06:18:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 pm0I4UuIm5OQ for <hybi@ietfa.amsl.com>; Tue, 29 Nov 2011 06:18:51 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id B78D221F8AFE for <hybi@ietf.org>; Tue, 29 Nov 2011 06:18:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1322576330; d=isode.com; s=selector; i=@isode.com; bh=ypp/8PIqIriEh8U7EX6x3ngfh6u+t6FQZKALRUhxcwI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=GVBrwU4cC/G0TcGnSttgTti1WENcsKEGyNCtjHMN4o4RImZnbYIQas8zjfZzZn8elNwT/F gxPXSxLc1gqfMblAn1E9ZnX0dqPzD7PcvrBNN7D501ivCMnBYyMcYBcsjE4mV6VL3t6nUw f1MBx3mqa4F1WuBLmN9qpNg2iEKk9h0=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TtTpyQBaKzBF@rufus.isode.com>; Tue, 29 Nov 2011 14:18:49 +0000
Message-ID: <4ED4E9CB.3040106@isode.com>
Date: Tue, 29 Nov 2011 14:18:51 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: Peter Thorson <webmaster@zaphoyd.com>
References: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com>
In-Reply-To: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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:18:51 -0000

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.