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

Peter H Thorson <webmaster@zaphoyd.com> Wed, 09 May 2012 14:57 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 7580121F8522 for <hybi@ietfa.amsl.com>; Wed, 9 May 2012 07:57:13 -0700 (PDT)
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 Tzl5W6mKkfV9 for <hybi@ietfa.amsl.com>; Wed, 9 May 2012 07:57:12 -0700 (PDT)
Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFEE11E8072 for <hybi@ietf.org>; Wed, 9 May 2012 07:57:12 -0700 (PDT)
Received: from belgaer.uchicago.edu ([128.135.45.61]:59269) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <webmaster@zaphoyd.com>) id 1SS8K7-0000j4-KL; Wed, 09 May 2012 10:57:03 -0400
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="iso-8859-1"
From: Peter H Thorson <webmaster@zaphoyd.com>
X-Priority: 1 (Highest)
In-Reply-To: <000001cd2dc3$47206370$d5612a50$@noemax.com>
Date: Wed, 09 May 2012 09:57:01 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B4EB3BD-9AD7-4482-B7CB-A5652FE23327@zaphoyd.com>
References: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> <4ED4E9CB.3040106@isode.com> <CAFWCB1mM=276jZGTmgRTDrd=i=m7B=VF8JG0hwUcO0Qor4pJoA@mail.gmail.com> <000001cd2dc3$47206370$d5612a50$@noemax.com>
To: Arman Djusupov <arman@noemax.com>
X-Mailer: Apple Mail (2.1257)
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: 'Takashi Toyoshima' <toyoshim@chromium.org>, 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: Wed, 09 May 2012 14:57:13 -0000

Hi All,

My apologies for the confusion here. A number of people have asked about this recently. My original proposal for this code (http://www.ietf.org/mail-archive/web/hybi/current/msg09280.html) had it named "Internal Endpoint Error" in recognition of the fact that unlike HTTP, websocket was a bidrectional system where both "client" and "server" could be expected to have internal errors. I didn't pay close enough attention to the final wording that went into the RFC, which definitely implies that it is an asymmetric server only code. This was not the original intention.

I absolutely agree that 1011 should be used by both clients and servers. That is how my implementations behave and how the Autobahn test suite close handshake tests interpret the spec. If there are opportunities to amend the spec to clarify this, renaming to Internal Endpoint Error or Internal Error and removing "server" would reduce this confusion and be a good idea.

Peter

On 2012-May-9, at 4:08, Arman Djusupov wrote:

> 
> Since WS is a duplex transport it should not differentiate the client from
> the server except during the handshake phase. I think we should assume that
> in this context the server is not meant to be the side that accepts a
> connection but the side that processes the message. It should be correct to
> use 1011 both on the server and on the client side. For this reason the
> specification might need a change in the error code name and description;
> suggestion:
> 
> 
> From : "Internal Server Error" To: "Internal Error"
> 
> Description, from :
>     "1011 indicates that a server is terminating the connection because
>       it encountered an unexpected condition that prevented it from
>       fulfilling the request."
> To:
>     "1011 indicates that a remote endpoint is terminating the connection
>      because it encountered an unexpected condition that prevented it
>      from fulfilling the request."
> 
> With best regards,
> Arman
> 
> -----Original Message-----
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
> Takashi Toyoshima
> Sent: Wednesday, May 09, 2012 7:03 AM
> To: Alexey Melnikov
> Cc: hybi@ietf.org; Peter Thorson
> Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal Server
> Error
> 
> Hi hybi,
> 
> Is this discussion valid also for browser side implementation?
> My concern is that what error code should be sent if a browser got an
> internal error.
> 
> On Tue, Nov 29, 2011 at 11:18 PM, Alexey Melnikov
> <alexey.melnikov@isode.com> 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.
>> 
>> 
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi