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

From: Takashi Toyoshima <[email-masked]>
Date: Wed, 9 May 2012 13:02:33 +0900

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
<[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi

---

From: "Arman Djusupov" <[email-masked]>
Date: Wed, 9 May 2012 12:08:12 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Takashi Toyoshima
Sent: Wednesday, May 09, 2012 7:03 AM
To: Alexey Melnikov
Cc: [email-masked]; Peter Thorson
Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal Server
Error

Hi hybi,

On Tue, Nov 29, 2011 at 11:18 PM, Alexey Melnikov
<[email-masked]> 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.
>> 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

---

From: Peter H Thorson <[email-masked]>
Date: Wed, 9 May 2012 09:57:01 -0500

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

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 10 May 2012 14:24:47 +0900

On Wed, May 9, 2012 at 11:57 PM, Peter H Thorson <[email-masked]>wrote:

> 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.

+1

Takeshi

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 10 May 2012 08:57:36 +0100

Hi,

On 10 May 2012, at 06:24, Takeshi Yoshino <[email-masked]> wrote:

> On Wed, May 9, 2012 at 11:57 PM, Peter H Thorson <[email-masked]> wrote:

It looks like everybody is in agreement on this change. As the Designated Expert for the registry I will ask IANA to update the definition.

---

From: Takashi Toyoshima <[email-masked]>
Date: Fri, 11 May 2012 13:52:03 +0900

Thank you Alexey, and persons who post comments.

Cheers,

On Thu, May 10, 2012 at 4:57 PM, Alexey Melnikov
<[email-masked]> wrote:
> It looks like everybody is in agreement on this change. As the Designated
> Expert for the registry I will ask IANA to update the definition.
>