Case Description

Same as Case 6.4.1, but we send message not in 3 frames, but in 3 chops of the same message frame.

MESSAGE PARTS:
PART1 = cebae1bdb9cf83cebcceb5
PART2 = f4908080
PART3 = 656469746564

Case Expectation

The first chop is accepted, we expect to timeout on the first wait. The 2nd chop should be rejected immediately (fail fast on UTF-8). If we timeout, we expect the connection is failed at least then, since the complete message payload is not valid UTF-8.

Case Outcome

Actual events differ from any expected.

Expected:
{'OK': [('timeout', 'A')], 'NON-STRICT': [('timeout', 'A'), ('timeout', 'B')]}

Observed:
[('timeout', 'A'), ('timeout', 'B'), ('message', u'\u03ba\u1f79\u03c3\u03bc\u03b5\ufffdedited', False)]

Case Closing Behavior

The connection was failed by the wrong endpoint (FAILED)

Opening Handshake

Closing Behavior

Wire Statistics

Octets Received by Chop Size

Octets Transmitted by Chop Size

Frames Received by Opcode

Frames Transmitted by Opcode

Wire Log

000 TX OCTETS: 474554202f20485454502f312e310d0a557365722d4167656e743a204175746f6261686e5465737453756974652f302e382e

               302d302e31302e390d0a486f7374 ...

001 RX OCTETS: 485454502f312e312031303120576562536f636b65742050726f746f636f6c2048616e647368616b650d0a55706772616465

               3a20576562536f636b65740d0a43 ...

002 TX OCTETS: 0195abac4aa0

003 TX OCTETS: 6516ab1d1263c96e1762ff

004 DELAY 1.000000 sec for TAG A

005 DELAY TIMEOUT on TAG A

006 TX OCTETS: 543b2cca

007 DELAY 1.000000 sec for TAG B

008 DELAY TIMEOUT on TAG B

009 TX OCTETS: c5cfc53ec5cf

010 TX FRAME : OPCODE=0, FIN=True, RSV=0, PAYLOAD-LEN=0, MASK=7a7646ef, PAYLOAD-REPEAT-LEN=None, CHOPSIZE=None, SYNC=False

011 TX OCTETS: 80807a7646ef

012 FAIL CONNECTION AFTER 1.000000 sec

013 RX OCTETS: 8114cebae1bdb9cf83cebcceb5efbfbd656469746564

014 RX FRAME : OPCODE=1, FIN=True, RSV=0, PAYLOAD-LEN=20, MASKED=False, MASK=None

               κόσμε�edited

015 FAILING CONNECTION

016 TX FRAME : OPCODE=8, FIN=True, RSV=0, PAYLOAD-LEN=12, MASK=9b4d5c3a, PAYLOAD-REPEAT-LEN=None, CHOPSIZE=None, SYNC=False

               0x03e9476f696e672041776179

017 TX OCTETS: 888c9b4d5c3a98a41b55f2233b1ada3a3d43

018 RX OCTETS: 810e03efbfbd476f696e672041776179

019 RX FRAME : OPCODE=1, FIN=True, RSV=0, PAYLOAD-LEN=0, MASKED=False, MASK=None

020 TCP DROPPED BY ME

Key	Value	Description
isServer	False	True, iff I (the fuzzer) am a server, and the peer is a client.
closedByMe	True	True, iff I have initiated closing handshake (that is, did send close first).
failedByMe	True	True, iff I have failed the WS connection (i.e. due to protocol error). Failing can be either by initiating closing handshake or brutal drop TCP.
droppedByMe	True	True, iff I dropped the TCP connection.
wasClean	False	True, iff full WebSocket closing handshake was performed (close frame sent and received) _and_ the server dropped the TCP (which is its responsibility).
wasNotCleanReason	peer did not respond (in time) in closing handshake	When wasClean == False, the reason what happened.
wasServerConnectionDropTimeout	False	When we are a client, and we expected the server to drop the TCP, but that didn't happen in time, this gets True.
wasOpenHandshakeTimeout	False	When performing the opening handshake, but the peer did not finish in time, this gets True.
wasCloseHandshakeTimeout	True	When we initiated a closing handshake, but the peer did not respond in time, this gets True.
localCloseCode	1001	The close code I sent in close frame (if any).
localCloseReason	Going Away	The close reason I sent in close frame (if any).
remoteCloseCode	None	The close code the peer sent me in close frame (if any).
remoteCloseReason	None	The close reason the peer sent me in close frame (if any).

Chop Size	Count	Octets
16	1	16
22	1	22
138	1	138
Total	3	176

Chop Size	Count	Octets
4	1	4
6	3	18
11	1	11
18	1	18
240	1	240
Total	7	291

Opcode	Count
1	2
Total	2

Opcode	Count
0	1
8	1
Total	2