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

[Takeshi Yoshino <[e-mail]>]

On Fri, May 25, 2012 at 5:19 AM, 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<http://tools.ietf.org/html/rfc6455#section-7.1.7>
>>>
>> On Wed, May 23, 2012 at 1:38 PM, Jason Duell <[e-mail]>
>> wrote:
>>
>
> So all protocol errors must deliver 1006 to JS instead of 1002?   This is
> counter-intuitive to me, and I think it will confuse both users and
> developers.
>

If we do so, the meaning of 1002 delivery to JS will be ambiguous. We need
a way to determine whether the remote server is misbehaving or the client
is. Otherwise, it makes healthy clients worry about bugs in themselves.

Solutions I can come up with are:

- check wasClean to distinguish it's remote error or local error
- check if onerror was invoked or not to distinguish it's remote error or
local error
- add new status codes for local errors (e.g. 1022 "protocol error in the
frame from the remote endpoint")

Whichever we choose, we need to make change on 7.1.5.


>  As 7.1.5 of the spechttp://tools.ietf.org/**html/rfc6455#section-7.1.5<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".
>>
>
> OK--so if I follow you, the justification here to deliver 1006 to the
> application when the client encounters a protocol error is because we
> always set the close code to the error the *server* sends us, or 1006, (i.e
> a protocol error means no close frame, so 1006).
>

Yes.


> I can see this reading of the spec.  But the exact language for 1002 is
> "1002 indicates that an endpoint is terminating the connection due to a
> protocol error."  Note that it says "an" endpoint, not "the remote
> endpoint."  This makes me think we can deliver 1002 to JS for a protocol
> error we detect from the server.


Yes, but I don't think the text has such implication. It's overridden by
7.1.5.