Zusammenfassung

  • Bei einer verpflichtenden Erweiterung machte RFC 2774 aus GET ein M-GET und aus PUT ein M-PUT. Ein unwissender Server sollte die fremde Methode ablehnen, statt die Bedingung zu verwerfen und die Grundoperation scheinbar erfolgreich auszuführen.
  • Ein fähiger Empfänger antwortete mit 510, wenn die Erweiterungsrichtlinie unerfüllt blieb, oder bestätigte die Erfüllung mit Ext beziehungsweise C-Ext. Das Experiment wurde später Historic; Code und Felder gelten heute als obsolet.

Wenn Rückwärtskompatibilität die falsche Operation rettet

Ein Client möchte eine Ressource mit PUT schreiben, allerdings nur unter einer zusätzlichen Regel. Ein neuer Server liest die Erweiterungsdeklaration, wendet die Regel an und speichert. Ein alter Server erkennt PUT, überspringt unbekannte Felder und speichert dieselben Bytes ohne die Regel. Beide können 200 OK liefern.

Auf der Leitung sieht das ähnlich aus. Für den Absender sind es unterschiedliche Vorgänge. Der zweite Server hat eine Operation durchgeführt, deren Voraussetzung er nicht kannte. Die sonst nützliche Toleranz gegenüber unbekannten Feldern macht aus Unverständnis eine Erfolgsmeldung.

RFC 2774 erschien im Februar 2000 als Experimental und stellte diesem Problem eine absichtliche Inkompatibilität entgegen. Pflichtige Erweiterungen verlangten ein M- vor dem Methodennamen. Wer den Rahmen nicht kannte, sah M-PUT statt PUT und musste vor der reduzierten Ausführung scheitern.

Sichtbares Scheitern vor der Nebenwirkung

Ein kompatibler Empfänger durfte das Präfix nicht einfach entfernen. Zuerst identifizierte er alle verpflichtenden Deklarationen, prüfte ihre Unterstützung für diese Nachricht und gab bei einer Lücke 510 Not Extended zurück. Erst danach durfte er die Erweiterungssemantik und die zugrunde liegende HTTP-Methode ausführen.

Die Spezifikation untersagte ausdrücklich, Erfüllung zu melden, ohne alle Pflichtdeklarationen verstanden und befolgt zu haben. Die unbekannte Methode war damit eine Sicherheitsgrenze: lieber ein eindeutiger Fehler als ein verfügbarer Dienst mit falscher Bedeutung.

Stärke und Reichweite

Der Rahmen ordnete Erweiterungen nach zwei Achsen. Sie waren verpflichtend oder optional und wirkten Ende-zu-Ende oder nur über einen Verbindungsschritt. Daraus entstanden Man, Opt, C-Man und C-Opt.

Diese Matrix verteilte Zuständigkeit. Ein Proxy durfte eine Ende-zu-Ende-Deklaration nicht verbrauchen, nur weil er sie lesen konnte. Eine Hop-by-Hop-Bedingung richtete sich dagegen an den nächsten Teilnehmer und musste in HTTP/1.1 zusammen mit ihren Daten durch Connection geschützt werden.

Eine Erweiterung besaß eine global eindeutige URI; unter engeren Voraussetzungen konnte auch ein standardisierter Feldname dienen. Die Deklaration konnte ein numerisches Präfix wie 16 reservieren. Felder mit 16- gehörten dann zu dieser Instanz. So wurden Kollisionen vermieden, ohne einer Erweiterung den gesamten Feldnamensraum zu überlassen.

Was 510 tatsächlich sagte

510 bezeichnete keinen allgemeinen Serverausfall. Abschnitt 7 beschrieb eine Zugriffsrichtlinie der Ressource, die noch nicht erfüllt war. Die Antwort sollte Informationen liefern, mit denen der Client eine akzeptable erweiterte Anfrage bilden konnte.

Konnte der Client fehlende Erweiterungen beisteuern, durfte er die Anfrage ändern und wiederholen. Andernfalls diente der Antwortkörper als Diagnose. Auch eine M--Methode ohne Pflichtdeklaration erhielt 510, denn sie behauptete eine zwingende Zusatzbedeutung, ohne diese zu benennen.

Der Status trennte damit Erreichbarkeit und semantische Gültigkeit. Server und Ressource konnten vorhanden sein, die Grundmethode konnte bekannt sein, und trotzdem war der Vertrag dieser einzelnen Operation nicht erfüllt.

Erfolg brauchte ein eigenes Zeugnis

Bei Erfüllung reichte ein gewöhnlicher Status nicht. Ext bestätigte alle verpflichtenden Ende-zu-Ende-Deklarationen, C-Ext die Pflichtbedingungen des Verbindungsschritts. Beide Felder trugen keine Anwendungsdaten, sondern ausschließlich die Aussage, dass die bezeichnete Semantik verstanden und befolgt worden war.

Das war weder ein Sicherheitszertifikat noch ein Beweis für ein korrektes Geschäftsergebnis. Es war die engere Evidenz, dass nicht bloß die Grundmethode gelaufen war.

Der lange Weg durch Proxys und Caches

Eine Ende-zu-Ende-Deklaration musste unwissende Proxys überqueren. Eine Verbindungsdeklaration musste am richtigen Hop enden. Ein Cache durfte eine unter einer Erweiterung erzeugte Antwort nicht für eine Anfrage ohne dieselbe Bedingung wiederverwenden.

RFC 2774 verlangte deshalb bei erfüllten verpflichtenden Ende-zu-Ende-Anfragen Cache-Control: no-cache="Ext". Für HTTP/1.0-Proxys kam ein bereits abgelaufenes Expires hinzu. Hing eine Antwort von einem numerisch präfigierten Feld ab, musste Vary sowohl dieses Feld als auch seine Deklaration nennen.

Jede Regel schloss einen Weg, auf dem Bedeutung entfernt, falsch zugestellt oder wiederholt werden konnte. Gemeinsam zeigten sie jedoch auch den Aufwand eines generischen Systems, das Clients, Ursprungsserver, Proxys, Caches und mehrere HTTP-Generationen koordinieren sollte.

Vom Versuch zum historischen Eintrag

Schon die IESG-Notiz der RFC war zurückhaltend. Der Entwurf hatte Proposed Standard angestrebt, doch gemischte Bewertungen und fehlender Konsens über die HTTP-Entwicklung führten zur experimentellen Veröffentlichung. Die Notiz erklärte, dies beweise nicht zwingend technische Mängel, und warnte davor, den Mechanismus als allgemeine Blaupause zu lesen.

2021 verschob die IETF RFC 2774 und weitere HTTP-Experimente nach Historic. Der offizielle Datensatz nennt abgeschlossene Experimente und fehlende Belege für weite Nutzung. IANA führt 510 nun als Not Extended (OBSOLETED); Man, Opt, C-Man, C-Opt, Ext und C-Ext sind obsoleted.

Die Quellen liefern keine Einsatzquote und keine einzelne Ursache. Sie belegen den Lebenszyklus: Der generische Mechanismus ist kein aktuelles HTTP-Verfahren.

Erweiterbarkeit blieb, der Rahmen nicht

RFC 9110 kennt weiterhin dauerhafte Erweiterungspunkte für Methoden, Statuscodes, Feldnamen, Authentifizierungsschemata und Cache-Direktiven. Explizite Register und Prüfregeln ordnen ihre Bedeutung und ihren Status, ohne die Deklarationsmatrix aus RFC 2774 wiederzubeleben.

Die bleibende Lehre ist kleiner. Eine Erweiterung muss erklären, ob sie optional oder unverzichtbar ist, wer sie auslegt, wie Namen kollisionsfrei bleiben, was Vermittler bewahren und woran Ausführung von bloßer Zustellung zu unterscheiden ist.

HTTP 510 gehört zur Geschichte. Das Problem bleibt: Übertragene Bytes beweisen kein gemeinsames Verständnis. Das gefährlichste Missverständnis ist jenes, das Erfolg meldet.

Quellen