1

I am working on a server and finished the handshake and basic websocket unmasking functions (the server is go!). I am wondering how I could test my fragment handling code. Is there a way to, with chrome, create a websocket, connect to my local server, and then split "hello" into 2 frames. I was able to send "hello" and see it on the server. Sending hello twice was just 2 messages with fin bits.

user2118704
  • 55
  • 7
  • I don't know of a client that exposes a way to fragment a message. I suggest testing your server with the [https://github.com/crossbario/autobahn-testsuite](https://github.com/crossbario/autobahn-testsuite) as [Gorilla does](https://github.com/gorilla/websocket/tree/master/examples/autobahn). The test suite includes fragmentation tests. – Charlie Tumahai Apr 27 '17 at 23:10
  • I didn't know about that... thanks! I guess I could take an object, serialize it to a byte array, send half with fin bit set to 0, then send the second half with a fin bit set to 1 and assemble the 2 parts... I was just hoping there was an easy way to test how chrome is going to handle since I'd like to support web browsers. I'll check out how they do it anyway to make sure my thinking is right, so thanks again. – user2118704 Apr 27 '17 at 23:35

1 Answers1

1

The Gorilla client sends fragmented messages when the message size is greater than the write buffer size.

The AutoBahn Test Suite includes tests for fragmented messages. You can use the Gorilla test server for Autobahn as a starting point for your tests.

Another option is to use the tested Gorilla websocket package instead of writing your own websocket code.

Charlie Tumahai
  • 113,709
  • 12
  • 249
  • 242
  • Writing the websocket code was fun though! Also, do you know how to get around this issue? http://stackoverflow.com/questions/8193761/how-can-i-send-larger-messages-over-websocket ? When I ws.send("a".repeat(128)) my server says the length is 126. Is this an issue with chrome? No matter what I send my second byte is 11111110 :( – user2118704 Apr 28 '17 at 00:19
  • 126 is a magic value that means "the actual message length was too big to fit into this 7-bit payload length field, so it has been placed in the following two bytes instead". See section 5.2 of https://tools.ietf.org/html/rfc6455 for details. 127 is another magic value that indicates that an 8-byte message length follows. Your server will need to be able to handle both of these cases. – ottomeister Apr 28 '17 at 02:26