WebSocket transport accepts text data frames as MQTT bytes

Start in src/io/tokio_ws.rs around the receive-side Message::Binary and Message::Text branches. Verify the reproduction with an MQTT-over-WebSocket connection and confirm that binary frames still reach the MQTT decoder while text frames close the network connection. Done means text data is rejected without changing handling for binary, Ping, Pong, or Close frames.

Description

The MQTT-over-WebSocket receive adapter accepts WebSocket text data frames and feeds their UTF-8 bytes into the MQTT decoder instead of closing the network connection.

The binary and text branches currently differ only in how their payload becomes Bytes:

https://github.com/microsoft/rust-mqtt-client/blob/e2df553b4ee0bc7f2d7b45175ef9bfe600a8424d/src/io/tokio_ws.rs#L150-L156

Message::Binary(next_read) => self.next_read = next_read,
Message::Text(next_read) => self.next_read = next_read.into(),

The public client API does not expose WebSocket frame selection, and the write side correctly sends MQTT data as binary:

https://github.com/microsoft/rust-mqtt-client/blob/e2df553b4ee0bc7f2d7b45175ef9bfe600a8424d/src/io/tokio_ws.rs#L208-L216

This is therefore a receive-side validation bug, not an outgoing framing or payload data-loss bug.

Reproduction

1. Establish an MQTT-over-WebSocket connection using the mqtt WebSocket subprotocol.

2. Have the server send bytes for a valid MQTT packet in a WebSocket text data frame. For example, this valid MQTT 5 QoS 0 PUBLISH to topic a with no payload is also valid UTF-8 byte data:

   30 04 00 01 61 00
   

3. Observe that the adapter exposes those bytes to the MQTT reader and the packet can be processed.

The connection should instead be closed as soon as the text data frame is received, regardless of whether its bytes happen to form a valid MQTT packet.

Expected behavior

Accept WebSocket binary data frames as the MQTT byte stream. On receipt of a WebSocket text data frame, terminate the network connection rather than forwarding its contents to the MQTT decoder.

WebSocket Ping, Pong, and Close are control frames, not alternative data-frame types, and are outside this rejection rule.

MQTT 5.0 [MQTT-6.0.0-1] states:

MQTT Control Packets MUST be sent in WebSocket binary data frames. If any other type of data frame is received the recipient MUST close the Network Connection.

Specification: https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html

Audited revision

e2df553b4ee0bc7f2d7b45175ef9bfe600a8424d