opcodes are incorrect about websocket-monitor

[tdhsmith]

Here's a quick demonstration server in NodeJS, if that helps. Sorry for the messy code; threw it together on lunch break.

https://gist.github.com/tdhsmith/8e71aba02c684f549cdec05761e6e87b

You'll need to install ws first. Run the server with node server.js then browse to http://localhost:3000/ and the browser and client will each send a variety of frame types.

Here's what I see:

Server

-> TEXT         (0x1); MASKED
-> BINARY       (0x2); MASKED
<- BINARY       (0x2); unmasked
<- PING         (0x9); unmasked
<- PONG         (0xA); unmasked
<- TEXT         (0x1); unmasked
<- CONTINUATION (0x0); unmasked
<- CLOSE        (0x8)
-> PONG         (0xA); MASKED
-> CLOSE        (0x8)

(note that the ordering of the last few is off slightly due to when I'm calling the log commands relative to the actual message queue)

WireShark

Raw capture file is available in the gist above.

websocket-monitor

[tdhsmith]

Actually I'm just realizing the inaccuracies are a bit larger than that:

• all frames are marked as having maskBit=true when they aren't (in my case messages from the server are being sent unmasked)
• disconnect frame is displayed as raw text with the reason code appended to the front. For example �ëonly text frames are supported, where the gibberish 0x03eb on the front should be parsed as reason code=1003.

(I don't have the capability right now to modify my stack to send true continuation frames with finBit=0, so I can't verify if the finBit is parsing correctly or not.)

[eliihen]

Yeah, the entire frame, including the metadata like opcode, comes from the Firefox API we're using to read websockets. We pretty much only map that to a string. I can't really give any info on the Firefox API because I haven't been that deep.

Let's try pinging @bakulf, he seems knowledgeable on the matter.

[bakulf]

Can I have a testcase? I would like to test it locally. @esphen, thanks.