curl deals in URLs and URLs don't allow spaces, so if they're allowed, spaces must be % encoded. However, RFC2229 doesn't define a URL format for sending the SHOW DB command. If it worked in curl in the past, it was a happy accident.

Don't agree here, and I was afraid for this answer:

• Curl implements the "dict" protocol.
• So dict is a separate protocol, the RFC says "SHOW DB", so this is what it should be no encoding.
• You can easily skip the space test if the protocol is "dict"

What I meant was that the dict protocol is supported by curl.
The "SHOW DB" command is, and many others commands are client side commands according to the RFC.
Indeed command approach seems more like a sendmail command exchange, and is called a "command pipeline".
So by enforcing the "space" as "%20" curl no longer allows a large part of the dict commands. So this means curl no longer supports the full dict protocol. You should mention this in your documentation and show in the --version output that dict protocol is only partial. Or you can make an exception and allow the subset of commands in RFC2229.

Mind you, there is a undocumented feature which allows the commands (which I didn't know before). Which is to replace "<space>" with ":" e.g.:

 $ curl dict://dict.org/SHOW:DB 2>/dev/null | head -n 5
 220 dict.dict.org dictd 1.12.1/rf on Linux 4.19.0-10-amd64 <auth.mime> <163757157.16019.1673978319@dict.dict.org>
 250 ok
 110 166 databases present
 gcide "The Collaborative International Dictionary of English v.0.48"
 wn "WordNet (r) 3.0 (2006)" 

For me this workaround is good enough. But for 'curl' I think you should choose between the above two options.
If you want to ignore this issue (third option), at least the workaround is documented 🙂. If you choose for the third option closing this issue is fine by me.

Perhaps it might make sense to have curl have an option to translate %20 to a in the URL. So something along the lines of:

curl --space-url "dict://dict.org/SHOW%20DB"

would result in a URL "dict://dict.org/SHOW DB" internally, assuming the internal URL parse won't have an issue with that.

A new option really isn't necessary. If we decide to preserve the old behaviour, then curl can just decode the URL path itself before sending it to the server. It's just that this isn't a valid dict URL so all bets are off in how it's handled.

I guess it's too big a deal to ask all of the Dict server project to fix their URLs to conform to modern URL rules. :(

The fact that curl doesn't URL decode the path when using it for DICT looks like a bug to me.

I was thinking about this and, from a curl perspective doing this with curl -X 'show db' dict://dict.org/ is probably the cleanest. -X is there to modify the request that would normally be sent which is basically what's desired here. But, are you saying that people are handing out dict urls in the wild like dict://dict.org/show db?

I was thinking about this and, from a curl perspective doing this with curl -X 'show db' dict://dict.org/ is probably the cleanest. -X is there to modify the request that would normally be sent which is basically what's desired here. But, are you saying that people are handing out dict urls in the wild like dict://dict.org/show db?

I personally wonder how many software products could handle the embedded space cleanly in a URL. Probably nothing in the Office suite or browsers.

From my view it is not actually a question specifically about space or %20, but about treating URL encoded paths correctly in general for DICT:

As described above, this command line and URL work: curl 'DICT://dict.org/SHOW:DB'

As per how URLs works, we should then be able to also pass this with parts of the path URL-encoded, like if we encode the colon as %3a: curl 'DICT://dict.org/SHOW%3aDB'. This does not work. Replace the S with %53:

curl 'DICT://dict.org/%53HOW:DB' - does not work either. I say this is a bug.