Subject: [hybi] Close frame response status code

From: Peter Thorson <[email-masked]>
Date: Mon, 12 Sep 2011 20:27:56 -0500

If I receive a close frame with some status code, say 1008/policy violation. Does the spec define what my response close code should be? What is the ideal behavior here?

- Send 1008 acknowledging the other end's status code?
- Send 1000/normal indicating that I am closing normally because they asked? 
- Send an empty close message?

---

From: Brian <[email-masked]>
Date: Mon, 12 Sep 2011 20:11:35 -0700

This could indeed use some clarification.  In my implementation, I
arbitrarily chose to send back 1000/normal.  Last I checked, this is
completely undefined in the spec.

Brian

On Mon, Sep 12, 2011 at 6:27 PM, Peter Thorson <[email-masked]>wrote:

> If I receive a close frame with some status code, say 1008/policy
> violation. Does the spec define what my response close code should be? What
> is the ideal behavior here?
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 13 Sep 2011 14:15:13 +1000

> completely undefined in the spec.

Ah! In my implementation I send back the code that I received.     I
thought this more useful as the other end could better guess if it was
getting an ack to it's close or just another close that happened to
occur at the same time.
But I'm not fussed really one way or the other - so long as it is standard.

cheers

---

From: Peter Thorson <[email-masked]>
Date: Tue, 13 Sep 2011 00:03:53 -0500

> But I'm not fussed really one way or the other - so long as it is standard.

I've also been sending back an echo of the closing frame that I received. Echoing the close allows an application to compare the reason it sent and the one it got back to determine if there was a disagreement about the close method. It also makes uniformly informing both client and server applications about implementation errors a bit easier.

Consider the following case: A client sends a message that is too big. The server responds with a 1009/too big close frame. If the client responds with a 1000/normal close frame and closes the connection, the server application gets delivered a 1000/normal message in its onclose call. You now have to implement some other API mechanism to allow the server application to distinguish this case from a regular voluntary client closing. Returning 1000/normal + firing an onerror message would work but seems slightly less elegant. 

Another potential complication that doesn't seem to be addressed in the spec:
What should happen when the initial close frame is malformed (close frame with reserved bits set, payload too big, invalid utf8, etc). Just kill the connection? Send a close frame back with the appropriate error? Send a 1000/normal or echo frame back... if an echo close frame, should it echo the original error? 

Some API related close handshake questions that are half on topic
- The browser API limits the status codes the local application can request to 1000 and 3000-4999. This seems reasonable. Is there any reason not to enforce this in general (servers/non browser clients).
- It probably doesn't matter too much since the connection is about to go away anyways, but should it be a protocol error to use reserved status codes (ie 0-999, 5000-65535 in particular)?
- How to deal with timing of the onclose event. If a local application requests that the connection be closed, how long is it reasonable to wait for a closing acknowledgement before deciding the connection was closed uncleanly and fire the onclose event?

---

From: Peter Thorson <[email-masked]>
Date: Fri, 16 Sep 2011 14:54:52 -0500

Hi all, I am working on some autobahn test cases for the closing handshake, did anyone have any opinions on whether any of the issues from this thread should be defined in the spec or just left as impliementation defined?

Begin forwarded message:

> From: Peter Thorson <[email-masked]>
> Date: September 13, 2011 1:03:53 EDT
> To: Greg Wilkins <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [hybi] Close frame response status code
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 22:00:05 +0200

2011/9/16 Peter Thorson <[email-masked]>:
> Hi all, I am working on some autobahn test cases for the closing handshake

I'm waiting for it :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 17 Sep 2011 18:13:06 +0100

Peter Thorson wrote:

>- The browser API limits the status codes the local application can request to 1000 and 3000-4999.
>
Just to double check: any value from the range 1000-4999 can be 
requested, right? If not, that is a bug in the API spec.

>This seems reasonable. Is there any reason not to enforce this in general (servers/non browser clients).
Sure :-).

---

From: Peter Thorson <[email-masked]>
Date: Sun, 18 Sep 2011 22:19:06 -0500

On Sep 17, 2011, at 12:13 , Alexey Melnikov wrote:

> Just to double check: any value from the range 1000-4999 can be requested, right? If not, that is a bug in the API spec.

The spec indicates that 1000-4999 is indeed the valid range. It also says that 1000-2999 are reserved for definition by the protocol and extensions and 3000-4999 are reserved for libraries and applications. Browsers websocket implementations (which use the full range internally) appear to be limiting the ability for JS code to request close values other than 1000 (normal) and 3000-4999.

I think the websocket protocol is fine here, websocket implementers and api users should just be aware that higher level APIs including the WHATWG one may restrict the types of close messages that can be directly sent.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 24 Sep 2011 17:23:27 +0100

>I think the websocket protocol is fine here, websocket implementers and api users should just be aware that higher level APIs including the WHATWG one may restrict the types of close messages that c…
Thank you for the clarification: this seems to be fine.