17.2 Vom Client zum Server und wieder zurück

Bevor wir den Fokus auf Server-generierte Web-Seiten lenken, wollen wir den Weg der Anfrage einmal genauer verfolgen.

17.2.1 Der bittende Client

Richtet der Web-Browser oder eine Applikation (wie wir dies schon im Netzwerkkapitel gesehen haben) eine Anfrage an den Web-Server, so schickt er eine Kennung mit der Anfrageart (auch Methode oder Kommando genannt) zusammen mit der angeforderten URI (eine URL ohne Host, Port und Formularinhalt) und der Versionsnummer des zu nutzenden Protokolls zum Server. Die Anfrage (engl. request) kann zum Beispiel so aussehen:

GET /index.html HTTP/1.0

Hier wird vom Server, mit dem eine Verbindung besteht, das Dokument index.html angefordert. Wer die Reaktion des Servers auf diese Anfrage sehen möchte, der kann sich mittels telnet mit dem Server verbinden und das Kommando GET abschicken:

$ telnet www.spielge.de 80
GET /index.html HTTP/1.0

Nach zweimaligem Bestätigen finden wir in dem Ausgabefenster von Telnet die Reaktion des Servers, die zu Beginn wie folgt aussieht:

HTTP/1.0 200 OK
Date: Wed, 05 Nov 2003 11:35:22 GMT
Server: Apache/1.3.26 (Unix) mod_fastcgi/2.2.12
Cache-Control: max-age=120
Expires: Wed, 05 Nov 2003 11:36:41 GMT
P3P: policyref=">http://www.spiegel.de/w3c/p3p.xml";, CP="NOI DSP CURa ADMa DEVa TAIi
 PSAi PSDi OUR STP IND UNI COM NAV INT STA PRE"
Content-Type: text/html; charset=iso-8859-15
Via: 1.1 127.0.0.1
X-Cache: MISS from 127.0.0.1
X-Cache: MISS from lnxc-029.srv.mediaways.net
Connection: close
<!-- Vignette StoryServer 5.0 

Die GET-Anfrage ist die häufigste Methode. Da sie oft mit POST verwechselt wird, wollen wir den Unterschied noch einmal herausarbeiten.

GET

GET ist eine Anfrage für eine normale Web-Seite, die etwa durch Verfolgen eines Links oder Eintrags in der Browserzeile für die URL gestartet wird. GET wird auch manchmal verwendet, wenn Daten über Formulare an den Server geschickt werden. In diesem Fall werden die Daten URL-kodiert an die URL angehängt. Die so übertragenen Daten können jedoch nicht beliebig lang sein und sind durch das System begrenzt; die Maximalgröße ist unterschiedlich, liegt jedoch in der Regel bei etwa zwei Kilobyte. Das schränkt GET-Anfragen für Parameter ein. Herkömmliche CGI-Programme kommen an die Daten über eine Umgebungsvariable. Genau diese sind längenbeschränkt und lassen Daten nicht unendlich groß werden.

POST

Auch POST überträgt Daten an den Server. Doch POST wird vom Browser nur für Formulare innerhalb von <form> mit der Anweisung method="post" verwendet. Die Daten werden nicht einfach an die URL angehängt, sondern in einem Datenstrom übermittelt. Zuerst wird dazu der HTTP-Server kontaktiert und mit Header-Informationen versorgt. Zum Beispiel steht die Länge der Daten im Request-Header Content-length. Danach werden die Daten gesendet, die CGI-Programmen in einem Datenstrom zur Verfügung stehen. Im Gegensatz zu GET gibt es bei POST keine Begrenzung des Informationsumfangs. Diese Methode wird auch meistens zur Übermittlung von Login-Daten verwendet, da bei der GET-Methode das Passwort unkodiert in der Browserzeile zu sehen wäre.

Andere Anfrage-Methoden

Die anderen Methoden werden nicht so häufig eingesetzt. Die HEAD-Methode fragt nach den Headern einer Web-Seite, ohne die Datei selbst zu übertragen. So lässt sich zum Beispiel das Datum der Änderung beziehen und dann feststellen, ob die Datei schon im Cache ist. Aus Sicherheitsgründen werden bei den meisten am Markt angebotenen Servern die Anfragemethoden PUT und DELETE nicht angeboten, da mit ihnen direkt auf den Server geschrieben werden kann.

Tabelle 17.1 Wichtigste Methoden seit HTTP 1.1

17.2.2 Was erzeugt ein Web-Server für eine Antwort?

Beantwortet ein Web-Server eine Client-Anfrage (so genanntes Response), so schickt er das Ergebnis in einer ganz besonderen Form zurück. Diese ist wieder ASCII-basiert und erinnert an die Anfrage:

HTTP/1.1 200 OK
Content-Type: text/plain
Mein erstes Textdokument.

Diese Ausgabe besteht aus einer Statuszeile, einem oder mehreren Antwort-Headern, einer Leerzeile und dem Dokument selbst. Die Statuszeile gliedert sich in drei Bereiche. Zuerst zeigt die Information dem Browser die Version des HTTP-Protokolls an. Dann folgt eine Ganzzahl, die den Statuscode kodiert. Dieser ist in der Header-Beschreibung der RFC bei http://www.w3. org/Protocols beschrieben. Dann folgt eine kurze Textanzeige, die den Statuscode menschenlesbar macht. Einer der wohl am besten bekannten Statuscodes ist 404. Dieser zeigt an, dass die angeforderte Datei auf dem Server nicht existiert.

Das Servlet erzeugt automatisch die erste und zweite Zeile mit dem Header. Auf diese können wir Einfluss nehmen. Um ordentliche HTML-Seiten zu erstellen, wollen wir zuerst den Content-Type ändern. Danach lernen wir weitere Header kennen und unterschiedliche Statuscodes. Wir werden zudem sehen, dass unterschiedliche Header oft andere Statuscodes bedingen.

17.2.3 Wer oder was ist MIME?

Wenn eine Seite vom Server zum Browser geschickt wird, dann erkennt der Anfrager wie von Zauberhand den Typ der verschickten Datei und kann sie passend anzeigen. Woher weiß also der Browser, dass eine HTML-Datei anders darzustellen ist als eine Grafik oder eine Word-Datei mit der Endung .doc, für das ein externes Anzeigeprogramm gestartet werden muss? Der Hinweis auf den Datentyp kommt vom Server mit einer Mitteilung, die sich MIME nennt. MIME ist ursprünglich für E-Mails entwickelt worden, um binäre Dateien zu versenden, doch MIME hat für das Web mittlerweile eine größere Bedeutung bekommen. MIME geht in Bezug auf elektronische Nachrichten durch E-Mails noch etwas weiter, als es im Protokoll HTTP genutzt wird, denn bei der Kommunikation im Web werden lediglich einige zentrale Teile benutzt.

Möchte der Web-Server dem Client den passenden MIME-Typ senden, muss er erst einmal herausfinden, welchen Typ die Datei besitzt. Dazu kann er zwei Taktiken verfolgen. Er kann in die Datei hineinsehen, die ersten Bytes untersuchen und seine Prognose abgeben oder einfach über die Dateiendung gehen. Letzteres wird sehr oft bei den Implementierungen von Web-Servern angewendet. Wenn wir Servlets programmieren, dann spielen wir selbst Server und müssen den MIME-Typ eigenständig angeben.

Wenn die Datei zum Client kommt, geht das Spielchen »wer -mit wem?« weiter, denn der Client muss nun aufgrund des MIME-Typs das passende Anzeigeprogramm finden. In der Regel kann der Browser die Daten direkt anzeigen, wenn es etwa eine HTML-Seite, Textseite oder Grafik ist. Sonst greift meistens ein ActiveX-Control (Microsoft) oder ein Plugin (Netscape) ein. Wenn er diesen MIME-Typ nicht mitgeschickt bekommt (was bei Servlets allerdings nicht passieren kann, da hier bei fehlender Programmierangabe immer ein Standardwert mitgeschickt wird), muss er genauso raten wie der Server.¹ Doch bleiben wir bei dem Servlet-Fall, dass der Typ immer mitgeschickt wird. Wie sieht dieser dann aus?

Beispiele für MIME-Typen

Jeder MIME-Typ besteht aus zwei Hälften: einer Kategorie und einem Datentyp. Wichtige Kategorien sind text, audio, image, video, application. Wir wollen einige Beispiele aufführen:

text/html Dies ist der Standardtyp für Web-Seiten. Ein Servlet, welches HTML-Seiten generiert, sollte diesen Typ immer setzen. So kann der Browser sofort HTML interpretieren und die Seite aufbauen.

text/plain Hierbei handelt es sich um eine Textdatei, die nicht vom Browser interpretiert wird. Auch wenn der Text ein HTML-Text ist, baut der Server daraus keine HTML-Seite auf. Typischerweise verbindet der Server normale Textdateien mit dem Typ plain.

image Die Datentypen für Grafikformate. Beispiel: image/gif, image/jpeg für GIF und JPEG

audio Sound-Dateien, zum Beispiel audio/basic oder audio/x-wav

video Darstellbare Bewegbilder wie video/mgep oder video/quicktime

application Dazu zählen in der Regel Binärdateien, die von anderen Programmen gelesen oder ausgeführt werden, etwa application/pdf für eine PDF-Datei, application/msword für ein Microsoft Word-Dokument oder application/vnd.ms-excel für ein Excel-Dokument.

multipart Anzeige, dass der Datenstrom unterschiedliche Teile beinhaltet. Oft bei E-Mails, die einen Text und einen Datenanteil für den Anhang besitzen. Beispiel: multipart/mixed, multipart/news.

Mittlerweile gibt es unzählige MIME-Typen, und es ist nicht sicher, dass diese immer vom Browser unterstützt werden. Im Zweifelsfall hilft nur ein Blick in die Zuordnungstabelle des Browsers. Unter ftp://ftp.isi.edu/in-notes/iana/assignments/media-types lässt sich in Erfahrung bringen, wo welcher MIME-Typ genau definiert ist.

¹ Der Microsoft Internet Explorer nutzt dazu eine Betriebssystemmethode mit dem Namen FindMimeFromData(). Mehr Informationen zu dieser Thematik findet der Leser auf den Microsoft-Seiten.