Missionare müssen indianisch lernen – mit lateinisch bekehrt man keine Indianer. – Kurt Tucholsky

13 Server für Webanwendungen

Bereits in Kapitel 6, »Windows«, 7, »Linux« und 8, »Mac OS X«, haben Sie einige Netzwerk-Serverdienste kennengelernt. Dort ging es um Datei- und Druckserver, die vornehmlich im lokalen Netzwerk von Firmen und Organisationen eingesetzt werden. In diesem und dem nächsten Kapitel werden dagegen Internet-Server behandelt, die für den systemunabhängigen Fernzugriff durch viele, oft anonyme Benutzer konzipiert wurden, aber auch oft im lokalen Intranet eingesetzt werden.

Im vorliegenden Kapitel erfahren Sie, wie Sie eine Infrastruktur für datenbankgetriebene PHP-Webanwendungen einrichten – ein LAMP- oder WAMP-System aus Linux beziehungsweise Windows, Apache, MySQL und PHP. [Wenn Sie ein BSD-UNIX verwenden, müsste die Konstellation »BAMP« heißen, mit Mac OS X »MAMP« und so weiter. Ein weiter unten angesprochenes Kompaktpaket aus all diesen Anwendungen heißt daher XAMPP – X für das austauschbare Betriebssystem sowie Apache, MySQL, PHP und Perl. ] Die Entwicklung der zugehörigen Anwendungen wird in Kapitel 18, »Webserveranwendungen«, beschrieben.

13.1 HTTP im Überblick

Wie bereits erwähnt, kommunizieren Webserver und Browser über das TCP/IP-Anwendungsprotokoll HTTP (Hypertext Transfer Protocol). Wie die meisten Internet-Protokolle der Anwendungsebene ist es klartextbasiert und besteht aus einigen Client-Befehlen sowie Server-Antworten in einem bestimmten Format. Es handelt sich also um ein Request/Response-Verfahren (Anfrage und Antwort).

13.1.1 Ablauf der HTTP-Kommunikation

Die HTTP-Kommunikation läuft von der Dokumentanforderung durch den Browser bis zur Darstellung oder Speicherung des empfangenen Dokuments wie folgt ab:

GET /fachinfo/index.html HTTP/1.1

HTTP/1.1 200 OK

Zum Schluss nimmt der Browser den Body der Server-Antwort entgegen und zeigt ihn je nach Datentyp selbst an (zum Beispiel HTML-Dokumente und bestimmte Bild- oder Multimediadateien) oder bietet ihn zum Speichern auf Datenträger an. Außerdem speichert er viele gelieferte Dokumente in seinem Cache, damit zuvor angeforderte Dateien nicht nochmals heruntergeladen werden müssen.

Hier ein Beispiel für eine komplette GET-Anfrage:

GET /fachinfo/index.html HTTP/1.1 
Accept: */* 
Accept-Language: de, en-US 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; 
i-NavFourF; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2) 
Host: buecher.lingoworld.de 
Connection: Keep-Alive

Die Header dieser Anfrage haben folgende Bedeutung:

• Accept: */* Jeder beliebige MIME-Type (Typ/Untertyp) wird akzeptiert. Das heißt lediglich, dass der Browser keinen bestimmten Datentyp bevorzugt, aber nicht, dass er auch jeden verarbeiten könnte.

• Accept-Language: de, en-US Wenn der Server mehrere Sprachvarianten einer Ressource zur Wahl stellt, bevorzugt dieser Browser Deutsch und US-Englisch in der angegebenen Reihenfolge.

• Accept-Encoding: gzip, deflate Der Browser ist in der Lage, GNUZip- oder ZIP-komprimierte Ressourcen anzunehmen und selbst zu entpacken; wenn ein Server dies unterstützt, spart es Netzwerkbandbreite.

• User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; i-NavFourF; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2) Dies ist die Angabe der Browserversion, die der Server zum Umgang mit Inkompatibilitäten auswerten kann sowie zu statistischen Zwecken in seine Logdateien schreibt. Hierbei handelt es sich um den Microsoft Internet Explorer 7.0 unter Windows XP. [Der interne Name vieler Browser lautet »Mozilla«, weil die gleichnamige Echse das Maskottchen des ersten grafischen Browsers NCSA Mosaic war, von dem sowohl der Internet Explorer als auch Netscape und die heutigen Mozilla-Browser abstammen ]

• Host: buecher.lingoworld.de Wie bereits erwähnt, ist dies ein Pflicht-Header, der bestimmt, welcher virtuelle Host angesprochen wurde.

• Connection: Keep-Alive Der Browser fordert an, dass der Server die TCP-Verbindung nach dem Versand der aktuellen Antwort offenhalten soll. Dies beschleunigt den Seitenaufbau, weil beispielsweise für jedes eingebettete Bild eine weitere Anfrage erforderlich ist, die über eine bereits geöffnete Verbindung schneller bearbeitet werden kann.

• • Bei einer erfolgreichen Anfrage könnte die Server-Antwort beispielsweise so aussehen:

HTTP/1.1 200 OK 
Date: Thu, 16 Apr 2009 12:18:57 GMT 
Server: Apache/2.2.9 (Unix) 
Last-Modified: Mon, 22 Sep 2008 10:21:37 GMT 
ETag: "1b380f2-1ba9-454723b1" 
Accept-Ranges: bytes 
Content-Length: 7081 
Content-Type: text/html 
 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 
4.0//Transitional//EN"> 
<html> 
<head> 
[...]

Hier die Bedeutung der Antwort-Header:

• Date: Thu, 16 Apr 2009 12:18:57 GMT Datum und Uhrzeit des Servers

• Server: Apache/2.2.9 (Unix) Versionsinformationen des Servers; die Ausführlichkeit kann mithilfe der weiter unten vorgestellten Direktive ServerTokens geändert werden

• Last-Modified: Mon, 16 Sep 2008 10:21:37 GMT Datum und Uhrzeit der letzten Änderung; wird vom Browser verwendet, um – zum Beispiel per HEAD-Anfrage – zu entscheiden, ob eine eventuell noch im Cache befindliche Version aktuell ist

• ETag: "1b380f2–1ba9–454723b1" Ein Hash-Wert aus Metadaten wie Änderungsdatum und Dateigröße, der Aufschluss über die Identität einer Ressource gibt und so ebenfalls für Cache-Entscheidungen verwendet werden kann.

• Accept-Ranges: bytes Der Server kann auf Wunsch Teile eines Dokuments ausliefern, wenn der Browser in einem Range-Header die gewünschten Byte-Grenzen mitteilt – dies ist etwa praktisch, um abgebrochene Downloads später fortzusetzen.

• Content-Length: 7081 Länge des gelieferten Bodys in Byte

• Connection: keep-alive Der Server bestätigt die Bitte des Browsers, die Verbindung offenzuhalten.

• Content-Type: text/html Der bereits erwähnte MIME-Type des Bodys, der wichtigste Antwort-Header. Im vorliegenden Beispiel handelt es sich um den Haupttyp Text und den Untertyp HTML.

13.1.2 HTTP-Statuscodes

Es wurde bereits erwähnt, dass jede HTTP-Antwort eine Statusmeldung enthält, bestehend aus Codenummer und Beschreibungstext. Die Codes werden anhand ihrer ersten Ziffer in folgende Gruppen unterteilt:

• 1xx – Information

• 2xx – Erfolgsmeldungen

• 3xx – Umleitungsmeldungen

• 4xx – Client-Fehler

• 5xx – Server-Fehler

Zur ersten Gruppe, den informativen Meldungen, gehören nur zwei Statuscodes: 100 Continue besagt, dass der Server eine vorbereitende Anfrage erhalten hat und auf eine Fortsetzung wartet. 101 Switching Protocols gibt an, dass der Server auf die im Header Upgrade angegebene HTTP-Version wechseln möchte. Beides kommt relativ selten vor.

Statuscodes, die mit 2 beginnen, zeigen eine erfolgreiche Verarbeitung der Anfrage an. Die häufigste dieser Antworten ist 200 OK; sie wird bei fast allen erfolgreichen GET-, HEAD-, POST- und DELETE-Anfragen zurückgeliefert.

3xx-Statuscodes sind für Weiterleitungen zuständig. Diese werden unter anderem verwendet, wenn ein serverseitiges Skript zwar Formulardaten verarbeitet, aber keine eigene Ausgabe erzeugt. In diesem Fall kann es einen Location-Header mit einer Weiterleitungs-URL senden, zusammen mit einem der Statuscodes 301 Moved Permanantly, 302 Found, 303 See Other oder 307 Temporary Redirect. Der Status 304 Not Modified dient dagegen als Antwort auf HEAD-Anfragen, die es dem Browser erlaubt, ein Dokument aus seinem Cache anzuzeigen.

4xx-Statuscodes zeigen verschiedene Fehlerzustände an, die aufgrund einer fehlerhaften oder unvollständigen Client-Anfrage zustandegekommen sind. Der häufigste Header dieser Gruppe ist sicherlich 404 Not Found; er kommt sowohl bei Tippfehlern im Ressourcenteil einer eingegebenen URL als auch bei fehlerhaften oder veralteten Links vor. 401 Unauthorized wird gesendet, wenn der Server eine Benutzeranmeldung erwartet; dies wird weiter unten erläutert. Bei 403 Forbidden ist der Zugriff dagegen grundsätzlich verboten; auch eine Authentifizierung würde nichts daran ändern.

5xx-Statuscodes schließlich bezeichnen Fehler, die aufgrund eines serverseitigen Pro-blems entstanden sind. Der häufigste dieser Fehler, 500 Internal Server Error, kommt unter anderem oft vor, wenn Sie bei der Programmierung eigener Webanwendungen Fehler machen. Einzelheiten über den Fehler stehen in diesem Fall in der Error-Logdatei Ihres Webservers (siehe unten).

In Tabelle 13.2 sehen Sie noch einmal alle Statuscodes im Überblick.

13.1.3 HTTP-Header

Wie bereits erwähnt enthalten HTTP-Anfrage und -Antwort verschiedene Header im Format

Header-Name: Wert[, Wert ...]

Die Namen der Header bestehen aus Buchstaben und Bindestrichen; Groß- und Kleinschreibung spielen keine Rolle. Falls ein Header mehrere Werte besitzt, werden diese durch Komma getrennt.

Neben den in RFCs definierten offiziellen HTTP-Header können Server und Clients auch beliebige zusätzliche Header senden. Gemäß der Konvention sollten solche Erweiterungs-Header stets mit X- beginnen, also beispielsweise X-My-Header heißen.

Tabelle 13.3 zeigt alle offiziellen HTTP-Standard-Header. Die einzelnen Spalten der Tabelle haben folgende Bedeutung:

• Header Der Name des jeweiligen Headers

• Seit Version Gibt die HTTP-Version an, in der der jeweilige Header eingeführt wurde: HTTP/1.0 gemäß RFC 1945 oder HTTP/1.1 (RFC 2616). Die nachträglich so benannte Vorabversion HTTP/0.9 besaß noch keine Header, sondern nur die Anfrage- beziehungsweise Statuszeile.

• Anfr. (Anfrage) Angekreuzt, wenn der Header in einer HTTP-Anfrage stehen kann

• Antw. (Antwort) Angekreuzt für Header, die in einer HTTP-Antwort vorkommen können

• Ent. (Entity) Angekreuzt für Header, die den Body der Anfrage beziehungsweise Antwort beschreiben

• Bedeutung Kurze Beschreibung der Aufgaben des Headers

Ihr Kommentar