Summary

  • Die Beschreibung des 1991 für das Web implementierten HTTP zeigt eine einzelne GET-Anfrage und ein HTML-Dokument, dessen Ende der Server durch das Schließen der Verbindung markierte.
  • Der knappe Austausch enthielt weder Statuszeile noch Header. Die damaligen Designnotizen sagen, dass auch ein Fehler als Dokument zurückkam und nur anhand seines Textes von Erfolg zu unterscheiden war.
  • HTTP ergänzte später Version, Header und Statuscodes, behielt aber die einfache Form aus Kompatibilitätsgründen bei; daraus lässt sich die Verbreitung von HTTP/0.9 nicht ablesen.

Die Seite war die ganze Antwort

In der 1991 beschriebenen World-Wide-Web-Implementierung öffnete der Client eine Verbindung zum Server. Wenn in der Adresse kein Port angegeben war, galt Port 80. Danach schickte der Client eine Zeile mit GET und der Dokumentkennung. Der Server antwortete mit einem Strom aus HTML-Bytes und schloss die Verbindung, sobald das Dokument übertragen war. Vor der Seite stand keine eigene Statuszeile, danach folgte kein Headerblock: Schon die ersten empfangenen Bytes gehörten zum Dokument.

Tim Berners-Lees archivierte Beschreibung kennt keine unsichtbare HTTP-Hülle um jede Seite. Sie nennt die Antwort eine HTML-Nachricht und sagt, dass das Schließen der Verbindung die Übertragung beendet. Ein Server konnte auch lesbaren Fehlertext in HTML ausgeben. Die Grenze wird ausdrücklich benannt: Ein Fehler ließ sich nur anhand des Textes von einer erfolgreichen Antwort unterscheiden. Der Browser konnte den empfangenen Inhalt anzeigen, aber das Drahtformat lieferte keinen maschinenlesbaren Code für „nicht gefunden“, Weiterleitung oder Serverfehler.

Die Zusammenfassung vom Juni 1992 beschreibt den Zielkonflikt. Der Browser schickte nur einen Befehl, GET, gefolgt von einer Dokumentkennung, die für einen benannten Index Suchbegriffe enthalten konnte. Der Server speicherte keinen Zustand über den Browser. Die Antwort durfte HTML oder Klartext sein und ein Dokument, ein Menü oder eine Trefferliste enthalten. Die Einfachheit war ein Vorteil: Vom Server kam nur ausgezeichnete Textausgabe. Zugleich fehlte eine sprachliche Grenze zwischen HTTP-Informationen, Dokumentinhalt und Dokumenttyp. Eine Fehlermeldung blieb ein Dokument, das Leser übersehen konnten.

Diese Mehrdeutigkeit beschreibt das Nachrichtenformat. Sie belegt weder häufige Ausfälle früher Server noch, dass Menschen Fehlerseiten nicht verstanden. Menschen konnten den Text lesen; Programmen fehlte ein Statusfeld. Außerdem markierte das Schließen der Verbindung sowohl das reguläre Dokumentende als auch den Abbruch eines unterbrochenen Austauschs. Der Client wusste, dass der Strom endete, aber nicht warum.

Auch auf statische Seiten war das frühe Design nicht beschränkt. Ein ISINDEX-Element konnte dem Browser signalisieren, eine Anfrage durch Suchbegriffe an die Dokumentkennung zu ergänzen; der Server konnte eine HTML-Trefferliste zurückgeben. In seinem Text darüber, warum ein neues Protokoll nötig war, nennt Berners-Lee außerdem Indexsuche, automatische Formatverhandlung und die Weiterleitung zu einem anderen Server als gewünschte Fähigkeiten für den Informationszugang. Das waren Ziele des umfassenderen Designs und kein Beleg dafür, dass der einfache Austausch mit einer Zeile alle diese Funktionen bereits bot.

Mehr Antwortinformationen, alte Form erkennbar

Eine öffentliche Nachricht in der Liste www-talk vom Dezember 1992 dokumentiert einen Erweiterungsvorschlag. Berners-Lee wollte, dass neue Server weiterhin GET <url> erkennen. Clients sollten in derselben Zeile ein Versionsmerkmal ergänzen und anschließend Header wie From, Accept und Accept-Encoding senden können. Sein Antwortbeispiel enthält eine Version, ein Antwortfeld, einen MIME-Inhaltstyp und erlaubte Methoden. Es handelte sich um einen Vorschlag in der Diskussion, nicht um einen endgültigen Mitschnitt des später eingesetzten Formats. Er macht jedoch deutlich, dass eine Antwort Informationen über sich selbst tragen sollte, nicht nur ihren Inhalt.

RFC 1945, 1996 als Informational RFC veröffentlicht, beschreibt später beide Formen. Die einfache Anfrage bleibt ein GET mit URI ohne Header; die einfache Antwort bleibt nur der Inhalt und endet beim Schließen der Verbindung durch den Server. Eine vollständige Antwort beginnt mit einer Statuszeile und kann Antwort- und Entity-Header enthalten. Der RFC warnt, dass der Server mit der einfachen Anfrage den Medientyp der zurückgegebenen Entität nicht angeben kann. Dass die alte Form erkennbar blieb, erlaubte späteren HTTP-Systemen Rücksicht auf ältere Clients und Server, ohne so zu tun, als hätten beide dieselbe Nachricht ausgetauscht.

Die zeitliche Einordnung zählt: Die rückblickende RFC-Definition hilft, Kompatibilität zu verstehen, beweist aber nicht, dass 1991 ein eigener HTTP/0.9-Standard verabschiedet wurde. Berners-Lee erinnerte sich später, dass der erste Webserver und die ersten Clients, darunter Nicola Pellows zeilenorientierter Browser, im Sommer 1991 zunächst der Hochenergiephysik und danach Hypertext- und NeXT-Gemeinschaften zur Verfügung standen. URI-, HTML- und HTTP-Spezifikationen seien auf dem ersten Server veröffentlicht worden, um Diskussion und Übernahme zu fördern.

Diese Quellen verorten das Experiment, zählen aber nicht die Installationen je Nachrichtenform.

Eine Antwort, die aus dem Dokument selbst bestand, machte das System leicht verständlich: Ressource anfordern, anzeigbaren Inhalt erhalten. Die Grenze wurde sichtbar, sobald ein Client die Antwort als Protokollereignis behandeln musste. Ohne Statuszeile nahmen HTML-Fehler und normale Seite denselben Platz ein. Die vollständigeren HTTP-Nachrichten trennten Ergebnis, Metadaten und Darstellung; die einfache Form blieb für Kompatibilität erkennbar.

Quellen