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: Sun, 15 Nov 2020 23:19:23 +0000
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 know if such messages start with a message-id/error number or
something? I used to work on IBM mainframe automation, where the
first token in many thousands of different messages was a message id,
and much of the automation basically monitored [virtual] consoles and
when a message starting with a documented id was issued by something
(OS or application program) some code would run to parse it and decide
what to do, if anything. For example
IEC150I 913-38,IFG0194F,COPYTAP,STEP1,TAPOUT,480,,BAK.INPUT.TXT
(The "IEC" bit tells you which part of the OS produced this message, the
150 is just a number, and the trailing "I" in the message id means this is
an information message.)
In this case this is the OS telling anyone who cares that "COPYTAP" was
refused access to a file, by the OS. But the point is that that layout of the
message is documented. In fact it has many different sub layouts, which
depend on the "913-38" at the start, but they are all documented too...
If a new release of the OS wanted to change the fundamental layout of
the msg it would be a show-stopper (until a site had checked that none
of their ops automation etc would be affected) in an OS upgrade. It'd be
unlikely to happen though.
More likely is that there'd be new (or many new) "nnn-nn" values added.
> A. Should we really add the URL in all error messages unconditionally?
> (Consistency could be one reason to favor it.)
Ah - that'd potentially affect every program that parses the existing
message layouts...
> B. Should we add a new option for this, that enables it by default for
> parallel mode and is disabled by default otherwise?
I would create a new message, so that - hopefully - any code [written
carefully at present] would skip it. You'd have to hope that no-one's
stupid enough to assume that if there's an error message of one type
then (say) the 17th line after it contains some vital information, without
looking at the contents of the intervening lines, and thus would already
be skipping lines that don't mean anything to them.
Date: Sun, 15 Nov 2020 23:19:23 +0000
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 know if such messages start with a message-id/error number or
something? I used to work on IBM mainframe automation, where the
first token in many thousands of different messages was a message id,
and much of the automation basically monitored [virtual] consoles and
when a message starting with a documented id was issued by something
(OS or application program) some code would run to parse it and decide
what to do, if anything. For example
IEC150I 913-38,IFG0194F,COPYTAP,STEP1,TAPOUT,480,,BAK.INPUT.TXT
(The "IEC" bit tells you which part of the OS produced this message, the
150 is just a number, and the trailing "I" in the message id means this is
an information message.)
In this case this is the OS telling anyone who cares that "COPYTAP" was
refused access to a file, by the OS. But the point is that that layout of the
message is documented. In fact it has many different sub layouts, which
depend on the "913-38" at the start, but they are all documented too...
If a new release of the OS wanted to change the fundamental layout of
the msg it would be a show-stopper (until a site had checked that none
of their ops automation etc would be affected) in an OS upgrade. It'd be
unlikely to happen though.
More likely is that there'd be new (or many new) "nnn-nn" values added.
> A. Should we really add the URL in all error messages unconditionally?
> (Consistency could be one reason to favor it.)
Ah - that'd potentially affect every program that parses the existing
message layouts...
> B. Should we add a new option for this, that enables it by default for
> parallel mode and is disabled by default otherwise?
I would create a new message, so that - hopefully - any code [written
carefully at present] would skip it. You'd have to hope that no-one's
stupid enough to assume that if there's an error message of one type
then (say) the 17th line after it contains some vital information, without
looking at the contents of the intervening lines, and thus would already
be skipping lines that don't mean anything to them.
-- 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