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: Daniel Stenberg via curl-users <curl-users_at_lists.haxx.se>
Date: Mon, 25 Jul 2022 17:36:42 +0200 (CEST)
On Mon, 25 Jul 2022, Timothe Litt via curl-users wrote:
I'm responding here mostly to illustrate how this is a tricky challenge. I'm
not personally planning on working in improving this area of curl for the time
being. Of course someone else would be more than welcome to take on the
challenge.
>> 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.
So: yes and no. Kind of my point. =)
> I guess there is a use case for multiple appearances of a URL on one command
> line. POST? File upload?
Yes, or just download the same URL several times.
> In that case, I'd include the index (ordinal position on the command line);
> either always or for the 2nd and subsequent instances.
It certainly complicates how you phrase the error message in a way that the
user understands and is proper English.
>> 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.
It might be tricky to always determine if the error code was returned due to a
provided file. And again, how to add the information into the error message
when the error comes from the library and it doesn't include the file name.
So in order to provide a proper English error message with this information
embedded, I think the tool would need to write its own error messages. Which
is a little unfortunate, because libcurl errors can have more context. Maybe
it therefore needs to output both? Complicated.
> Something like "B: (n) read error on A.dat" (optionally + " at byte 6154")
> vs. "B: (n) server returned Not found (404)"
And the URL?
Compare to the current error message:
$ curl -f localhost -T daasdas
curl: Can't open 'daasdas'!
curl: try 'curl --help' or 'curl --manual' for more information
curl: (26) Failed to open/read local data from file/application
The last line is the error message, that would need the file name and the URL
inserted. But if the error is instead 22, it is (probably) not because of the
file and the file name should (probably) not be included when it reports:
curl: (22) The requested URL returned error: 405
> The library keeps sufficient context in the handle to generate the string on
> demand.
libcurl generates the error string at the time of the error, for most/many
error situations. That buffer is what then what the client code gets and uses
as error message. Trying to recreate the exact error string post-fact is
simply not possible.
Date: Mon, 25 Jul 2022 17:36:42 +0200 (CEST)
On Mon, 25 Jul 2022, Timothe Litt via curl-users wrote:
I'm responding here mostly to illustrate how this is a tricky challenge. I'm
not personally planning on working in improving this area of curl for the time
being. Of course someone else would be more than welcome to take on the
challenge.
>> 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.
So: yes and no. Kind of my point. =)
> I guess there is a use case for multiple appearances of a URL on one command
> line. POST? File upload?
Yes, or just download the same URL several times.
> In that case, I'd include the index (ordinal position on the command line);
> either always or for the 2nd and subsequent instances.
It certainly complicates how you phrase the error message in a way that the
user understands and is proper English.
>> 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.
It might be tricky to always determine if the error code was returned due to a
provided file. And again, how to add the information into the error message
when the error comes from the library and it doesn't include the file name.
So in order to provide a proper English error message with this information
embedded, I think the tool would need to write its own error messages. Which
is a little unfortunate, because libcurl errors can have more context. Maybe
it therefore needs to output both? Complicated.
> Something like "B: (n) read error on A.dat" (optionally + " at byte 6154")
> vs. "B: (n) server returned Not found (404)"
And the URL?
Compare to the current error message:
$ curl -f localhost -T daasdas
curl: Can't open 'daasdas'!
curl: try 'curl --help' or 'curl --manual' for more information
curl: (26) Failed to open/read local data from file/application
The last line is the error message, that would need the file name and the URL
inserted. But if the error is instead 22, it is (probably) not because of the
file and the file name should (probably) not be included when it reports:
curl: (22) The requested URL returned error: 405
> The library keeps sufficient context in the handle to generate the string on
> demand.
libcurl generates the error string at the time of the error, for most/many
error situations. That buffer is what then what the client code gets and uses
as error message. Trying to recreate the exact error string post-fact is
simply not possible.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-07-25