Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
koernepr opened this issue Jun 29, 2021 · 4 comments
Closed

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

koernepr opened this issue Jun 29, 2021 · 4 comments
Labels
MQTT URL

Comments

@koernepr
Copy link

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
Copy link
Member

bagder commented Jun 29, 2021

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
Copy link
Author

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 added a commit that referenced this issue Jun 30, 2021
@bagder
mqtt: extend the error message for no topic
545074a 
... and mention that it needs URL encoding.

Reported-by: Peter Körner
Fixes #7316
@bagder bagder mentioned this issue Jun 30, 2021
Closed
@bagder
Copy link
Member

bagder commented Jun 30, 2021

The PR #7317 now makes it say:

No MQTT topic found. Forgot to URL encode it?

@bagder bagder closed this as completed in 5372ee3 Jun 30, 2021
@koernepr
Copy link
Author

koernepr commented Jul 1, 2021

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
MQTT URL
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

mqtt: extend the error message for no topic curl/curl
2 participants
@bagder @koernepr