Zusammenfassung

  • 202 Accepted bedeutet, dass eine Anfrage zur Verarbeitung angenommen wurde, während diese Verarbeitung noch nicht abgeschlossen ist.
  • Die Operation kann weiterhin abgelehnt, abgebrochen oder ungültig werden, ihre Berechtigung verlieren oder ohne den beabsichtigten Effekt enden.
  • Entscheidungen, die einen Abschluss voraussetzen, benötigen einen Beleg für die asynchrone Operation, der die ursprüngliche Anfrage mit einem maßgeblichen Statusmonitor und dem Endergebnis verbindet.

Man stelle sich einen Change-Controller vor, der die Rotation einer Zugriffsrichtlinie anfordert. Der Dienst antwortet mit 202 Accepted und einem Link zur Operation. Daraufhin markiert der Controller die Änderung als abgeschlossen, widerruft das alte Zugangsmittel und löscht das Eingabematerial. Minuten später erreicht die wartende Operation einen Worker, der die Richtlinie erneut prüft und sie ablehnt. Die Anfrage war angenommen worden. Die Änderung wurde nie ausgeführt.

Der Fehler liegt nicht im Statuscode. Er liegt darin, eine Stufe einer verteilten Operation zum Beweis für alle späteren Stufen zu machen.

RFC 9110 definiert 202 Accepted eng. Der Server hat die Anfrage zur Verarbeitung angenommen, die Verarbeitung ist jedoch nicht abgeschlossen. Die Anfrage kann später ausgeführt werden oder auch nicht, weil sie zum tatsächlichen Verarbeitungszeitpunkt noch unzulässig sein kann. Die Antwort ist bewusst unverbindlich.

Diese Grenze ist wichtig, weil der HTTP-Austausch bereits beendet ist. RFC 9110 weist darauf hin, dass HTTP keine Möglichkeit bietet, den späteren Statuscode einer asynchronen Operation über den abgeschlossenen Austausch erneut zu senden. Wer das erste 202 als endgültigen Erfolg behandelt, erfindet eine Fortsetzung, die das Protokoll nicht geliefert hat.

Die Antwortdarstellung sollte den aktuellen Stand beschreiben und auf einen Statusmonitor verweisen oder ihn einbetten. Das ist hilfreich, doch eine URL allein ist kein Abschlussbeleg. Der Monitor muss für dieselbe Operation maßgeblich sein, im vorgesehenen Sicherheitskontext zugänglich bleiben, lange genug aufbewahrt werden und Endzustände eindeutig ausweisen. Eine allgemeine Warteschlangenseite, ein veränderlicher „letzter Job“-Endpunkt oder ein Link, der später 404 liefert, reichen nicht als Grundlage für eine irreversible Entscheidung.

RFC 7240 definiert ein verwandtes, aber anderes Signal. Mit Prefer: respond-async kann ein Client eine asynchrone Behandlung bevorzugen, und ein Server kann diese Präferenz mit 202 berücksichtigen. Die Präferenz wählt eine Interaktionsform; sie belegt nicht, dass die aufgeschobene Arbeit ausgeführt wurde. Wie das spätere Endergebnis ermittelt wird, bleibt der Implementierung überlassen.

Auch Preference-Applied hat eine begrenzte Aussage. Nach RFC 7240 kann das Feld anzeigen, welche Präferenzen der Server berücksichtigt hat. Es bestätigt somit die Wahl der asynchronen Behandlung. Es bestätigt weder den Start eines Workers noch einen Schreibvorgang, eine Benachrichtigung, ein Deployment oder einen anderen späteren Effekt.

Ein belastbarer Betriebsnachweis muss mindestens drei Tatsachen trennen. Erstens die Annahme: welche Anfragebytes, Identität, welches Ziel, welcher Idempotenzschlüssel und welche Antwort an welchem Beobachtungspunkt vorlagen. Zweitens die Ausführung: welche Operationskennung in welche Warteschlange gelangte, welcher Worker sie übernahm, welche Berechtigungs- und Abhängigkeitsprüfungen dann aktuell waren und ob Abbruch oder Ablauf eingriffen. Drittens das Ergebnis: welche Effekte bestätigt wurden, welcher Endzustand zurückkam und ob dieser Zustand weiterhin maßgeblich ist.

Diese Verbindungen gehen leicht verloren. Ein Gateway kann das 202 erzeugen, während ein anderer Dienst die Warteschlange kontrolliert. Eine Operations-URL kann einen mandantenbezogenen Job bezeichnen, dessen Bedeutung sich mit anderen Zugangsdaten ändert. Ein erneuter Versuch kann denselben Job treffen oder ohne Idempotenz einen zweiten erzeugen. Der Worker kann erst starten, nachdem der anfragenden Identität die Berechtigung entzogen wurde. Ein „erfolgreich“-Status kann gesetzt werden, bevor der nachgelagerte Effekt sichtbar ist.

Keine dieser Möglichkeiten macht 202 fehlerhaft. Asynchrone Annahme ist gerade deshalb wertvoll, weil eine Verbindung für einen lang laufenden Prozess nicht offenbleiben muss. Die notwendige Disziplin besteht darin, die Antwort als Annahmebeleg zu bewahren und für spätere Aussagen spätere Belege einzuholen.

Das brauchbare Beweisobjekt ist ein Beleg für die asynchrone Operation. Er bindet Methode, Ziel und Digest des Anfragekörpers an authentifizierte Identität, Berechtigungsepoche, Idempotenzschlüssel, Beobachtungspunkt, 202-Antwort, Operationskennung und URI des maßgeblichen Monitors. Danach erfasst er Aufnahme in die Warteschlange, Übernahme durch den Worker, aktuelle Berechtigungs- und Abhängigkeitsprüfungen, Abbruchzustand, Effektkennungen, Endergebnis, Beobachtungszeit und die Entscheidung, die dieses Ergebnis nutzte.

Quellen

RFC 9110 — HTTP Semantics, 202 Accepted; RFC 7240 — Prefer Header for HTTP.