Autobahn test 6.4.3 does not look right

#1

I’m working on a C++ implementation of websockets that is modeled after the boost::asio interfaces. I’m trying to get the Autobahn tests to pass (which is a wonderful software package by the way). I have concerns about test 6.4.3 “UTF8 Handling: Fail-fast on invalid UTF-8”

This is what the Autobahn fuzzingclient does:

  1. Send frame header, payload len = 21

  2. Send 11 bytes of payload

  3. Send 4 bytes of payload

  4. Receive close frame

  5. Send close frame

  6. Send remaining 6 bytes of payload

Other implementations pass this test, presumably by expecting the close from 5 right away instead of eating up the 6 bytes remaining in the frame payload. For example, websocketpp passes the test. You can see the last 6 payload bytes getting sent after the close (Line 11 in Wire Log):
http://autobahn.websocketpp.org/servers/websocket___0_5_1_permessagedeflate_case_6_4_3.html

On my server I see these steps take place:

  1. Receive frame header, payload len = 21

  2. Receive 11 bytes of payload

  3. Receive 4 bytes of payload, utf8-check failure

  4. Send close frame

  5. Receive close frame

Here’s where I think there’s an issue. Passing the test means that the other end has to send a close message in the middle of a frame payload? And the server has to assume that the last 6 bytes of the expected frame payload are not going to be received? That can’t be right. TCP/IP offers no guarantee in what group bytes arrive at their destination other than they are ordered correctly. For all the server knows, in step 5 when it is expecting a close frame those last 6 payload bytes could arrive late. And now the frame stream is desynced, with no way to do a clean shutdown.

It seems one of three statements must be true:

  1. The Autobahn test is wrong. It should never start a new frame while there are still payload bytes remaining in the current frame

  2. There’s a flaw in the WebSocket specification where proper close handling could leave the frame stream desynced depending on network conditions.

  3. I simply don’t understand how this thing works and there’s something obvious I’m missing.

Please advise!

0 Likes

#2

This issue has been resolved, the answer is in rfc6455 section 8.1 and section 7.1.7.

The question was answered here:
https://github.com/crossbario/autobahn-testsuite/issues/1

···

On Wednesday, March 23, 2016 at 7:38:01 PM UTC-4, Vinnie Falco wrote:

I’m working on a C++ implementation of websockets that is modeled after the boost::asio interfaces. I’m trying to get the Autobahn tests to pass (which is a wonderful software package by the way). I have concerns about test 6.4.3 “UTF8 Handling: Fail-fast on invalid UTF-8”

0 Likes