4 HyperText Transfer Protocol (HTTP)

4.1 Funktionsweise

Das HyperText Transfer Protocol ist ein zustandsloses Protokoll auf Anwendungsschicht für verteilte hypermediale Informationssysteme. Die folgende Grafik zeigt die Einordnung des HTTP in die Internet Protokollhierarchie. Neben HTTP befinden sich auf der selben Stufe auch Protokolle wie z.B. SMTP :
 

Im Falle des WWW wird HTTP standardmäßig über TCP Port 80 abgewickelt. Nach Definition, RFC (Request for Comments) 2068  ist aber auch jede beliebige, gesicherte Verbindung erlaubt, so daß sich das HTTP auch für andere Anwendungen neben dem World Wide Web einsetzen läßt.

Der grundsätzliche Ablauf einer HTTP Übertragung stellt sich wie folgt dar:

  1. Die Verbindung vom Client zum Server wird aufgebaut.
  2. Der Client sendet eine Anfrage (Request Message) für das gewünschte Dokument.
  3. Der Server Antwortet mit den entsprechenden Daten oder mit einer Fehlermeldung, falls kein Zugriff möglich ist.
  4. Die Verbindung wird abgebaut. Jetzt ist keine Beziehung zwischen den beiden Kommunikationspartnern mehr nachvollziehbar. In dieser Zustandslosigkeit liegt eine große Schwäche des HTTP. Näheres zu Lösungen dieses Problems  findet sich im Kapitel Zustandsinformationen.
 
 
Dieser Ablauf ist hier noch einmal grafisch dargestellt. Der Vorgang wiederholt sich für jedes Element, also jedes Textobjekt und jede Grafik auf einer WWW Seite. Da diese inzwischen jedoch aus vielen einzelnen Dateien bestehen, sieht HTTP Version 1.1 nun auch sogenannte Persistent Connections vor, die erst nach Übertragung einer beliebigen Anzahl von Teilstücken wieder geschlossen werden. Dadurch reduziert sich die durch das ständige Auf- und Abbauen der Verbindung zusätzlich erzeugte Netzlast.
 

4.2 HTTP Uniform Ressource Locator (URL)

Die Quelle der zu übertragenden Daten wird eindeutig beschrieben durch den Uniform Ressource Locator (URL). Dieser sieht laut Definition (RFC 2068) für HTTP-Anfragen wie folgt aus: 
"http:" "//" host [ ":" port ] [abs_path]
Dabei bedeutet:
  
host
 Ein zulässiger Internet Rechner-Domain-Name oder eine IP-Nummer.
  
port
 Der TCP-Port auf welchem der "host" HTTP-Anfragen entgegennimmt. Fehlt die Angabe wird defaultmäßig Port 80 verwendet.
  
abs_path  
 Der Pfad zu dem gewünschten Dokument im Verzeichnissystem des Servers. Die Angabe ist ebenfalls optional. Standardmäßig wird in der Regel die Homepage der zu "host" gehörigen Website (des Betreibers) geladen
Ein Beispiel: 
http://www.uni-karlsruhe.de
entspricht
http://www.uni-karlsruhe.de:80/Uni/index.html
 

4.3 HTTP Beispieldialog

Im Folgenden wird der oben beschriebene Dialog zwischen WWW-Client und -Server einmal ausführlich dargestellt. Der obere Block (Client:) zeigt die an der Server geschickte Request-Message zum Abruf einer WWW-Seite. Darunter sieht man die Antwort des Servers bestehend aus einem Header und daran anschließend den ersten Zeilen des übertragenen Dokumentes:
 
Client: 
GET / HTTP/1.0 
Accept: */* 
Accept: application/html 
Accept: text/plain 
Accept: text/html 
Accept: www/mime 
Accept-Language: en; q=1 
Accept-Language: *; q=0.1 
User-Agent:  Lynx/2-4-2  libwww/2.14 
<Leerzeile>
 
Server: 
HTTP/1.1 200 OK  
Date: Mon, 27 Oct 1997 11:57:03 GMT 
Server: Apache/1.2.1 PHP/FI-2.0b12 
Last-Modified: Wed, 13 Aug 1997 07:30:38 GMT 
ETag: "64861-57c-33f1629e"  
Content-Length: 1404 
Connection: close  
Content-Type: text/html 

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <HTML> 
<HEAD> 
<BASE TARGET="_top"> 
</HEAD>
 
 

Hier eine kurze Beschreibung einiger Elemente:
 

GET Veranlaßt die Übertragung des gesamten Dokumentes. Alternativ läßt sich z.B. mit HEAD nur der Kopf der HTML-Datei übertragen (z.B. zum Lesen des Titels und der Meta-Informationen von Suchmaschinen)
 
Accept: www/mime Zeigt dem Server den vom Client gewünschten Datentyp an. Wie hier sind mehrere solcher Einträge für verschiedene Typen zulässig. MIME steht für Multipurpose Internet Mail Extensions. (Näheres zu MIME siehe Thema 2)
 
HTTP/1.1 200 OK Die Anfrage ist vom Server verstanden worden; der Server ist HTTP Version 1.1 fähig  (hier jedoch vom Client nicht unterstützt)
 
Server Die verwendete Serversoftware. Durch Auswertung dieses Response-Eintrages läßt sich die oben beschriebene Grafik vollautomatisch erstellen
 
Connection: close Die Verbindung wird nach Übertragung dieser einen Datei geschlossen. (Keine Persistent Connection)
 
 

4.4 HTTP Common Gateway Interface

Das Common Gateway Interface (CGI) stellt eine Standardschnittstelle dar, durch die HTTP-Server in die Lage versetzt werden, mit anderen Programmen Daten auszutauschen. Dabei spielt die Programmiersprache, in welcher diese geschrieben sind keine Rolle, solang sich die CGI-Programme auf der lokalen Maschine des Servers ausführen lassen. Eine oft verwendete Sprache zu Erstellung von CGI-Scripten ist die Skriptsprache PERL :
 

Die Anwendung liegt insbesondere in der Bereitstellung von dynamisch erzeugten Webseiten. Bei Suchmaschinen z.B. kann die dem Client zu übertragende WWW-Seite ja erst nach der Eingabe der gesuchten Schlagworte erstellt werden. Dies geschieht dann, indem das CGI-Programm als Rückgabewerte den HTML-Code dieser Seite übergibt.

Am Beispiel Suchmaschine erkennt man auch, daß ein enger Zusammenhang zwischen dem Einsatz von CGIScripten und Formularen im WWW besteht. In Formularen stehen zwei Methoden zur Übergabe von Daten durch den HTTP-Server an das CGI-Programm zu Verfügung:
 

  1. Die GET Methode:

    2. Alle Daten werden nach einem "?" als "Variable=Wert" Pärchen getrennt von "&" an den URL angehängt:

    http://www.irgendwo.de/cgi-bin/beispiel.cgi?vorname=paul&nachname=meier

    Das CGI-Script muß in diesem Falle die Umgebungsvariable QUERY_STRING des Servers auslesen.
     

  2. Die POST Methode:

    3. Die Variablen/Werte werden als Anhang an die Request-Message des Clients an den Server übertragen. Das CGI-Programme bekommt die Daten dann vom Server über seine Standardeingabe weitergereicht.
     
In jedem der beiden Fälle muß das CGI-Script alle Daten, die an den Server zurückgegeben werden sollen, auf seine Standardausgabe schreiben.

Außer der Umgebungsvariablen QUERY_STRING existieren noch zahlreiche andere, z.B. REMOTE_HOST, SERVER_NAME, CONTENT_TYPE, CONTENT_LENGTH. Mit deren Hilfe lassen sich zum Beispiel einfache Zugangsbeschränkungen realisieren, indem nur bestimmten Rechnern (REMOTE_HOST) der Zugriff gestattet wird.

Hier ein in Python programmiertes, einfaches Beispiel zur Verwendung von CGI-Scripten und Formularen (POST-Methode) sowie Nutzung von Umgebungsvariablen.
 
 

4.5 HTTP und Zustandsinformationen

Durch die Eigenschaft einer HTTP-Übertragung, die Verbindung jedesmal neu aufzubauen und wieder zu beenden, besteht von sich aus keine Möglichkeit, Zustandsinformationen zwischen Client und Server bzw. aufeinanderfolgenden Abruf von WWW-Seiten zu speichern und auszuwerten. Ein typisches Problem in diesem Zusammenhang sind Websites, die erfordern, daß sich der Benutzer zunächst mit Namen und Passwort anmeldet. Nun ist es wünschenswert, daß diese Authetifizierung für die Dauer der gesamten Sitzung Gültigkeit besitzt und nicht bei jeder weiteren, abgerufenen Seite erneut erfolgen muß.

Derartige Aufgaben lassen sich mit folgenden Lösungsmöglichkeiten bewältigen:
 

  1. Unsichtbare Formularfelder in HTML-Formularen (Datentyp HIDDEN)

    2. Diese werden vom Browser des Benutzers nicht angezeigt, können aber genauso wie reguläre Eingabefelder Daten an ein CGI-Script übergeben. Damit lassen sich Informationen von einer Seite an die nächste durchreichen.

    An diesem einfachen Addierer läßt sich dieser Mechanismus leicht ausprobieren.
     

  2. Speichern von Daten auf der Festplatte des Anwenders durch Cookies

    3. Cookies sind kleine Datenmengen, die beim Aufruf bestimmter WWW-Seiten vom HTTP-Server an den Browser geschickt, und von diesem dann als Einträge in eine Textdatei auf die lokale Festplatte geschrieben werden. Sie dienen im wesentlichen zur Speicherung von "Variable=Wert" Pärchen. Weitere Datenfelder sind die Domain des Servers, der das Cookie gesetzt hat, der Pfad des Dokumentes, auf welches sich das Cookie bezieht und ein Verfallsdatum, nach dessen Ablauf der Eintrag wieder gelöscht wird.

    Sobald nun der Benutzer den selben URL das nächste mal abruft, schickt der Browser die gespeicherten Informationen selbständig an den an den Server zurück. Dieser Datenaustausch geschieht in der Regel über spezielle HTTP-Request/Response - Felder. Aber auch mit Hilfe von JavaScript lassen sich Cookies schreiben und lesen.

    Entgegen der weitverbreiteten Meinung besteht wenig Gefahr für den unerlaubten Zugriff auf private Daten von Außen. Cookies werden im Normalfall nur an denjenigen Server zurückgeschickt, von welchem sie ursprünglich stammen. Außerdem wird das Lesen und Schreiben auf die lokale Festplatte des Anwenders alleine vom Browser durchgeführt und ist somit vom WWW-Server nicht kontrollierbar.

    Cookies sind allerdings nicht unumstritten, da sie die Erstellung von personenbezogenen Nutzungsprofilen begünstigen. Dies geschieht z.B. dadurch, das entsprechende Organisationen Werbung auf möglichst vielen fremden WWW-Seiten plazieren. Da diese Werbebanner nicht statisch z.B. als Grafikdatei an die Eigentümer der Sites vergeben, sondern jedesmal von einem zentralen Server eingespielt werden, läßt sich auch somit jedesmal ein Cookie setzen und wieder lesen. Auf diese Weise kann man die Spur eines bestimmten Websurfers über weite Strecken im WWW verfolgen.

    Weiterführend hier die genaue (vorläufige) Spezifikation über HTTP Cookies der Firma Netscape.
     

  3. Die Möglichkeit des Dynamic Argument Embedding beruht im Wesentlichen auf Speicherung von Informationen durch geschickte Veränderung des URLs einer Seite bei der Übergabe zwischen Client und CGI-Script. Diese Technik ist jedoch noch nicht weit verbreitet, da sie besondere Software auf der Serverseite nötig macht.
 
    Eine ausführliche Beschreibung ist bei Arun Iyengar am IBM T.J. Watson Research Center zu finden.
     
 

HTTP und Datensicherheit

Die zunehmende Verbreitung des WWW im kommerziellen Bereich z.B. für Online-Banking und Intranet/ Virtual Private Network Anwendungen bringt auch gleichzeitig den Bedarf nach Verfahren zur Sicherung von Übertragungen gegen Manipulation und Abhören mit sich. Weder TCP/IP noch das HTTP in ihren heute im Einsatz befindlichen Versionen bieten dem Benutzer dahingehende Möglichkeiten wie z.B. die Verschlüsselung vertraulicher Daten.

Zum Ausgleich dieser Unzulänglichkeiten stehen derzeit im wesentlichen zwei Methoden zur Verfügung:
 

  1. Das Secure Sockets Layer (SSL) Protocol:

    2. Es arbeitet transparent auf Schicht 5 (Session Layer) nach dem ISO/OSI-Modell und ver- bzw. entschlüsselt auf Wunsch des Anwenders alle Daten, die von der Anwendung ins Netzwerk und umgekehrt übertragen werden. Nach diesem Prinzip ließe sich SSL theoretisch anwendungsunabhängig implementieren. Da jedoch beim Internet die Schichten fünf, sechs und sieben zu einer einzigen Anwendungsschicht zusammengefaßt werden, bleibt es wieder dem WWW-Client überlassen, SSL zu verwirklichen.

    Beim SSL wird zunächst durch ein asymmetrisches Verschlüsselungsverfahrens (RSA) ein Schlüssel für ein symmetrisches Verfahren (DES) ausgetauscht. Mit letzerem werden schließlich die zu übertragenden Daten verschlüsselt. Diese Kombination ist sinnvoll, da asymmetrische Verfahren zwar keinen gesicherten Übertragungskanal für den Schlüssel benötigen, sich dafür aber wegen des hohen Rechenaufwandes nur für die Verschlüsselung kurzer Nachrichten wie z.B. eines Schlüssels für ein symmetrisches Verfahren eignen.

    Weiterführende Information en hierzu im Rahmen von Thema 7 - Sicherheit der Datenübertragung im Internet.
     

  2. Secure HTTP (S-HTTP):

    3. S-HTTP arbeitet nach einem ähnlichen Verschlüsselungsmodell wie SSL. Im Gegensatz dazu ist es aber als Erweiterung des HTTP vollständig in die Anwendung integriert d.h. nur für auf diesem Protokoll basierende Dienste einsetzbar.
 
SSL/ S-HTTP in der Internet-Protokollhierarchie
(vergleiche auch ISO/OSI)