Buy commercial curl support from WolfSSL. 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
himself.
Re: show the URL in the error message?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dan Fandrich via curl-users <curl-users_at_cool.haxx.se>
Date: Sun, 15 Nov 2020 18:37:06 -0800
On Sun, Nov 15, 2020 at 11:19:23PM +0000, Jeremy Nicoll via curl-users wrote:
> On Sun, 15 Nov 2020, at 22:39, Daniel Stenberg via curl-users wrote:
> > One way to fix this issue, is to include the used URL in the error message,
> > which is what my current PR does [2].
> If anyone currently parses error messages that might cause some grief.
I don't think curl has ever made any guarantees that verbose logs or error
message text will never change. This is a risk that applications that parse
these messages are taking. There are ways that most applications can get more
fine-grained data (e.g., one of the 99 different error codes, one
of the 27 different callback functions or one of the 66 different CURLINFO
values). If there's a need for even finer monitoring than that, then a more
robust means of getting that data should be specified instead of freezing
what's meant to be human-readable messages.
Dan
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-11-16
Date: Sun, 15 Nov 2020 18:37:06 -0800
On Sun, Nov 15, 2020 at 11:19:23PM +0000, Jeremy Nicoll via curl-users wrote:
> On Sun, 15 Nov 2020, at 22:39, Daniel Stenberg via curl-users wrote:
> > One way to fix this issue, is to include the used URL in the error message,
> > which is what my current PR does [2].
> If anyone currently parses error messages that might cause some grief.
I don't think curl has ever made any guarantees that verbose logs or error
message text will never change. This is a risk that applications that parse
these messages are taking. There are ways that most applications can get more
fine-grained data (e.g., one of the 99 different error codes, one
of the 27 different callback functions or one of the 66 different CURLINFO
values). If there's a need for even finer monitoring than that, then a more
robust means of getting that data should be specified instead of freezing
what's meant to be human-readable messages.
Dan
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-11-16