MQTT: Unexpected handling of multi-level wildcard ("#")

[koernepr]

I did this

Try to do an MQTT subscribe using the multi-level wildcard (#):

$ curl --no-buffer --output - 'mqtt://localhost/#'
curl: (3) Error: No topic specified.

I expected the following

curl subscribing using the multi-level wildcard (#) instead of dropping the hash character. For comparison, using the single-level wildcard (+), subscribing works as expected.

Workaround: Percent-encode the wildcard (i.e. mqtt://localhost/%23).

curl/libcurl version

$ curl -V
curl 7.77.0 (x86_64-alpine-linux-musl) libcurl/7.77.0 OpenSSL/1.1.1k zlib/1.2.11 brotli/1.0.9 nghttp2/1.43.0
Release-Date: 2021-05-26
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL TLS-SRP UnixSockets

operating system

Alpine Linux 3.14.0

$ uname -a
Linux 41f387d260bf 5.8.0-59-generic #66-Ubuntu SMP Thu Jun 17 00:46:01 UTC 2021 x86_64 Linux

[bagder]

A stand-alone # letter in a URL signifies a divider for the fragment part. It is therefor not a "work-around" when you use %23 to pass on a # as data. It's how it needs to be done!

[koernepr]

Hm ... you're right of course; somehow I connected dropping the fragment part with HTTP usage only 🤦

Could you then maybe amend the error message ("...; did you forget to percent-encode a hash character?") or add a specific one for this case?

[bagder]

The PR #7317 now makes it say:

No MQTT topic found. Forgot to URL encode it?

[koernepr]

@bagder Thank you for the quick fix.

There's another, non-minimal, case where this is an issue, and actually more subtle - when the topic consists of more than the wildcard:

$ curl --no-buffer --output - 'mqtt://localhost/foo/#'

In this case, curl will subscribe to foo/, i.e. there will be no error message, but it will obviously receive fewer messages than expected if you intended to subscribe to the whole subtree.

Thus, could you also add a warning for this case with reasonable effort? At least in verbose mode to help with debugging if you think it's too much otherwise? ... or could/should there rather be a generic warning for all protocols maybe, in case there is a fragment part and it's being dropped?