Open robinzimmermann opened 8 years ago
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_.
See https://github.com/kaazing/gateway/issues/472#issuecomment-201508244 for related discussion, this should not be added until we added a corresponding feature in the gateway to set this.
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
Now, modify mqtt.html by adding the following lines above the
<script src="mqttws31.js"></script>
line: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 theSec-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.