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

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 9 May 2012 14:12:19 +0900

Hi,

Endpoints MUST NOT send a close frame with close code of 1005, 1006 or 1015.

What should we do when received such a frame from a broken endpoint? It
seems there's no text specifying this.

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.

Thoughts?

Takeshi

---

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

Yes. The connection is getting closed anyway, such an event only requires to
be logged and somehow reported to the application. The handling that you
suggested would do fine. 

A more "kind" alternative would be to send a close frame with 1002 "Protocol
Error" so that the remote side would be able to realize that there is
something wrong with their implementation, provided of course that they log
close frame codes.

With best regards,

Arman

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Takeshi Yoshino
Sent: Wednesday, May 09, 2012 8:12 AM
To: [email-masked]
Subject: [hybi] RFC6455 clarification: when received close code of 1005,
1006, 1015

Hi,

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.

Thoughts?

Takeshi

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 May 2012 20:57:52 +0100

> Hi,
Hi Takeshi,
> What should we do when received such a frame from a broken endpoint? 
> It seems there's no text specifying this.
I think Garbage-In-Garbage-Out rule applies here, but as this affect the 
WebSocket API, you are right we should clarify this.
> 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?

Alternatively, we can reserve a new "you lied to me about your reason" 
close code.

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 10 May 2012 11:51:43 +0900

Hi Alexey,

>  1006 seems as good of a code for this as any. Does "wasClean=false"

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"

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.

---

From: Takashi Toyoshima <[email-masked]>
Date: Tue, 22 May 2012 15:18:00 +0900

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 <[email-masked]> wrote:
> Hi Alexey,
>
> On Thu, May 10, 2012 at 4:57 AM, Alexey Melnikov <[email-masked]>
> wrote:
>>>
>>> such a bad close frame should _Fail the WebSocket Connection_ and invoke
>> 1006 seems as good of a code for this as any. Does "wasClean=false" matter
>> in this case?
>
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Jason Duell <[email-masked]>
Date: Tue, 22 May 2012 21:38:22 -0700

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

Jason Duell
Mozilla

---

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 24 May 2012 13:12:15 +0900

> 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

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

---

From: Takashi Toyoshima <[email-masked]>
Date: Thu, 24 May 2012 16:43:50 +0900

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 <[email-masked]> wrote:
> 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.
>

---

From: Jason Duell <[email-masked]>
Date: Thu, 24 May 2012 16:19:07 -0400

> On Wed, May 23, 2012 at 1:38 PM, Jason Duell <[email-masked]> 

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.

>  As 7.1.5 of the spechttp://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).

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.   I suggest that we handle malformed close frames (with close code 1005/1006/1015) as a protocol error, and deliver 1002 to both the remote end and JS, and reserve 1006 for the case where the connection is simply closed, w/o any protocol error (i.e. no malformed frames received).

I agree that in either case we should Fail the WS connection, so deliver onerror.

Thoughts?

Jason Duell
Mozilla

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 25 May 2012 16:15:49 +0900

On Fri, May 25, 2012 at 5:19 AM, Jason Duell <[email-masked]>wrote:

>>> http://tools.ietf.org/html/**rfc6455#section-7.1.7<http://tools.ietf.org/html/rfc6455#section-7.1.7>
>>>
> 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,
>>
> 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.