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: working around status code 429
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dirk Hünniger via curl-users <curl-users_at_lists.haxx.se>
Date: Thu, 1 Feb 2024 10:17:12 +0100
Hi Ray,
you are right. Its retrying after one second, and not doing the
exponential fallback it usually does. Thats why it concluded after a few
minutes. Thanks for the explanation that curl is following the servers
proposal to try again after one second. Everything is explained this
way. If you want, you can add a command line option to override the
servers proposal. For me it is not needed because, I do the retrying in
an external loop around the call to curl now.
Yours Dirk
On 01.02.24 09:58, Ray Satiro via curl-users wrote:
> On 1/31/2024 7:08 AM, Dirk Hünniger via curl-users wrote:
>
>
> Try:
> grep "Warning: Problem : HTTP error. Will retry in" out
>
> This most recent log shows transfers are retried (you can see the
> decreasing numbers in the barrage of output). Why do you think the
> transfers are not retried? This may be an unusual case because the
> server sets the retry delay time to 1 second using the header
> `retry-after: 1` and curl complies with that directive [1], but it is
> probably an impractical time.
>
> To address this I am proposing a new command line option that will
> allow ignoring the server's retry delay time. [2]
>
>
> [1]: https://curl.se/docs/manpage.html#--retry
> [2]: https://github.com/curl/curl/pull/12837
>
Date: Thu, 1 Feb 2024 10:17:12 +0100
Hi Ray,
you are right. Its retrying after one second, and not doing the
exponential fallback it usually does. Thats why it concluded after a few
minutes. Thanks for the explanation that curl is following the servers
proposal to try again after one second. Everything is explained this
way. If you want, you can add a command line option to override the
servers proposal. For me it is not needed because, I do the retrying in
an external loop around the call to curl now.
Yours Dirk
On 01.02.24 09:58, Ray Satiro via curl-users wrote:
> On 1/31/2024 7:08 AM, Dirk Hünniger via curl-users wrote:
>
>
> Try:
> grep "Warning: Problem : HTTP error. Will retry in" out
>
> This most recent log shows transfers are retried (you can see the
> decreasing numbers in the barrage of output). Why do you think the
> transfers are not retried? This may be an unusual case because the
> server sets the retry delay time to 1 second using the header
> `retry-after: 1` and curl complies with that directive [1], but it is
> probably an impractical time.
>
> To address this I am proposing a new command line option that will
> allow ignoring the server's retry delay time. [2]
>
>
> [1]: https://curl.se/docs/manpage.html#--retry
> [2]: https://github.com/curl/curl/pull/12837
>
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-02-01