Kaazing WebSocket client doesn't enforce invalid Sec-WebSocket-Protocol

[robinzimmermann]

Gateway with version:

Gateway 5.0

Can the bug be reproduced in a Kaazing demo out-of-the-box?

No.

Steps to reproduce:

Follow the instructions specified in Gateway sends response with invalid Sec-WebSocket-Protocol header #472

WebSocket connection to 'ws://localhost:8080/mqtt' failed: Error during WebSocket handshake: Sent non-empty 'Sec-WebSocket-Protocol' header but no response was received

Now, modify mqtt.html by adding the following lines above the <script src="mqttws31.js"></script> line:

<script src="http://cache.kaazing.net/bower/kaazing-websocket-client-javascript/5.0.0-50/WebSocket.js"></script>
<script>
    window.WebSocket = Kaazing.Gateway.WebSocket;
</script>

Open mqtt.html in a browser: http://localhost:8000/mqtt.html. Notice that the app succeeds, and the echoed message is written to the screen.

However this should not succeed because the server never send a Sec-WebSocket-Protocol header with the value of "mqtt". But it should have because the request contained the Sec-WebSocket-Protocol header with the value of "mqtt".

In the first case, the browser is enforcing the RFC 6455 spec. In the second case, the Kaazing client library should be doing the same enforcement, but is not.

Expected behavior:

In both cases, the handshake should fail.

[dpwspoon]

Relevant spec sections

   4.  If the response lacks a |Sec-WebSocket-Accept| header field or
       the |Sec-WebSocket-Accept| contains a value other than the
       base64-encoded SHA-1 of the concatenation of the |Sec-WebSocket-
       Key| (as a string, not base64-decoded) with the string "258EAFA5-
       E914-47DA-95CA-C5AB0DC85B11" but ignoring any leading and
       trailing whitespace, the client MUST _Fail the WebSocket
       Connection_.

   5.  If the response includes a |Sec-WebSocket-Extensions| header
       field and this header field indicates the use of an extension
       that was not present in the client's handshake (the server has
       indicated an extension not requested by the client), the client
       MUST _Fail the WebSocket Connection_.  (The parsing of this
       header field to determine which extensions are requested is
       discussed in Section 9.1.)

   6.  If the response includes a |Sec-WebSocket-Protocol| header field
       and this header field indicates the use of a subprotocol that was
       not present in the client's handshake (the server has indicated a
       subprotocol not requested by the client), the client MUST _Fail
       the WebSocket Connection_.

[dpwspoon]

See kaazing/gateway#472 (comment) for related discussion, this should not be added until we added a corresponding feature in the gateway to set this.