Zusammenfassung

  • Eine Anfrage kann mehrere Digest- oder Präferenzfelder enthalten und deshalb mehrere gleichartige Probleme auslösen. Der erste Array-Eintrag ist weder zwingend die Grundursache noch die normative Reparaturreihenfolge.
  • Ein Retry-Automat braucht eine stabile Operationsidentität, eine Obergrenze, Feld- und Algorithmuskontext sowie eigenständige Autorität für die Wiederholung. Ein Problem Detail liefert Diagnose, nicht diese Autorität.

Die erste Antwort nannte einen nicht unterstützten Algorithmus. Der Client ersetzte ihn und sendete erneut. Die zweite Antwort meldete einen formal unmöglichen Digest-Wert in einem anderen Feld. Nach der Korrektur folgte eine echte Abweichung. Der vierte Versuch scheiterte an der Anwendung.

Jeder einzelne Schritt wirkte vernünftig. Zusammen bildeten sie eine ungebremste Schleife, weil der Client eine Liste von Diagnosen als schrittweisen Verhandlungsplan gelesen hatte. Er reparierte stets den ersten sichtbaren Eintrag und nahm an, die nächste Anfrage sei damit näher an einer garantierten Annahme.

Der Entwurf HTTP Problem Types for Digest Fields macht diese Annahme nicht. Er erlaubt mehrere ähnliche Probleme, weil eine HTTP-Nachricht mehrere Integritäts- oder Präferenzfelder enthalten kann. Erweiterungen sind optional. Ihre Reihenfolge verleiht weder Priorität noch Autorität, und ihre Abwesenheit hat keine besondere Bedeutung.

Betrachtet wird Revision 06 vom 24. Juni 2026 mit Ablauf am 26. Dezember 2026. Am 2. Oktober führte Datatracker den HTTPAPI-Arbeitsgruppenentwurf in der RFC-Editor-Warteschlange als „Awaiting First Editor“. Mike Bishop war verantwortlicher Area Director; die IANA-Prüfung nannte erforderliche Maßnahmen mit RFC-Ed-Ack. Angestrebt wird Standards Track als Proposed Standard, doch eine RFC-Nummer war noch nicht vergeben. Dieser Reifegrad beweist weder Implementierung noch einheitliches Antwortverhalten.

Drei Problemtypen sind keine lineare Leiter

digest-unsupported-algorithms besagt, dass der Validator keinen der angebotenen Algorithmen für das betreffende Feld unterstützt. Einträge nennen Algorithmus und Header. Eine Antwort kann das passende Präferenzfeld ergänzen und unterstützte Optionen samt Präferenz anzeigen.

Das hilft bei der Kompatibilität. Es sagt nicht, dass die nächste Anfrage einen korrekten Wert enthält, autorisiert ist oder die Geschäftsregeln erfüllt. Eine Präferenz ist ein Hinweis des Validators, keine Vorabzusage der Anwendung.

digest-invalid-values bezeichnet einen Wert, der nicht vom genannten Algorithmus stammen kann—etwa eine unmögliche Länge für SHA-512. Ein menschenlesbarer Grund kann die Diagnose erleichtern. Ein unveränderter Retry wird typischerweise erneut scheitern, weil Berechnung oder Kodierung falsch ist.

Ein Structured-Fields-Syntaxfehler liegt noch früher und gehört nicht einfach in diese Kategorie. Kann das Feld nicht geparst werden, gibt es noch kein verwertbares Algorithmus-Wert-Paar. Parserfehler und mathematisch unmöglicher Wert benötigen andere Besitzer und andere Reparaturen.

digest-mismatched-values setzt dagegen einen vergleichbaren Wert voraus, der nicht dem Serverergebnis für den genannten Geltungsbereich entspricht. Die Antwort kann Algorithmus, bereitgestellten Digest und Header nennen. Den serverseitig berechneten Digest lässt der Entwurf bewusst weg, um kein Orakel zu schaffen.

Diese Typen bilden keine Fortschrittsleiter von „fast gültig“ zu „akzeptiert“. Ein Client kann nach Behebung eines Typs auf einen anderen treffen, ohne dass der Server zuvor Vollständigkeit versprochen hat.

Mehrere Einträge sind Beobachtungen, kein Programm

Wenn zwei Digest-Felder und ein Präferenzfeld in einer Anfrage vorkommen, kann der Server mehrere Fehler berichten. Er kann aus Sicherheits- oder Implementierungsgründen auch Details auslassen. Der Client darf deshalb weder „erstes Element = Hauptursache“ noch „kein weiteres Element = kein weiteres Problem“ speichern.

Ein robuster Zustandsautomat sammelt alle offenbarten Diagnosen nach header und algorithm, unterscheidet bekannte von unbekannten Zuständen und erstellt einen neuen Kandidaten. Bevor er ihn sendet, prüft er jedoch eine andere Bedingung: Ist eine neue Ausführung dieser Operation erlaubt?

Die Zahl der Reparaturen muss begrenzt sein. RFC 9110 rät davon ab, einen fehlgeschlagenen automatischen Retry erneut automatisch zu wiederholen. Das ist nicht nur ein Schutz vor Last. Nach jedem Versuch wächst die Unsicherheit über bereits ausgelöste Nebenwirkungen und darüber, ob der Client noch dieselbe Operation oder faktisch eine neue ausführt.

Der Header ist Teil des Schlüssels

RFC 9530 unterscheidet Content-Digest für HTTP content und Repr-Digest für die ausgewählte Repräsentation. Content Codings und Transformationen können die Bytebereiche verändern. Der separate aktive Entwurf Unencoded-Digest beschreibt einen weiteren Bereich für unkodierten Inhalt und war zum Stichtag noch kein RFC.

Darum enthält jeder Diagnoseeintrag header. Eine Schleife, die nur „SHA-256 reparieren“ speichert, kann einen Wert für den falschen Bereich neu berechnen. Mathematisch korrekt ist dann nicht semantisch korrekt.

Der Zustandsautomat braucht mindestens den Feldnamen, den Validierungspunkt und bekannte Transformationen. Sonst löst ein neuer Wert womöglich eine andere Vergleichsschicht aus, und die Folge von Antworten wird fälschlich als unstabiler Server statt als inkonsistente Reichweite interpretiert.

Problem Details schließen die Transaktion nicht ab

RFC 9457 stellt ein maschinenlesbares Fehlerformat bereit. Der Typ benennt eine Klasse; optionale Erweiterungen liefern Kontext. Ein status-Mitglied im JSON ist nur beratend und kann nach einer Änderung durch einen Intermediär vom tatsächlichen HTTP-Status abweichen. Der Body ersetzt weder Methodenbedeutung noch Anwendungsbeleg.

Auch ein 400 beweist nicht, dass in einer verteilten Architektur nirgends eine Nebenwirkung entstand. Gateway, Audit, Queue, Origin und weitere Dienste können unterschiedliche Reihenfolgen haben. Der Digest-Entwurf normiert diesen Ausführungsgraphen nicht.

RFC 9110 zieht deshalb eine separate Retry-Grenze. Idempotente Methoden können nach Verbindungsfehlern eher automatisch wiederholt werden. Eine nicht idempotente Anfrage sollte nur wiederholt werden, wenn ihre tatsächliche Semantik idempotent ist oder feststeht, dass sie nicht angewendet wurde. Ein Proxy darf nicht idempotente Anfragen nicht automatisch wiederholen.

Die Beispiele des Digest-Entwurfs umfassen PUT und POST. Der Problemtyp verleiht keiner Methode neue Semantik. Eine Idempotency-Key-Vereinbarung, Transaktions-ID, Bedingung oder dauerhafte Anwendungsquittung kann Retry-Autorität schaffen. Die Array-Reihenfolge kann es nicht.

Detail erhöht Diagnose und Angriffsfläche zugleich

Der Server gibt bei einer Abweichung den bereitgestellten, nicht aber den berechneten Digest zurück. Damit begrenzt er ein mögliches Orakel. Dennoch können unterstützte Algorithmen, Header, Begründungen und unterschiedliches Antwortverhalten Implementierungen oder Intermediäre fingerprinten. Der wiederholte bereitgestellte Wert kann in Logs und Tickets gelangen.

Server dürfen daher allgemeinere Probleme wählen. Clients müssen fehlende Erweiterungen als unbekannt behandeln. Ein sicherer Fingerprint kann zur Korrelation genügen; Rohwerte gehören in geschützte Evidenzspeicher. Mehr Detail ist kein kostenloses Gut.

Diese Sicherheitsgrenze hat eine operative Folge: Ein Client kann nie voraussetzen, dass er durch wiederholte Versuche schrittweise die vollständige interne Prüfliste des Servers entdeckt. Eine solche Schleife ist weder zuverlässige Aushandlung noch verantwortbare Erkundung.

Der kleinste belastbare Zustandsautomat

Heng Lus Realitätsschichten trennen Symbol, Ausführung und Ergebnis. Digest und Header behaupten etwas über benannte Bytes. Der Problemtyp ist die Aussage eines Validators. Die neu gesendete Anfrage ist eine neue Handlung. Anwendungskommitment und Nutzerergebnis sind spätere Beobachtungen.

Eine Minimum Initial Specification speichert stabile Operations-ID, Methode, Ziel, Versuchszähler und Höchstzahl, Idempotenzautorität, Digest-Header, Algorithmus, geschützten Wert-Fingerprint, Parser-/Form-/Vergleichsergebnis, Validierungspunkt, HTTP-Status, Problemtyp, Antwortprovenienz und Anwendungsquittung. Sie darf unbekannte Felder nicht mit false füllen.

Running-Code Primacy verlangt Kombinationstests: mehrere Header, mehrere Algorithmen, vertauschte Array-Reihenfolge, ausgelassene Erweiterungen, Syntaxfehler, unmöglicher Wert und echte Abweichung. Danach muss eine Antwort nach einem Anwendungscommit verloren gehen und ein nicht idempotenter Retry an der fehlenden Autorität stoppen. Ein zweiter fehlgeschlagener Automatismus darf keine dritte Anfrage erzeugen.

Der Entwurf liefert bessere Wegweiser. Ein Wegweiser ist trotzdem kein Fahrbefehl. Wer Diagnoseeinträge in eine endlose Reparaturliste verwandelt, macht aus zusätzlicher Präzision zusätzliche Unsicherheit.

Quellen