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: Jeremy Nicoll via curl-users <curl-users_at_cool.haxx.se>
Date: Mon, 16 Nov 2020 12:14:40 +0000
On Mon, 16 Nov 2020, at 02:37, Dan Fandrich via curl-users wrote:
> 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.
Sure, I understand that. But curl is more or less by definition a tool for
scripts to use, and thus you have to expect that its messages may be
redirected somewhere and post-processed.
> 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).
And which of those will contain the error URL?
> 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.
/Are/ they meant only to be human-readable?
There's clearly a point when a programmer needs to consider whether it's
more sensible to make a minor change to an existing message, or to
produce a new message.
Date: Mon, 16 Nov 2020 12:14:40 +0000
On Mon, 16 Nov 2020, at 02:37, Dan Fandrich via curl-users wrote:
> 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.
Sure, I understand that. But curl is more or less by definition a tool for
scripts to use, and thus you have to expect that its messages may be
redirected somewhere and post-processed.
> 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).
And which of those will contain the error URL?
> 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.
/Are/ they meant only to be human-readable?
There's clearly a point when a programmer needs to consider whether it's
more sensible to make a minor change to an existing message, or to
produce a new message.
-- Jeremy Nicoll - my opinions are my own. ----------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2020-11-16