Bridge connection to public broker fails because of invalid UTF-8 topic names

[krismattheus]

When testing our mosquitto broker to make a bridge connection to the iot.eclipse.org mosquitto broker, the bridge connection is established but within the same second it's disconnected again.
This only happens when the configuration of our bridge contains:

topic # both 0

When a specific topic is used, the bridge connection remains established.

After some debugging I found that the iot.eclipse.org mosquitto broker contains topics with invalid UTF-8 names (for example 'ÿ' with only one byte = 0xFF). Apparently, a disconnect is forced in handle_publish.c when a PUBLISH message contains an invalid UTF-8 topic.

mosquitto/src/handle_publish.c

Lines 72 to 75 in 19fbbd8

	if(mosquitto_validate_utf8(topic, slen) != MOSQ_ERR_SUCCESS){
	mosquitto__free(topic);
	return 1;
	}

I think it would be better to just ignore such a topic and continue with the next PUBLISH messages.

Maybe the code in handle_publish.c should be changed to:

if(mosquitto_validate_utf8(topic, slen) != MOSQ_ERR_SUCCESS){
    log__printf(NULL, MOSQ_LOG_INFO, "Dropped PUBLISH from %s because non UTF-8 topic (d%d, q%d, r%d, m%d, '%s')", context->id, dup, qos, retain, mid, topic);
    goto process_bad_message;
}

We use mosquitto version 1.5.5.
The test was done on Windows 10.

[ralight]

The MQTT spec is pretty clear on the required behaviour here.

If a Server or Client receives a Control Packet containing ill-formed UTF-8 it MUST close the Network Connection [MQTT-1.4.0-1].

The issue at hand is that iot.eclipse.org isn't kept up to date, and so isn't validating UTF-8 strings. It is worth noting that the test server at iot.eclipse.org is going to disappear soon: https://bugs.eclipse.org/bugs/show_bug.cgi?id=541419

[krismattheus]

OK. I understand.
However, It would we good to log a message why the connection is closed.
Or at least return MOSQ_ERR_MALFORMED_UTF8 instead of 1 when the topic is invalid UTF-8.
This would greatly simplify diagnosing such a problem.

[ralight]

@krismattheus Agreed, I've just added in a new log message to cover this case.