hivemq-mqtt-client icon indicating copy to clipboard operation
hivemq-mqtt-client copied to clipboard

Java API unexpected disconnect: malformed topic

Open aaron-613 opened this issue 3 years ago • 3 comments

Hello there!

Using the Hive Java API (both v3 and v5) to connect to brokers where I don't control the topic space, occasionally I receive messages that are published to topics that the API considers bad: e.g. topics with wildcards + and #. The API abruptly disconnects without any obvious warning message. I had to use Eclipse IDE thrown exception breakpoints to try to find out what was happening internally, and then also eventually figured out that I could put a disconnect listener in to see the error message:

com.hivemq.client.mqtt.mqtt5.exceptions.Mqtt5DisconnectException: Exception while decoding PUBLISH: malformed topic

No indication of what the topic was. Through some trial-and-error I figured out it was wildcard chars. Strange, your JavaScript ~~API~~ Client (https://www.hivemq.com/demos/websocket-client/) is much more capable at dealing with unexpected characters, it happily receives PUBLISH messages with + and # chars in the topic, no sweat.

image

Hopefully you can relax parsing rules to make the Java API more tolerant. Even though it's written in the MQTT spec [MQTT-3.3.2-2] that wildcard chars shouldn't be there, sometimes we run into this "in the wild" and ideally your API should be able to cope and stay online. And also/either log what the invalid topic was, and/or stay online and ignore it instead of just dying.

Thanks very much!

aaron-613 avatar Dec 05 '21 15:12 aaron-613

Hi @aaron-613 As you already said, this is a requirement of the MQTT specification:

The Topic Name in the PUBLISH Packet MUST NOT contain wildcard characters [MQTT-3.3.2-2].

MQTT is a standard which allows different devices/things/machines to communicate with each other. This only works if all implementations obey to the rules of the specification. As this rule is a "MUST" requirement, no implementation must violate it, otherwise it is not conform to the MQTT specification. This means, you should raise a bug at the broker you are using, as an MQTT broker must never accept malformed topics from publishers and also not send malformed topics to subscribers then.

SgtSilvio avatar Dec 14 '21 09:12 SgtSilvio

Hi @SgtSilvio... thanks for the response. While I agree with the spec, I also think it's not the API's responsibility to enforce it... it should be left to the broker. There are multi-protocol message brokers (e.g. Solace) that support MQTT as one of many protocols, where having # and + in the topic string is perfectly valid.

This is the first API that I've seen that strongly enforces this requirement. As I said, even the Hive JavaScript ~~API~~ Client https://www.hivemq.com/demos/websocket-client/ is tolerant. As are all other MQTT APIs that I've used.

Thanks!

aaron-613 avatar Dec 17 '21 22:12 aaron-613

Both of you make a good argument. At a minimum, the client could be strict by default with an option to disable topic name validation.

I'll mark this as a feature request to be considered in a future release. Thanks for filing @aaron-613!

pglombardo avatar Nov 21 '22 09:11 pglombardo