Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Improve Error Handling message to become user friendly
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_lists.haxx.se>
Date: Fri, 15 Aug 2025 10:48:24 +0200 (CEST)
On Fri, 15 Aug 2025, cyber security via curl-users wrote:
> └─$ curl https://127.0.0.0.1.1
> curl: (6) Failed to parse the ip 127.0.0.0.1.1 excepted. must have 4 octets
> (e.g, 127.0.0.1).
This is harder than it may seem.
First: an IPv4 address in a URL can be specified using one, two, three or four
numbers (not octets) so the suggested error message is not exactly right.
Then: when the string provided is not a valid IPv4 address (as proposed
above), it is by defintion "a hostname" and that's why it doesn't get reported
as a bad IP address. Let me show you:
$ grep 127.0.0.0.1.1 /etc/hosts
127.0.0.1 127.0.0.0.1.1
$ curl http://127.0.0.0.1.1 -o /dev/null
$ echo $?
$ 0
> └─$ curl -6 http://127.0.0.1
> curl: (7) This not valid IPv6. It seems ipv4 tries to remove -6.
Fair. But remember that you can specify any amount of URLs and they can use
mixed versions:
curl -6 http://127.0.0.1 http://[::1] https://example.com/
... so it can't just error on it. The messaging can however probably be
improved of course.
> improve it to ┌──(relun㉿relunsec)-[~/Test]
> └─$ curl https://httpbin.org --tls-max 1
> curl: option --tls-max: Invalid TLS Version choose from 1.0,1.1,1.2,1.3
> curl: try 'curl --help' or 'curl --manual' for more information
Yep, that would be neat.
> and also you can improve other error messages you can adjust if you would.
There is certainly always room for improvements. Feel free to dig in and help
us!
Date: Fri, 15 Aug 2025 10:48:24 +0200 (CEST)
On Fri, 15 Aug 2025, cyber security via curl-users wrote:
> └─$ curl https://127.0.0.0.1.1
> curl: (6) Failed to parse the ip 127.0.0.0.1.1 excepted. must have 4 octets
> (e.g, 127.0.0.1).
This is harder than it may seem.
First: an IPv4 address in a URL can be specified using one, two, three or four
numbers (not octets) so the suggested error message is not exactly right.
Then: when the string provided is not a valid IPv4 address (as proposed
above), it is by defintion "a hostname" and that's why it doesn't get reported
as a bad IP address. Let me show you:
$ grep 127.0.0.0.1.1 /etc/hosts
127.0.0.1 127.0.0.0.1.1
$ curl http://127.0.0.0.1.1 -o /dev/null
$ echo $?
$ 0
> └─$ curl -6 http://127.0.0.1
> curl: (7) This not valid IPv6. It seems ipv4 tries to remove -6.
Fair. But remember that you can specify any amount of URLs and they can use
mixed versions:
curl -6 http://127.0.0.1 http://[::1] https://example.com/
... so it can't just error on it. The messaging can however probably be
improved of course.
> improve it to ┌──(relun㉿relunsec)-[~/Test]
> └─$ curl https://httpbin.org --tls-max 1
> curl: option --tls-max: Invalid TLS Version choose from 1.0,1.1,1.2,1.3
> curl: try 'curl --help' or 'curl --manual' for more information
Yep, that would be neat.
> and also you can improve other error messages you can adjust if you would.
There is certainly always room for improvements. Feel free to dig in and help
us!
-- / daniel.haxx.se || https://rock-solid.curl.dev
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-08-15