Zusammenfassung

  • Retry-After nennt eine Wartezeit vor der Folgeanfrage, garantiert aber keinen Wiederherstellungszeitpunkt.
  • Der Wert kann ein absolutes HTTP-Datum oder eine Verzögerung in Sekunden sein; deshalb müssen auch die verwendete Uhr und die Auslegung des Werts dokumentiert werden.
  • 503 und 429 beschreiben die beobachtete Antwort, nicht künftige Kapazität oder sämtliche Abhängigkeiten.
  • Ein Nachweis zur Freigabe des nächsten Versuchs muss die Anweisung mit aktuellen Zustandsdaten und dem tatsächlichen Ergebnis verbinden.

Man stelle sich einen Wiederherstellungscontroller vor, der 503 Service Unavailable mit Retry-After: 120 erhält. Er hält alle Anfragen zurück, setzt zwei Minuten später eine grüne Marke und gibt die gesamte Warteschlange in derselben Sekunde frei. Der Vorfall gilt als beendet, bevor eine neue Anfrage erfolgreich war. Nach zwei Minuten bleibt der Ursprungsserver überlastet, eine Abhängigkeit ist weiter nicht verfügbar, und die synchronisierte Welle verlängert die Überlastung.

Der Header war gültig. Die Wiederherstellungsaussage war erfunden.

RFC 9110 definiert Retry-After eng: Der Wert gibt an, wie lange ein User Agent vor einer Folgeanfrage warten sollte. Bei 503 kann der Server einen geeigneten Wiederholungszeitpunkt vorschlagen. In einer Weiterleitungsantwort kann das Feld angeben, wie lange vor dem Aufruf des neuen Ziels gewartet werden sollte. Beides macht den Zeitpunkt nicht zu einer Zustandsprognose.

Der Header kennt zwei Formen. Ein HTTP-Datum bezeichnet einen Zeitpunkt; ein Verzögerungswert gibt eine nichtnegative Anzahl von Sekunden nach dem Empfang an. Das Datum hängt von Uhren ab, die Verzögerung vom tatsächlichen Empfang und dem Umgang von Zwischenstationen, Warteschlangen und lokalen Timern mit verstrichener Zeit. Nur die berechnete Frist zu speichern, verwirft die ursprüngliche Anweisung.

RFC 9110 beschreibt 503 als vorübergehende Unfähigkeit infolge Überlastung oder geplanter Wartung. Der Server darf eine passende Wiederholung vorschlagen, garantiert aber nicht, dass die Einschränkung genau dann endet. Die Spezifikation verlangt auch nicht, dass jeder überlastete Server mit 503 antwortet. Die Erholung kann früher, später, teilweise, regional oder vom Zugriffskontext abhängig eintreten.

RFC 6585 definiert 429 Too Many Requests. Die Antwort kann Retry-After enthalten, doch wie ein Nutzer erkannt und wie gezählt wird, bleibt dem Server überlassen. Token, Konto, Route, Mandant oder Edge können verschiedene Grenzen haben. Ein Timer ohne diesen Geltungsbereich belegt nicht, dass die nächste Anfrage angenommen wird.

Der Nachweis zur Freigabe des nächsten Versuchs hält Anfrage, Antwort, Beobachtungspunkt, Status, Rohwert, Form, Empfangszeit, berechneten Zeitpunkt, Uhrquelle und das Alter durch Zwischenstationen fest. Er bindet die Anweisung ohne Geheimnisse an ihren Konto-, Token-, Routen- oder Mandantenbereich.

Danach speichert er Backoff-Strategie, Jitter, Versuchslimit, die Obergrenze gleichzeitiger Anfragen, den Abbruchzustand und die tatsächliche Versandzeit. Unmittelbar vor dem nächsten Versuch kommen aktuelle Daten zum Dienstzustand, zu verfügbaren Ressourcen, zu Abhängigkeiten und zur Autorisierung hinzu. Zuletzt folgen die erhaltene Antwort und das Transaktionsergebnis. „Wartezeit abgelaufen“, „Zustand geprüft“, „neuer Versuch freigegeben“ und „Transaktion abgeschlossen“ sind getrennte Tatsachen.

Quellen

RFC 9110 — HTTP Semantics; RFC 6585 — Additional HTTP Status Codes.