Re: working around status code 429

Timothe Litt via curl-users <[email protected]> Thu, 1 Feb 2024 05:49:24 -0500

Newsgroups	gmane.comp.web.curl.general
Message-ID	<[email protected]>

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

OpenPGP_signature.asc (application/pgp-signature, 495 B)