MQTT: Output of received messages always contains variable header. Results in binary output warning.

[schicho]

The current state

I have recently started to use curl for some simple MQTT. Mostly to test out some things.

There I have noticed that receiving messages on subscribed topics always errors with the binary output warning.

./curl mqtt://localhost:1883/temp -N 
Warning: Binary output can mess up your terminal. Use "--output -" to tell 
Warning: curl to output it to your terminal anyway, or consider "--output 
Warning: <FILE>" to save to a file.

Printing to a file reveals that the variable header is always contained in the direct output, which is a two byte value specifying the topic lenght, followed by the topic name. (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718013 Chapter 3.3.2)

In our case that is
00 04 74 65 6D 70 i.e. ..temp in a hex editor

I was wondering if this is a sensible approach and if a change regarding this would be of interest?

Proposed change

The documentation describes the above observation that the response curl delivers will be the topic length, topic and the payload (https://curl.se/docs/mqtt.html).

Given a significantly short topic, which may mostly be the case, using curl to test MQTT operation is not possible as one may expect, like when testing a REST API with curl.

Can we break the current implementation of the output and leave the header value hidden behind a -v flag like with HTTP?
Instead only outputting the payload of the message.

[bagder]

Can we break the current implementation of the output and leave the header value hidden behind a -v flag like with HTTP?

While a behavior change I think we should seriously consider it, yes. It will probably make mqtt more useful.

The question is how to deal with binary data, especially null bytes.