Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The problem is caused by use of Sec-WebSocket-Protocol in the handshake response. The client did not request a subprotocol so the only valid response from the server is to complete the handshake without specifying a subprotocol. If the server responds with an unexpected subprotocol, the client is required to close the connection. See the /subprotocol/ section in section 4.2.2 of <a href="http://tools.ietf.org/html/rfc6455#section-4.2.2" rel="nofollow noreferrer">RFC 6455</a> for details.</p> <p>The easiest fix is to remove the Sec-WebSocket-Protocol header from your response. If you want to retain it, you need to pass a subprotocol name as the second argument to the client's WebSocket constructor and use this subprotocol in your server's response. See the <a href="http://dev.w3.org/html5/websockets/#the-websocket-interface" rel="nofollow noreferrer">client API</a> docs for details.</p> <p>EDIT: <br>Once you've completed your handshake, the server will quite possibly fail trying to read the "TestOutput" message from the client's onOpen. WebSocket messages aren't plain text and don't use HTTP so the line <code>this.ReadLine()</code> is hugely unlikely to find a \r\n to terminate on. See the <a href="http://tools.ietf.org/html/rfc6455#section-5.2" rel="nofollow noreferrer">data framing</a> section of the spec for details. This <a href="https://stackoverflow.com/questions/8125507/how-can-i-send-and-receive-websocket-messages-on-the-server-side">wiki post</a> has some useful psuedo-code for websocket reads/writes. Or, you could try my <a href="https://github.com/openhome/ohNet/blob/master/OpenHome/Net/Device/Upnp/DviServerWebSocket.cpp" rel="nofollow noreferrer">C++ server</a>. See <code>WsProtocol80::Read()</code> for how to read messages. Or look at one of the open source C# servers, such as <a href="https://github.com/statianzo/Fleck/blob/master/src/Fleck/Handlers/Hybi13Handler.cs" rel="nofollow noreferrer">Fleck</a> (code to read/write messages is linked).</p> <p>There are some other small changes you could consider which would make your code more robust but won't make the difference between an immediate pass and fail:</p> <ul> <li>Any subprotocol you specify should ideally include your domain name to minimise the chances of accidentally matching any incompatible protocol request. An <a href="http://tools.ietf.org/html/rfc6455#section-1.9" rel="nofollow noreferrer">early section</a> of RFC 6455 explains why.</li> <li>It'd be worth considering checking for the presence and value of a Sec-WebSocket-Protocol header in a request before responding with your supported subprotocol.</li> <li>The order of headers in a client request isn't guaranteed so you could delay your response until you read an empty line.</li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload