26.8 Das HTTP-Protokoll 

Das Hypertext Transfer Protocol (kurz HTTP) ist das Protokoll, mit dem sich der Webbrowser und der Webserver über das Internet miteinander unterhalten. Und da CGI auf dem HTTP-Protokoll aufbaut, ist es recht sinnvoll, sich auch ein wenig damit auszukennen. Natürlich ist es nicht die Absicht, Ihnen alles über das Thema mitzuteilen, sondern nur das Wichtigste. Sollten Sie mehr Informationen benötigen, kann ich Ihnen die Webseite www.w3.org/Protocols/ empfehlen.

26.8.1 Web-Protokolle 

Der Sinn dieses Abschnitts ist es, zu erklären, wo das HTTP-Protokoll seinen Platz in der Netzwerktechnik hat. Es gibt natürlich weitaus mehr Protokolle für das Web als nur das HTTP. Beispielsweise das File-Transfer-Protokoll (besser bekannt unter FTP), das TELNET-Protokoll, das Simple-Mail-Transfer-Protokoll (SMTP) und noch eine Menge mehr. Für Sie als CGI-Programmierer ist das HTTP-Protokoll am meisten von Interesse.

26.8.2 Wozu Protokolle? 

Im Prinzip können Sie die Protokolle der Netzwerktechnik mit Sprachen vergleichen. In aller Welt sprechen die Menschen gut tausend verschiedene Sprachen. Wenn Sie sich mit jedem Menschen auf der Welt unterhalten wollten, müssten Sie all deren Sprachen beherrschen. Ein schwieriges Unterfangen. Würde dasselbe auf Computer angewendet, ließe sich wohl kaum noch eine Webseite darstellen. Sie würden dann wahrscheinlich eine Fehlermeldung erhalten wie: Diese Webseite kann nicht angezeigt werden, da Ihr System das Protokoll nicht versteht.

26.8.3 Was ist ein Protokoll? 

Protokolle sind eine Mischung aus Kommunikationsregeln und Nachrichtenformaten, deren Regeln vernetzte Computer befolgen müssen, sollten diese Daten miteinander austauschen wollen. Werden z.B. Daten von Computer Ernie zum Computer Bert versendet, so werden diese zunächst in eine Nachricht verpackt. Diese Nachricht wird in einer bestimmten Kommunikationsregel des Protokolls definiert. In der Kommunikationsregel wird z.B. beschrieben, wie die Nachricht beim Zielrechner Bert behandelt werden soll, wenn ein Fehler bei der Übertragung auftritt. Zur Übertragung von Daten wird das IP-Protokoll (Internet Protocol) verwendet.

Die Sprache der Computer ist nicht ganz so komplex wie die des Menschen. Dieser verständigt sich mit anderen Gleichgesinnten durch die Binärzahlen 0 und 1. Trotz dieser universellen Sprache sind nicht alle Computer vom gleichen Typ. Angefangen bei unterschiedlicher Hardware bis hin zu einem anderen Betriebssystem kann es dabei ziemliche Verständigungsprobleme geben. Und Protokolle sind sozusagen die Dolmetscher, welche die Probleme der Kommunikation lösen. Damit ist es erst möglich, dass sich unterschiedliche Computertypen mit unterschiedlichen Betriebssystemen verständigen können.

26.8.4 Normen für die Netzwerktechnik 

Damit jetzt die vernetzten Computer mit einheitlichen Protokollen miteinander kommunizieren können, bedurfte es zuvor einer einheitlichen Netzwerktechnik im Allgemeinen. Eine Normung war auch allmählich notwendig, denn durch die fortschreitende Entwicklung von Netzwerkkomponenten kamen im Laufe der Zeit immer mehr herstellerspezifische Netzwerke und Protokolle zu Stande. Das dabei mit zunehmender Vernetzung immer mehr Probleme aufgetreten sind, liegt auf der Hand.

1978 hat sich dann ein Gremium mit dem Namen ISO (International Standardization Organization) zusammengefunden, mit dem Ziel, eine Schnittstelle zu standardisieren, welche für die Vernetzung von PCs in Betracht kommen könnte. Es dauerte danach weitere sechs Jahre, bis das ISO-Komitee einen Standard bekanntgab. Der Standard wurde Open System Interconnection (kurz OSI) genannt. Mit OSI wurde jetzt festgelegt, wie die Kommunikation der unterschiedlichen Rechner mit diversen Protokollen stattzufinden hat.

26.8.5 Das OSI-Schichtenmodell 

Mit Einführung des OSI-Modells wurden endlich einheitliche Produkte für den Netzwerkeinsatz hergestellt, da die Hersteller gezwungen waren, sich an diesen Vorgaben zu orientieren. Es muss aber hinzugefügt werden, dass dies allein noch lange keine Realisierung aller Standards bedeutet. Beim OSI-Referenzmodell handelt es sich um ein geprüftes und bewährtes Modell für die Hard- und Softwareentwicklung. Ob und wie die Hersteller dieses Modell anwenden, bleibt immer noch deren Angelegenheit.

Das genormte OSI-Schichtenmodell wurde auf sieben Schichten verteilt. Jede Schicht hat dabei ihre eigene Aufgabe. Hier ein kurzer Überblick zu diesen sieben Schichten und den Protokollen, welche die einzelnen Schichten nutzen können:

Hier klicken, um das Bild zu Vergrößern

Abbildung 26.11   Das OSI-Schichtenmodell und die Protokolle

Nicht abgebildet sind hier die UDP-Protokolle. Das HTTP-Protokoll (in der Abbildung grau eingefärbt), das Sie zur CGI-Programmierung verwenden, ist über dem TCP-Protokoll angesiedelt. Der gesamte Webverkehr verläuft über das TCP/IP-Protokoll.

26.8.6 Die Elemente einer URL 

Häufig begegnen Sie einer URL (Uniform Resource Locator), deren Bedeutung einem fremd erscheint. Betrachten Sie folgende URL:

http://www.pronix.de:80/cgi/name.cgi?vorname=Clint&nachname=East

Diese URL soll jetzt in ihre Einzelteile zerlegt werden.

http (Schema)

Dies ist das verwendete Protokoll, womit der Webbrowser mit dem Webserver kommuniziert. Es gibt natürlich noch mehr Protokolle außer dem HTTP. Mehr dazu gleich bei den Ports. Danach folgt der Rechnername.

www.pronix.de (Rechnername)

Dabei handelt es sich um den Rechnernamen, auf dem sich die Webseite oder das Dokument befindet. Dies kann aber auch eine IP-Adresse (beispielsweise http://127.0.0.1) und muss nicht immer ein Domainname (http://www.pronix.de) sein.

80 (Portnummer)

Der Webserver nimmt hier über Port 80 einen Auftrag entgegen. Dass dieser Port bei der URL nicht angegeben werden muss, liegt daran, dass Port 80 der voreingestellte Port des HTTP-Protokolls ist.

Die Daten müssen aber nicht immer über Port 80 übertragen werden. Sie können genauso gut einen Server konfigurieren, mit dem Sie Daten über den Port 85 empfangen können. Folgende Ports und ihre Protokolle sind in der Regel voreingestellt:

/cgi/name.cgi (Pfadangabe)

Damit wird der Ort des gespeicherten Dokuments auf dem Webserver bezeichnet.

?vorname=Clint&nachname=East (Query-String)

Der Query-String kann aus mehreren Paaren von Namen und den dazugehörenden Werten bestehen. Die einzelnen Paare werden mit dem Zeichen & voneinander getrennt. Die Variable und der Wert werden mit einem = getrennt. In diesem Beispiel haben Sie folgende zwei Paare:

Variable des ersten Paars: vorname; Wert des ersten Paars: Clint
Variable des zweiten Paars: nachname;Wert des zweiten Paars: East

Der Query-String wird noch ausführlicher behandelt.

26.8.7 Client-Anfrage – HTTP Request (Browser-Request) 

Das Erste bei einer HTTP-Verbindung ist immer die Anfrage (HTTP-Request) des Webbrowsers an den Webserver. Geben Sie beispielsweise in Ihrem Browser folgende URL ein

http://www.pronix.de/

und drücken (¢), schickt der Browser eine Anfrage an den Webserver, die aus zwei Teilen besteht. Zum einen Teil aus der Anforderungszeile und zum anderen aus den Header-Feldern:

GET /index.html HTTP/1.1
Host: www.pronix.de
Accept: image/gif, image/jpeg, image/pjpeg, */*
Accept-Language: de
Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Referer: ...
...

Die erste Zeile ist die so genannte Request-Zeile:

GET /index.html HTTP/1.1

GET ist dabei die Request-Methode, mit der eine Ressource vom Server angefordert wird, ohne dass dabei irgendwelche Daten auf dem Server verändert werden. GET ist die Standard-Methode, wenn ein Browser per HTTP ein Dokument anfordert. In diesem Beispiel wird die Datei index.html angefordert. Das Protokoll, durch das der Webbrowser und der Webserver sich unterhalten sollen, ist hier HTTP mit der Versionsnummer 1.1.

Eine andere häufig verwendete Request-Methode ist POST. Im Wesentlichen unterscheiden sich diese beiden Methoden zur Datenübermittlung in der Art, wie die Daten an den Webserver übergeben werden.

Um Ihnen den Unterschied zwischen den beiden Request-Methoden GET und POST etwas deutlicher zu machen, folgt hier eine kurze theoretische Beschreibung.

GET

Hier soll bei einem HTML-Formular einfach die Eingabe eines Textfeldes ausgewertet werden. Ich verwende hierfür folgenden HTML-Code:

<form action="http://localhost/cgi-bin/auswert.cgi" method=get>
  <b>Bitte geben Sie Ihren Namen ein : </b>
  <input value="hallo" name="Textfeld" size="20">
  <input type=submit value="abschicken">
</form>

Dadurch entsteht das folgende Textfeld mit einem Button:

Hier klicken, um das Bild zu Vergrößern

Abbildung 26.12   Eingabefeld mit Button

Mit der Zeile

<form action="http://localhost/cgi-bin/auswert.cgi" method=get>

fordern Sie das CGI-Programm auswert.cgi mit der Methode GET (method=get) an. Dabei können Sie auch gleich sehen, wie Sie die Methode des HTTP-Requests bestimmen können. Beim Drücken des Buttons wird die CGI-Anwendung auf dem Server aufgerufen. Ein Blick auf die URL des Webbrowsers zeigt Folgendes:

http://localhost/cgi-bin/auswert.cgi?Textfeld=hallo

Den Query-String können Sie jetzt auf dem Webserver mit der CGI-Anwendung auswert.cgi aus der gleichnamigen Umgebungsvariablen QUERY_STRING auslesen. In dieser Variablen befindet sich jetzt folgender String:

QUERY_STRING= Textfeld=hallo

POST

Wollen Sie das Gleiche mit der POST-Methode machen, müssen Sie nur Folgendes im HTML-Code umändern:

<form action="http://localhost/cgi-bin/auswert.cgi" method=post>

Jetzt befindet sich in der URL, bei Klicken des Buttons, kein Query-String mehr. In diesem Beispiel müssen Sie die Umgebungsvariable CONTENT_LENGTH nach der Anzahl der Bytes, die diese Nachricht enthält, abfragen. Anschließend können Sie CONTENT_LENGTH Bytes von der Standardeingabe (stdin) einlesen. Zum Beispiel mit fgets():

fgets(puffer, CONTENT_LENGTH, stdin);

Danach befindet sich die komplette Eingabe (Textfeld=IhrName) vom HTML-Formular im String puffer.

Sowohl bei der Methode GET als auch bei der POST-Methode liegen die Daten kodiert vor und müssen noch dekodiert werden. Wie das geht, erfahren Sie in Kürze.

Weitere Methoden

Es gibt noch einige weitere Methoden, auf die hier aber nicht eingegangen wird. Diese Methoden werden in der Praxis kaum eingesetzt. Hier nur ein schneller Überblick zu den weiteren möglichen Anforderungen, die Sie an den Webserver stellen könnten:

HEAD – holt nur die HTTP-Header und keinen Inhalt vom Webserver.

PUT – erzeugt Ressource auf dem Server.

DELETE – löscht Ressource auf dem Server.

OPTIONS – Abfrage der möglichen Request-Methoden des Servers.

Request Header

Außer der Request-Zeile schickt der Browser dem Webserver noch einige Informationen, den so genannten Request-Header mit. Diese Informationen bestehen aus dem Feldnamen, vom Wert mit einem Doppelpunkt getrennt. Dazu nochmals zur Erinnerung das Beispiel eines HTTP-Request, welches Sie weiter oben schon gesehen haben:

GET /index.html HTTP/1.1
Host: www.pronix.de
Accept: image/gif, image/jpeg, image/pjpeg, */*
Accept-Language: de
Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Referer: …

In diesem Beispiel ist das Fettgedruckte der Request-Header.

In der folgenden Tabelle finden Sie einen Überblick zu einigen HTTP-Request-Headern. Diese Informationen schicken Sie praktisch immer mit, wenn Sie mit einem Webbrowser unterwegs sind und eine neue Webseite vom Webserver anfordern.

26.8.8 Serverantwort (Server-Response) 

Nachdem Sie einen HTTP-Request des Webbrowsers ausführlich durchgearbeitet haben, wird Ihnen der Webserver auch irgendwann mit einer HTTP-Response antworten. Die Antwort besteht aus einer Statuszeile, ebenfalls aus einigen Header-Feldern und häufig auch aus einem Nachrichten-Body. Hierzu ein Antwort-Beispiel des Webservers:

HTTP/1.1 200 OK
Date: Wed, 30 Oct 2002 01:21:22 GMT
Server: Apache/1.3.14
Last Modified: Tue, 29 Oct 2002 22:21:19 GMT
Content-Length: 2232
Content-Type: text/html
<html>
...
</html>

Der Statuscode

In der ersten Zeile, der Statuszeile, wird außer dem Protokoll mit der Versionsnummer ein dreistelliger Statuscode angegeben.

HTTP/1.1 200 OK

Anhand dieses Statuscodes bekommt der Webbrowser die Antwort auf seine Anforderung. In diesem Beispiel wird der Statuscode 200 zurückgegeben, was einem erfolgreichen Request vorangeht. Recht häufig dürfte Ihnen der Statuscode 404 im Internet begegnet sein. Dieser wird zurückgegeben, wenn das angeforderte Dokument nicht gefunden wurde.

Hierzu folgt ein Überblick der möglichen Statuscodes. Zuerst eine Tabelle der fünf Gruppen von Codes, die anhand der ersten Ziffer unterschieden werden:

Dazu noch eine Tabelle, mit denen in der Praxis etwas häufiger auftretenden Statuscodes und ihren Bedeutungen:

Server-Header

Es folgt eine kurze Beschreibung der gängigsten HTTP-Server-Header, die der Webserver dem Webbrowser sendet.

26.8.9 Zusammenfassung 

Jetzt haben Sie mit dem HTTP-Protokoll das schwierigste und wahrscheinlich auch langweiligste Kapitel hinter sich. Im Laufe der nächsten Seiten wird Ihnen einiges, was Ihnen vielleicht noch nicht so klar ist, in einem anderen Licht erscheinen. Speziell in den nächsten Abschnitten werden Sie sehen, wie Sie mit CGI-Anwendungen und dem HTTP-Webserver zusammenarbeiten können, um dynamische Webseiten zu erstellen.