websocket: fix parsing of control frames

[tai-kun]

This relates to #2859

Rationale

If a PING frame is received before binary/text frames is received, those data will be dropped.

Message data is decoded to UTF-8 text if the opcode is TEXT, or converted to Blob or ArrayBuffer if it is BINARY. However, the receiver (ByteParser) determines that the opcode of a frame that cannot be fragmented, such as a PING, is the opcode of a potentially fragmented message. And it will not be overturned until a message handler is called. Therefore, by restricting the type of opcode that is set in this.#info.originalOpcode, we ensure that messages are processed accordingly with the appropriate opcode.

Changes

• Restrict the frame type of fragmented messages to be binary or text only.

Features

N/A

Bug Fixes

• WebSocket: message handler sometimes called with null data (potentially issue in frame processing) #2859

Breaking Changes and Deprecations

N/A

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested
• Benchmarked (optional)
• Documented
• Review ready
• In review
• Merge ready

[Uzlopak]

Ok, existing tests are not breaking but can you add a unit test, please?

[tai-kun]

yes. I'll write tests as soon as possible, even though I won't be able to write any code for a while.

[KhafraDev]

I believe my PR should fix this also, but we'd need a test.

[tai-kun]

I have added a test here:
test/websocket/issue-2859.js

Added test is based on test/websocket/fragments.js. In this test, a TEXT frame is sent before sending a PING, so message data was never dropped. Added test reproduces the problem this time by sending a PING first.

Before fixing control frames parsing, the test issue-2859.js fails with an error similar to the following:

✖ Fragmented frame with a ping frame in the first of it (42.77125ms)
  AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
  
  null !== 'Hello'
  
      at <...trace> {
    generatedMessage: true,
    code: 'ERR_ASSERTION',
    actual: null,
    expected: 'Hello',
    operator: 'strictEqual'
  }

[mcollina]

lgtm

[KhafraDev]

This is fixed in #3241 as well, which is a more reliable fix. Thank you for the test, I added it there as well..