Sec-WebSocket-Key

Mar 7, 2012 at 8:08 PM

Hi.  Thank you for making this library available.  I am testing WebSocket4Net against the "WebSockets Protocol Test Suite" found at http://www.tavendo.de/autobahn/testsuite.html.

The first problem that I encountered is that the Sec-WebSocket-Key should be a 16 byte value that is then Base64 encoded resulting in 24 bytes.  I reviewed the spec on-line and indeed this value should be 16 bytes encoded to Base64.  I modified your code accordingly and now I can continue with the validation against the test suite.

Have you guys run any tests against 3rd party test suites?

Regards,

Arthur

Coordinator
Mar 8, 2012 at 12:53 AM

Sorry, I failed to find a description about it in rfc6455:

http://tools.ietf.org/html/rfc6455#section-1.3

 

To prove that the handshake was received, the server has to take two
   pieces of information and combine them to form a response.  The first
   piece of information comes from the |Sec-WebSocket-Key| header field
   in the client handshake:

        Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

   For this header field, the server has to take the value (as present
   in the header field, e.g., the base64-encoded [RFC4648] version minus
   any leading and trailing whitespace) and concatenate this with the
   Globally Unique Identifier (GUID, [RFC4122]) "258EAFA5-E914-47DA-
   95CA-C5AB0DC85B11" in string form, which is unlikely to be used by
   network endpoints that do not understand the WebSocket Protocol.  A
   SHA-1 hash (160 bits) [FIPS.180-3], base64-encoded (see Section 4 of
   [RFC4648]), of this concatenation is then returned in the server's
   handshake.

Where did you find the spec?

Yes, Chrome send Sec-WebSocket-Key like you said, I'll change it if I find the definition.

Mar 8, 2012 at 2:10 AM

See section 4.1 of that same document - http://tools.ietf.org/html/rfc6455#section-4.1

   7.   The request MUST include a header field with the name
        |Sec-WebSocket-Key|.  The value of this header field MUST be a
        nonce consisting of a randomly selected 16-byte value that has
        been base64-encoded (see Section 4 of [RFC4648]).  The nonce
        MUST be selected randomly for each connection.
Coordinator
Mar 8, 2012 at 2:11 AM

Great!

Thank you, I'll fix it ASAP!

Coordinator
Mar 8, 2012 at 3:27 AM

This bug has been fixed in the latest change.

Thank you for your helping!

Mar 8, 2012 at 4:13 PM

Thank you for the quick response.  This part is working fine for me now.  You might want to look at the test suite - http://www.tavendo.de/autobahn/testsuite.html.  A couple of the tests cause a crash down at the SuperSocket level.

Coordinator
Mar 9, 2012 at 12:14 AM

Ok, thank you very much!

Coordinator
Mar 9, 2012 at 12:58 AM

Oh, I failed to play with autobahn, I cannot find the fuzzing_client.py...

Coordinator
Mar 11, 2012 at 3:20 PM

The test suit works for me.

SuperWebSocket will not crash because of the tests, just there is a maxCommandLength configuration doesn't allow requests longer than that limitation.

Now, SuperWebSocket pass the most test cases of autobahn test suite, please download the latest code of SuperWebSocket.