You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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_.
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.
The text was updated successfully, but these errors were encountered: