websocket "Invalid Frame Header"
Reported by
anth...@two-bulls.com,
Sep 16 2016
|
||
Issue description
Chrome Version : Version 53.0.2785.116 (64-bit)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari:
Firefox: OK
IE:
What steps will reproduce the problem?
(1) Send a websocket packet from the server to the browser. The length
is 8000 bytes (of text). Encode the length using the 64-bit length
variant.
(2)
(3)
What is the expected result?
The packet should be accepted by the browser.
What happens instead?
The websocket object reports an error (via the onerror handler) with
the message Invalid Frame Header.
Encoding with the 16 bit length variant works.
Please provide any additional information below. Attach a screenshot if
possible.
This header is accepted by both Firefox and Wireshark.
,
Dec 14 2016
See https://tools.ietf.org/html/rfc6455#section-5.2 > Note that > in all cases, the minimal number of bytes MUST be used to encode > the length, for example, the length of a 124-byte-long string > can't be encoded as the sequence 126, 0, 124. For 8000, the 2 byte long extended payload length field must be used. Though there's no explicit word in the spec requiring failing of the connection, we'd like to have Chromium reject such frames to conform to this text. |
||
►
Sign in to add a comment |
||
Comment 1 by tkent@chromium.org
, Dec 9 2016