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: Printing the URL in the error messages when --fail is passed?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Timothe Litt <litt_at_acm.org>
Date: Mon, 25 Jul 2022 05:07:29 -0400
inline
.
On 24-Jul-22 17:57, Daniel Stenberg via curl-users wrote:
> On Sun, 24 Jul 2022, Bhavin Gandhi via curl-users wrote:
>
>> I'm new to curl code, but based on what we decide, I can help in
>> doing this change.
>
> The reason those details are not present in the error messages
> already, is that it isn't that clear-cut as to how and when to include
> what in the error messages.
>
> I'm all for improving them, but it might require some proper thinking
> and planning first.
>
> Some questions to ponder:
>
> 1. Should the URL be included in all error messages? If not all, which
> ones?
>
As I noted, Yes.
The only obvious exception might be a failure before any operation -
e.g. no memory to initialize the library. It may be simpler to use a
placeholder in those rare cases.
> 2. If you use the same URL in multiple places in the cmdline, then how
> does the error message differentiate between *which* of the identical
> URLs it is in regards to?
I guess there is a use case for multiple appearances of a URL on one
command line. POST? File upload?
In that case, I'd include the index (ordinal position on the command
line); either always or for the 2nd and subsequent instances. While the
latter is slightly more complex, it keeps simple output for simple
commands. Scripts that might always want the index can use -w - which
they should anyway, since default message text is (as here) subject to
change.
>
> 3. If there's a file associated with the URL (for example, we upload
> file A to URL B), should that file name be included too in error
> messages? How? In which error messages?
If there's an error associated with the file (e.g. open, read, write,
seek, close), yes. Otherwise, I don't see any value.
Something like "B: (n) read error on A.dat" (optionally + " at byte
6154") vs. "B: (n) server returned Not found (404)"
>
> 4. Most error messages come "provided" by the library and the client
> code only passes them through. How should the process be to add the
> URL/file name into the error message to show?
>
The client calls the library with the curl handle to get the associated
string. Say curl_get_message(h) (like strerror/strerror_r,
FormatMessage()..). Might allocate a flags argument in case demand for
variable detail arises.
The library keeps sufficient context in the handle to generate the
string on demand. Some is kept in advance of any error (e.g. filename);
some when the error happens (e.g. operation, error code, file position).
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Received on 2022-07-25
Date: Mon, 25 Jul 2022 05:07:29 -0400
inline
.
On 24-Jul-22 17:57, Daniel Stenberg via curl-users wrote:
> On Sun, 24 Jul 2022, Bhavin Gandhi via curl-users wrote:
>
>> I'm new to curl code, but based on what we decide, I can help in
>> doing this change.
>
> The reason those details are not present in the error messages
> already, is that it isn't that clear-cut as to how and when to include
> what in the error messages.
>
> I'm all for improving them, but it might require some proper thinking
> and planning first.
>
> Some questions to ponder:
>
> 1. Should the URL be included in all error messages? If not all, which
> ones?
>
As I noted, Yes.
The only obvious exception might be a failure before any operation -
e.g. no memory to initialize the library. It may be simpler to use a
placeholder in those rare cases.
> 2. If you use the same URL in multiple places in the cmdline, then how
> does the error message differentiate between *which* of the identical
> URLs it is in regards to?
I guess there is a use case for multiple appearances of a URL on one
command line. POST? File upload?
In that case, I'd include the index (ordinal position on the command
line); either always or for the 2nd and subsequent instances. While the
latter is slightly more complex, it keeps simple output for simple
commands. Scripts that might always want the index can use -w - which
they should anyway, since default message text is (as here) subject to
change.
>
> 3. If there's a file associated with the URL (for example, we upload
> file A to URL B), should that file name be included too in error
> messages? How? In which error messages?
If there's an error associated with the file (e.g. open, read, write,
seek, close), yes. Otherwise, I don't see any value.
Something like "B: (n) read error on A.dat" (optionally + " at byte
6154") vs. "B: (n) server returned Not found (404)"
>
> 4. Most error messages come "provided" by the library and the client
> code only passes them through. How should the process be to add the
> URL/file name into the error message to show?
>
The client calls the library with the curl handle to get the associated
string. Say curl_get_message(h) (like strerror/strerror_r,
FormatMessage()..). Might allocate a flags argument in case demand for
variable detail arises.
The library keeps sufficient context in the handle to generate the
string on demand. Some is kept in advance of any error (e.g. filename);
some when the error happens (e.g. operation, error code, file position).
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature