# Empty string for mosquitto\_subscribe **URL:** \ **Category:** MQTT protocol\ **Created:** [July 18, 2022, 12:40pm UTC](https://forum.cedalo.com/t/empty-string-for-mosquitto-subscribe/582 "2022-07-18T12:40:02Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Eugeny](https://avatars.discourse-cdn.com/v4/letter/e/bbce88/32.png) [@Eugeny](https://forum.cedalo.com/u/Eugeny)\ **Post date:** [July 18, 2022, 12:40pm UTC](https://forum.cedalo.com/t/empty-string-for-mosquitto-subscribe/582/1 "2022-07-18T12:40:02Z")
The question has happened because I need to put something into the target topic field which will not match anything. The first and obvious try was giving `mosquitto_subscribe()` an empty string. Server responded with QoS=128 (rejected by broker). But looking into MQTT specification I see > All Topic Names and Topic Filters MUST be at least one character long and it does NOT define client or server behavior if empty string is provided. Do I understand properly that at the protocol and API level the behavior is undefined, and application calling subscription must check for null string before calling? If it is true (by the requirement of the standard) then it is strange because empty string can be checked at all levels - in application, in client code and in server/broker code, and the most correct behavior - from my point of view, is what I observe - server returning error through standard mechanism (callback). Empty string is a valid special case for any string, and it must be explicitly defined in the standard. ---
**Author:** ![roger.light](https://avatars.discourse-cdn.com/v4/letter/r/838e76/32.png) [@roger.light](https://forum.cedalo.com/u/roger.light)\ **Post date:** [July 20, 2022, 3:45pm UTC](https://forum.cedalo.com/t/empty-string-for-mosquitto-subscribe/582/2 "2022-07-20T15:45:15Z")
Hi Eugeny, You are correct to state that topics and topic filters must be at least one character long. On handling errors, the protocol spec states the below: `Unless stated otherwise, if either the Server or Client encounters a protocol violation, it MUST close the Network Connection on which it received that Control Packet which caused the protocol violation` This is clear behaviour, not undefined. That means, in my opinion, that the broker you are using does not comply to the specification. I’ve checked Mosquitto and it disconnects the client as it should be doing. The Mosquitto library should be denying the ability to send subscribe messages with empty strings, I’ve fixed that for future versions. Regards, Roger ---
**Author:** ![Eugeny](https://avatars.discourse-cdn.com/v4/letter/e/bbce88/32.png) [@Eugeny](https://forum.cedalo.com/u/Eugeny)\ **Post date:** [July 20, 2022, 4:55pm UTC](https://forum.cedalo.com/t/empty-string-for-mosquitto-subscribe/582/3 "2022-07-20T16:55:57Z")
Hello Roger, > [@roger.light](#): > > The Mosquitto library should be denying the ability to send subscribe messages with empty strings, I’ve fixed that for future versions. What would be the future behavior? Error code returned - which one? > [@roger.light](#): > > You are correct to state that topics and topic filters must be at least one character long. Can you explain why is this and what is the reason behind. Let me explain the case: my application takes topic name from the config file, and this config file may contain any string, including empty one. Even more, it is logical that empty string for subscription would not subscribe to anything, therefore I just leave string in config file empty if I do not want subscription. The way it works like now with my broker it responds with QoS=128 (subscription failed), but `mosquitto_subscribe()` itself returns success. Why are we limiting client in its subscription freedom while, if server/broker does not support empty string, let it do this way return failed subscription error code, and it will be final response from broker, and not local error code from the library. ---
**Author:** ![roger.light](https://avatars.discourse-cdn.com/v4/letter/r/838e76/32.png) [@roger.light](https://forum.cedalo.com/u/roger.light)\ **Post date:** [July 20, 2022, 5:25pm UTC](https://forum.cedalo.com/t/empty-string-for-mosquitto-subscribe/582/4 "2022-07-20T17:25:03Z")
> [@Eugeny](#): > > Hello Roger, > > > [@roger.light](#): > > > > The Mosquitto library should be denying the ability to send subscribe messages with empty strings, I’ve fixed that for future versions. > > What would be the future behavior? Error code returned - which one? Returning MOSQ\_ERR\_INVAL, to indicate invalid input. > [@Eugeny](#): > > > [@roger.light](#): > > > > You are correct to state that topics and topic filters must be at least one character long. > > Can you explain why is this and what is the reason behind. You’d have to ask the protocol designers for the original reason. I can see that a zero length topic doesn’t make a whole lot of sense though. > [@Eugeny](#): > > Why are we limiting client in its subscription freedom while, if server/broker does not support empty string, let it do this way return failed subscription error code, and it will be final response from broker, and not local error code from the library. The point is that this behaviour is an absolute requirement of the spec. As it stands, the behaviour of mosquitto\_subscribe() in this case is non-compliant with the spec. It must not send subscribe messages with zero length topics. The behaviour of the broker you are using is also non-compliant, it must not accept subscribe messages with zero length topics. Used anywhere else this behaviour will result in the client being disconnected. To write your argument in another way, you’re effectively saying that the way you want to check whether a string is empty or not is to send it as part of a subscribe packet to the broker, have that broker check that it’s empty and deny the subscription request in another network packet to you, which you then have to parse. I’d suggest that using strlen() is more efficient… 🙂 Regards, Roger ---
**Author:** ![Eugeny](https://avatars.discourse-cdn.com/v4/letter/e/bbce88/32.png) [@Eugeny](https://forum.cedalo.com/u/Eugeny)\ **Post date:** [July 20, 2022, 5:30pm UTC](https://forum.cedalo.com/t/empty-string-for-mosquitto-subscribe/582/5 "2022-07-20T17:30:21Z")
> [@roger.light](#): > > deny the subscription request in another network packet to you, which you then have to parse. I’d suggest that using strlen() is more efficient… I the light of the weight of the protocol, this is major reason 👍 I am using [this](https://mosquitto.org/api/files/mosquitto-h.html) as reference, would it be possible to put comment that “sub” can not be an empty string causing this specific behavior you described. ---
**Author:** ![Eugeny](https://avatars.discourse-cdn.com/v4/letter/e/bbce88/32.png) [@Eugeny](https://forum.cedalo.com/u/Eugeny)\ **Post date:** [July 21, 2022, 1:14pm UTC](https://forum.cedalo.com/t/empty-string-for-mosquitto-subscribe/582/6 "2022-07-21T13:14:26Z")
Roger, I am kind of surprised not to see this zero string limitation for the publishing. What do you think? Seems to be valid to publish into the topic identified by the empty string! ---
**Author:** ![roger.light](https://avatars.discourse-cdn.com/v4/letter/r/838e76/32.png) [@roger.light](https://forum.cedalo.com/u/roger.light)\ **Post date:** [July 21, 2022, 4:12pm UTC](https://forum.cedalo.com/t/empty-string-for-mosquitto-subscribe/582/7 "2022-07-21T16:12:44Z")
I’m going to keep on saying this 🙂 Topics cannot be zero length. If you have a broker that accepts this, they do not comply with the MQTT protocol. If your client allows you to send zero length topics, they do not comply with the MQTT protocol. If this is code you’ve written yourself, you should fix it. If it’s code from other people, you should tell them. There is a _slight_ caveat to that. In MQTT v5.0, it is possible to set up topic aliases. This means on publish number one, you include your topic and an alias integer. Say `topic='Eugeny'`, `alias=1`. On subsequent publishes, you can set topic to be an empty string as long as you also provide the alias, so `topic=''` and `alias=1`. This is _not_ publishing to an empty topic - the broker will use the previously defined topic for that alias, so `Eugeny`. If you publish a zero length topic without an alias, that is a protocol error and your client must be disconnected. If you publish with a zero length topic with an alias that hasn’t been previously defined, that is also a protocol error. Cheers, Roger