Re: [hybi] RFC6455 clarification: when received close code of 1005, 1006, 1015

[Takashi Toyoshima <[e-mail]>]

I'm planing to deliver 1006 and fall back to the _Fail the WebSocket
Connection_ process.
Currently it doesn't send an appropriate status code. But I also think
1002 is the best if I sent.

On Thu, May 24, 2012 at 1:12 PM, Takeshi Yoshino <[e-mail]> wrote:
> On Wed, May 23, 2012 at 1:38 PM, Jason Duell <[e-mail]>
> wrote:
>>
>> On Mon, May 21, 2012 at 11:18 PM, Takashi Toyoshima
>> <[e-mail]> wrote:
>> > I'll fix WebKit implementation of receiving 1005, 1006, 1015, and
>> > length=1 of close frames.
>> > These frames will fire CloseEvent with code=1006 and wasClean=false.
>>
>> What, if anything, do you plan to reply to the endpoint with, if the
>> 1005/1006/1015 is received before your client has sent its own close
>> frame?  Will you be replying with 1002, but delivering 1006 to
>> onclose?  I can see the logic there, though it's a little confusing.
>
>
> Yes. It's a bit confusing but well defined behavior. For any other protocol
> violation, the endpoint received a broken frame SHOULD send 1002 and MUST
> invoke onclose with 1006.
>
> http://tools.ietf.org/html/rfc6455#section-7.1.7
>
>>
>> The only other choice would seem to be to simply shut down the TCP
>> connection with no close frame, but that seems harsh.  Or we could
>> both send 1002 to the remote server and deliver it to onclose (though
>> I agree that 1006 seems closer in meaning).
>
>
> It's SHOULD. Shutting down TCP without sending 1002 is also fine as per
> spec. http://tools.ietf.org/html/rfc6455#section-7.1.7
>
> There has been discussion about the meaning of the code argument of the
> onclose handler. As 7.1.5 of the
> spec http://tools.ietf.org/html/rfc6455#section-7.1.5 explains, now it's
> meaning is finalized as "the status code contained in the first
> Close control frame received". That's my understanding. So, the code for
> onclose must be 1006.
>