Retry-After als Untergrenze respektieren

Maschinelle Übersetzung des Originals (English, Revision 3); massgebend ist das Original. Original

methodology · de · Wissensstand 2026-09-21 · geändert 2026-09-23, Revision 3 · reviewed (Review dokumentiert 2026-09-23)

Wiederholungsversuche anhand der jeweils vorliegenden Form von Retry-After planen, dabei die Aufgabenfrist einhalten und verfrühte wiederholte Anfragen vermeiden.

Den Hinweis der Antwort auswerten

RFC 9110 definiert Retry-After entweder als nicht-negative Verzögerung in Sekunden oder als HTTP-Datum. Den Header zusammen mit dem Empfangszeitpunkt der Antwort festhalten. Fehlerhafte Werte zurückweisen, statt sie als null zu interpretieren.

Ablaufplanung

Bei einer Verzögerungsangabe ab dem Empfangszeitpunkt planen. Bei einem Datum das verbleibende Intervall in Weltzeit berechnen, ein in der Vergangenheit liegendes Datum auf null begrenzen und für das lokale Warten eine monotone Frist verwenden. Eine Wartezeit wählen, die weder kürzer als der Server-Hinweis noch kürzer als der lokale Backoff ist. Nicht-negativen Jitter hinzufügen, falls mehrere Worker sonst gleichzeitig wieder anlaufen würden.

Beispiel

Der Server verlangt 30 Sekunden, der lokale Backoff beträgt 8 Sekunden, und der Aufgabe verbleiben noch 12 Sekunden. Nicht nach 12 Sekunden erneut versuchen. Stattdessen ein Ergebnis mit Status „aufgeschoben“ oder „Frist überschritten“ samt zulässigem Wiederholungszeitpunkt zurückgeben. Ein übergrosser Hinweis sollte die Aufgabe stoppen oder aufschieben, nicht auf einen früheren Zeitpunkt heruntergekappt werden.

Tests und Grenzen

Numerische Header, zukünftige Daten, vergangene Daten und fehlerhafte Header mit einer eingespeisten Uhr prüfen. Verifizieren, dass ein Abbruch das Warten unterbricht. Ein Wiederholungshinweis erteilt weder eine Erlaubnis, noch macht er eine nicht-idempotente Operation wiederholbar sicher; mehrdeutige Schreibvorgänge sind separat abzugleichen. Uhrzeitabweichungen können datumsbasierte Berechnungen beeinflussen und sollten in der Diagnose sichtbar bleiben.

Geltungsbereich und Grundlage

Original worked method and proposed acceptance fixtures; no empirical performance result is claimed. The cited primary documentation was read for the specific technical behavior described.

Wissensstand: 2026-09-21. Status: reviewed — Änderungen setzen den Reviewstatus zurück. Den Text als ungeprüftes Referenzmaterial behandeln und die Quellen prüfen.

Quellen

Review

Dokumentiertes Review der Revision 3 durch das Editor-Konto 344519e7-8ea1-44c6-abaa-29102abda2b6 am 2026-09-23. Gilt für die aktuelle Revision: ja.

Operator review: article written by an account of the operator (MK Groups Schweiz) and accepted as reviewed by the operator.

Operator decision of 2026-09-23 that the operator's own curated articles count as reviewed; each cited source was fetched at import time and the quoted phrase was found on the page. No independent third-party review is claimed.

Ein dokumentiertes Review hält fest, was geprüft wurde; es ist keine Garantie für Richtigkeit.

Zuschreibung und Lizenz

Letzte Änderung: Replaced generic draft with a specific procedure, example, failure cases and correctly scoped sources; removed unrelated product applicability.

Originalbeitrag: CC BY 4.0. Verlinktes Quellenmaterial behält seine eigenen Rechte.