HTTP: Hypertext Transfer Protocol

1. Einführung: Transfer Protokoll

Nachdem in den vorangegangenen Vorträgen Art und Weise der Beschreibung und Präsentation von Information (Inhalt) für das WWW im Zentrum der Betrachtung gestanden hat, soll in diesem Vortrag die Kommunikationssprache des WWW Thema sein: Von der Frage nach der Strukturierung und Darstellung von Daten und Dokumenten kommen wir nun dazu, zu fragen, wie diese Daten (z.B. Hypertext-Dokumente) zum Nutzer transferiert werden.

Bevor die eigentliche Kommunikationssprache betrachtet wird, ist es nützlich, die Eigenschaften und Anforderungen an eine solche Sprache zu betrachten. Da diese Sprache zur Kommunikation zwischen Anwendungen bzw. Geräten dienen soll, muß ihre Definition offensichtlich sehr viel genauere Angaben über die zugelassenen Konstrukte der Sprache und deren Bedeutung (also Interpretation) treffen. Weiterhin muß neben der reinen Sprache auch das Verhalten der Kommunikationspartner (wie sie auf bestimmte Nachrichten reagieren) definiert werden. Dies geschieht üblicherweise mit Hilfe eines Protokolls:

Wenn man nun ein Protokoll für den Transfer von Dokumenten definieren möchte, so muß man sich zuerst überlegen, wer an der Kommunikation beteiligt sein soll (Kommunikationspartner). Im Rahmen des Transfers von Dokumenten ist diese Antwort recht schnell gefunden: Die Kommunikation findet zwischen genau einem Nutzer und genau einem Diensterbringer, der das Dokument zur Verfügung stellt, statt. Natürlich wird die eigentliche Kommunikation zwischen dem sogenannten »User Agent«, der die Anforderungen des Nutzers in die verwendete Kommunikationssprache übersetzt, und einem Dienstserver, der die Anfragen verarbeitet und eine Antwort generiert, stattfinden, so daß weder Diensterbringer noch Nutzer eine genaue Kenntnis des zur Kommunikation verwendeten Protokolls benötigen (vgl. Abbildung 1).

1.1. Grundanforderungen an ein Transfer Protokoll in einem globalen Netz

Mit Hilfe dieser grundlegenden Architektur kann man nun leicht einige wesentliche Anforderungen an ein Transfer Protokoll für Ressourcen (z.B. Dokumente, Bilder, Dateien etc.) in einem weltweiten Netz aufstellen:

1. Pull-Kommunikation: Anders als bei Mail-Protkollen (SMTP) soll die Kommunikation durch den Client und nicht durch den Server initiiert werden. Der Server soll jederzeit auf Anfragen von Clients antworten können.
   In der letzten Zeit gibt es allerdings ein wachsendes Bedürfnis für Push-Techniken, bei denen der Erzeuger von Daten (z.B. beim Eintreten bestimmter Ereignisse) die Kommunikation initiieren kann.
2. Uniforme Identifizierung: Ressourcen müssen in einem globalen Netz uniform, eindeutig und verlässlich identifizierbar sein, sie dürfen nicht von Standort oder Kontext des Nutzers abhängen.
3. Uniforme Adressierung: Ressourcen müssen in uniformer und eindeutiger Weise adressierbar sein, so daß sie von jedem beliebigen Client abgerufen werden können.
   Man beachte, daß uniforme Adressierung nicht sofort uniforme Identifizierung bedingt (mit der Adresse als Identifikator), da Identifikatoren verlässlich sein sollen, während für Adressen dies nicht gewährleistet sein muß (und ist), d.h. Identifikatoren sollen konstant auf die gleiche Ressource zeigen, während sich die Adresse einer Ressource während ihrer Lebenszeit ändern kann.
4. Zuverlässiger Transport: Es muß sicher gestellt sein, daß eine durch den Nutzer angeforderte Ressource vollständig und unverfälscht bei diesem ankommt.
   Diese Forderung mag selbstverständlich erscheinen, ist in einem paketvermitteltem Netz (wie dem Internet) jedoch nicht ohne erheblichen Aufwand zu erreichen und hat in ihren technischen Folgen lange Zeit zu Diskussionen geführt.
5. Keine Authentifizierung: Die zur Verfügung gestellten Daten sollen generell ohne Authentifizierung des Nutzers (oder User Agents) verfügbar sein (anders als bei Dateidiensten wie FTP).
   Auch hier hat sich in den letzten Jahren — vor allem durch die Kommerzialisierung des WWW — die Anforderung verändert, so daß mitlerweile optionale Authentifizierung gefordert wird.
6. Einfachheit: Schließlich sollte ein Protokoll für den Transfer von Ressourcen möglichst einfach sein, um auf allen denkbaren Plattformen eingesetzt werden zu können und als Grundlage für andere Anwendungen zu dienen.
   Offensichtlich steht dieses Ziel im Widerspruch zu einigen der übrigen Anforderungen, hier muß stets abgewogen werden, welche Ziele größerer Bedeutung haben (vgl. Abschnitt 4).

2. Was ist HTTP?

Ausgehend von den vorgestellten Anforderungen an ein Transferprotokoll für Ressourcen im Internet soll nun die tatsächliche Lösung, wie sie von Tim Berners-Lee 1990/91 vorgestellt und seither umfassend weiterentwickelt und verändert wurde, vorgestellt werden: HTTP. HTTP ist die standardisierte Abkürzung für das »Hypertext Transfer Protocol«, wie sie als Schema-Name in URLs (vgl. Abschnitt Ex. 1) verwendet werden darf.

Bevor wir die Realisierung und Architektur von HTTP genauer betrachten, soll der Aufgabenbereich von HTTP innerhalb der Internet-Protokolle noch einmal verdeutlicht werden. Dazu betrachte man zuerst das folgende Beispiel für einen Transfervorgang:

Angenommen ein Student möchte ein Buch bestellen. Dazu muß der Besteller (Client) das gewünschte Buch (die gewünschte Ressource) dem Verkäufer (Server) gegenüber spezifizieren. Dieser besorgt das Buch (die Daten) und sendet sie, abhängig von den Wünschen (Parametern) des Kunden (z.B. Zeit der Versendung, Verpackung, Lieferant etc.) über den Lieferanten an diesen (vgl. Abbildung 2). Entscheidend ist, daß für dieses Protokoll irrelevant ist, wie der Lieferant das Buch ausliefert (z.B. mit welchem Verkehrsmittel, auf welcher Route etc.). Von Interesse ist einzig und allein, daß der Lieferant das Buch zuverlässig in einer geeigneten Zeitspanne ausliefert.

Diese Charakteristika treffen weitgehend auch auf HTTP zu: Der Client spezifiziert nur welche Daten ihn interessieren (mittels der URL) und reichert diese Anfrage u.U. noch mit Informationen über seine Wünsche (Datenformat etc.) an. Der Server greift nach den Wünschen des Clients auf die Daten zu und sendet diese mit Hilfe eines zuverlässigen Lieferantens (TCP, vgl. Definition im folgenden Abschnitt) an den Client zurück.

2.1 Terminologie

Um die Architektur von HTTP zu verstehen ist es nötig einige Begriffe klar zu definieren (nach [Stal 2000] und [RFC 2616]).

2.2 Kommunikationsstruktur

Mit Hilfe der eben definierten Begriffe können wir nun die Struktur der Kommunikation von HTTP genauer betrachten. HTTP verwendet grundsätzlich drei Formen der Verbindung, wie sie in Abbildung 3 dargestellt sind:

1. Direkte Verbindung: In diesem einfachsten Fall wird unmittelbar eine direkte Verbindung zwischen dem User Agent und dem Origin Server aufgebaut.
2. Mittler-Verbindung: Verbindung über einen oder mehrere Mittler (Proxy, Gateway oder Tunnel), wobei die Mittler die Anfragen des User Agents interpretieren und u.U. verändern können.
3. Verbindung unter Nutzung eines Caches: Der Client nimmt Verbindung mit einem als Cache dienenden Mittler (Proxy) anstelle des Origin Servers auf. Ist die Ressource bereits gecached und noch aktuell, kann der Cache die Anfrage beantworten ohne den Origin Server zu kontaktieren.

Tatsächlich hat sich gerade diese Vielfalt an Verbindungsmöglichkeiten als ein entscheidender Faktor für den raschen Erfolg von HTTP erwiesen, da durch die zweite Verbindungsform etablierte Internetprotokolle (wie FTP) und Legacy-Systeme leicht integriert werden konnten, während die dritte Verbindungsform den Netzverkehr (vor allem aus großen Organisationen) deutlich reduzieren kann.

2.2.1 Verbindung über Mittler

Es gibt also, wie bereits festgstellt, drei Typen von Mittlern (Intermediates), wie in Abbildung 4:

2.2.2 Nutzung von Caches

Schon kurz nach der Einführung von HTTP ist deutlich geworden, daß ein in der Informatik weit verbreitetes Konzept auch für den Zugriff auf Ressourcen im Internet gilt: Nutzer (insbesondere innerhalb einer Organisation) neigen dazu, auf Ressourcen, auf die sie (oder ein anderer Angestellter, Student etc.) bereits zugegriffen haben, erneut zuzugreifen. Dieses Prinzip wird als Lokalität bezeichnet, ihm wird durch die Verwendung von Caches Rechnung getragen.

Beispiel: Angenommen zwei Benutzer A und B nutzen einen gemeinsamen Cache. Greift nun Benutzer A auf eine (cachebare) Ressource zu, so wird diese vom Origin Server geholt und im Cache gespeichert. Greift dann Benutzer B darauf zu, so muß die Ressource nicht erneut vom Origin Server geladen werden, sondern kann direkt an den Benutzer weitergegeben werden (vgl. Abbildung 5). Dadurch wird der Zugriff schneller und die Netzlast nimmt ab.

Tatsächlich hat es sich gezeigt, daß durch die intelligente Verwendung von Caches (z.B. in Proxy implementiert) der Verkehr im Internet deutlich reduziert werden kann. Um Caching effizient und sinnvoll (so sollte einen Ressource nur dann aus dem Cache gelesen werden, wenn sie sich in der Zwischenzeit nicht geändert hat) sowohl in End-Geräten (z.B. Browsern) als auch in Proxies zu unterstützen, sind einige Änderungen am ursprünglichen Entwurf von HTTP erforderlich gewesen (vgl. Abschnitt 3.2 und 3.3.2). Insbesondere muß einiger Aufwand in Kauf genommen werden, um zu verhindern, daß der Cache semantisch intransparent wirkt, also Ressourcen in anderer Form liefert als bei einem Zugriff ohne Cache (vgl. auch Abschnitt 3.3.2).

2.3 Einordnung in den Protokollstack

Nachdem wir nun gesehen haben, auf welche Weise die Kommunikation in HTTP strukturiert werden kann, ist es nötig kurz darauf einzugehen, wie der eigentliche Transport der Daten stattfindet.

Einer der großen Vorteile eines sauber definierten Protokolls ist es, daß seine Dienste selbst wieder zur Implementierung von Protokollen für Dienste höherer Ebene realisiert werden können. Dadurch ergibt sich eine Hierarchie oder Schichtung der benötigten Protokolle. Im Rahmen des Internets ist dies der TCP/IP-Protokollstack, innerhalb dessen HTTP ein Protokoll der Anwendungsschicht (Application Layer), wie in Abbildung 6 dargestellt:

Man kann der Abbildung zweierlei entnehmen: Zum einen sieht man, daß bei der Nutzung von HTTP nicht nur der Overhead durch den HTTP-Header, wie er in Abschnit 3.2 skizziert wird, sondern zusätzlich noch die Steuerinformationen für TCP, IP und eventuell darunterliegende Protokolle (z.B. ATM) übertragen werden müssen. Andererseits bietet eine solche Schichtung einen weiteren Vorteil: Solange sich das Interface gegenüber der nächsthöheren Schicht nicht ändert, können Protokolle der unterliegenden Schichten ausgetauscht werden, ohne daß die Protokolle der höheren Schichten verändert werden müssen. Dies ist z.B. bei TLS (als Ersatz für TCP) geschehen und für die (daher hier auch nicht spezifizierten) Network-Access-Protokolle üblich.

2.4 Einfache Beispielsitzung

Diese Einführung soll durch eine Beispielsitzung abgeschlossen werden, in der die einfachste Syntax einer HTTP Anfrage und der darauf folgenden Antwort dargestellt ist.
Im folgenden werden Sitzungsprotokolle mit Hilfe von telnet erzeugt, da so die Syntax von HTTP, die von üblichen User Agents verborgen wird, sichtbar wird. Eingaben des Benutzers seien durch farbigen Fettdruck und der Inhalt der HTTP-Antwort durch grünen Schriftzug markiert. Weitgehend sollten sich diese Sitzungen auf jedem UNIX-System mit Anschluß an das Internet nachvollziehen lassen, während die Windows-Version von telnet die Statusinformationen ausspart und daher für unsere Zwecke nicht geeignet ist.

In dieser Sitzung ist also GET / die Anfrage, mit deren Hilfe eine Ressource angefordert wird. Diese Ressource wird als Antwort (ohne weitere (Meta-) Informationen) übertragen. Man beachte auch, daß nach der Übertragung der Server (foreign host) unmittelbar die Verbindung bendet (vgl. Abschnitt 3.1). Hier ist Telnet der User Agent, während der Server durch den beim Aufruf von telnet gegebenen Hostnamen und Port bezeichnet wird.

3. Entwicklung von HTTP

Nach diesem kurzen Überblick über die wesentlichen Merkmale der Kommunikation mittels HTTP sei nun ein Blick auf die Entwicklung seit seiner Einführung 1990/91 gestattet.

3.1 HTTP/0.9 — Der erste Versuch

Begonnen hat die Entwicklung von HTTP, wie nicht anders zu erwarten, mit Tim Berners-Lee am CERN in den Jahren 1990/1991 (vgl. [HTTP 0.9]). Berners-Lee benötigte für sein Hypertext-System ein Transfer-Protokoll und erkannte richtigerweise, daß keines der zu diesem Zeitpunkt etablierten Transfer-Protokoll für seine Arbeit geeignet war (man Vergleiche die Anforderungsliste aus Abschnitt 1.1). Insbesondere wurde FTP aufgrund seiner Komplexität (Authentifizierung, Verbindungsorientierung etc.) für ungeeignet befunden, Berners-Lee wollte in erster Linie ein extrem einfaches Protokoll implementieren.

Aus dieser Motivation heraus entstand die ursprüngliche Implementation von HTTP, die mittlerweile als HTTP/0.9 bezeichnet wird. Die gesamte Beschreibung dieses Protokolls umfaßt nur wenige Seiten (der aktuelle Standard 180-230 Seiten): Ein Client baut eine Verbindung zu einem Server über TCP an Port 80 auf. Der Client sendet genau eine Anfrage in einer der beiden folgenden Formen:

GET document.html CRLF
GET document.html?help+me CRLF

Jede Anfrage beginnt also mit dem Wort GET, der sogenannten Methode. Keine weiteren Methoden werden unterstützt. Auf die Methode folgt, getrennt durch genau ein Leerzeichen, der Name des Hypertext-Dokuments, gefolgt durch ein CRLF als Zeilenendezeichen. Alternativ kann der Dokumentname durch einen Suchstring, der vom eigentlichen Dokumentnamen durch ein ? getrennt sein muß, erweitert werden, wobei mehrere Suchstrings durch + getrennt angegeben werden können.
Der Server darf als Antwort ausschließlich den Inhalt des Dokuments ohne jegliche Metainformationen (wie Format des Inhalts) übertragen, wobei das Dokument ausschließlich HTML-Hypertext enthalten darf. Nach der Übertragung des Inhalts muß der Server unmittelbar die Verbindung schließen, um das Ende des Dokuments anzuzeigen. Dies ist notwendig, da keine Information über die Länge des Dokuments übertragen wird und auch kein beliebiges Dokumentendezeichen verwendet werden kann.
Es dürfte offensichtlich sein, daß die Implementation dieses Protokolls tatsächlich trivial ist.

HTTP/0.9 stellt ein gutes Beispiel für eine typischen Fehler bei der Spezifikation von Protokollen dar: Für ein Protokoll, das in einem globalen Netzwerk eingesetzt werden soll, ist die Spezifikation viel zu spezifisch. Es werden unnötig strenge Annahmen über das Format der Anfragen wie auch das Format der Dokumente getroffen, die Spezifikation schließt jegliche Erweiterungen a priori aus. Schließlich ist es auch nicht möglich, dem Server weitergehende Informationen über den Client oder dessen Wünsche mitzuteilen, was sich bald als größter Nachteil erweisen sollte.
Als folgenreicher, weil schwerer zu beheben und in seinen Konsequenzen lang nicht klar erkannt, hat sich jedoch die Entscheidung erwiesen, zur Kennzeichnung des Endes eines Dokumentes das Ende der TCP-Verbindung zu benützen. Damit muß für jede Anfrage von einem Client A an einen Server B eine neue TCP-Verbindung aufgebaut werden, auch wenn A wiederholt Anfragen an B stellt. Leider wird aber gerade dieser Fall nach dem Prinzip der Lokalität häufig vorkommen. Dies hat zu einer merklich höheren Last im Netz wie auf den HTTP-Servern geführt und wird erst in jüngster Zeit kompensiert (vgl. Abschnitt 3.1).

Eine wichtige, aber bis heute gültige Einschränkung von HTTP, die sich im Gegensatz zu den übrigen als sehr segensreich erwiesen hat, da sie die Implementation und Wartung von Webservern deutlich erleichtert, ist schließlich das Fehlen von Zustandsinformationen. Eine HTTP-Anfrage besitzt keinen Zustand, ein Web-Server »weiß« nichts von vorhergehenden Anfragen eines Clients und soll eine Anfrage immer in der gleichen Weise behandeln. Offensichtlich vereinfacht dies die Operationen mittels HTTP beträchtlich. Auch diese Einschränkung wird jedoch kontrovers diskutiert und ist bereits z.T. durch die Einführung von Cookies aufgehoben worden, die jedoch nicht zum offiziellen Standard gehören (vgl. [RFC 2109]).

3.2 HTTP/1.0 — Der Weg zum Standard

All diese Einschränkungen legen eigentlich nahe, daß die Anpassung des Standards zur Unterstützung der fehlenden Möglichkeiten rasch geschehen hätte sollen. So hat Berners-Lee selbst schon 1992 ein Dokument vorgelegt, in dem er die Anforderungen an ein »richtiges« Transfer-Protokoll für das WWW vorgelegt hat. Zentrale Idee dabei war es, daß nicht nur Hypertext, sondern Hypermedia-Dokumente, also Dokumente in allen denkbaren Datenformaten, übertragen werden können. Um dies zu ermöglichen, muß jedoch das Protokoll eine Möglichkeit bereitstellen, daß (1) der Client anzeigen kann, welche Datenformate er verarbeiten kann, und (2) der Server die übertragenen Daten mit Metainformationen z.B. über das Format anreichern kann.

Tatsächlich dauerte jedoch die Entwicklung dieses neuen Protokolls (das so wenig mit dem alten HTTP/0.9 gemein hatte, daß man die Unterstützung von Anfragen im alten Format explizit als Kompatibilitätsmodus fordern mußte) über vier Jahre und wurde erst im Mai 1996 durch die IETF (Internet Engineering Task Force), allerdings nur als Informational RFC ([RFC 1945]) fixiert — also nicht als echter Standard, sondern nur zur Beschreibung der empfehlenswerten (und üblichen) Nutzung von HTTP, in dieser Hinsicht vergleichbar zu HTML 3.2. Einer der Gründe, daß man sich scheute ein normatives RFC (Request for Comment, entspricht etwa einer Recommendation des W3C, allerdings in erster Linie für die eher technischen Seiten des Internets verwendet) zu publizieren, war die andauernde Unzufriedenheit über die Realisierung von HTTP. Diese wurde erst durch HTTP/1.1 teilweise beseitigt.

Um die Änderungen gegenüber HTTP/0.9 vorzustellen, sei eine Beispielsitzung gezeigt, die ebenfalls die GET-Methode verwendet:

Die beiden auffälligsten Änderungen sind die Versionsnummer in der Anfrage und die vom Server gesendeten Informationen vor dem Dokument. Was also sind nun die wesentlichen Neuerungen in HTTP/1.0?

Strukturiertes Nachrichten-Format:

Die Erweiterungen haben es nötig gemacht, das Nachrichtenformat von Antworten und Anfragen genauer zu spezifizieren, wie es in Abbildung 7 dargestellt wird: Der Rumpf einer Nachricht enthält die Entität (also die konkrete Instanz der Ressource), gegliedert in Entity-Header, in dem Metainformationen wie Länge, Format etc. über die Entität angegeben sind, und den Rumpf der Entität. Eine Anfrage besteht aus einer Request-Line, in der die HTTP-Methode, die URI und die Version des HTTP-Protokolls angegeben wird, einem General-Header, in dem sowohl für Antworten als auch für Anfragen geltende Informationen angegeben werden, einem Request-Header mit den anfragespezifischen Headerfeldern und einer Entität, eine Antwort aus einer Status-Line, welche die verwendete Version des HTTP-Protokolls, den Fehlercode und die Reason-Phrase enthält, einem General-Header, einem Antwort-Header und der Entität.

Bedingte Anfragen:

Eine wichtige Erweiterung ergibt sich ganz natürlich: Bedingte Anfragen. Wie in der Beispielsitzung gezeigt, kann der Header durch das Feld Is-Modified-Since ergänzt werden. Eine Ressource wird dann nur übertragen, wenn sie seit dem angegebenen Datum verändert worden ist.
Bedingte Anfragen sind besonders für Caches von großer Bedeutung, da sie eine einfache Möglichkeit bereitstellen, zu überprüfen, ob einen im Cache gespeicherte Ressource noch gültig ist, sich also seit der Speicherung nicht verändert hat. Jedoch ist damit immer noch eine nennenswerte Verzögerung durch die Anfragen an den Origin Server verbunden.

Content Negotiation:

Unter Content Negotiation versteht man die Aushandlung eines Datenformats zwischen Client und Server, in dem eine angeforderte Ressource übertragen werden soll. Diese Erweiterung ist die Voraussetzung für die Entwicklung des WWW zu einem Hypermedia-System gewesen und daher von entscheidender Bedeutung.
Einerseits kann der Client in HTTP/1.0 die Anfrage um zusätzliche Informationen erweitern, insbesondere kann er über das Header-Feld Accept angeben, welche Datenformate er für die angeforderte Ressource vorziehen würde. Die Reaktion des Servers, falls die Ressource in keinem der angegebenen Datenformate vorliegt, ist im Standard nicht spezifiziert. Üblicherweise wird die Ressource in einem der auf dem Server vorhandenen oder erzeugbaren Formate übertragen, da der Standard keinen Fehlercode (s.u.) für diesen Fall vorsieht.

Umgekehrt sieht man, daß der Server zusätzlich zu den eigentlichen Daten noch eine Anzahl Metainformationen über die Daten wie über sich selbst versendet. Insbesondere spezifiziert der Server hier das tatsächliche Format der übertragenen Daten und andere Informationen über diese (Länge, Gültigkeit etc.). Dadurch ist es erst möglich geworden, neben Hypertext auch andere Daten wie Bilder, Ton, Videos etc. zu übertragen und darzustellen. Wie wichtig diese Erweiterung ist sieht man an der Präambel des HTTP/1.0-RFCs:

The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. [RFC 1945]

Erweiterung der HTTP-Methoden:

Die Erweiterung von HTTP-Antworten durch Metainformationen legt sofort nahe, eine Methode zur Verfügung zu stellen, nur diese Metainformationen anzufordern. Dies geschieht durch die HEAD-Methode, wie in der folgenden Beispielsitzung dargestellt (es wird die gleiche Ressource wie in der letzten Sitzung angefragt):

tim@orodreth:~ > telnet jigsaw.w3.org 80
Trying 138.96.249.65...
Connected to jigsaw.w3.org.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Sun, 16 Jul 2000 11:28:41 GMT
Content-Length: 4097
Content-Location: http://jigsaw.w3.org:80/Overview.html
Content-Type: text/html;charset=ISO-8859-1
Etag: "mvanct:s0m02tu0"
Last-Modified: Wed, 05 Jul 2000 15:32:00 GMT
Server: Jigsaw/2.1.0
Connection closed by foreign host.

Verwendung findet diese Methode vor allem bei der maschinellen Verarbeitung von Webseiten, z.B. durch Spiders, die tote Links aufspüren sollen.

Eine weitere naheliegende Erweiterung wird durch die Erweiterung von HTML mit Formularen (die bekanntlich in diese Zeit fällt) nahegelegt: Die POST-Methode erlaubt es dem Client größere Mengen an Daten an den Server zur Verarbeitung zu senden. Bisher waren solche Informationen in der URL übertragen worden (nach dem Query-Indikator ?), wodurch der Aufwand für das Parsing der URL wächst, Leerzeichen, Zeilenumbrüche und andere in URLs nicht zugelassene Zeichen maskiert werden müssen. Dadurch ist es nun möglich gewesen Formulare, Studien etc. im WWW zu veröffentlichen und zu verarbeiten.
Neben diesen drei wichtigen Methoden sind noch einige in der RFC als »zusätzlich« bezeichnete Methoden definiert worden, die z.B. zum Löschen, Verschieben etc. von Ressourcen dienen sollten, sich aber vor allem wegen der schlechten Authentifizierungsmöglichkeiten von HTTP nicht auf breiter Basis durchgesetzt haben. Ein Beispiel sei hier gezeigt:

tim@orodreth:~ > telnet jigsaw.w3.org 80
Trying 138.96.249.65...
Connected to jigsaw.w3.org.
Escape character is '^]'.
DELETE / HTTP/1.0
HTTP/1.1 405 Method Not Allowed
Date: Sun, 16 Jul 2000 11:29:23 GMT
Content-Length: 26
Content-Type: text/html
Server: Jigsaw/2.1.0
Method DELETE not allowed.Connection closed by foreign host.

Einführung von Fehlercodes:

Die gerade gezeigte Sitzung demonstriert auch die nächste nennenswerte Erweiterung: Der Server muß jede Antwort mit einem Status-Code und einer Reason-Phrase versehen, die anzeigen, ob die Anfrage korrekt verarbeitet werden konnte (200 ok) oder ob und welcher Fehler aufgetreten ist. Dadurch ist es dem Client u.U. möglich geeignete Maßnahmen zu ergreifen oder wenigstens dem Nutzer eine sinnvolle Fehlermeldung (wie das berüchtigte 404 Not Found) zu liefern.

Rudimentäre Authentifizierung:

Die letzte Erweiterung schließlich ermöglicht die Beschränkung des Zugriffes auf Ressourcen. Ein Server kann einen Client auffordern, Benutzername und Passwort zu übertragen, bevor eine bestimmte Ressource gesendet wird. Es wird also eine einfache Authentifizierung über ein sogenanntes shared secret bereitgestellt. Da diese Form der Authentifizierung für ein globales Netz zumindest problematisch ist (wie wird das Passwort sicher vereinbart?), das Passwort unverschlüsselt übertragen wird und der Server sich dem Client gegenüber nicht authentifizieren kann (so daß der Client nicht sicher sein kann, ob er an den echten Server sein unverschlüsseltes Passwort sendet) bietet diese Technik keine adäquate Sicherheit und soll in HTTP/1.1 nicht mehr verwendet werden (s.u.). Bei fehlender oder falscher Authentifizierung wird der Statuscode 403 Forbidden generiert, wie die folgende Sitzung zeigt:

tim@orodreth:~ > telnet www.pms.informatik.uni-muenchen.de 80
Trying 129.187.214.81...
Connected to www.pms.informatik.uni-muenchen.de.
Escape character is '^]'.
GET /studinfo/ HTTP/1.0
HTTP/1.1 403 Forbidden
Date: Sun, 16 Jul 2000 11:30:34 GMT
Server: Apache/1.3.6 (Unix)  (SuSE/Linux) mod_ssl/2.3.11 OpenS
SL/0.9.3 PHP/3.0.11 mod_perl/1.19
Content-Location: forbidden.de.shtml
Vary: negotiate, accept-language
TCN: choice
Connection: close
Content-Type: text/html
Content-Language: de
Expires: Sun, 16 Jul 2000 11:30:34 GMT
<HTML>
<HEAD>
<TITLE>Error 403!</TITLE>
<!-- Changed by: Lars Eilebrecht -->
[...]

Diese Erweiterungen sind heute der Kern von HTTP und haben den ungeheuren Erfolg des Internets als Hypermedia-System erst ermöglicht:

This Hypertext Transfer Protocol (HTTP) made it very easy for any computer on the Internet to safely offer up its collection of documents into the greater whole; using HTTP, a computer that asked for a file from another computer would know, when it received the file, if it was a picture, a movie, or a spoken word. With this feature of HTTP, the Internet began to reflect an important truth—retrieving a file's data is almost useless unless you know what kind of data it is. In a sea of Web documents, it's impossible to know in advance what a document is—it could be almost anything—but the Web understands »data types« and passes that information along.
Mark Pesce, 1995.

3.3 HTTP/1.1 — Standardisierung und Evolution

Neben den unbestreitbaren Vorzügen dieser Erweiterungen haben diese jedoch auch unzählige Probleme mit sich gebracht (eben da es sich nicht um durchdachte Lösungen, sondern um eine Beschreibung der vorhandenen, z.T. nur mit Aussicht auf schnellen kommerziellen Erfolg entwickelten Ansätze handelt). Insbesondere haben diese Erweiterungen zu einer Explosion des Netzverkehrs geführt, da erstens aufwendigere (Bild-) Daten übertragen werden und zweitens für die Darstellung einer Seite durch Browser (und andere Endnutzer-Anwendungen), die nur zum Ziel haben, die Seiten möglichst schnell darzustellen, häufig mehrere parallele Verbindungen zu dem Origin Server einer Ressource geöffnet werden (z.B. für die Teile einer Frame-Seite oder für Bilder), wodurch nicht nur deutlich mehr Bandbreite verbraucht wird, sondern auch die Server drastisch stärker belastet werden.
Schließlich haben sich durch das Wachstum des Internets die technischen Probleme von HTTP/1.0 noch verschärft, so daß die HTTP-Arbeitsgruppe der IETF bereits 1995 die Arbeit an einem echten Standard, der einen Großteil der Probleme entschärfen sollte, aufgenommen hatte. Diese Entwicklung hat schließlich bereits 1997 in HTTP/1.1 geendet.

Nach dieser kurzen Motivation soll nun ein Überblick über die Neuerungen von HTTP/1.1 (angelehnt an [Kris 1998]) gegeben werden.

3.3.1 Verbindungsmanagement

Wie in Abschnitt Ex. 1 dargestellt, treten bei der Nutzung von HTTP/1.0 über TCP durch den Aufbau einer Verbindung pro Anfrage erhebliche Probleme auf. Einige Implementationen von HTTP haben versucht, durch Verwendung des Keep-Alive-Headerfeldes, das anzeigen soll, daß eine Verbindung offengehalten werden soll, diese Probleme zu behandeln. Jedoch ist dies von Mittlern wie Proxies und Gateways nicht beachtet worden, so daß man bei der Entwicklung von HTTP/1.1 einen umfassenden Lösungsansatz entwickelt hat: Persistente Verbindungen (persistent connections).
Es wird also eine einzige Verbindung für alle Anfragen eines Clients an einen Server verwendet. Die Vorteile sind offensichtlich:

• Es werden weniger TCP-Verbindungen geöffnet und geschlossen, wodurch der Verarbeitungsaufwand in Routern und Hosts (Clients, Servern, Proxies etc.) sinkt.
• Die Belastung des Netzwerks wird durch Vermeidung des Overheads für die TCP-Verbindungen und die Umgehung des Slow-Start-Problems reduziert.
• Anfragen auf einer bereits offenen Verbindung können schneller beantwortet werden (TCP-Handshake fällt weg — vgl. Abbildung 8).
• Während bisher eine Fehlermeldung auch sofort den Abbau der Verbindung bedeutet hat, ist es nun möglich, Fehler in Zusammenarbeit zwischen Client und Server zu behandeln, ohne allzu große Geschwindigkeitseinbußen.

Durch persistente Verbindungen allein kann jedoch die Frage, wie eine Web-Seite mit eingebetteten Ressourcen wie Bildern effizient behandelt werden kann, nicht gelöst werden. Wie bereits bemerkt, öffnen die gängigen User Agents (Web-Browser) dazu mehrere parallele Verbindungen mit entsprechend ansteigendem Overhead, besonders falls bereits eine Stauung im Netz vorliegt. HTTP/1.1 bietet hierfür wiederum einen angemesseneren, wenn auch komplexeren Ansatz: Pipelining von HTTP-Nachrichten.
Ein Client kann nun eine weitere Anfrage stellen, ohne auf die Antworten auf vorherige Anfragen warten zu müssen. Der Server muß jedoch die Anfragen in der richtigen Reihenfolge abarbeiten und die Antworten entsprechend generieren. Dies ist nur möglich, da TCP garantiert, daß Daten in der korrekten Reihenfolge übermittelt werden. Der Client kann beliebig viele Anfragen senden, ohne eine Antwort zu erhalten, es wird hier keine Overflow-Behandlung definiert.
Offensichtlich tritt bei dieser Vorgehensweise ein Problem auf (allerdings auch bei mehreren parallelen Verbindungen): HTTP-Anfragen können Seiteneffekte haben, die dazu führen, daß darauf folgende Anfragen zu anderen Ergebnissen führen.
Angenommen eine Anfrage A füge (z.B. mittels POST) eine Ware in einen Warenkorb eines E-Shops ein, eine Anfrage B gebe den Inhalt des Warenkorbs aus. Offensichtlich kann die Ausführung von A und B in einer Pipeline zu einem falschen Ergebnis führen (Hazard). Das Protokoll überläßt es vollständig dem Client, dafür zu sorgen, daß solche Anfragen nicht gepipelined werden. Dies dürfte einer der Gründe sein, daß aktuelle User Agents (wie z.B. alle verbreiteten Browser) kein Pipelining für Anfragen verwenden, da es nicht klar ist, wie ein Client solche Abhängigkeiten erkennen kann. Leider ist nach dem HTTP-Standard weder die Implementation von persistenten Verbindungen noch von Pipelining Pflicht, beide sind nur empfohlen. Diese Entscheidung bedingt, daß einem Client, der keine persistenten Verbindungen implementiert, eine Möglichkeit gegeben wird, dies dem Server anzuzeigen: Dazu dient das Connection-Feld im Request-Header, wie in der folgenden Sitzung dargestellt, welches nur die Werte close (schließe die Verbindung sofort wieder) oder default annehmen kann

Die Quantifizierung des Nutzens vor allem von persistenten Verbindungen ist in der Forschung immer noch heftig umstritten:

Our analysis indicates that the persistent connection optimizations do not substantially affect Web access for the vast majority of users. Most users see end-to-end latencies of about 250 ms and use modem lines. At these rates, the optimizations reduce the overall transaction time by 11%. Bandwidths over 200 Kbps are required to provide user-noticeable performance improvements. [Heid 1996]

Our study has shown that on a wireless network, HTTP/1.1 doubles the throughput of HTTP/1.0, while reducing the number of packets sent by 60%. We believe this significantly improves the performance seen by the user and increases the scalability of the wireless network. In the future, wide area wirless networks are likely to remain high latency because of the inherent interference wireless networks must overcome. In addition, for these wireless networks to remain inexpensive, there will have to be many wireless routers without a wired connection to the Internet, thus causing packets to traverse several high latency wireless hops. Similarly, satellite-based wireless networks are likely to have high latency. However, these wireless networks will have greatly increased bandwidth because of more eficient use of the spectrum and the allocation of more parts of the spectrum. In such an environment, we believe that HTTP/1.1 will have even greater benefits than we have measured. [Cheng 1999]

Trotzdem unterstützen mittlerweile alle verbreiteten Clients (Browser, Proxies) und Server persistente Verbindungen, während Pipelining zwar auf Seiten der Server und Mittler unterstützt wird, durch die gängigen User Agents jedoch kaum genutzt wird, da hier erheblicher Implementationsaufwand erforderlich wäre. So baut Netscapes Navigator immer noch bis zu 6 parallele Verbindungen zu einem Server für eine Seite auf, Microsofts Internet Explorer immerhin bis zu 2.

3.3.2 Effizientes Caching

Schon früh ist deutlich geworden, daß ein effizientes Caching einen großen Beitrag zur Verringerung der Antwortzeiten und der Netzlast beitragen kann. Effizientes Caching setzt jedoch eine umfassende Kenntnis der zu cachenden Ressource voraus, da nur so verläßlich entschieden werden kann, was wie lange gecached werden darf. Eine solche Kenntnis besitzt i.a. nur der Origin Server einer Ressource, daher ist es für effizientes Caching nötig, daß der Origin Server volle Kontrolle über das Caching seiner Ressourcen erhält.

HTTP/1.1 fügt der einfachen und z.T. undurchdachten Unterstützung von Caches in HTTP/1.0 eine ansehnliche Anzahl weiterer Steuerungsmöglichkeiten hinzu, so daß heutige Proxy-Caches eine Trefferrate von 20-40% erreichen (was nahe an der oberen Grenze von 30-50% liegt, vgl. [Abra 1995]

Ein Problem der bisher verwendeten Caching-Methoden ist die Verwendung von absoluten Zeitstempeln (z.B. im If-Modified-Since- oder Expires-Headerfeld), die in einem globalen Netz (aufgrund von Verzögerung, fehlender Synchronisation etc.) zu semantisch intransparentem Verhalten des Caches führen können. Daher verwendet HTTP/1.1 zum einen relative Zeitangaben (max-age), zum anderen einen neuen Mechanismus zur Revalidierung einer Ressource: Jeder Entität wird ein Etag oder Entity-Tag durch den Origin Server zugeordnet (dieses muß eindeutig sein). Zur Revalidierung sendet der Cache eine bedingte Anfrage mit If-Match-Feld, wie in der folgenden Sitzung:

Die meisten übrigen Erweiterungen (wie der Cache-Control-Header) erlauben dem Origin Server genau zu spezifizieren, ob, wie lange, für wen etc. eine Antwort vorgehalten werden darf. Generell gilt, daß nur Antworten auf GET- und HEAD-Anfragen gecached werden dürfen, außer der Origin Server erlaubt explizit Caching.
Zur genauen Bedeutung der verschiedenen Headerfelder zur Steuerung eines Caches vergleiche man [RFC 2616] bzw. [Stal 2000].

Auch wenn es scheinen mag, daß die Komplexität der Caches durch diese Erweiterung deutlich anwächst, ist dies nicht der Fall. Indem die Kontrolle über das Cacheverhalten bezüglich einer Ressource durch den Origin Server übernommen wird, werden die Caches sogar entlastet. Dies ist besonders bei Proxy-Caches von großem Vorteil. Schließlich können nun auch Anfragen mit Nebeneffekten, die bisher häufig zu semantischer Intransparenz geführt haben, korrekt behandelt werden.

3.3.3 Erweiterbarkeit

Ein zentrales Ziel bei der Entwicklung von HTTP/1.1 resultiert aus den bitteren Erfahrungen mit verschiedenen nur teilweise kompatiblen Versionen von HTTP/1.0, die immer wieder zu erheblichen Problemen geführt hatten. Um diese Probleme künftig so weit wie möglich zu umgehen und gleichzeitig die Entwicklung von Erweiterungen zu erleichtern, legt HTTP/1.1 großen Wert auf Erweiterbarkeit.

Wie schon bei HTTP/1.0 ist es möglich, die Header-Felder zu erweitern, ohne dadurch bestehende HTTP-Anwendungen zu beeinträchtigen, da diese unbekannte Header-Felder ignorieren dürfen. Gleichzeitig wird nun eine Möglichkeit gegeben auch weitere Methoden hinzuzufügen. Dazu gibt es eine neue Methode OPTIONS, die Auskunft über die unterstützen Methoden einer Ressource (OPTIONS URI) oder eines Servers (OPTIONS *) gibt:

Das gerade gegeben Beispiel zeigt auch, daß selbst der vom W3C entwickelte Jigsaw-HTTP-Server die RFC 2616 nicht korrekt umsetzt: Das Headerfeld Public darf nicht länger verwendet werden und es gilt für die Antwort auf eine OPTIONS-Methode: »If no response body is included, the response MUST include a Content-Length field with a field-value of "0".« [RFC 2616]

Von einem echt erweiterbaren Protokoll ist HTTP jedoch noch weit entfernt, dies wird als ein bedeutsamer Nachteil angesehen und soll in kommenden Versionen korregiert werden (vgl. Abschnitt 4).

3.3.4 Optimierung der Bandbreite

HTTP/1.0 verschwendet in vieler Hinsicht Bandbreite im Netzwerk, nicht nur durch die ineffiziente Nutzung von TCP (vgl. Abschnitt Ex. 2): Zum einen wird eine Ressource stets komplett an den Client übertragen, auch wenn dieser nur einen Teil davon benötigt. Umgekehrt wird eine große Anfrage (z.B. eine PUT- oder POST-Operation) stets komplett übertragen, auch wenn der Server diese nicht verarbeiten kann. Beide Probleme werden in HTTP/1.1 angegangen.

Wenn ein Client nur einen Teil einer Ressource benötigt (z.B. nur den Beginn eines Dokuments), erlaubt HTTP/1.1 ihm dies durch sogenannte Bereichsanfragen (range requests): Mit Hilfe des Range-Headerfelds spezifiziert der Client den Bereich der Ressource, an dem er interessiert ist. Dieser Mechanismus ist zwar auf beliebige Einheiten erweiterbar (z.B. Kapitel eines Dokuments), jedoch in HTTP/1.1 nur für Bytes realisiert, da über andere Einheiten keine Einigung erziehlt werden konnte (u.a. da es nicht klar ist, wie andere Einheiten definiert werden sollen, vgl. Abschnitt 4).
Bereichsanfragen für Bytes können auf unterschiedliche Weise verwendet werden, z.B. um

• den Anfang eines Bildes einzulesen, um seine Ausdehnung zu bestimmen und damit das Seitenlayout festzulegen, ohne das gesamte Bild lesen zu müssen.
• einen unterbrochenen Transfer wiederaufzunehmen.
• das Ende eines sich permanent vergrößernden Objekts zu lesen.

Dies ist wiederum eine Fähigkeit von HTTP/1.1, die nicht implementiert werden muß, aber empfohlen wird.
Die folgende Beispielsitzung zeigt die Verwendung des Range-Feldes und die Antwort eines Servers auf diese Anfrage (mit 206 Partial Content), wobei die erste Anfrage die letzten 20, die zweite die ersten 200 Bytes derselben Ressource anfordert:

Es wäre wünschenswert, daß bei der Anforderung einer URI, die einen Fragmentindikator (#) enthält, nur dieses Fragment übertragen wird und nicht die gesamte Ressource. Dies ist jedoch in HTTP/1.1 nicht möglich, vielmehr spezifiziert das Protokoll, daß eine URI tatsächlich ohne Fragmentindikator und Fragmentidentifikator an den Server gesendet, die gesamte Ressource zum Client übertragen wird und schließlich der Client den Fragmentidentifikator auswertet. Diese Vorgehensweise wird durch die Realisierung von Fragmenten in HTML erzwungen (es ist nicht klar, wie weit ein Fragment reicht, da nur sein Beginn über einen Anker definiert ist). Es besteht jedoch die Hoffnung, daß es durch Techniken im Umfeld von XML (XPointer) möglich wird, tatsächlich nur die erwünschten Fragmente zu übertragen (vgl. Abschnitt 4).

Umgekehrt erfordern einige HTTP-Anfragen (wie z.B. die PUT- oder POST-Methode) Anfragerümpfe beliebiger Länge. Wenn der Server eine solche Anfrage nun ablehnt, z.B. aufgrund eines Authentifikations-Fehlers, wird eine nennenswerte Menge Bandbreite für die Übertragung des großen Anfragerumpfs verschwendet.
Dies wird vermieden, indem der Client das Feld Expect: 100-continue zu seiner Anfrage hinzufügt, und der Server darauf entweder mit einer Fehlermeldung (falls die Anfrage nicht verarbeitet werden kann) oder mit 100 Continue antwortet, was der Client wiederum mit dem eigentlichen Anfragerumpf beantwortet.

Schließlich bietet HTTP/1.1 endlich eine sinnvolle Möglichkeit, Bandbreite durch Kompression der zu übertragenden Daten zu reduzieren. Es ist gezeigt worden, daß sich durch aggressiven Einsatz von Kompression 40% der mittels HTTP übertragenen Daten einsparen lassen. HTTP/1.1 unterscheidet zwischen

• Content-Encoding: End-zu-End Codierung, die bereits durch das ursprüngliche Format der Ressource gegeben sein kann. Hierbei wird die Ressource im Origin Server codiert und im User Agent decodiert.
• Transfer-Encoding: Hop-by-Hop Codierung. Hierbei wird der Nachrichtenrumpf nur für den direkten Transfer von einem Client zu einem Server (z.B. Origin Server zu Gateway) codiert.

Diese Unterscheidung ist sinnvoll, da es so möglich ist, auf verschiedenen Teilstrecken unterschiedliche Codierungen zu verwenden, z.B. wenn ein beteiligter Client nur identische Codierung unterstützt.

Während bereits HTTP/1.0 eine Möglichkeit die Codierung einer Ressource anzugeben (Content-Encoding Header) bot, ist erst durch HTTP/1.1 dieser Mechnismus effektiv nutzbar, da es ermöglich wird (über das Accept-Encoding-Feld im Anfrage-Header) die durch den User Agent unterstützen Codierungen anzugeben. Analoge Möglichkeiten gibt es auch für das Transfer-Encoding.

Die folgende Sitzung illustriert verschiedene Transfer-Encodings (gzip, deflate, Identität) für dieselbe Ressource. Da beide verwendeten Kompressionsverfahren adaptiv sind und die Ressource sehr repetitiv ist, ist auch der Gewinn durch die Kompression sehr hoch:

3.3.5 Fragmentierte Nachrichten

HTTP-Nachrichten können einen Rumpf beliebiger Länge enthalten, so daß ein Mechanismus definiert werden muß, um das Ende einer Nachricht zu bestimmmen. HTTP/1.0 stellt dafür den Content-Length Header zur Verfügung, der die Länge des Nachrichtenrumpfes enthält. Dazu muß aber offensichtlich die Länge der Entität bereits im voraus bekannt sein, was bei dynamisch generierten Entitäten nicht der Fall ist. Bisher mußten solche Entitäten vollständig generiert und gepuffert werden, um ihre Länge zu berechnen und konnten erst dann verschickt werden, wodurch die Antwortzeit (bei großen Antworten deutlich) anwächst. Bei HTTP/1.0 ist dies noch kein bedenkliches Problem gewesen, da der Content-Length Header nicht notwendig gewesen ist, das Ende der Nachricht ist ja durch das Schließen der Verbindung markiert worden. In HTTP/1.1 ist dies nicht mehr sinnvoll, daher ist eine bessere Möglichkeit entwickelt worden, die fragmentierte Transferkodierung (Chunked Transfer-Encoding):
Der Sender zerlegt die Nachricht in Fragmente beliebiger Länge, die mit ihrer Länge verschickt werden, wobei ein leeres Fragment das Ende der Nachricht bezeichnet (vgl. Abbildung 9). Der Sender markiert eine fragmentierte Nachricht durch den Header Transfer-Encoding: chunked.
Dadurch kann der Sender jeweils nur kleine Teile der Nachricht puffern, ohne daß merklich Komplexität oder Overhead hinzugefügt wird. Aufgrund der Einfachheit dieser Lösung müssen alle HTTP/1.1-Implementationen dieses Verfahren unterstützen.

Die folgende Beispielsitzung zeigt eine Antwort in fragmentierter Transfer-Kodierung, wobei das erste Fragment die Größe 789 besitzt:

Ein Beispiel für die Verwendung von fragmentierten Nachrichten ist die Antwort auf die neue Methode TRACE, die einfach die Anfrage als Antwortrumpf wieder zurückgibt:

Einige HTTP-Headerfelder (z.B. ETag) erfordern die Kenntnis des Inhalts der gesamten Nachricht. Um dafür wieder nicht die ganze Nachricht puffern zu müssen, führt HTTP/1.1 bei fragmentierten Nachrichten einen Trailer ein, in dem solche Felder übertragen werden können, wobei im Header ein Verweis auf die Trailer-Felder existieren muß.

3.3.6 Einsparung von IP-Adressen

Mit dem Anwachsen des Internets wächst auch die Anzahl an Hostnamen (wie www.w3.org) dramatisch an. Die Anzahl an Hostnamen ist unbegrenzt, nicht jedoch die Anzahl an IP-Adressen. Daher erlaubt das Domain Name System (DNS) mehrere Hostnamen an dieselbe IP-Adresse zu binden. Leider jedoch ist auch dies in der Entwicklung von HTTP vernachlässig worden: HTTP/1.0-Anfragen übergeben den Hostnamen nicht als Teil der Anfrage-URL. Will ein Nutzer beispielsweise die Ressource an der URL http://example1.org/home.html betrachten, so sendet der Browser im wesentlichen nur die Anfrage
GET /home.html HTTP/1.0
an den Server example1.org. Da der Hostname des Servers zu einer IP-Adresse aufgelöst wird, bevor die Anfrage gesendet wird, ist es für den HTTP-Server nicht möglich zu erkennen, an welchen Hostnamen die Anfrage gestellt wird.

Um dieses Problem in den Griff zu bekommen, erfordert eine HTTP/1.1-Anfrage die Angabe der voll-qualifizierten URL oder das Einschließen des Headers Host in die Anfrage. Also sind
GET http://example1.org/home.html HTTP/1.1
und
GET /home.html HTTP/1.1
Host: example1.org
gültige Anfragen, nicht jedoch
GET /home.html HTTP/1.1.

Wird dieser Mechanismus von allen Clients verwendet, können mehrere Hostnamen problemlos auf dieselbe IP-Adresse abgebildet werden, da mittels des Host-Headers unterschieden werden kann.

3.3.7 Erweiterung der Fehlermeldungen

HTTP/1.1 erweitert die 16 Statuscodes von HTTP/1.0 und macht sie erweiterbar. Auch wird ein neuer Header für Warnungen hinzugefügt. Die Statuscodes lassen sich in fünf Klassen unterteilen:

Durch die Fehlermeldungen der 3xx-Klasse ist es möglich, einem Client einen Hinweis zugeben, warum eine Ressource nicht mehr verfügbar ist und wo diese sich nunmehr befindet (über den Location Header):

3.3.8 Erweiterung des Content Negotiation

Wie bereits dargestellt, ist die Möglichkeit, übertragene Daten zu typisieren (über den Content-Type Header) vielleicht entscheidend für den Erfolg von HTTP gewesen. Die Möglichkeiten, das optimale Format einer Ressource für eine Anfrage zwischen Client und Server auszuhandeln (Content Negotiation) sind jedoch in HTTP/1.0 noch sehr beschränkt und nur unzureichend spezifiziert. Diesen Mangel behebt HTTP/1.1 durch eine präzise Spezifikation, wo und wie diese Aushandlung stattzufinden hat (im Server, im Client oder sogar im Cache, dann als Transparent Content Negotiation bezeichnet [RFC 2295]) und wie dabei im wesentlichen vorzugehen ist.

Insbesondere wird eine Syntax zur genauen Angabe der Vorlieben eines Nutzers verwendet, indem man zu jeder akzeptablen Variante einer Ressource (z.B. einem Format, einer Sprache etc.) einen Qualitätswert zwischen 0 und 1 angeben kann. Der Ausdruck
Accept-Language: fr, de;q=0.9, en;q=0.6, x-klingon;q=0.1
bedeutet also, daß der Nutzer am liebsten Französisch spricht, aber auch mit Deutsch sehr zufrieden ist, Englisch akzeptiert und schließlich sogar ein bißchen Klingonisch versteht.

Zur Verdeutlichung betrachte man die folgende Sitzung, die eine Ressource in verschiedenen Formaten anfordert.

Es sollte klar sein, daß durch die Möglichkeit, Qualitätswerte an die Varianten zu binden und durch die drei Dimensionen des Formats (Typ, Sprache, Kodierung) der Algorithmus zur Auswahl der besten Variante keineswegs trivial ist. Content Negotiation ist weiterhin Thema der Forschung und wird auch von einer IETF-Arbeitsgruppe weiterentwickelt.

3.3.9 Statusverwaltung

HTTP-Anfragen sind statuslos, d.h. aus der Perspektive eines Servers kann jede Anfrage (abgesehen von Seiteneffekten) als unabhängig von jeder anderen angesehen werden. Viele Webanwendungen (z.B. E-Shops) erfordern jedoch gerade diese Möglichkeit, z.B. um den Inhalt eines Warenkorbs über mehrere HTTP-Anfragen verfolgen zu können.
Daher ist durch Netscape im Navigator 1.1 das Konzept der »Cookies« eingeführt und durch die IETF (mit starken Einschränkungen) in der RFC 2109 standardisiert worden als Ergänzung zu HTTP. Statusverwaltung ist also nicht Teil des HTTP/1.1-Standards.

Der grundlegende Mechanismus ist denkbar einfach: Ein Origin Server sendet in seiner Antwort beliebige Informationen an den Client. Der Client soll für die Speicherung der Informationen sorgen und diese mit seiner nächsten Anfrage an den Origin Server zurücksenden.

Das folgende Beispiel illustriert die typische Verwendung von Cookies:

1. User Agent -> Server

   POST /acme/login HTTP/1.1
   [Daten eines Formulars]

   Der Benutzer identifiziert sich mittels eines Formulars.
2. Server -> User Agent

   HTTP/1.1 200 OK
   Set-Cookie: Customer="GAIUS_JULIUS_CAESAR"; Version="1"; Path="/acme"

   Der Cookie speichert die Identität des Nutzers, wobei durch Path angegeben wird, daß der Cookie für alle Ressourcen auf diesem Host unterhalb von /acme gilt.
3. User Agent -> Server

   POST /acme/pickitem HTTP/1.1
   Cookie: $Version="1"; Customer="GAIUS_JULIUS_CAESAR"; $Path="/acme"
   [Daten eines Formulars]

   Der Benutzer legt eine Ware in seinen Warenkorb.
4. Server -> User Agent

   HTTP/1.1 200 OK
   Set-Cookie: Part_Number="BELLUM_GALLICUM"; Version="1"; Path="/acme"

   Warenkorb enthält nun die Ware.
5. User Agent -> Server

   POST /acme/shipping HTTP/1.1
   Cookie: $Version="1";
           Customer="JULIUS_CAESAR"; $Path="/acme";
           Part_Number="BELLUM_GALLICUM"; $Path="/acme"
   [Daten eines Formulars]

   Der Benutzer legt die Versandart mittels eines Formulars fest.
6. Server -> User Agent

   HTTP/1.1 200 OK
   Set-Cookie: Shipping="IMPERIALE_FELDPOST"; Version="1"; Path="/acme"

   Der neue Cookie speichert die Versandart.
7. User Agent -> Server

   POST /acme/process HTTP/1.1
   Cookie: $Version="1";
           Customer="GAIUS_JULIUS_CAESAR"; $Path="/acme";
           Part_Number="BELLUM_GALLICUM"; $Path="/acme";
           Shipping="IMPERIALE_FELDPOST"; $Path="/acme"
   [Daten eines Formulars]

   Benutzer will die Bestellung abschicken.
8. Server -> User Agent

   HTTP/1.1 200 OK

   Transaktion ist abgeschlossen.

Neben ihrem offensichtlichen Nutzen haben Cookies in der Vergangenheit oft zu heftigen Kontroversen, insbesondere hinsichtlich Datenschutz und Sicherheit geführt. Da ihr Inhalt beliebig ist, können Cookies auch persönliche Daten wie Benutzername, Passwort etc. enthalten. Solche Informationen sind sowohl beim Transfer der Cookies, als auch auf dem lokalen Rechner gefährdet und können u.U. abgehört werden.

Neben diesen Sicherheitserwägungen können Cookies zur Überwachung des Nutzerverhaltens benützt werden (unlängst durch die Banneragentur doubleclick.com geschehen), wie das folgende Szenario zeigt:

1. Der Benutzer besucht die Seite http://www.example1.com/home.html.
2. Die zurückgelieferte Seite enthält ein Bild mit einer Referenz auf http://ad.example.com/adv1.gif, einen Werbebanner.
3. Der Browser des Benutzers lädt das Bild automatisch, die Antwort enthält einen Cookie von ad.example.com (der automatisch angenommen und gespeichert wird).
4. Der Benutzer besucht die Seite http://www.exampleB.com/home.html.
5. Auch hier findet sich eine Anzeige mit einem Verweis auf http://ad.example.com/adv2.gif.
6. Der Browser lädt das Bild automatisch, wobei der vorher angenommene Cookie wieder zurückgesendet wird. Die Antwort enthält einen neuen Cookie von ad.example.com.

Das Problem ist offensichtlich: Der Benutzer erhält einen (Third-Party-) Cookie von einer Seite, die er nicht einmal besucht hat (unverifiable transaction).
Diese Möglichkeit kann ausgenutzt werden, um das Nutzungsverhalten festzustellen, wenn nur genügend Seiten beispielsweise auf einen Werbungsserver verweisen.

Cookies, die aus unverifiable transactions stammen, sollen nach [RFC 2109] durch den User Agent zurückgewiesen werden. Diese Forderung ist jedoch auf massiven Widerstand gestossen und von den meisten existierenden User Agents nicht umgesetzt.

Da es auch technische Bedenken hinsichtlich des Cookie-Systems gibt (Overhead), wird der Standard gerade einer umfassenden Revision unterzogen.

3.3.10 Sicherheit und Integrität

Bekanntlich erlaubt HTTP/1.0 eine rudimentäre Authentifizierung, wobei jedoch Benutzername und Passwort unverschlüsselt übertragen werden. Daher ist für HTTP/1.1 eine bessere Methode entwickelt und standardisiert worden ([RFC 2617]): Digest Authentication. Die Idee ist, daß ein Server nicht einfach Benutzername und Passwort anfordert, sondern diese Anforderung durch einen nur einmal gültigen Wert anreichert (nonce). Der Client bildet nun eine Quersumme (üblicherweise nach dem MD5-Verfahren) über Benutzername, Passwort, nonce, der HTTP-Methode der Anfrage und der angeforderten URI. Die Vorteile sind offensichtlich: Das Passwort wird nicht unverschlüsselt übertragen und die Antwort ist stets nur für eine Anfrage gültig, so daß mit ihr keine anderen Anfragen authentifiziert werden können.

Auch dieses Authentifizierungsschema ist noch recht eingeschränkt, da es sich weiterhin auf ein shared secret stützt, dessen sicherer Austausch in einem globalen Netz keineswegs trivial ist. Als Ersatz für die einfache Authentifizierung in HTTP/1.0 stellt es jedoch einen großen Schritt dar.

3.3.11 Zusammenfassung

Es sollte mittlerweile deutlich geworden sein, daß sich HTTP in der Version 1.1 weit von seinen einfachen Ursprüngen entfernt hat. Die Präambel der RFC ist gegenüber der Version 1.0 fast gleich geblieben, mit einer bezeichnenden Ausnahme: Die Worte lightness und speed wurden gestrichen. So gilt HTTP/1.1 heute eher als unhandlich und ineffizient:

HTTP started out as a simple protocol, but quickly became much more complex due to the addition of several features unanticipated by its original design. [Stal 2000]

Zwar hat HTTP/1.1 einen großen Teil der offensichtlichen Probleme der ersten (informellen) Spezifikation gelöst, ist aber in vielen Bereichen inkonsequent (Erweiterbarkeit, Content Negotiation) und kann einige der selbstgesteckten Ziele nicht erreichen.

HTTP/1.1 differs from HTTP/1.0 in numerous ways, both large and small. While many of these changes are clearly for the better, the protocol description has tripled in length, and many of the new features were introduced without any real experimental evaluation to back them up. The HTTP/1.1 specification also includes numerous irregularities for compatibility with the installed base of HTTP/1.0 implementations. This increase in complexity complicates the job of client, server, and especially proxy cache implementors. It has already led to unexpected interactions between features, and will probably lead to others. We do not expect the adoption of HTTP/1.1 to go entirely without glitches. Fortunately, the numerous provisions in HTTP/1.1 for extensibility should simplify the introduction of future modifications. [Kris 1998]

Das größte Problem stellt tatsächlich aktuell die fehlende oder fehlerhafte Unterstützung der Erweiterungen in HTTP/1.1 durch die üblichen HTTP-Server und User Agents dar. Erst unlängst (August 1999) hat eine Studie über die Protokoll-Konformität üblicher Webserver erschreckende Resultate gebracht:

Our Experiments show that even though many of the popular sites claim to run HTTP/1.1, some fail the basic compliancy requirement, while others run with many of the significant improvements turned off. [Kris 1999]

In Abschnitt 3.3.3 haben wir bereits Beispiele für eine inkorrekte Umsetzung des Standards gesehen. Gerade die neuen Methoden, wie OPTIONS werden häufig nicht konform umgesetzt, andererseits werden permanent neue Features hinzugefügt, ohne die möglichen Folgen zu überblicken, wie die folgende Sitzung zeigt:

Genauso ungenügend ist die Unterstützung auf Seiten der User Agents, man betrachte dazu die folgenden Header üblicher Web-Browser:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* 
Accept-Language: de,en 
Connection: Keep-Alive 
Host: privacy.net 
User-Agent: Mozilla/4.6[de]C-CCK-MCD QXW0321j (Win98; I) 
Accept-Encoding: gzip 
Accept-Charset: iso-8859-1,*,utf-8

Accept: application/vnd.ms-powerpoint, application/vnd.ms-excel, 
    application/msword, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* 
Accept-Language: de 
Connection: Keep-Alive 
Host: privacy.net 
Referer: http://privacy.net/ 
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) 
Accept-Encoding: gzip, deflate

Accept: image/gif, image/x-xbitmap, image/jpeg, text/html, */*
Connection: Keep-Alive
Host: privacy.net
User-Agent: Mozilla/4.72 (Windows 98;US) Opera 4.0 Beta 3  [en]
Accept-Encoding: identity, *;q=0

Accept: */* 
Connection: TE,Keep-Alive 
Host: privacy.net 
User-Agent: amaya/V2.4 libwww/5.2.9 
Accept-Encoding: *,deflate 
TE: trailers,deflate

Accept: text/html, text/plain, image/jpeg, image/*,
   application/x-gunzip, application/x-gzip,
   application/x-bunzip2, application/x-tar-gz,
   video/*, text/sgml, video/mpeg, image/jpeg,
   image/tiff, image/x-rgb, image/png, image/x-xbitmap,
   image/x-xbm,image/gif, application/postscript, */*;q=0.01 
Accept-Language: en 
Host: privacy.net
User-Agent: Lynx/2.8.3dev.9 libwww-FM/2.14
Accept-Encoding: gzip, compress

Accept: multipart/alternative, multipart/mixed,
multipart/*,application/x-x509-ca-cert,
application/x-x509-user-cert,application/octet-stream,
application/dvi,application/emacs-lisp, application/x-tar,application/x-latex,
application/x-tex, application/latex,application/tex, application/texinfo,
application/zip,application/pdf, application/postscript, audio/x-mpeg,audio/*,
message/rfc-*822, image/x-xwd, image/x11-dump,image/windowdump, image/*,
text/plain, text/enriched, text/html, video/mpeg, x-world/x-vrml, archive/tar
Host: privacy.net:80 
Referer: http://privacy.net 
User-Agent: Emacs-W3/4.0pre.46 URL/p4.0pre.46 (i386-suse-linux; X11) 
MIME-Version: 1.0
Extension: Security/Digest Security/SSL 
Accept-encoding: base64, 7bit, 8bit, binary, x-compress, x-gzip,
compress, gzip, x-hqx, quoted-printabl

Man sieht, daß die Behandlung der für Content Negotiation verwendeten Header inkonsistent und nicht konform ist: Insbesondere die Verwendung von */* zusammen mit anderen Varianten ohne Qualitätswert ist nach Standard nicht sinnvoll, da die Bedeutung dann stets ist: Alle Varianten sind gleich geeignet. Eine Bevorzugung nach Reihenfolge findet nicht statt (auch wenn dies bei HTTP/1.0 üblich war und daher immer noch verwendet wird, aber selbst bei dieser Semantik ist der Accept-Encoding Header von Netscape sinnlos). Der Accept-Encoding Header von Opera ist in der durch den Standard empfohlenen Syntax.

3. Zukünftige Entwicklungen

Im Rahmen der Entwicklung der nexten Generation von Transfer-Protokollen entfaltet insbesondere das W3C eine Anzahl Aktivitäten zur Bestimmung der Anforderungen an ein solches Protokoll im Rahmen der Web Characterization Activity (http://www.w3.org/WCA/). Es wird versucht, Charakteristika des WWW festzustellen, wie (Daten aus dem Jahr 1999)

Where do all the clicks go?

50% of the clicks go to only 1% of the WWW sites visited and 80% of the clicks go to only 26% of the sites!

How fast is the Web growing?

Not as quickly as during the early years of the Web. The rapid hyper-growth of the Web from 1992 to mid 1995 has slowed to roughly gaining an order of magnitude every 30 months.

How many WWW pages are there?

NEC reports that there are 320 million pages while DEC reports that there are 275 million pages. Our analysis of the AOL log files point to approximately 200 - 250 million pages as of this writing.

How often are broken links encountered? Redirections? POSTS? GETs with appended content?

The number of broken links encountered while users surf the Web is between 5 and 8% of all clicks. The occurrence rate of redirections (when a site automatically sends your request to another locations as often occurs with advertising and legacy servers) is approximately 6 to 7% of the time. The HTTP header POST only occurred 1% of the time whereas GET requests with appended material occurred around 10% of the time. Secure links (using SSL) occupies 152 000 out of 300 million links (0.05%)! [Kris 1999]

Diese Erkenntnisse können in vielerlei Hinsicht zum besseren Verständnis der Anforderungen an ein Transfer-Protokoll führen, wenn sie richtig bewertet werden (so heißt die Inakzeptanz von SSL nicht, daß keine Sicherungstechnologie auf Transportebene erforderlich wäre, sondern daß SSL diese Aufgabe, vor allem wegen der Nutzung eines eigenen URI-Schemas (https), unzureichend erfüllt). Beispielsweise zeigt die erste Feststellung, daß Second-Level-Caches für mehrere Nutzer (Proxy-Caches) ein hohes Potential an Bandbreiten-Einsparung besitzen und weiterhin zentraler Punkt eines Transfer-Protokolls bleiben müssen.
Weiterhin läßt sich beobachten, daß viele Ressourcen sich zwar häufig, aber stets nur minimal ändern. Für solche Ressourcen läßt sich drastisch Bandbreite einsparen, wenn ein Cache, anstatt die gesamte Ressource erneut anzufordern, nur die Änderungen abrufen und auf die gespeicherte Ressource anwenden könnte (Delta-Transfer, vgl. [Kris 1997]).

Die wichtigste Schlußfolgerung aus den Erfahrungen mit HTTP/1.1 ist, daß künftige Protokollversionen so gestaltet sein müssen, daß sowohl die Hersteller von Servern, als auch von Browsern die neuen Möglichkeiten einsetzen wollen, da sonst wiederum die Umstellung zu großen Problemen führen dürfte.

Schließlich ist HTTP ein durch Menschen lesbares Protokoll in ASCII-Codierung, wodurch der Overhead zur Übertragung und zum Parsen der Nachricht deutlich anwächst:

Automatable, machine-readable messages are different from human readable messages even though they may both be encoded using ASCII strings. The choice of MIME based header encoding in HTTP has led to the general misconception that HTTP is intended as a human readable protocol. The result has been verbose messages and extremely complicated parsers. As an example, a typical HTTP request is about 250 bytes long. Due to the nature of typical Web usage, subsequent requests are often closely related leading to about 90% in redundancy between requests. This means slowing down information exchange over low bandwidth connections. [Niel 1998a]

Neben diese offensichtlichen Anforderungen an eine Weiterentwicklung treten noch einige, nicht weniger wichtige, aber sehr kontroverse Anforderungen resultierend aus der künftigen Entwicklung des WWW, von denen einige hier genannt werden sollen:

1. XML: Welchen Einfluß wird die Verbreitung von XML zur Repräsentation von Daten auf ein Transfer-Protokoll nehmen? Einerseits wird es durch XML (mittels XPointer) endlich möglich Range-Operationen nicht nur für Bytes, sondern für logische Einheiten zu verwenden, und so nur die Teile von Ressourcen zu übertragen, die auch gewünscht werden. Auch könnte sich die zu übertragende Datenmenge reduzieren, durch Separation von Inhalt und Darstellung und die Verwendung von Transformationen auf der Seite des Clients. Andererseits ist nicht klar, welchen Einfluß XML auf die Charakteristiken des Netzverkehrs haben wird (Burstiness, Anfrage-/Antwort-Struktur).
2. Substrate Protocol: HTTP wird immer stärker als Übertragungsprotokoll für neue Protokolle des Anwendungslevels verwendet (z.B. XML-RPC, SOAP, DAV). Diese Verwendung ist fragwürdig wegen des erheblichen Overheads von HTTP und Problemen mit Proxies, Caches etc.
   Insbesondere in Zusammenhang mit XML werden immer schneller leichtgewichtige Protokolle auf Basis von HTTP definiert, die HTTP auf eine vollkommen neue Weise verwenden:

   The most obvious battle over adaptive reuse, and the one that likely has the most dollars at stake, is the current battle over HTTP. The arrival of XML-RPC—and particularly SOAP—has meant that developers are treating what was once a publishing protocol, with limited two-way communications, as a full-blown peer-to-peer communications protocol. While these protocols continue to use HTTP to transport documents, the contents of those documents have been given new status in the processing of requests and responses. [...]
   
   In some ways, it's deeply ironic that SOAP and XML-RPC are reusing the HTTP protocol rather than starting fresh and building a simpler transport for XML information. The HTTP infrastructure is well-understood, incredibly widely deployed, and offers the promise of crossing firewall boundaries. Yet HTTP is also rather inefficient, subject to caching along the way, and not always the best choice for transmitting short disconnected messages.
   
   A generic XML transmission protocol, something like the Extensible Protocol, or perhaps optimized for shorter messages, seems like something that could be very useful for a wide range of XML-based communication. A generic foundation might open the way for large-scale exchange of XML messages of many different varieties, using a shared and easily internationalized infrastructure.
   (Simon St. Laurent,
   http://www.xml.com/pub/2000/06/21/disruption/index.html)

3. Extension Framework: Im Rahmen des experimentellen Extension Frameworks für HTTP (definiert in RFC 2774) wird eine Möglichkeit geschaffen, HTTP auf eine universelle Weise erweiterbar zu machen und einen Mechanismus zur Verfügung zu stellen, um die benützten Erweiterungen zwischen Client und Server auszuhandeln. Die bisher dafür definierten Mechanismus erhöhen jedoch den Protokolloverhead von HTTP erneut merklich.

All diese Entwicklungen sollen zu einer neuen Generation von HTTP führen: HTTP-ng [Niel 1998a]. Die grundlegenden Ziele sind:

• Einfachheit in den Kerngebieten zur Erhöhung der Akzeptanz.
• Erweiterbarkeit in einem verteiltem Umfeld.
• Skalierbarkeit in globalem Maßstab.
• Effiziente Nutzung der Netzwerk-Ressourcen.
• Flexibilität bei der Wahl des Transportmechanismus (z.B. TLS).

HTTP-ng soll zum Erreichen dieser Ziele eine Schichtarchitektur mit einer verteilten Plattform als Grundlage verwenden. Bisher ist jedoch nicht klar, ob und wie weit diese Ideen sinnvoll sind oder jemals umgesetzt werden. Insbesondere nehmen die bisherigen Ansätze keine Rücksicht auf die inhaltliche Entwicklung des WWWs und eine mögliche Veränderung des Nutzungsverhaltens.

Wie wird sich HTTP entwickeln?
Thus, some HTTP servers evolved so that the components no longer produced a rendering output such as WML or HTML, but a more abstract model. The components became service components. They responded to requests by producing documents structured with XML-based service document types, instead of documents structured with XML-based rendering document types. When the consumer was a ›user agent‹ (a device that interpreted the received document into something accessible to the senses), the HTTP server sent a document structured with a rendering language document type. When the consumer was another server, the document was structured with a service language document type. Both kinds of languages were still based on the XML meta-language (i.e., the common alphabet). After all, XML wasn't a language, it was more a set of rules used to create languages.
(Didier Martin, A Campfire Story,
http://www.xml.com/pub/2000/07/19/campfire/index.html)