Zusammenfassung

  • In RFC 2068 bezeichnete die HTTP-Version das Nachrichtenformat und die höchste Fähigkeit des Senders, weitere Kommunikation zu verstehen – nicht die in dieser Nachricht tatsächlich eingesetzten Funktionen.
  • Ein Proxy, der eine Nachricht verarbeitet und weiterleitet, wird für den nächsten Abschnitt selbst zum Sender und darf nur eine Version nennen, die er auch beherrscht.
  • Ein neuerer Sender durfte einem älteren Empfänger neue Felder schicken, musste aber gewährleisten, dass nach deren Entfernung eine gültige Nachricht der älteren Version übrig blieb.

Drei Befunde in einer einzigen Startzeile

Eine aufgezeichnete Startzeile scheint zunächst eindeutig: Methode, Ziel und danach HTTP/1.1. Doch die Zahl trägt weniger und zugleich präzisere Bedeutung, als ihr oft zugeschrieben wird. Sie sagt etwas über die Nachricht aus, die gerade vorliegt, und über die Fähigkeit desjenigen, der sie gesendet hat. Sie zählt nicht auf, welche Mechanismen in diesem Austausch aktiviert wurden.

Diese Trennung war schon in RFC 1945 angelegt. Das im Mai 1996 veröffentlichte Dokument beschrieb den verbreiteten Gebrauch von HTTP/1.0 und unterschied zwischen weitgehend konsistent umgesetzten Eigenschaften und seltenen oder uneinheitlichen Erweiterungen. Zwei Programme mit demselben Versionsnamen konnten praktisch unterschiedliche Funktionsmengen besitzen. Eine Versionszahl konnte deshalb kein vollständiges Inventar ihrer Implementierung sein.

RFC 1945 erklärte sie stattdessen als Hinweis auf das Nachrichtenformat und auf die Fähigkeit des Senders, weitere HTTP-Kommunikation zu verstehen. Der Hauptteil der Nummer sollte sich ändern, wenn sich das Nachrichtenformat änderte. Der Nebenteil konnte steigen, wenn zusätzliche Semantik oder Fähigkeiten hinzukamen, ohne dass der allgemeine Parser ersetzt werden musste. Allein ein neuer Wert in einem erweiterbaren Feld verlangte noch keine neue Version.

RFC 2068 übernahm dieses Modell im Januar 1997 und band es an eine Konformitätsaussage. Die dort definierten Anfragen und Antworten sollten in ihrer ersten Zeile HTTP/1.1 tragen. Wer diese Version sendete, erklärte damit, mindestens bedingt mit der Spezifikation übereinzustimmen. Die Version einer Anwendung war die höchste HTTP-Version, für die sie diese Aussage tragen konnte.

Damit liegen in derselben Beobachtung drei getrennte Belege. Erstens zeigt die Startzeile, nach welchem Format die aktuelle Nachricht gelesen werden soll. Zweitens nennt sie eine obere Fähigkeit des aktuellen Senders für nachfolgende Kommunikation. Drittens lässt sich aus dem restlichen Inhalt feststellen, welche Mechanismen in genau dieser Nachricht vorkommen. Der dritte Befund folgt nicht automatisch aus dem zweiten.

Eine einfache HTTP/1.1-Anfrage kann ohne Chunked Transfer Coding, ohne sichtbare Inhaltsaushandlung und ohne besondere Cache-Steuerung auskommen. Ihre Versionszahl bleibt sinnvoll, weil der Empfänger weiß, welche Art von Antwort oder späterer Anfrage der Sender grundsätzlich verstehen kann. Umgekehrt beweist HTTP/1.1 weder eine dauerhafte Verbindung noch den Einsatz irgendeines einzelnen Merkmals.

Auch für die Identität oder Korrektheit einer Anwendung ist die Zahl kein Echtheitssiegel. Fehlerhafte Software kann eine zu hohe Version behaupten. Der normative Text legt fest, wie eine regelgerechte Behauptung auszulegen ist; er liefert keine kryptografische Prüfung der Implementierung. Ebenso wenig quittiert die Zahl die Zustellung an den Endpunkt, die Annahme des Inhalts, eine Speicherung oder den Erfolg einer Geschäftsoperation.

Hinter dem Proxy beginnt eine neue Aussage

Bei einem Intermediär wird aus der theoretischen Unterscheidung eine betriebliche Pflicht. Ein Proxy oder Gateway kann Felder auswerten, entfernen und hinzufügen. Er empfängt eine Nachricht und erzeugt für seinen nächsten Nachbarn eine weitere. RFC 2068 untersagte ihm deshalb, eine höhere Version als seine eigene tatsächliche Fähigkeit zu senden.

Trifft eine für ihn zu neue Anfrage ein, muss der Intermediär die Version herabsetzen, einen Fehler zurückgeben oder als Tunnel arbeiten. Bei einer älteren Anfrage darf er die Version unter passenden Bedingungen für die Weiterleitung anheben. Eine Konvertierung kann auch Felder hinzufügen oder streichen. Wer die Ausgangsnachricht baut, übernimmt also eine eigene Verpflichtung; er darf die Fähigkeit des vorherigen Clients nicht einfach ausleihen.

Ein HTTP/1.0-Proxy, der blind HTTP/1.1 kopiert, teilt dem nächsten Server etwas über sich mit, das womöglich nicht stimmt. Umgekehrt ist ein Wechsel von HTTP/1.0 auf HTTP/1.1 nicht ohne Weiteres ein Fehler: Er kann ausdrücken, dass der Proxy auf dem nächsten Abschnitt selbst HTTP/1.1 beherrscht.

RFC 2145 erschien im Mai 1997, weil Auslegung und Verwendung der Versionsnummern zu Verwirrung, Debatten und Interoperabilitätsproblemen geführt hatten. Seine knappe Folgerung lautete, dass HTTP-Versionsnummern abschnittsweise und nicht Ende-zu-Ende gelten. Ein Proxy „leitet“ die Versionsnummer einer Anfrage oder Antwort nicht im Sinne eines unveränderten Herkunftsmerkmals weiter.

Das Feld Via kann die von vorgelagerten Abschnitten gemeldeten Protokolle getrennt dokumentieren. Es erfüllt damit eine andere Aufgabe als die aktuelle Startzeile. Via macht aus ihr aber weder eine vollständige noch eine unverfälschbare Pfadchronik. Sieht der Ursprungsserver HTTP/1.1, kennt er zunächst die Aussage seines direkten Nachbarn; für die Version am Browserabschnitt braucht er Beobachtungen oder verlässliche Aufzeichnungen dieses Abschnitts.

Der Entfernungstest für neue Felder

Die Nebenversionszahl sollte innerhalb derselben Hauptversion nicht heimlich die Bedeutung bereits bekannter Felder verändern. RFC 2145 stellte diese Grenze ausdrücklich heraus. Ein Empfänger kann ein unbekanntes Feld im Regelfall ignorieren, während der gemeinsame Kern lesbar bleibt. So kann das Protokoll erweitert werden, ohne jeden älteren Teilnehmer gleichzeitig auszutauschen.

Die Freiheit des neueren Senders war jedoch an einen Test gebunden. Schickte er eine HTTP/1.1-Nachricht an einen HTTP/1.0-Empfänger oder an einen Empfänger unbekannter Version, musste nach Entfernung aller in HTTP/1.0 nicht definierten Felder weiterhin eine gültige HTTP/1.0-Nachricht übrig bleiben. Der Sender durfte neue Informationen anbieten, durfte aber nicht voraussetzen, dass der ältere Empfänger sie für das Verständnis benötigt.

Diese Regel verlagert die Kosten der Neuerung auf denjenigen, der sie einsetzt. Alte Software muss keine künftigen Erweiterungen erraten. Neue Software muss einen vollständigen älteren Kern bewahren. Das ist mehr als die pauschale Aufforderung, unbekannte Bytes zu tolerieren.

Der von RFC 2145 behandelte Grenzfall macht das deutlich: Ein HTTP/1.1-Server darf auf eine HTTP/1.0-Anfrage keine Antwort schicken, deren Aufbau von Transfer-Encoding: chunked abhängt. Wenn der alte Client nur den unbekannten Header entfernt, fehlen ihm die Regeln, um den Nachrichtenkörper korrekt abzugrenzen. Die Restnachricht wäre gerade nicht gültig.

Zudem sind unbekannte End-to-End-Felder und abschnittsbezogene Felder nicht dasselbe. Ein Proxy soll ein unbekanntes Feld normalerweise erhalten, weil ein späterer Empfänger die Erweiterung kennen könnte. Wird ein Feld dagegen in Connection genannt, gehört es zur aktuellen Verbindung und muss vor dem nächsten Abschnitt entfernt werden. Erweiterbarkeit schützt neue Ende-zu-Ende-Information; sie erlaubt nicht, lokale Verbindungsanweisungen weiterzureichen.

Was eine Klarstellung historisch belegt

RFC 2145 erklärte, es wolle den beabsichtigten Sinn von HTTP/1.0 und HTTP/1.1 nicht ändern, sondern Mehrdeutigkeiten verbindlich auflösen. Das Dokument belegt somit, dass es Reibung zwischen Spezifikation und Implementierung gab. Es nennt aber keine belastbare Zahl betroffener Produkte, keine Herstellerliste und keinen Anteil am Datenverkehr. Solche Behauptungen lassen sich aus seiner Existenz nicht gewinnen.

Die Klarstellung regelte außerdem die Versionswahl. Ein Client sollte normalerweise die höchste Version senden, für die er mindestens bedingt konform ist, ohne eine bekannte höhere Hauptversion des Servers zu überschreiten. Der Server sollte mit seiner höchsten konformen Version antworten, deren Hauptteil nicht über dem empfangenen liegt. Keine Seite darf eine Version behaupten, die sie nicht implementiert.

Für einen nachweislich fehlerhaften Peer konnte eine niedrigere Angabe als gezielte Umgehung dienen – erst nachdem das Problem beobachtet worden war. Als Voreinstellung hätte die Herabstufung korrekte Gegenstellen von neuen Möglichkeiten ausgeschlossen und fehlerhafte Implementierungen belohnt. Eine übertriebene Angabe erzeugt das umgekehrte Risiko: Der Partner baut auf eine Fähigkeit, die nicht vorhanden ist.

RFC 2616 bewahrte 1999 diese Trennung und verwies ausdrücklich auf RFC 2145. RFC 7230 formulierte 2014 noch klarer, dass die Nebenversionszahl künftige Verständigungsfähigkeit ankündigt, selbst wenn die gegenwärtige Nachricht nur eine rückwärtskompatible Teilmenge verwendet. Es hielt zudem fest, dass die Überarbeitung von RFC 2068 zu RFC 2616 keine höhere Nebenversion auslöste. Eine neue Dokumentausgabe, eine geänderte Pflicht und ein neues Signal auf der Leitung sind verschiedene Ereignisse.

RFC 9110 trennte 2022 die gemeinsamen HTTP-Semantiken weiter von den jeweiligen Syntaxen von HTTP/1.1, HTTP/2 und HTTP/3. Diese Hauptversionen bestehen nebeneinander; das Nebenversionsmodell von HTTP/1.1 lässt sich nicht schematisch auf ihre Aushandlung übertragen. Leitet ein Intermediär eine Nachricht weiter, bezeichnet die Version weiterhin das Protokoll, das er für diesen Abschnitt verwendet, während Via einen eigenen Nachweis über vorgelagerte Abschnitte liefert.

Veröffentlichung ist noch kein Betrieb

Lu Hengs spätere Formel von minimaler Ausgangsspezifikation, lokalisierten Zukunftsentscheidungen und freiwilliger Übernahme bietet dafür eine rückblickende redaktionelle Linse. Ein belastbarer gemeinsamer Kern macht Nachrichten zwischen unabhängigen Teilnehmern lesbar; jeder ausführende Teilnehmer entscheidet lokal, welche kompatiblen Möglichkeiten er nutzt. Eine veröffentlichte Erweiterung wird erst durch Implementierung, Prüfung und tatsächlichen Einsatz zur Betriebspraxis.

Das ist keine Behauptung, die HTTP-Autoren hätten Lu Hengs institutionelle oder Distributed-Ledger-Vorschläge vorweggenommen oder gebilligt. Die Analogie hält lediglich fünf Belege auseinander: verfügbares RFC, deklarierte Version, installierte Software, in einer Nachricht genutzte Funktion und vollendetes Ergebnis.

RFC 2068 machte aus HTTP/1.1 keine universelle Bescheinigung. Es ordnete eine begrenzte Zusage dem Akteur zu, der die Nachricht tatsächlich erzeugte, und verband die Einführung neuer Möglichkeiten mit der Pflicht, einen gültigen Weg für den älteren Nachbarn offen zu lassen.

Quellen