Hypertext

HTTP - Das Hypertext-Transfer-Protocol

Das jüngste Instrument zur Informationssuche im Internet ist WWW - Das World-Wide-Web. Es wurde 1992 vom europäischen Kernforschungsinstitut CERN in der Schweiz mit dem Ziel entwickelt, Forschungsergebnisse aus dem Bereich der Elementarteilchenphysik möglichst schnell publizieren zu können und effizient auf solche Veröffentlichungen zuzugreifen. Das Informationssuchsystem WWW basiert auf dem Prinzip des Hypertext. Hypertextdokumente sind Textdateien, die über Schlüsselwörter ('Links') mit einem oder mehreren anderen Textdokumenten vernetzt sind. Das Standardtransferprotokoll im Web ist HTTP. Jede Interaktion besteht aus einer ASCII-Anfrage, gefolgt von einer MIME-ähnlichen (RFC 822) Antwort.

HTTP ist ein zustandsloses, obkjektorientiertes Protokoll für ein verteiltes Hypermedia Informationssystem. Es regelt die Übertragung von Dokumenten zwischen WWW-Servern und WWW-Clients. HTTP hat momentan den Status eines 'Draft Standard' der in RFC 2616 (1999) spezifiziert wird. Die aktuelle Version ist HTTP/1.1. Wenn HTTP auf TCP als Transportprotokoll läuft, dann wird der (wellknown-) Port 80 benutzt.

Das HTTP-Protokoll besteht aus zwei getrennten Elementen: Anfragen von Clients ('Browsern') an Server und Antworten die vom Server zurück zum Client gesendet werden. Man unterscheidet volle und einfache Anfragen an HTTP-Server. Die einfachen Anfragen enthalten keine Versionsangabe von HTTP und kommen ohne MIME, Codierung etc. aus. Neuere HTTP- Versionen (>=1.0) unterstützen volle Anfragen. Da HTTP ebenso wie die im Abschnitt 'Klassische Protokolle' beschriebenen Protokolle ein ASCII- und klartext-orientiertes Protokoll ist, kann man die Kommunikation zwischen einem HTTP-Client und einem HTTP-Server sichtbar machen, indem man eine TELNET Sitzung zum Port 80 des Servers aufbaut (Beispielsweise: telnet www.fernuni-hagen.de 80). HTTP wurde speziell für die Nutzung im WWW entwickelt, aber im Hinblick auf künftige (objektorientierte) Nutzungen absichtlich allgemeiner als nötig gehalten. In einer Anfragezeile steht deshalb als erstes der Name einer Methode die auf eine Web-Seite oder ein Objekt angewendet werden soll. In der folgenden (aus Tanenbaum, 1998) entnommenen Tabelle werden die sogenannten integrierten Methoden aufgelistet:

GET	Anfrage zum Lesen einer Web-Page. Damit wird der Server aufgefordert, die Page oder allgemeiner das Objekt, zu senden die entsprechend mit MIME codiert ist. Folgt der GET-Anfrage der Header If-Modified-Since, sendet der Server die Daten nur dann, wenn sie seit dem letzten Zugriff geändert wurden. Mit diesem Mechanismus kann der Browser, bei einer Seite die sich schon in seinem Cache befindet, sicherstellen, dass die Seite nicht nocheinmal vom Server gesendet werden muss.
HEAD	Anfrage zum Lesen des Headers einer Web-Page. Die HEAD Methode fragt nur nach dem Nachrichten Header ohne eigentlichen Inhalt. Diese Methode kann z.B. benutzt werden, um das Datum der letzten Änderung einer Page zu holen oder einen URL auf Gültigkeit zu prüfen.
PUT	Anfrage zum Speichern einer Web-Page. Die PUT-Methode bewirkt das Gegenteil von GET. Mit ihrer Hilfe lassen sich Web-Pages vom Client auf einnen Web-Server transferieren. Die Anfrage enthält die Page die mit MIME codiert sein darf. In diesem Fall enthalten die Zeilen nach PUT eventuell einen Content-Type und Authentifizierungsheader (für den Schreibzugriff auf den Server)
POST	Anhängen einer benannten Ressource (z.B. einer Web-Page). Die POST Methode ist mit PUT vergleichbar. Sie enthält ebenfalls einen URL, hängt aber die neuen Daten an, statt vorhandene Daten zu ersetzen. Beispiele sind Bereitstellung von Artikeln in Newsgruppen oder Bulletinboards. damit wird die Absicht erkennbar, dass das Web die Funktionalität des Usenet-Systems übernehmen soll.
DELETE	Entfernen einer Web-Page. Die DELETE-Methode löscht die Seite auf die der URL zeigt derihr als Parameter mitgegeben wurde. Ebenso wie bei der PUT-Methode spielen Authentifikation/Autorisation eine wichtige Rolle.
LINK	Verbindet zwei Ressourcen
UNLINK	Löst die Verbindung zwischen zwei Ressourcen

Wie bei den Protokollen NNTP und SMTP gibt auch der HTTP-Server numerisch codierte Antworten zurück:

1xx	Informationsantwort, die z.B. den Status des Servers zurückgibt. Die Statusmeldung kann optionale Header mitführen und wird von einer Leerzeile abgeschlossen.
2xx	positive Vollzugsmeldung, die angeforderte Aktion wurde korrekt beendet (z.B. 200 für 'ok').
3xx	positive Übergangsbestätigung, zur vollständigen Bearbeitung ist ein weiteres Kommando notwendig.
4xx	Fehlermeldung (Fehler beim Client), in einer anliegenden Erläuterung kann spezifiziert werden, ob die Fehlerbedingung permanent oder vorübergehend ist.
5xx	Fehlermeldung (Fehler beim Server), in einer anliegenden Erläuterung kann spezifiziert werden, ob die Fehlerbedingung permanent oder vorübergehend ist.

Insgesamt werden von Scheller, et al., 1994 vier Operationen unterschieden:

Connection: Der Client initiiert eine Verbindung zum Server, die von ihm bestätigt wird. Über TCP erfolgt der Verbindungsaufbau entweder über den Port 80 oder über jeden anderen nicht reservierten Port, der dann aber explizit angegeben werden muß.
Request: Der Client stellt über ein 'request message' eine Anfrage.
Response: Der Server sendet eine Antwort an den Client (response message).
Close: Der Verbindungsabbau erfolgt entweder durch den Server nach Übertragung der Daten oder durch den Client durch Abbruch

Beim Request unterscheidet man, wie oben erwähnt, zwischen einem SimpleRequest und einem FullRequest. Der SimpleRequest entspricht der Zeile:

GET URL <cr><lf>

Wobei URL für eine Server URL steht und <cr><lf> für carriage-return linefeed. Der SimpleRequest wird noch aus Kompatibilitätsgründen unterstützt, er entspricht der Funktionalität von HTTP/0.9. Der FullRequest hat die Form:

Method URL ProtocolVersion <cr><lf>
[*<HTRQ Header>][<cr><lf><DATA>]

Der FullRequest unterscheidet sich durch die Angabe einer Protokollversion vom SimpleRequest. Über die Protokollversion wird das Aussehen der gesamten Anfrage spezifiziert. Ab Version 1.0 sind eine beliebige Anzahl an <HTRQ Header> Feldern (HyperText Transfer Request) erlaubt. Über diese Felder kann der Client bestimmte Mitteilungen machen. Hier einige Beispiele:

From: Feld über das die Mailadresse des Anwenders dem Server bekannt gemacht wird.
Accept: Feld, über das der Client anzeigt, welche MIME Typen er akzeptiert.
Authorization: Feld das zur Autorisierung verwendet wird.
If-modified-since: Feld das zu Steuerung des Cache des Clients dient (siehe oben unter 'GET')

Beim Response Block der vom Server zum Client gesendet wird, ist die Syntax wie folgt:

<status-line> *[( general-header | response-header | entity-header ) <cr><lf>] <cr><lf>
[ message-body ]

Die Antwort des Servers beginnt mit der Statuszeile, die das folgende Format hat (in RFCs wird gern die BNF für syntaktische Darstellungen verwendet):

Die Statuszeile gibt die HTTP-Version des Servers zurück, gibt einen dreistelligen Zahlencode (siehe oben) gefolgt von einer kurzen Erläuterung aus. Anschliessend können beliebig viele Response|General|EntityHeader-Informationen folgen. Zum Schluss erfolgt die Übertragung der Daten - also beipielsweise einer Web-Page.

Die General-Header sind Informationen und Anweisungen die sowohl Abfragen als auch Antworten als Message betreffen, nicht jedoch das Objekt das übertragen wird. Die Entity-Header definieren Metainformationen über das Objekt das übermittelt oder referenziert werden soll. Einige dieser Metainformationen sind optional andere sind verpflichtend. Die Response-Header erlauben dem Server zusätzliche Informationen über die Antwort an den Client zurückzugeben die keinen Platz in der Statuszeile finden. Diese Header-Felder geben Informationen über den Server und über weitere Zugriffsmöglichkeiten auf die referenzierte URI zurück.

Für die Darstellung der zahlreichen Header und ihrer ebenso umfangreichen Werte und Ausprägungen sei auf RFC 2616 verwiesen.