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

Hi Takeshi,

I agreed your suggestion and also think receiving close frames of
payload length=1 is the same as your cases.
If payload length was zero, it can be handled as 1005 safely. But
length=1 is clearly broken.

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.

Thanks,

On Thu, May 10, 2012 at 11:51 AM, Takeshi Yoshino <tyoshino@google.com> wrote:
> Hi Alexey,
>
> On Thu, May 10, 2012 at 4:57 AM, Alexey Melnikov <alexey.melnikov@isode.com>
> wrote:
>>>
>>> I think this should be taken as protocol error. The endpoint received
>>> such a bad close frame should _Fail the WebSocket Connection_ and invoke
>>> onclose() with code=1006 and wasClean=false.
>>
>> 1006 seems as good of a code for this as any. Does "wasClean=false" matter
>> in this case?
>
>
> As the received close frame is considered to be broken, we should not take
> this as successful completion of closing handshake. I think it should be
> taken as "_The WebSocket Connection is Closed_ but not _cleanly_" which
> results in wasClean=false for the WebSocket API's case.
>
>>
>> Alternatively, we can reserve a new "you lied to me about your reason"
>> close code.
>
>
> We can. But as Arman suggested, we can also just use the existing code 1002
> to tell the remote endpoint that it's broken when the closing handshake
> initiator is the remote endpoint.
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>