Sehr Umfangreiche Webseite zum Programmieren in C Perl CGI, Skripting, Linux, SystemprogrammierungURL, HTTP Request, HTTP Response, Statuscode, Header, GET, POST, Query-String Das HTTP-Protokol | URL, HTTP Request, HTTP Response, Statuscode, Header, GET, POST GGI Kurs Kapitel 4

Das HTTP-Protokol          zurück zum Inhaltsverzeichnis

Das HperText Transfer Protocol (HTTP) ist das Kommunikationsprotokol zwischen dem Webbrowser und dem Webserver. Wie auch CGI bauen viele andere Skriptsprachen auf dieses Protokol auf. Das HTTP-Protokol ist eine Höheres Protokol und basiert auf dem TCP-Protokol. Das TCP-Protokol basiert wiederum auf dem IP-Protokol. Mit dem TCP/IP-Protokol stellen Sie übrigens auch eine Verbindung ins Internet her. Ich will mich jetzt hier nicht in Details verstricken und beim Thema dieses Kapitels bleiben.

Somit läßt sich also auch sagen, wenn Sie wirklich wissen wollen, was zwischen dem Webbrowser und dem Webserver passiert, dann sollten Sie sich die Details von HTTP genauer betrachten.

Die Elemente einer URL

Oftmals geben wir im Browser eine URL (Uniform Resource Lacators) ein oder klicken auf einen Link, ohne uns dabei Gedanken zu machen, was die einzelnen Elemente dieser URL eigentlich bedeuten. Betrachten wir dazu doch folgende URL ...

http://www.pronix.de/:80/cgi/name.cgi?vorname=john&nachname=wayne

Hierzu nun die Bedeutung der einzelnen Bestandteile dieser URL ...

http (Schema)

Dies ist das verwendete Protokol, womit der Webbrowser mit dem Webserver kommuniziert. Einige Protokolle, außer HTTP, haben Sie bereits im Kapitel "Der Webserver" kennengelernt.

www.pronix.de (Rechnername)

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

80 (Portnummer)

Auch darauf sind wir schon im Kapitel "Der Webserver" eingegangen.

/cgi/name.cgi (Pfandangabe)

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

?vorname=john&nachname=wayne (Query-String)

Der Query-String kann aus mehreren Paaren aus Namen und den dazugehörenden Werten bestehen. Die einzelnen Paare werden mit dem Zeichen & voneinander getrennt. Der Name und der Wert wird mit einem = getrennt. In diesem Beispiel haben wir 2 Paare ...

Name des ersten Paares: vorname; Wert des ersten Paares: john
Name des zweiten Paares: nachname; Wert des zweiten Paares: wayne

Auf den Query-String kommen wir später noch zu sprechen.

Anfrage des Webbrowsers (HTTP-Request)

Das erste bei einer HTTP-Verbindung, ist immer die Anfrage (HTTP-Request) des Webbrowsers. Geben Sie Beispielsweise in Ihrem Browser folgende URL ein ...

http://www.pronix.de/

... und drücken ENTER, schickt der Browser eine Anfrage an den Server, die aus zwei Teilen besteht. Zum einen Teil aus der Anforderungs-Zeile und zum anderen Teile 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 sogenannte Request-Zeile. Zerlegen wir diese Zeile ...

GET /index.html HTTP/1.1

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

Eine andere häufig verwendete Request-Methode ist mit POST. Mit der POST-Methode können, im Gegensatz zur GET-Methode, mit einem HTML-Formular Daten auf dem Webserver verändert werden.

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

GET

Wir wollen einfach die Eingabe eines Textfeldes auswerten. 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 ensteht das folgende Textfeld mit einem Button ...

Bitte geben sie ihren Namen ein :   keine Funktion, dient nur als Ansicht

Mit der Zeile ...

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

... fordern wir das CGI-Skript auswert.cgi mit der Methode GET (method=get) an. Dabei können Sie auch gleich sehen, wie Sie die Methode des HTTP-Request bestimmen können. Beim drücken des Buttons rufen wir nun das Skript auf. Ein Blick auf die URL des Webbrowsers zeigt uns nun folgendes ...

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

Den Query-String können Sie nun auf Ihrem Server mit dem CGI-Skript auswert.cgi aus der gleichnamigen Umgebungsvariablen QUERY_STRING auslesen. In dieser Variablen befindet sich nun folgender String ...

QUERY_STRING= Textfeld=hallo

POST

Wollen Sie das gleich jetzt mit der POST-Methode machen, müssen sie 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, keine 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 mit der Funktion read() CONTENT_LENGTH Bytes von der Standardeingabe (STDIN) einlesen. Zum Beispiel ...

read(STDIN, $input, $ENV{'CONTENT_LENGTH'});

Danach befindet sich in der skalaren Variable $input der String ...

Textfeld=hallo

Sowohl bei der Methode GET als auch bei der POST-Methode liegen die Daten codiert vor und müssen noch dekodiert werden. Aber dazu kommen wir noch in der Praxis zu sprechen.

Es gibt zwar noch einige weitere Methoden, aber auf diese werden wir in diesem Tutorial nicht zum sprechen kommen. Diese Methoden werden in der Praxis eh kaum eingesetzt. Hierzu nur ein schneller Überblick, zu weiteren möglichen Anforderungen, die wir an den Webserver stellen könnten ...

Request Header

Außer der Request-Zeile, schickt unser Browser dem Webserver noch einige Informationen, den sogenannten Request-Header, mit. Diese Informationen bestehen zum einen aus dem Feldnamen, getrennt mit einem Doppelpunkt vom Wert. Dazu nochmals zur Erinnerung das Beispiel eines HTTP-Request, welches wir 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.

Folgende gebräuchlichen HTTP-Request-Header kann dabei der Webbrowser dem Webserver als zusätzliche Informationen mitangeben ...

Host

Der Host ist der Zielrechner, auf dem sich das angeforderte Dokument befindet.

Content-Length

Damit der Server weiß, wieviele Daten er aus dem Nachrichten-Body des HTTP-Request lesen soll, wird dieser Header verwendet. Natürlich gilt dies nur für den POST-Request (siehe POST). Bei einer Anforderung mit der Methode GET wird dieses Feld nicht mit angegeben.

Content-Type

Besitzt ein Request einen Nachrichten-Body, muss der Content-Type-Header mitgeschickt werden. Damit wird der Medientyp angegeben des Nachrichten-Body angegeben.

User-Agent

Darin befinden sich Angaben, mit welchem Webbrowser und Betriebssystem die Anfrage gemacht wurde.

Referer

Darin befindet sich in der Regel die URL, welche der Anwender zuletzt besucht hat. Wenn der User aber eine URL direkt in den Webbrowser oder ein Bookmark verwendet, befindet sich nichts in diesem Header.

Accept

Es gibt mehrere Accept-Header. Darin schickt der Browser dem Server Daten, welche Arten von Response (Anworten vom Server) er verstehen kann. Zum Beispiel ...

Cookies

Damit teilt der Browser dem Server mit, ob dieser Cookies akzeptiert. Deaktivieren Sie zum Beispiel in Ihrem Browser die Cookies, so wird dieser Header nicht mitgeschickt. Der Server kann, falls Cookies aktzeptiert werden, ein mit dem Response ein Cookie setzen.

Browser-Request auslesen

Nun wollen wir uns ein CGI-Skript ansehen, wie man eine Anfrage eines Browser auslesen kann. Hierzu das Skript ...

#!usr/bin/perl -w

$referer = $ENV{'HTTP_REFERER'};
$browser = $ENV{'HTTP_USER_AGENT'};

print "Content-type: text/html\n\n";

print "<p>Ihre zuletzt besuchte Seite : $referer" if $referer;
print "<p>Ihr System und Ihr Browser  : $browser" if $browser;

Hiermit lesen wir den HTTP-Header Referer und User-Agent aus. Wenn Sie online sind, können Sie auf diesen LINK klicken und das Skript in Aktion sehen.

Wir kommen auf dieses Beispiel nochmals genauer im Kapitel Die CGI-Schnittstelle zu sprechen, wenn es um die Umgebungsvariablen geht, wo Sie außer den beiden eben verwendeten, noch viele andere Umgebungsvariablen kennen lernen werden.

Die Antwort des Webservers (HTTP-Response)

Nach dem wir einen HTTP-Request des Webbrowser ausführlich durchgearbeitet haben, wird uns der Webserver auch irgendwann mal mit einem HTTP-Response antworten.

Die Antwort besteht aus einer Statuszeile, ebenfalls aus einigen Header-Feldern und häufig auch aus einem Nachrichten-Body. Hierzu ein Beispiel, einer Antwort 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 Protokol mit der Versionsnummer, ein dreistelliger Statuscode angegeben. Anhand diesem Statuscode bekommt unser Webbrowser, die Antwort auf seine Anforderung. In diesem Beispiel wird der Statuscode 200 zurückgegeben, was einem erfolgreichen Request vorangeht. Recht bekannt dürfte Ihnen der Statuscode 404 sein. Dieser wird zurückgegeben, wenn das angeforderte Dokument nicht gefunden wurde.

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

Statusbereich Bedeutung
200-299 Alles in Ordnung
300-399 Veränderungsstatus, Verlagerungen, Weitere Maßnamen müssen getroffen werden
400-499 Fehlermeldung vom Client (meistens Webbrowser)
500-599 Fehlermeldung vom Server

Dazu wollen wir uns noch eine Tabelle ansehen, mit den gängisten Statuscodes und deren Bedeutung ...

Statuscode Bedeutung
200  Alles OK
201 POST-Befehl erfolgreich
202 Anforderung akzeptiert
203 GET - Anforderung erfüllt
204  Anforderung erfüllt aber Rücksendung nicht verstanden
300  Datenquelle an mehreren Stellen gefunden
301  Datenquelle war dauernd in Bewegung
302  Datenquelle war zeitweise in Bewegung
304  Datenquelle konnte nicht näher bestimmt werden
400  Unverständliche Anforderung vom Client
401 ein File wurde angefragt, für den sich der User ausweisen muss
403  Anfrage war verständlich, der Server weigert sich jedoch das Dokument zu senden, da dieser oder der Client keine Berechtigung haben. Beispiel: keine Leserechte der Datei
404  Datenquelle nicht gefunden
405  Verfahren an Datenquelle nicht erlaubt. Z.B. die Abfragemethode  POST ist explizit gesperrt
406  Art der Datenquelle nicht erwünscht
408  Anfrage Timeout ->Server überlastet? Fehlkonfiguriert?
500  Fehler im CGI-Skript, Falsche Zugriffrechte, Server falsch konfiguriert
501  Anfrage wird vom Server nicht unterstützt, da notwendige Module nicht implementiert
502 Schlechte Netzverbindung oder Server überladen
503  Dienst steht nicht zur Verfügung - Timeout - wenn z.B. ein hinterliegender Datenbankserver nicht reagiert

Server-Header

Kommen wir nun zur Beschreibung einiger HTTP-Server-Header, die der Webserver dem Webbrowser sendet.

Zusammenfassung

Jetzt haben Sie mit dem HTTP-Protokol das schwierigste und wahrscheinlich auch Langweiligste Kapitel hinter sich. Im Laufe der nächsten Kapitel, wird Ihnen einiges, was jetzt vielleicht noch nicht so deutlich ist, in einem anderen Licht erscheinen. Speziell im nächste Kapitel werden Sie sehen, wie Sie mit CGI-Skripten und dem HTTP-Webserver zusammenarbeiten können um dynamische Webseiten zu erstellen.