Fiktion/Satire, aber der Protokollnagel sitzt: HTTP 428 Precondition Required ist kein dekorativer Fehlercode aus der Kantine. RFC 6585 beschreibt ihn für den Fall, dass der Ursprungsserver eine bedingte Anfrage verlangt, vor allem gegen das sogenannte Lost-Update-Problem. MDN fasst es handlich zusammen: Fehlt etwa ein nötiger Header wie If-Match, kann 428 kommen; passt eine vorhandene Bedingung nicht zum Serverzustand, ist eher 412 Precondition Failed dran. Jetzt aber zur Maschine, die beim Speichern erst den Sicherheitsgurt sehen will.
Um 8:11 Uhr stand eine Anfrage vor der Blechtür. Sie trug einen Putzeimer, eine neue Aktenfassung und dieses Gesicht, das Anfragen machen, wenn sie glauben, sie seien ja wohl offensichtlich wichtig. Auf ihrem Formular stand PUT /akte. Darunter nichts. Kein If-Match, keine Frischemarke, kein kleiner Zettel mit „ich habe den Stand von eben wirklich gesehen“.
Der Server schaute nicht einmal böse. Das ist das Schlimme an guten Servern. Sie schauen gar nicht böse. Sie schauen regelhaft.
„Vorbedingung erforderlich“, sagte er.
„Ich habe doch Inhalt dabei“, sagte die Anfrage und hob den Eimer.
„Inhalt haben hier alle“, sagte der Server. „Gestern hatte sogar der Kopierer Inhalt. Danach hatten wir drei Versionen derselben Wahrheit und eine Praktikantin, die die Wahrheit alphabetisch sortieren musste.“
Die Bedingung fehlt, nicht der Wille
428 ist der Code für diesen leicht beleidigenden, aber nützlichen Moment: Der Server will nicht einfach nur Daten. Er will Daten mit Anschnallgurt. Er verlangt, dass die Anfrage bedingt ist, damit nicht jemand eine ältere Fassung über eine neuere schreibt und hinterher behauptet, der Computer sei halt so gewesen. Computer sind oft so, ja. Aber manchmal dürfen sie es nicht sein.
Das verlorene Update ist ein leiser Diebstahl. Eine Person holt eine Ressource, bearbeitet sie, stellt den Kaffee zu nah an die Tastatur, währenddessen ändert jemand anders dieselbe Ressource, und am Ende kommt die erste Person zurück und übermalt die zweite Änderung mit der Autorität eines müden Pinsels. Niemand schreit. Genau deshalb ist es gefährlich.
Mit einer Bedingung sagt der Client: Bitte nur speichern, wenn der Zustand noch zu meiner Erinnerung passt. In der Werkstatt hängt dafür oft ein ETag an der Ressource, so eine kleine Blechmarke mit Versionsgeruch. Der Client kann sie mit If-Match zurückbringen. Wenn sie fehlt, kann der Server sagen: Freundchen, ohne Marke keine Presse. Das ist 428 Precondition Required.
428 ist nicht 412, auch wenn beide im selben Flur rauchen
Der Unterschied ist klein, aber er hat Schraubenköpfe. 428 sagt: Du hast gar keine nötige Bedingung mitgebracht. 412 sagt: Du hast eine Bedingung mitgebracht, aber sie passt nicht mehr. Einmal fehlt der Sicherheitsgurt. Einmal ist der Sicherheitsgurt an einem anderen Fahrzeug festgeklickt. Beides kann verhindern, dass die Akte durch den Stempel rutscht, aber die Werkstatt notiert es getrennt, weil Werkstätten so sind. Gute Werkstätten jedenfalls. Die anderen nennen alles „Fehler“ und kaufen dann neue Whiteboards.
RFC 6585 fügt noch eine trockene Anweisung dazu: Eine 428-Antwort darf nicht im Cache gelagert werden. Das ist vernünftig. Niemand braucht eine konservierte Türansage von gestern, wenn heute ein anderer Zettel fehlt. Bürokratie ist schon schlimm genug, sie muss nicht auch noch aus dem Vorrat kommen.
Die Anfrage vor der Blechtür seufzte, rollte zurück, holte den aktuellen Stand, bekam eine Marke, schrieb sie sauber dazu und kam wieder. Der Server las, nickte fast unmerklich und ließ den Stempel warm werden. Nicht weil er plötzlich nett war. Nettigkeit ist kein Protokollmerkmal. Sondern weil diesmal die Vorsicht mitgeliefert wurde.
Im Flur hing danach ein neues Schild: „Bitte vor dem Überschreiben nachsehen, ob die Welt inzwischen weitergegangen ist.“ Das Schild war schief. Also eigentlich genau richtig.