New issue
Advanced search Search tips

Issue 863465 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 14
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Sec-WebSocket-Extensions not respected

Reported by tomab...@gmail.com, Jul 13

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

Steps to reproduce the problem:
1. connect to a WebSocket server that responds without the 'Sec-WebSocket-Extensions' header (IE rejecting any Extensions)
2. Send a text-only message of 130kb or larger
3. See that first byte in the socket frame is invalid. In my experiences, the first byte is a Unicode Header (\u0001) and followed by a 255 byte (0xFF)

What is the expected behavior?
Socket Frame should well-formed.

What went wrong?
The Socket frame appears to be coming back as an encoded frame of some sort.

Attached is a buffer example (should be ~130kb of "0") captured with NodeJS (so it is a Uint8Array)

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 67.0.3396.99  Channel: stable
OS Version: OS X 10.13.5
Flash Version: 

This appears to work as expected in Safari and Firefox
 
invalid-buffer.json
224 KB View Download
Components: Blink>Network>WebSockets
Status: WontFix (was: Unconfirmed)
The attached WebSocket frame appears completely correct by RFC6455 section 5.2: https://tools.ietf.org/html/rfc6455#page-28

It has opcode 1 (text). None of the reserved bits are set, indicating that no extensions are in use. The FIN bit is not set, indicating that this is not the final frame in the message. The frame length is 131061 bytes. The MASK bit is set, as required for a client frame. The mask is [147,205,57,141]. The rest of the frame consists of the byte 0x30 (ASCII "0") repeated, masked by the mask.

The frame sent by Safari and Firefox should be similar, except as far as I know they always send each message as a single frame, so the length will be longer and the FIN bit will be set.

Closing the issue as everything appears to be working as expected.
Sorry for the inaccurate bug, but thank you for the quick and thorough response. I realize now that my Socket server was not padding bytes correctly when reading them.

Sign in to add a comment