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: Sun, 24 Jul 2022 14:30:15 -0400
On 24-Jul-22 13:58, Bhavin Gandhi via curl-users wrote:
>
> I came across a couple of similar places in tool_operate.c while reading
> the code base. I'm leaving some examples here (not all error messages
> will have something but some should have more context):
>
> curl: (23) Failed to truncate file [which file?]
> curl: (%d) Failed writing body [where?]
>
I would include both the URL and the filename in these cases, since the
filename may have been derived from the URL. And in any case, the URL
would be needed to retry the operation (perhaps on a different
disk/directory).
In general, since curl works on URLs, the URL should be in all error
messages, with the filename (and other data) included where
appropriate. E.g. curl: example.com/foo%21: (23) Failed to truncate
'foo!' Other data might include the target of a seek that fails and
similar operation-specific context.
Note that it can be a bit tricky (and in the general case impossible) to
get filenames when redirections are active, e.g. curl ... >foo.baz -
curl only knows that it's writing to stdout. In this case, one either
says '<stdout>', or falls into OS-specific attempts. E.g. Linux can use
/proc/self/fd/1, many posix systems can use fstat & try to match dev/ino
- but these fields aren't valid on others. In any case, with links a
file can have many names. I'd stick with '<stdout>', though Linux is
common enough that it might be worth a special case for it, and maybe
for others where it's easy...
It can be helpful to include the resolved filename when what you have
isn't an absolute path. But that has challenges (realpath has buffer
length issues, readlink may not be implemented, and not all OSs that run
curl use POSIX filename syntax...)
The minimum is to include the url, and whatever curl has for the
filename. More than that gets both more helpful and more difficult.
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-24
Date: Sun, 24 Jul 2022 14:30:15 -0400
On 24-Jul-22 13:58, Bhavin Gandhi via curl-users wrote:
>
> I came across a couple of similar places in tool_operate.c while reading
> the code base. I'm leaving some examples here (not all error messages
> will have something but some should have more context):
>
> curl: (23) Failed to truncate file [which file?]
> curl: (%d) Failed writing body [where?]
>
I would include both the URL and the filename in these cases, since the
filename may have been derived from the URL. And in any case, the URL
would be needed to retry the operation (perhaps on a different
disk/directory).
In general, since curl works on URLs, the URL should be in all error
messages, with the filename (and other data) included where
appropriate. E.g. curl: example.com/foo%21: (23) Failed to truncate
'foo!' Other data might include the target of a seek that fails and
similar operation-specific context.
Note that it can be a bit tricky (and in the general case impossible) to
get filenames when redirections are active, e.g. curl ... >foo.baz -
curl only knows that it's writing to stdout. In this case, one either
says '<stdout>', or falls into OS-specific attempts. E.g. Linux can use
/proc/self/fd/1, many posix systems can use fstat & try to match dev/ino
- but these fields aren't valid on others. In any case, with links a
file can have many names. I'd stick with '<stdout>', though Linux is
common enough that it might be worth a special case for it, and maybe
for others where it's easy...
It can be helpful to include the resolved filename when what you have
isn't an absolute path. But that has challenges (realpath has buffer
length issues, readlink may not be implemented, and not all OSs that run
curl use POSIX filename syntax...)
The minimum is to include the url, and whatever curl has for the
filename. More than that gets both more helpful and more difficult.
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