Das HTTP Request - Response Modell

Wenn ein Browser eine Seite von einem Server anfordert, benutzt er meist das HTTP-Protokoll. Sie erkennen das an der URL, die mit dem Namen des Protokolls beginnt: http://server.de/page.html. Das Dokument RFC 2616 zum HTTP (=Hypertext Transfer) Protokoll legt dabei fest, in welcher Form der Browser seine Anfrage zu stellen hat, damit sie von der Netzwerksoftware weitergeleitet und vom Webserver verstanden werden kann. Die Netzwerkhardware baut eine Verbindung (Connection) zum betreffenden Webserver auf, über die der Browser seine Anfrage (Request) abschickt. Sie kennen dies aus der Programmierung, wo Sie eine Datei oder Datenbankverbindung erst öffnen müssen, um darauf zuzugreifen.

Der Webserver liest die Anfrage des Browsers (Clients), bearbeitet und schickt über die selbe Connection seine Antwort (Response) zurück. Auch diese Antwort ist ebenso wie die Anfrage im HTTP - Protokoll beschrieben. Dann schließt der Server die Connection und verliert sofort jegliche Erinnerung an den Client, den er da gerade bedient hat.

Weil das Herstellen einer Connection recht aufwändig ist, sieht die aktuelle Version 1.1 des HTTP-Protokolls vor, dass eine Connection offen bleiben kann und der Browser entscheidet, ob er sie schließen will oder seine nächste Anfrage über sie abwickelt. Der Server sendet dazu den Header: Connection: Keep-Alive. In der Tat arbeiten fast alle Server und die gängigen Browser heute in dieser Weise. Für uns Entwickler bringt das aber keine grundsätzliche Änderung.

Das HTTP-Protokoll definiert Header und Body, die durch eine Leerzeile (CRLF) getrennt werden. Eine einfache GET - Anfrage des Browsers zur Anforderung einer HTML Seite hat einen leeren Body und sieht beispielsweise so aus:

GET /jspkurs/web/script/kap1.html HTTP/1.1
Host: java1.de
User-Agent: Mozilla/5.0
Accept: text/xml,application/xml,application/xhtml+xml, [...]
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost/

Wie man sieht, sind die wesentlichen Informationen bereits in den ersten beiden Zeile enthalten, die übrigen Header-Zeilen geben mehr oder weniger wichtige Infos über den Client in der Form key: value. Als erstes wir die Methode des Aufrufs GET genannt, dann die Resource, auf die sich der Aufruf bezieht. Die Angabe des gewünschten Protokolls schließt die erste Zeile ab. In der zweiten Zeile erfolgt die Angabe des Servers (Host), auf den sich die Anfrage bezieht. Das ist erforderlich, wenn sich mit HTTP 1.1 unterschiedliche Hosts eine IP-Adresse teilen (Stichwort: Name based virtual hosting).

Wenn Sie HTML-Formulare verwenden, werden Sie diese häufig mit einer anderen Methode des HTTP Protokolls versenden, POST. Post besitzt sinnvollerweise einen Body und ist daher besser geeignet, Daten an den Server zu schicken. Eine Anfrage sieht beispielsweise so aus:

POST /test/post.php HTTP/1.1
Host: java1.de
User-Agent: Mozilla/5.0 Gecko/20020823 [..]
Accept: text/xml,[..]
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66,*;q=0.66
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost/Bremsserver/test/post.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

eins=zwei&drei=vier&los=los

Der Server erkennt an der Zeile Content-Length: 27, dass nach dem Header noch 27 Bytes zu lesen sind. Zeile Content-Type sagt ihm, die diese Bytes zu interpretieren sind, in unserem Fall als URL-encodeter Text. Es sind aber durchaus andere Formate möglich und häufig.

Der Server sendet dann seine Antwort, die idealerweise mit dem Server Status Code 200 OK beginnt. Alle Status Codes sind in der genannten RFC 2616 definiert und müssen vom Browser verstanden werden. Die wichtigsten kenne Sie wahrscheinlich (302 Found (Redirekt), 304 Not Modified, 403 Forbidden, 404 Not Found, 500 Internal Server Error usw.). Eine typische Response eines Servers:

HTTP/1.1 200 OK
Date: Wed, 08 Jan 2003 21:42:25 GMT
Server: Apache/2.0.44-dev (Unix)
Cache-Control: max-age=86400
Expires: Thu, 09 Jan 2003 21:42:25 GMT
Accept-Ranges: bytes
Content-Length: 7893
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN
[...]

Die wichtigsten Informationen für den Browser: Content-Length gibt an, wie viele Bytes Body gelesen werden sollen. Leider gibt es bei Netzwerkverbindungen kein EndOfFile wie bei Dateien, sodass der Browser das Ende des Contents ohne diese Angabe nicht bestimmen könnte. Er würde auf weitere Daten warten, bis der Server die Connection schließt. Ebenfalls wichtig: die Angabe des Content-Types, damit der Browser weiß, was er mit den Daten anstellen soll. Nach der Leerzeile folgt der Body, in diesem Fall eine HTML Seite. Wir sehen hier auch: Connection: Keep-Alive, sodass der Server die Connection zunächst nicht schließt, falls der Browser sie noch einmal verwenden möchte.