WebSocket RFC 6455 section 5.1 implementation?
Categories
(Core :: Networking, defect)
Tracking
()
People
(Reporter: mozilla, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0
Steps to reproduce:
Does Firefox support RFC 6455 section 5.1 stating that "a server MUST NOT mask any frames that it sends to the client. A client MUST close a connection if it detects a masked frame" ? https://www.rfc-editor.org/rfc/rfc6455#section-5.1
It looks like the RFC is implemented in reverse?
Actual results:
After connecting to a simple PHP WSS server script, I've tried to send a message like this to Firefox:
0x80 0x03 0x48 0x69 0x21 (which should translate to [FINAL FRAME WITHOUT A MASK] / [LENGTH OF 3 BYTES] / PAYLOAD "H", "i", "!")
Firefox immediately closes the connection and the console shows: The connection to wss://whatever:8888/ was interrupted while the page was loading. Code = 1006, Reason = ""
But if I add the masking bit (EVEN THOUGH I do NOT actually add the 4 masking-key bytes after the payload) and redo the test, so with:
0x81 0x03 0x48 0x69 0x21
Then Firefox is happy, receives the proper "Hi!" message and does not disconnect. I can continue to send messages back and forth and it keeps alive as normal.
Further more, I could not send a payload larger than 65535 bytes as Firefox would again close the connection with an error code of 1006 and no reason. RFC 6455 Section 5.2 describes that the payload length (0x03 in the example above) can extend to 7+64 bits when the payload exceeds 65535 bytes in size. This does not seem to be supported by Firefox either.
Expected results:
Is it me or the RFC 6455 Section 5 is implemented in reverse and it's missing some stuff?
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Note that I was finally able to send a payload larger than 65535. The length bytes need to be in reverse order, so this can be ruled out, but the mask bit issue still remains. Why is it that Firefox expects the 9th bit to be on when RFC says that the server should never enable the mask bit?
I had all the bits shifted 1 position too far. Sorry for the inconvenience, this can be closed! facepalm
Description
•