curl / Mailing Lists / curl-users / Single Mail
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

From: Daniel Stenberg via curl-users <>
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:

  | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
Received on 2021-01-02