Subject: [hybi] was_clean and _Fail the WebSocket connection_

From: Yutaka Hirano <[email-masked]>
Date: Mon, 9 Dec 2013 16:36:34 +0900

Hi,

I'm revising WebSocket implementation on Chrome and I have some questions
about RFC6455.

A: I think a client should _Fail the WebSocket Connection_ when it receives
a masked frame
    instead of just closing the connection as specified in the spec, given
that other protocol errors
    such as RSV or opcode errors cause failure. Is that right?
B: If A holds, is it possible to say that all client-side unclean
connection close are caused by _Fail the
 WebSocket Connection_ operation?

Thanks,

---

From: Joakim Erdfelt <[email-masked]>
Date: Mon, 9 Dec 2013 06:44:58 -0700

For a client receiving a masked frame, that's handled by Section 5.1.
Overview.

   A server MUST NOT mask any frames that it sends to
   the client.  A client MUST close a connection if it detects a masked
   frame.  In this case, it MAY use the status code 1002 (protocol
   error) as defined in Section 7.4.1.  (These rules might be relaxed in
   a future specification.)

In Jetty we close the connection on any protocol level error / failure, as
we can't trust the connection to be sane anymore.
Especially when Extensions are in use.

Things like (this is the list for incoming frames only):

 * Too large payload on control frames
 * If an unknown opcode is received
 * Close frames with payload length of 1
 * A data frame payload exceeding Integer.MAX_VALUE (this is an arbitrary
memory sanity check for Jetty, not part of the spec.  only used when
complete message delivery is expected, vs streaming message delivery.  The
intSane check)
 * A data frame payload that will put the complete message size over the
per-endpoint configuration (part of the javax.websocket spec)
 * A RSV flag is set, yet no Extension in use is registered for it.
 * If server received an un-masked frame. (this is in violation of the rfc
spec, but is a controllable policy configuration)
 * Client received a masked frame.
 * If an extension reported an error in processing the incoming frame.
 * If any IOException occurs during read / parse
 * If a Binary or Text frame is received without a prior FIN ending the
prior message.
 * If a continuation frame is received after a FIN
 * If a control frame with FIN=false is received
 * Any memory allocation error for the incoming payload or complete message

(Incidentally, most of these are part of the autobahn websocket protocol
testsuite)

All of these will cause:

 * Local endpoint onError() notification
 * Remote endpoint close / harsh (don't wait for close response. aka,
wasClean=false)
 * Connection disconnect
 * Local endpoint onClose() notification (with harsh indicator)

--
Joakim Erdfelt <[email-masked]>
webtide.com <http://www.webtide.com/> - intalio.com/jetty
Expert advice, services and support from from the Jetty & CometD experts
eclipse.org/jetty - cometd.org

On Mon, Dec 9, 2013 at 12:36 AM, Yutaka Hirano <[email-masked]> wrote:

> A: I think a client should _Fail the WebSocket Connection_ when it
> receives a masked frame
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Yutaka Hirano <[email-masked]>
Date: Tue, 10 Dec 2013 12:44:08 +0900

The WebSocket API spec[1] says:
  If the user agent was required to fail the WebSocket connection, or if
the the WebSocket connection was closed after being flagged as full, fire a
simple event named error at the WebSocket object.

and I'm wondering if I can fire an error event when receiving a masked
frame (as a client).
Is it OK to fire an error event for a non-failure protocol error?

Thanks,

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html

On Mon, Dec 9, 2013 at 10:44 PM, Joakim Erdfelt <[email-masked]> wrote:

> On Mon, Dec 9, 2013 at 12:36 AM, Yutaka Hirano <[email-masked]>wrote:
>
>> Hi,
>>
>>     instead of just closing the connection as specified in the spec,
>> given that other protocol errors