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: Timothe Litt <litt_at_acm.org>
Date: Thu, 1 Feb 2024 05:49:24 -0500
On 01-Feb-24 05:39, Daniel Stenberg via curl-users wrote:
> On Thu, 1 Feb 2024, Dirk Hünniger via curl-users wrote:
>
>> 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.
>
> I'm thinking it could perhaps be argued that curl should treat the
> Retry-After time as a *minimum* time, so that if it already has backed
> off a bit by itself, it would still use that longer time...
>
>
Yes. That's what RFC9110 says it should do. If the user agent has
reason (or instructions) to wait longer, Retry-After should not
supersede them.
10.2.3.<https://www.rfc-editor.org/rfc/rfc9110#section-10.2.3>Retry-After
<https://www.rfc-editor.org/rfc/rfc9110#name-retry-after>
Servers send the "Retry-After" header field to indicate how long the
user agent ought to wait before making a follow-up request. When sent
with a503 (Service Unavailable)
<https://www.rfc-editor.org/rfc/rfc9110#status.503>response, Retry-After
indicates how long the service is expected to be unavailable to the
client. When sent with any3xx (Redirection)
<https://www.rfc-editor.org/rfc/rfc9110#status.3xx>response,
*Retry-After indicates the _minimum _time that the user agent is asked
to wai*t before issuing the redirected request.
Received on 2024-02-01
Date: Thu, 1 Feb 2024 05:49:24 -0500
On 01-Feb-24 05:39, Daniel Stenberg via curl-users wrote:
> On Thu, 1 Feb 2024, Dirk Hünniger via curl-users wrote:
>
>> 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.
>
> I'm thinking it could perhaps be argued that curl should treat the
> Retry-After time as a *minimum* time, so that if it already has backed
> off a bit by itself, it would still use that longer time...
>
>
Yes. That's what RFC9110 says it should do. If the user agent has
reason (or instructions) to wait longer, Retry-After should not
supersede them.
10.2.3.<https://www.rfc-editor.org/rfc/rfc9110#section-10.2.3>Retry-After
<https://www.rfc-editor.org/rfc/rfc9110#name-retry-after>
Servers send the "Retry-After" header field to indicate how long the
user agent ought to wait before making a follow-up request. When sent
with a503 (Service Unavailable)
<https://www.rfc-editor.org/rfc/rfc9110#status.503>response, Retry-After
indicates how long the service is expected to be unavailable to the
client. When sent with any3xx (Redirection)
<https://www.rfc-editor.org/rfc/rfc9110#status.3xx>response,
*Retry-After indicates the _minimum _time that the user agent is asked
to wai*t before issuing the redirected request.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature