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: curl ignores the Retry-After header with fail-on-error option
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-users <curl-users_at_cool.haxx.se>
Date: Sat, 2 Jan 2021 11:59:19 +0100 (CET)
On Thu, 31 Dec 2020, Cherish98 via curl-users wrote:
> I was expecting curl to use the Retry-After value in the HTTP response for
> the retry delay period. However, curl (libcurl to be precise, but this issue
> is more concerned with the tool, as library users can deal with errors
> programmatically) ignores (almost) all the HTTP headers with the
> CURLOPT_FAILONERROR option. I would suggest that curl looks for the
> Retry-After header in case of HTTP error 429, even the request itself is
> marked as failed.
Yeps. I can certainly see how this is surprising and even not what you want
for the case you describe. The CURLOPT_FAILONERROR option exits the transfer
hard and very early and doesn't bother to even read any headers - I think
maybe this provides a reason for us to consider a different approach.
Would you mind submitting this as an issue on GitHub so that we can keep
better track of it? I hope to make a go at fixing this. The tricky part is
just to make sure that it doesn't break any existing functionality.
> By the way, on the curl(1) man page, it reads that "Transient error means
> either: [...] an HTTP 408 or 5xx response code." HTTP 429 was left out here.
Thanks! I fixed that now: https://github.com/curl/curl/commit/aa71750687d1244
Date: Sat, 2 Jan 2021 11:59:19 +0100 (CET)
On Thu, 31 Dec 2020, Cherish98 via curl-users wrote:
> I was expecting curl to use the Retry-After value in the HTTP response for
> the retry delay period. However, curl (libcurl to be precise, but this issue
> is more concerned with the tool, as library users can deal with errors
> programmatically) ignores (almost) all the HTTP headers with the
> CURLOPT_FAILONERROR option. I would suggest that curl looks for the
> Retry-After header in case of HTTP error 429, even the request itself is
> marked as failed.
Yeps. I can certainly see how this is surprising and even not what you want
for the case you describe. The CURLOPT_FAILONERROR option exits the transfer
hard and very early and doesn't bother to even read any headers - I think
maybe this provides a reason for us to consider a different approach.
Would you mind submitting this as an issue on GitHub so that we can keep
better track of it? I hope to make a go at fixing this. The tricky part is
just to make sure that it doesn't break any existing functionality.
> By the way, on the curl(1) man page, it reads that "Transient error means
> either: [...] an HTTP 408 or 5xx response code." HTTP 429 was left out here.
Thanks! I fixed that now: https://github.com/curl/curl/commit/aa71750687d1244
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ----------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-01-02