Zusammenfassung

  • Mit 428 kann ein Ursprungsserver eine zustandsändernde Anfrage zurückweisen, wenn die vorgeschriebene Bedingung fehlt. Bedingtes Schreiben wird von freiwilliger Vorsicht zur Zulassungsregel.
  • Der typische Vertrag ist If-Match mit einem starken Entity-Tag. 428 bedeutet fehlende Bedingung; 412 bedeutet, dass eine vorhandene Bedingung falsch war.
  • Der Status sperrt und verschmilzt nichts. Verlässliche Validatoren, eine atomare Verbindung von Vergleich und Commit sowie echte Konfliktklärung bleiben notwendig.

Wie zwei Erfolge eine Änderung vernichten

Zwei Bearbeiter öffnen dieselbe Ressource in Version 7. Der erste korrigiert sie und speichert Version 8. Der zweite arbeitet noch auf seiner alten Kopie und sendet später das ganze Dokument zurück. Prüft der Server nur Berechtigung, Syntax und Ziel, können beide Antworten Erfolg melden. Die zuerst gespeicherte Korrektur ist trotzdem verschwunden.

Dieses „lost update“ braucht keinen Angreifer. Die zweite Anfrage hat Inhalt und Ziel genannt, aber nicht den Zustand, auf dem die Entscheidung beruhte. „Ersetze diese Ressource“ ist nicht dasselbe wie „ersetze sie nur, falls sie noch der Fassung entspricht, die ich gelesen habe“.

HTTP kannte bedingte Anfragen bereits. Validatoren werden häufig über Caches erklärt: Ein Client reicht ein Tag ein und vermeidet die erneute Übertragung einer unveränderten Darstellung. Dieselbe Evidenz kann einen Schreibvorgang schützen. Es fehlte jedoch eine präzise Antwort für einen Ursprung, der die unbedingte Form grundsätzlich nicht mehr akzeptieren wollte.

RFC 6585 führte im April 2012 428 Precondition Required ein. Der Code besagt, dass der Ursprungsserver eine bedingte Anfrage verlangt. Als typischen Zweck nennt das Dokument genau den Fall, in dem ein Client einen Zustand liest, bearbeitet und zurückschreibt, obwohl eine dritte Partei ihn inzwischen geändert hat.

Aus Vorsicht wird eine Eintrittsbedingung

Erhält ein Client beim Lesen das starke Tag "v7", erklärt If-Match: "v7" beim Schreiben seine Ausgangslage. Der Ursprung führt die Methode nur aus, wenn die ausgewählte aktuelle Darstellung noch dieses Tag trägt. Hat ein anderer Vorgang "v8" erzeugt, ist die Bedingung falsch und die Änderung darf nicht stattfinden.

Sorgfältige Clients konnten dies schon zuvor tun. 428 erlaubt dem Ursprung, die Sorgfalt zur Ressourcenpolitik zu machen. Das Beispiel in RFC 6585 empfiehlt If-Match; die Antwort soll erklären, wie die Anfrage erfolgreich erneut eingereicht werden kann.

Das Beispiel schreibt nicht für jeden Fall dasselbe Feld vor. If-Match: * setzt voraus, dass eine aktuelle Darstellung existiert. If-None-Match: * setzt ihre Nichtexistenz voraus und kann eine parallele Erstellung schützen. Ohne Entity-Tag bietet If-Unmodified-Since eine zeitliche Bedingung. Der Ursprung muss klar benennen, welche Evidenz für die konkrete Operation gilt.

Die historische Neuerung ist damit eine Kontrollentscheidung: Wer den aktuellen Zustand besitzt, darf verlangen, dass ein Schreibender seinen beobachteten Ausgangszustand offenlegt.

Fehlende und falsche Evidenz

428 und 412 markieren verschiedene Momente. 428 Precondition Required prüft die Zulassung: Die Richtlinie verlangt eine Bedingung, doch die Anfrage hat keine akzeptable mitgebracht. Die wirkende Methode beginnt nicht.

412 Precondition Failed folgt auf die Auswertung. Eine Bedingung war vorhanden, der Ursprung hat sie mit dem aktuellen Zustand verglichen, und sie war falsch. Der Client hat seine Vergangenheit genannt; sie ist nicht mehr die Gegenwart.

Für den Betrieb ist die Trennung wertvoll. Viele 428 können auf alte SDKs, unklare Dokumentation oder ein Gateway hinweisen, das Felder entfernt. Viele 412 können lange Bearbeitungssitzungen, echte Konkurrenz oder zu nervöse Tags zeigen. Eine gemeinsame Fehlerquote verwischt diese Ursachen.

428 ist auch keine Unterart von 409. Ein 409 kann einen semantischen Konflikt mit dem Ressourcenzustand ausdrücken. 428 verlangt die Grundlage, bevor der Ursprung überhaupt eine überschreibende Operation riskiert. WebDAVs 423 beschreibt wiederum eine Sperre; 428 richtet keine ein.

Weshalb If-Match einen starken Vergleich verlangt

Die aktuelle HTTP-Semantik in RFC 9110 schreibt für If-Match den starken Vergleich vor. Ein schwaches Tag kann für einen Cache ausreichende Gleichwertigkeit anzeigen. Beim Schreiben will der Client die Methode dagegen stoppen, sobald sich Darstellungsdaten geändert haben.

Die Tag-Erzeugung wird dadurch Teil der öffentlichen Schnittstelle. Bleibt das Tag trotz relevanter Änderung gleich, kann ein veralteter Schreibvorgang passieren. Springt es wegen belangloser Serialisierung, entstehen falsche Konflikte. Ein Dienst, der If-Match fordert, aber kein brauchbares starkes Tag ausgibt, macht 428 zur Sackgasse.

Zeitbedingungen sind weniger genau. If-Unmodified-Since kann ohne Tag gegen verlorene Änderungen helfen, doch RFC 9110 behandelt If-Match als präziseren Ersatz und ignoriert die Zeitbedingung, wenn beide vorliegen. Uhrauflösung und Zeitstempelbildung begrenzen die Aussagekraft.

Vergleich und Commit gehören zusammen

HTTP lässt Vorbedingungen am Ursprung nach den normalen Anfrageprüfungen und unmittelbar vor der Methodenaktion auswerten. Ein Vermittler darf nicht behaupten, If-Match entspreche dem aktuellen Ursprungszustand, den er nicht besitzt; er muss weiterleiten.

Auch intern darf die Nähe nicht verloren gehen. Prüft eine Anwendung zuerst das Tag, beendet ihre Transaktion und schreibt später, kann sich ein Konkurrent zwischen Prüfung und Commit schieben. Auf dem Draht sieht alles bedingt aus, im System entsteht erneut ein Prüfzeitpunkt-Nutzungszeitpunkt-Rennen.

Vergleich und Änderung brauchen eine atomare Entscheidung: Versionsspalte, Compare-and-Swap oder eine gleichwertige Transaktion. HTTP definiert die sichtbare Zusage, nicht die Isolation der Datenbank.

Außerdem muss der Geltungsbereich stimmen. Das Tag einer gerenderten Seite schützt nicht automatisch mehrere Hintergrunddatensätze. Löst dieselbe Anfrage noch eine externe Nachricht aus, überschreitet sie eine weitere Grenze. 428 macht aus solchen Effekten keine verteilte Transaktion.

Ein sichtbarer Konflikt ist noch keine Lösung

Ein Client kann nach 412 lediglich ein frisches Tag holen und es an den alten vollständigen Inhalt kleben. Die neue Bedingung erfüllt sich, doch niemand hat die zwischenzeitliche Änderung berücksichtigt. Ein sichtbarer Konflikt wird so zum formal autorisierten Überschreiben.

Eine richtige Erholung liest den aktuellen Zustand, vergleicht die ausstehende Absicht und entscheidet über Zusammenführen, Verwerfen oder bewusstes Ersetzen. Feldbezogene Patches oder kommutative Operationen können die Konfliktfläche verkleinern. Manchmal muss ein Mensch entscheiden. 428 eröffnet diesen Weg, übernimmt ihn aber nicht.

RFC 6585 erklärt den Status zudem für optional und warnt, dass Clients sich nicht auf seinen Einsatz gegen alle verlorenen Updates verlassen können. Bietet eine API bedingtes Schreiben, sollte ein verantwortlicher Client die Bedingung selbst senden.

Kein Cache darf die Ablehnung konservieren

Eine 428-Antwort darf nicht gespeichert werden. Sie beschreibt einen bestimmten Versuch, der die Zulassungsregel nicht erfüllte, nicht eine wiederverwendbare Darstellung der Ressource. Ein später abgespieltes altes 428 würde einem Cache Autorität über die Ursprungspolitik geben.

Die Antwort sollte deshalb handlungsfähig machen: erwartetes Feld, Weg zum aktuellen Validator und Hinweis auf notwendige Abstimmung. Der Statusname allein reicht nicht.

Das IANA-Register führt 428 weiterhin als Precondition Required mit RFC 6585. Der kurze Name hält eine tiefere Regel fest: Wer die Gegenwart ersetzen will, muss die Vergangenheit nennen, auf der sein Entschluss beruht.

Quellen und Grenzen

Die Belege sind RFC 6585, RFC 9110 und das IANA-Register. Sie bestimmen Semantik, Reihenfolge und Grenzen, nicht aktuelle Verbreitung, universelle Bibliotheksunterstützung, konkrete Schäden oder genau-einmalige Ausführung. 428 ist weder Sperre noch Merge oder Transaktion.