Open Bug 1572025 Opened 5 years ago Updated 2 years ago

Support for WebSocket frame payload binary type

Categories

(DevTools :: Netmonitor, enhancement, P3)

70 Branch
enhancement

Tracking

(Not tracked)

People

(Reporter: tanhengyeow, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36

Steps to reproduce:

  1. Go to this test site and press Connect.
  2. Open Netmonitor > Click on request > Click on Messages panel.
  3. Send the message via Send Blob/Send Array Buffer/Send ByteBuffer.

Actual results:

The payload is observed in the Messages panel as a String.

Expected results:

In nsIWebSocketListener.idl, the frame payload is defined to be of type ACString.

It would be nice if the payload returned is in the form of its corresponding binary type. This would support Bug 1555641 as DevTools can check the payload's binary type and parse its result correctly to the user.

Two thoughts here:

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3

Andrea, what is the proper way to check whether WS frame payload is text or binary?

  • Do we have an access to WebSocket.binaryType or this is only accessible by JS on the (content) page?
  • Should we just check the frame.opCode == nsIWebSocketFrame.OPCODE_BINARY?

Also, how should we properly read the binary data from frame.payload?
We want to see the raw bytes and convert it to Base64 & UTF-8.

Honza

Flags: needinfo?(amarchesini)

Looking at WS on https://send.firefox.com/ , it uses both text and binary messages, so we need to determine type per message, using opcode.

Flags: needinfo?(amarchesini)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.