PHP 5 - Ein praktischer Einstieg
2. Auflage

PHP 5 - Ein praktischer Einstieg, 2. Auflage

Von Ulrich Günther
2. Auflage, August 2004
O'Reilly Verlag, ISBN: 3-89721-278-1
www.oreilly.de/catalog/einphp2ger/



TOC PREV NEXT INDEX

Kapitel 2

Kapitel 2

Technische Grundlagen

In diesem Buch stehen uns noch eine ganze Menge technische Details bevor. Deshalb ist es nötig, dass wir uns erst einmal einen Überblick über die Grundlagen des WWW und die wichtigsten Web-Technologien verschaffen. In diesem Kapitel werden wir uns nicht nur ansehen, wie das Zusammenspiel zwischen einem Webbrowser und einem Webserver funktioniert, sondern auch, wie und wo Web-Dokumente erzeugt, gespeichert und beeinflusst werden können.

Fangen wir mit der Lingua Franca des World Wide Web an: dem HTTP-Protokoll und seinen Bausteinen IP und TCP.

Das Hypertext Transfer Protocol (HTTP)

Dass Computer miteinander kommunzieren und Daten austauschen können, ist für Sie sicher keine Neuigkeit. Dazu werden Computer über Kabel, Glasfasern und Funkstrecken miteinander verbunden. Wenn wir erst einmal eine solche physikalische Verbindung hergestellt haben, stellt sich die Frage, wie wir die Daten robust und zielgerichtet austauschen.

Für diesen Zweck gibt es einen ganzen Stapel von Protokollen. Das fundamentalste dieser Protokolle ist das so genannte Internet Protocol (IP). Die von IP zur Verfügung gestellten Funktionen werden von dem so genannten Transport Control Protocol (TCP) verwendet, das wiederum von HTTP verwendet wird. Sehen wir uns IP und TCP kurz an, um HTTP besser verstehen zu können.

Das Internet Protocol (IP)

Dabei handelt es sich um eine Konvention, die besagt, wie man Daten in einen Datenblock (ein so genanntes Paket oder engl. packet) packt und diesen durch ein Computer-Netzwerk namens Internet an einen Empfänger-Computer versendet. Abbildung 2-1 verdeutlicht das Prinzip.
Abbildung 2-1 Internet Protocol: Ein einzelnes nicht-nummeriertes Datenpaket wird von einem Computer A an einen Computer B geschickt

Zu diesem Zweck muss der sendende Computer zwei Informationen kennen: die Internet-Adresse (IP-Adresse) des Empfängers. Sie dient zum Auffinden des Empfängers im Netz, so wie eine Telefonnummer zum Auffinden eines Telefons im Telefonnetz dient. Die IP-Adresse ist bis heute eine Zahl, die aus vier Bytes besteht, z.B. 130.216.197.6. Der Wert jedes Bytes kann im Prinzip zwischen 0 und 255 liegen. Die Version 6 von IP ist allerdings schon einsatzreif und sieht erheblich größere Adressbereiche vor.

Das Versenden von einzelnen Datenpaketen ist allerdings eine ziemliche Ad-hoc-Angelegenheit, insbesondere weil IP noch nicht einmal garantiert, dass die Pakete auch ankommen. In den meisten Fällen brauchen Anwendungen etwas Zuverlässigeres. Dafür gibt es TCP.

Das Transport Control Protocol (TCP)

Das Transport Control Protocol definiert ein Verfahren zum Austausch von Paketen, so dass der Empfänger-Computer dem Sender Rückmeldung über den Empfang von Daten geben und Antwortdaten an den Sender zurückschicken kann.

TCP bringt außerdem vier wichtige Konzepte ins Spiel, die uns immer wieder begegnen werden:

  1. Das Konzept einer Verbindung (Connection). Eine Verbindung ist ein geregelter Paketfluss in beiden Richtungen zwischen zwei Anwendungen auf zwei Computern. In der Praxis können Sie sich das wie eine Telefonverbindung vorstellen, nur dass Sie statt Sprache Daten in die Leitung schicken.
  2. Das Konzept der Ports beim Empfänger und beim Sender. Weil ein Computer gleichzeitig mehrere Anwendungen betreiben kann, die mit anderen Computern im Internet kommunizieren müssen (z.B. Webserver, Browser, E-Mail-Programm, Chat usw.), müssen wir sicherstellen, dass unsere Datenpakete beim Empfänger an die richtige Anwendung gelangen. Deshalb enthält jedes TCP-Paket zwei Portnummern zwischen 0 und 65535. Diese Nummern identifizieren jeweils die Anwendungen auf beiden Seiten der Verbindung, die miteinander kommunizieren. Sie können sich das in etwa so vorstellen, dass ein Computer jeweils nur als eine Art Postamt agiert und die Portnummern die Postfachnummern des eigentlichen Senders bzw. Empfängers darstellen.
  3. Das Konzept des Clients, das heißt des Computers bzw. der Anwendung, die den Verbindungsaufbau einleitet.
  4. Das Konzept des Servers, das heißt des Computers bzw. der Anwendung, die auf eingehende Verbindungen wartet und sie »bedient«.

Da TCP und IP heute fast immer zusammen verwendet werden, ist auch oft von »TCP über IP« bzw. schlicht von »TCP/IP« die Rede.

Verbindungen mit TCP/IP sind fehlerfrei. Das heißt, die beiden Kommunikationspartner können sich sicher sein, dass Daten, die über die Verbindung empfangen werden, auch so von der Gegenseite abgeschickt worden sind. Abbildung 2-2 zeigt, wie durchnummerierte Pakete zwischen einem Client und einem Server ausgetauscht werden.
Abbildung 2-2 Datenverbindung mit TCP/IP; die Pakete tragen unter TCP eine Seriennummer (hier vereinfacht dargestellt), so dass fehlende Pakete erkannt, gemeldet und neu gesendet werden können

Dank TCP/IP wurden Anwendungen möglich, die auf robuste Kommunikationskanäle angewiesen sind. Zu den frühen Anwendungen dieser Art gehören Telnet (ein Protokoll, das es ermöglicht, einen entfernten Computer so zu bedienen, als sitze man an seiner Tastatur und seinem Bildschirm) und FTP (ein Dateiübertragungsprotokoll, mit dem man Dateien aller Art zwischen Computern austauschen kann).

Das Grundprinzip der HTTP-Kommunikation

Im Jahr 1989 publizierte der Physiker Tim Berners-Lee vom europäischen Kernforschungszentrum CERN die Idee, Dateien im Internet zu verknüpfen und in einer speziellen Anwendung darzustellen: einem Webbrowser. Zu diesem Zweck entwickelte er ein eigenes Protokoll namens HTTP zur Übertragung dieser Dateien - das HyperText Transfer Protocol (die verknüpften Dateien bestanden zunächst fast ausschließlich aus speziell formatiertem Text - so genanntem HyperText).

HTTP legt fest, wie ein Client und ein Server im Internet über eine TCP/IP-Verbindung kommunizieren müssen, um die Funktionalität des WWW zu implementieren.

Der Client ist dabei der Computer, auf dem der Webbrowser läuft, während der Server - Sie haben es erraten - die Maschine ist, auf der das Webserver-Programm läuft und auf der die Webseiten gespeichert sind.

Eine HTTP-Kommunikation ist eigentlich ganz einfach. Sie besteht aus vier Schritten:

  1. Der Client baut eine TCP/IP-Verbindung (Connection) zum Server auf. Der dabei verwendete Port am Server ist üblicherweise der Default-Port 80, wobei experimentelle und Zweitserver auch oft auf anderen Ports mit einer 8 in der Portnummer laufen: 88, 8080, 8008, 8088 usw. Die Portnummer des Clients wird von diesem automatisch gewählt.
  2. Sobald die Verbindung steht, schickt der Client eine Anfrage (HTTP-Request genannt) an den Server, in der er mitteilt, was er vom Server möchte. Das ist üblicherweise eine Webseite, die der Client über eine Webadresse (auch Universal Resource Locator bzw. URL genannt) identifiziert.
  3. Der Server bearbeitet den eingehenden HTTP-Request und schickt dem Client eine Antwort (HTTP-Response) zurück. Die HTTP-Response enthält im Erfolgsfall u.a. das Dokument mit der vom Client angeforderten Webseite.
  4. Falls Client und/oder Server im HTTP-Request bzw. in der HTTP-Response keine Aufrechterhaltung der TCP/IP-Verbindung erbeten bzw. vorgeschlagen haben (z.B. zum nachfolgenden Herunterladen von Bildern, die zu einer Webseite gehören), trennt der Server die Verbindung zum Client (Disconnect).
    Abbildung 2-3 Der Ablauf eines Request/Response-Austauschs in HTTP

Abbildung 2-3 zeigt diesen Ablauf und den dabei involvierten Meldungsaustausch. Wenn Sie dynamische Webseiten mit PHP programmieren wollen, sollten Sie diese Vorgänge verstehen. Zum Glück ist HTTP ziemlich einfach gehalten.

Verbindungsaufbau zum Server

Den Verbindungsaufbau zum Server übernimmt Ihr Webbrowser automatisch. Dazu sucht er sich in der angegebenen Webadresse (URL) den Servernamen und ggf. den Port heraus, soweit dieser angegeben ist. Wenn die URL beispielsweise http://www.oreilly.de:80/index.html ist, ist der zugehörige Server www.oreilly.de und die Portnummer 80.

Bevor der Client ein Paket zum Verbindungsaufbau an den Server schicken kann, muss er die IP-Adresse des Servers kennen. Die kann der Client über den Servernamen erfahren. Dazu schickt er den Namen über eine TCP/IP-Verbindung an einen so genannten DNS-Server, dessen Adresse zu den Konfigurationsdaten des Clients gehört. Der DNS-Server spielt dabei die Rolle der »Telefonauskunft«: Er liefert dem Client die gewünschte IP-Adresse zurück. Mit der IP-Adresse kann der Client dann eine Verbindung zu der angegebenen Portnummer des Servers aufbauen.

Wenn Ihr Computer richtig eingerichtet ist, spielt sich das alles hinter den Kulissen ab. Aber auch manuell ist das möglich. Dazu geben Sie unter Linux in der Kommandozeile und unter Windows unter Start > Ausführen... das folgende Kommando ein:

telnet www.oreilly.de 80
 

Was dann passiert, hängt etwas von Ihrem Betriebssystem ab. Sowohl Linux als auch Windows werden Ihnen im Regelfall sagen, dass die Verbindung aufgebaut wird. Ihr Computer sendet dann eine Bitte um Verbindungsaufbau an den Webserver. Der Webserver antwortet mit einer Bestätigung an Ihren Rechner.

Linux wird jetzt eine Meldung ausgeben, die besagt, dass die Verbindung steht. Unter Windows springt ggf. nur der Cursor in die nächste Zeile, oder es erscheint ein schwarzer Schirm mit einem Cursor. Wie auch immer: Sie sind drin - Sie reden mit einem Webserver.

Der HTTP-Request

Nur zu gut, dass das HTTP-Protokoll zu einem großen Teil aus dem Austausch von Textinformationen besteht. So können Sie mit dem Webserver tatsächlich reden, ohne sich in Einsen und Nullen ausdrücken zu müssen. Geben Sie dann einfach mal die folgenden zwei Zeilen ein (kriegen Sie keine Panik, wenn Sie beim Tippen nichts sehen), gefolgt von einer Leerzeile:

GET  /index.html HTTP/1.1
 
Host:www.oreilly.de
 

Nachdem Sie die Leerzeile eingegeben haben, wird Ihnen plötzlich der Bildschirm voll geschrieben. Die beiden obigen Zeilen sind nämlich bereits ein gültiger HTTP-Request, den praktisch alle modernen Webserver verstehen sollten. Die Reaktion, die Sie sehen, ist die HTTP-Response des Servers!

Ein HTTP-Request besteht aus einer Request-Zeile und (ab HTTP-Version 1.1) aus einer oder mehreren so genannten Header-Zeilen. Header-Zeilen bestehen aus einem Header-Namen und dem so genannten Content (Inhalt), der hinter dem Doppelpunkt steht.

In der ersten Zeile (der Request-Zeile) schicken wir ein GET-Kommando (auch GET-Methode genannt) an den Webserver, mit dem wir die Indexdatei index.html des Webserver-Stammverzeichnisses (Document Root) anfordern. Der letzte Teil der GET-Methode gibt das Protokoll (HTTP) und dessen Version (1.1) an.

Die nächste Zeile in unserem Beispiel ist die einzige Header-Zeile, der so enannte Host-Header. Als Host bezeichnet man generell einen Computer, mit dem man eine Verbindung aufbauen kann. Der Content des Host-Headers gibt hier konkret den Webserver an, von dem der Client das Dokument anfordert. Moment mal - warum müssen wir das dem Server mitteilen? Weiß der Webserver etwa nicht, wie er heißt? Die Antwort ist ein entschiedenes: »Ja, aber ...«

Unter einer einzigen IP-Adresse und einem Port können sich nämlich tatsächlich »verschiedene« Webserver befinden. Solche Webserver nennt man »virtuelle« Webserver oder »virtual hosts« - den Begriff »virtual webhosting« haben Sie vielleicht schon einmal gehört.

Dabei handelt es sich zwar immer um dasselbe Webserver-Programm, das aber je nach übergebenem Host-Header eine andere »Persönlichkeit« annimmt. Das kann zum Beispiel bedeuten, dass das Document-Root-Verzeichnis bei jedem virtuellen Server einem anderen physikalischen Verzeichnis auf der Festplatte des Webserver-Computers entspricht. Auf diese Weise lassen sich auf einem einzigen Computer eine große Anzahl Websites unterbringen.

In dem obigen Fall führen die beiden Zeilen dazu, dass Ihnen der Webserver des O'Reilly Verlags eine HTTP-Response mit der angeforderten Webseite zurückschickt.

Die meisten HTTP-Requests von »echten« Browsern sind allerdings noch etwas aufwendiger. Der nächste Abschnitt beschreibt HTTP-Requests von Netscape 6 und Internet Explorer.

HTTP-Requests von Netscape und Internet Explorer

Ein HTTP-Request von Netscape 6.2.2 kann wie folgt aussehen:

GET / HTTP/1.1
 
Host: localhost
 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) 
 
     Gecko/20020314 Netscape6/6.2.2
 
Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, 
 
     image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1
 
Accept-Language: en-us
 
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
 

Nun, die Request-Zeile kennen Sie schon. Wenn das Dokument dort nur mit einem Schrägstrich (oder mit einem Pfadnamen, gefolgt von einem Schrägstrich) angegeben ist, soll der Server entweder die Indexdatei (typischerweise index.html oder index.htm) oder ein Inhaltsverzeichnis des angegebenen Verzeichnisses zurückliefern. Dem Host-Header sind wir auch schon begegnet.

Der User-Agent-Header gibt dem Server an, mit welchem Browser er es zu tun hat, ggf. unter Angabe des Betriebssystems, für das die Browser-Software geschrieben wurde. Das ermöglicht dem Server, maßgeschneiderte Dokumente zu erzeugen. Wenn der Browser beispielsweise eine bestimmte Funktionalität (z.B. DHTML) nicht unterstützt, kann der Server das am User-Agent-Header erkennen und gegebenenfalls eine spezielle Response liefern, die diese Funktionalität nicht benötigt.

Die diversen Accept-Header geben an, mit welchen Dateiformaten, Sprachen, Codierungen und Zeichensätzen der Browser umgehen kann. Das können Sie z.B. zum Erstellen von sprachspezifischen Antworten verwenden. Wenn die Accept-Language nicht en-us, sondern de ist, können Sie eigentlich damit rechnen, dass der Benutzer des Browsers eine Seite auch in Deutsch versteht.

Die Header Keep-Alive und Connection bitten den Server darum, die Verbindung auch nach der Auslieferung des Dokuments aufrechtzuerhalten. Das kann beispielsweise sinnvoll sein, wenn ein erwartetes Dokument vielleicht Bilder oder Frames enthalten könnte, die von demselben Webserver zu beziehen sind. In diesem Fall muss der Browser dann nicht erst mühsam und Zeit raubend eine neue Verbindung zum Server aufbauen. Wie schon bei unserem »hausgemachten« Request schließen wir die Header mit einer Leerzeile ab. Sie signalisiert dem Server, dass er mit der Bearbeitung des Requests anfangen kann.

Beim Internet Explorer 5.5 sieht ein HTTP-Request auch nicht viel anders aus, hat aber einen gewissen »Microsoft-Geschmack«:

GET / HTTP/1.1
 
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/
 
     vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, application/
 
     pdf, */*
 
Accept-Language: en-us
 
Accept-Encoding: gzip, deflate
 
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
 
Host: localhost
 
Connection: Keep-Alive
 
Daten zum Server schicken

Alle bisher besprochenen HTTP-Requests waren GET-Requests. Diese werden normalerweise zum direkten Anfordern von Dokumenten verwendet. Falls zusätzliche Daten mit GET an den Server übergeben werden sollen, beispielsweise Formulardaten, können wir das mit einem Abfrage-String tun. Er wird nach einem Fragezeichen an die URL angehängt. In der folgenden URL werden ein Kundenname und eine Nummer an den Server übergeben:

http://www.beispiel.de/meinskript.php?kundenname=Fred%20Fisch&nr=54362
 

Die Name-Wert-Paare werden dabei durch ein Ampersand-Zeichen (&, »Kaufmanns-Und«) getrennt. Da gewisse Zeichen nicht in einer URL vorkommen dürfen oder spezielle Bedeutungen haben, werden solche durch ihre Hexadezimaldarstellung ersetzt. Die Zeichenfolge %20 steht beispielsweise für ein Leerzeichen. In einen HTTP-Request übersetzt, sieht diese URL so aus:

GET /meinskript.php?kundenname=Fred%20Fisch&nr=54362 HTTP/1.1
 

Dieses Verfahren hat allerdings auch seine Nachteile: Vertrauliche Daten lassen sich so schwer übermitteln, außerdem führt es zu unleserlichen Bandwurm-URLs. Deswegen gibt es eine andere Methode, die bei Formulardaten im Regelfall vorzuziehen ist: den so genannten POST-Request.

In einem POST-Request werden die Daten nach den Request-Headern übertragen. Vor und nach den Daten befindet sich jeweils eine Leerzeile, die die Daten von den Headern trennt bzw. das Ende des Requests markiert.

Der folgende POST-Request von Netscape 6.2.2 schickt zwei Variablen, spendername und adresse, an den Server:

POST /meinanderesskript.php HTTP/1.1
 
Host: www.meinhost.com
 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) 
 
     Gecko/20020314 Netscape6/6.2.2
 
Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, 
 
     image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1
 
Accept-Language: en-us
 
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
 
Content-type: application/x-www-form-urlencoded
 
Content-Length: 62
 

 
spendername=Fred+Fisch&adresse=Am+feuchten+Weg+25%0D%0AHamburg
 

In diesem Fall kommen noch zwei zusätzliche Header hinzu: Content-type, der die Art der angehängten Daten angibt, und Content-Length, der die Länge der Daten in Bytes angibt. In Daten vom Typ application/x-www-form-urlencoded werden »problematische« Zeichen ebenfalls in Hexadezimaldarstellung codiert, aus historischen Gründen wird das Leerzeichen aber als ein Pluszeichen dargestellt.

So, jetzt wissen Sie (fast) alles, was Sie zum Ansprechen eines Webservers brauchen. Jetzt ist der Server an der Reihe. Er antwortet mit einer HTTP-Response.

Die HTTP-Response

Die Antwort eines Webservers auf einen HTTP-Request bezeichnet man als HTTP-Response. Auch eine HTTP-Response besteht zunächst einmal hauptsächlich aus Text. Selbst auf einfache, handgestrickte HTTP-Requests wie den obigen antworten die meisten Webserver sehr ausführlich. Eine (verkürzte) Response des O'Reilly-Webservers kann ungefähr so aussehen:

HTTP/1.1 200 OK
 
Date: Wed, 08 May 2002 03:44:38 GMT
 
Server: Apache/1.3.20 (Linux/SuSE) mod_perl/1.26 mod_ssl/2.8.4 OpenSSL/0.9.6b 
 
     PHP/4.2.0
 
Content-Length: 19022
 
Keep-Alive: timeout=1, max=100
 
Connection: Keep-Alive
 
Content-Type: text/html
 

 
<html>
 
<head>
 
<title>Willkommen beim O'Reilly Verlag</title>
 
...
 

Die erste Zeile einer HTTP-Response ist immer die Response-Zeile. Sie fängt stets mit dem String HTTP an, gefolgt von einem Schrägstrich und der vom Server angebotenen HTTP-Version, in diesem Fall 1.1. Dem folgt ein dreistelliger Status-Code und ein kurzer String, der diesen beschreibt.

Die häufigsten Status-Codes sind:

200 OK
HTTP-Request kann zufrieden stellend beantwortet werden.
403 Forbidden
Der Server darf das angeforderte Dokument nicht an den Client ausliefern (z.B. weil das Dokument nur im Intranet des Server-Betreibers sichtbar ist).
404 Not Found
Das angeforderte Dokument wurde nicht auf dem Server gefunden. Diesen Status-Code haben Sie vermutlich schon öfter gesehen.
500 Internal Server Error
Diesen Response-Code bekommen Sie im Regelfall dann, wenn ein CGI-Skript wegen eines Fehlers abstürzt. Entwickler von CGI-Skripten bekommen diesen Status-Code häufig zu Gesicht - PHP-Entwickler praktisch nie: PHP sorgt bei Programmierfehlern in der Regel für eine sanftere Landung mit einem Status-Code 200.
304 Not Modified
Ihr Browser bekommt diesen Status-Code oft zu sehen, wenn er ein Dokument mit einem Request-Header If-Modified-Since anfordert. Wenn sich das angeforderte Dokument seit dem im Request-Header angegebenen Zeitpunkt nicht geändert hat, teilt der Server das dem Browser auf diese Weise mit. Der Browser kann das Dokument dann aus seinem Cache beziehen.

Auf die Response-Zeile folgen die Response-Header, eine Leerzeile und der so genannte Response-Body, das heißt der eigentliche Inhalt der Response, also im Regelfall das angeforderte Dokument.

Der erste Header besteht aus dem Zeitstempel des Webservers. Damit erfährt der Browser, auf welche Zeit der Server seine Zeitangaben bezieht. Diese Zeit kann sich von der des Browsers unterscheiden, z.B. weil die Uhr des Client-Computers bzw. des Servers nicht richtig gestellt ist.

Dies ist wichtig, wenn der Browser das angegebene Dokument erneut anfordern will. Er muss dem Server dann einen HTTP-Request mit dem Header If-Modified-Since schicken, dessen Zeitstempel auf der hier angegebenen Server-Zeit beruht.

Der Server-Header hat für den Browser in der Regel keine besondere Bedeutung, wird aber von fast allen Servern zwecks Eigenwerbung implementiert. So kommen u.a. Statistiken wie beispielsweise http://www.php.net/usage.php zu Stande.

Der Content-Length-Header gibt die Länge des Response-Body in Bytes an. In manchen Responses fehlt dieser Header, und es wird stattdessen eine Hexadezimalzahl in einer eigenen Zeile zwischen Header und Body der Response ausgegeben.

Die nächsten beiden Header, Keep-Alive und Connection, regeln die Erwartung des Webservers für die Zeit, nachdem er das Dokument an den Client ausgeliefert hat. Sie haben hier leicht andere Bedeutungen als im HTTP-Request.

Erwartet der Webserver noch weitere HTTP-Requests desselben Clients (z.B. weil ausgelieferte Dokumente Frames oder Bilder enthalten, die als eigene Dokumente angefordert werden müssen), lassen sich Zeit und Kommunikationsressourcen sparen, indem die Verbindung zwischen Client und Server »am Leben« gehalten wird.

Die Verbindung kann natürlich nicht auf ewig bestehen, deshalb wird eine maximale Verbindungszeit (Timeout) in Sekunden angegeben. Außerdem wird die maximale Anzahl der Dokumente festgelegt, die der Browser über diese Verbindung anfordern darf. Wenn der Webserver die Verbindung nicht aufrechterhalten möchte, wird das mit Connection: close angezeigt.

Dem nächsten Header, Content-type, sind wir auch schon im HTTP-Request begegnet. Er gibt an, welche Art Daten das mitgelieferte Dokument enthält. Dazu wird der so genannte MIME-Dokumenttyp1 angegeben. In unserem Fall ist das text/html, d.h. ein Textdokument mit HTML-Markup, eine typische Webseite also. Andere geläufige Dokumenttypen sind z.B. Bilder wie image/gif oder image/jpeg, PDF-Dokumente mit application/pdf oder Musikdateien mit audio/mp3.

Wie beim HTTP-Request werden auch in der HTTP-Response die Header mit einer Leerzeile beendet, gefolgt von den Daten des Response-Body. Je nach Connection-Header schließt der Server danach die Verbindung oder hält sie noch eine Zeit lang aufrecht, um dem Client zusätzliche Requests zu vereinfachen.

Statische und dynamische Dokumente

Im Web unterscheidet man zwischen drei Arten von Dokumenten: statischen Dokumenten, serverseitig erzeugten Dokumenten und clientseitig erzeugten Dokumenten. Die letzten beiden Arten bezeichnet man auch als dynamische Dokumente, da sie jeweils auf die Bedürfnisse des Clients zugeschnitten erzeugt werden. Um Web-Technologien verstehen und einordnen zu können, sollten Sie mit den Unterschieden vertraut sein.

Statische Dokumente

Ein statisches Dokument können Sie sich ein bisschen wie kalt gewordene Standardpizza vorstellen, die Ihnen an die Haustür geliefert wird. Sie rufen beim Pizzadienst an, dort nimmt man eine mehr oder minder erkaltete Quattro Stagioni vom Regal, und wenige Sekunden später ist sie bei Ihnen an der Haustür.

Statische Dokumente sind die einfachsten Dokumente, die Sie im Internet finden können. Dazu gehören z.B. einfache HTML-Dokumente, Bilder, MP3-Clips, PDF-Dateien oder Software zum Herunterladen und Installieren. Alle diese Dokumente haben eines gemeinsam: Sie sind als Dateien auf dem Webserver gespeichert, also - wie unsere Pizza - bereits gebacken, bevor wir sie bestellen.

Wenn der Webbrowser ein statisches Dokument anfordert, öffnet der Webserver die Datei einfach und schickt ihren Inhalt unbesehen im Response-Body an den Browser. Das geht ziemlich schnell. Die Pizza liegt ja bereits im Regal.

Für den Pizzabäcker bzw. Webserver ist es kein großer Aufwand: Die Datei kann unverändert weitergegeben werden, keine weiteren Prozesse müssen gestartet werden, und eine Bearbeitung des Dateiinhalts ist auch nicht nötig.

Für den Browser sind sie ebenfalls Brot-und-Butter-Fälle: Wenn der Browser selbst mit ihnen umgehen kann (wie z.B. mit HTML-Dateien), öffnet er sie, wenn nicht, leitet er sie an externe Hilfsprogramme oder Plugins weiter oder speichert sie unter einem vom Benutzer bestimmten Dateinamen ab. Klar, auch kalte Pizza ist essbar.

Der Nachteil statischer Dokumente ist, nun ja, dass sie statisch sind. Sie können mit statischen Dokumenten weder auf Benutzereingaben reagieren noch Daten nach Bedarf frisch auf dem Server zusammenstellen. Nur die üblichen Pizzasorten, sonst nichts. Extra Käse gibt's nicht, und den Schinken können Sie auch nicht weglassen.

Statische Dokumente sind also ziemlich unflexibel. Wenn Sie E-Commerce oder sonstige interaktive Websites betreiben wollen, kommen Sie um dynamische Dokumente nicht herum. Sie müssen individuell zusammengestellte, warme Pizza ausliefern.

Serverseitig erzeugte Dokumente

Serverseitig erzeugte Dokumente sind die beliebteste Variante dynamischer Dokumente. Technologien wie PHP, CGI, JSP (JavaServer Pages), Servlets, ASP oder mod_perl beruhen allesamt auf diesem Prinzip.

Die Grundidee ist eigentlich ganz einfach: Auch ein statisches Dokument ist irgendwann einmal erzeugt worden, von einem Texteditor, einem MP3-Kompressor, einem Bildbearbeitungsprogramm, einer Kamera o.Ä. Was hindert uns also daran, das Dokument erst dann zu erzeugen, wenn es gebraucht wird, d.h., wenn es vom Browser angefordert wird? Just in time sozusagen.

Der Vorteil eines serverseitig erzeugten Dokuments liegt auf der Hand: Wir können aktuelle Daten aus einer Datenbank bzw. vom Browser übergebene Daten einfließen lassen. Die Pizza wird also jetzt auf Ihren Telefonanruf hin frisch mit den Zutaten Ihrer Wahl belegt.

Ob es nun eine Ergebnisseite einer Suchmaschine ist, ein Warenkorb mit einer Auflistung der Produkte, die Sie in einem Online-Shop kaufen wollen, oder auch eine Webseite, die Ihnen Ihre neusten E-Mails anzeigt - in allen diesen Fällen stellt der Server ein individuelles Dokument zusammen, das dann auf Ihrem Browser angezeigt wird.

Serverseitig erzeugte Dokumente haben aber auch ihre Nachteile. Wenn der Server ein Dokument auf dynamische Weise erzeugt, kostet das bei jedem Aufruf des Dokuments etwas mehr Rechenzeit als ein statisches Dokument. Wenn das Dokument plötzlich von hunderten oder tausenden von Browsern verlangt wird, kann das den Server unter Umständen überfordern. So wie Ihr Pizzadienst die helle Panik kriegt, wenn Sie eben mal ein paar hundert frische Pizzas ordern.

Zweitens führen serverseitig erzeugte Dokumente zwangsläufig dazu, dass auf dem Webserver Code auf externe Anforderung hin (und gegebenenfalls mit extern zur Verfügung gestellten Daten) ausgeführt wird. Daraus können sich Sicherheitsprobleme ergeben: Als Autoren eines serverseitigen Programms zur dynamischen Erzeugung von Dokumenten müssen wir aufpassen, dass wir keinen Code ausführen, der die Sicherheit unseres Servers beeinträchtigt.

Drittens sind serverseitig erzeugte Dokumente nicht ganz ohne Programmierkenntnisse zu erstellen. Die meisten Programme zur Erstellung von Webseiten, wie z.B. Microsoft FrontPage, Adobe PageMill oder Netscape Composer, können - wenn überhaupt - nur eine sehr begrenzte dynamische Funktionalität implementieren.

Wir werden uns etwas weiter unten einen Überblick über verschiedene serverseitige Technologien verschaffen.

Clientseitig erzeugte Dokumente

In einigen Fällen ist es angebrachter, Dokumente nicht schon auf dem Server zu erzeugen, sondern erst auf dem Browser. Das kann dann der Fall sein, wenn alle zur Erzeugung des Dokuments benötigten Daten auf dem Browser vorliegen und keine Statusänderungen auf dem Server benötigt werden, also z.B. kein Lesen oder Schreiben in einer Datenbank notwendig ist.

Um Dokumente auf dem Browser erzeugen zu können, übergibt der Server dem Browser ein Stück Code. Das ist ungefähr so, als würde Ihnen der Pizzadienst die Zutaten und die Backanweisungen ins Haus schicken. Sie können sich dann immer noch überlegen, ob Sie die Tomaten wirklich wollen, aber Sie verwenden Ihren eigenen Backofen.

Zur Erzeugung von clientseitigen Dokumenten gibt es zurzeit hauptsächlich vier Technologien:

Java
Dabei wird ein eigenständiges Java-Programm als Applet in eine HTML-Seite eingebettet. Java-Code wird auf der Client-Maschine durch eine so genannte Virtual Machine ausgeführt. Das Laden von Java-Applets setzt in der Regel das Laden der Virtual Machine voraus, was mit einer Zeitverzögerung verbunden ist. Dafür ist Java sehr leistungsfähig und wird von allen wichtigen Browsern unterstützt.
JavaScript (bei Microsoft auch JScript genannt)
Der Code dieser Programme wird in HTML-Code eines HTML-Dokuments eingebettet und ausgeführt, wenn die Seite lädt oder wenn ein bestimmtes Ereignis auftritt (z.B. wenn ein Button auf der Seite angeklickt wird). Mit JavaScript können Sie u.a. HTML-Code schreiben und zum Teil auch austauschen oder löschen. JavaScript wird mehr oder weniger von allen wichtigen Browsern unterstützt. Leider lässt sich JavaScript in den meisten Browsern auch abschalten - daher ist keineswegs garantiert, dass diese Funktionalität immer tatsächlich zur Verfügung steht.
Beispiele für clientseitige Anwendungen sind Animationen, Rollover-Buttons, die beim Überfahren mit der Maus ihr Aussehen ändern, oder auch komplette Applikationen.
VBScript
Diese Programmiersprache funktionert ähnlich wie JavaScript, ist aber sehr eng an den Microsoft Internet Explorer gebunden.
ActiveX
Mit dieser Technologie, die ebenfalls praktisch nur von Microsoft unterstützt wird, können Sie entsprechend kompilierte Windows-Anwendungen in einem Fenster des Internet Explorer ausführen.

Ein großer Vorteil dieser clientseitigen Technologien ist, dass der Code aus der Server-Perspektive gesehen im einfachsten Fall ein statisches Dokument ist. Damit wird - durch die Ausführung des Codes im Browser - keine zusätzliche Rechenzeit auf der Serverseite benötigt.

Ein weiterer Vorteil clientseitiger Technologie besteht darin, dass Dokumente zunehmend auch auf der Clientseite verändert werden können. Fast alle Browser unterstützen inzwischen ein mehr oder minder kompatibles Document Object Model (DOM). Mit einem DOM können Sie mit clientseitigen Skriptsprachen oder mit Java über eine verzeichnisbaumartige Struktur auf alle Inhalte und Eigenschaften eines Dokuments im Webbrowser zugreifen. Mit der neuen SVG-Technologie (Skalierbare Vektorgrafik) ist dies sogar für Grafiken möglich.

Zu den Nachteilen der clientseitigen Technologien zählen die zu ihrer Verwendung nötigen Programmierkenntnisse sowie die Vielzahl der installierten Browser, die es schwierig machen, clientseitige Anwendungen zu schreiben, die wirklich auf allen Browsern laufen.

Ebenso können clientseitige Technologien in den meisten Browsern selektiv durch den Benutzer abgeschaltet werden. In manchen Firmen schalten Systemadministratoren Java, JavaScript oder ActiveX bereits bei der Installation der Browser ab, um realen oder befürchteten Sicherheitsproblemen vorzubeugen. Das bedeutet, dass Sie sich als Webprogrammierer nicht immer auf das Vorhandensein einer bestimmten Technologie im Browser verlassen können, selbst wenn der entsprechende Browser diese im Prinzip unterstützt.

Clientseitige und serverseitige Technologien können auch kombiniert werden. So kann beispielsweise das an den Browser geschickte Programm vom Server mit Daten versehen werden, die dann auf dem Client weiterverarbeitet werden.

Serverseitige Technologien

Wie schon erwähnt, sind serverseitige Technologien die populärste Methode, dynamische Dokumente herzustellen. Inzwischen gibt es eine ganze Reihe serverseitiger Technologien, die alle ihre Vor- und Nachteile haben und mehr oder minder Verbreitung gefunden haben.

Einige Technologien sind an eine bestimmte Webserver- oder Betriebssystem-Plattform gebunden, andere nicht. Manche kosten Geld, andere gibt es kostenlos. Um einige Technologien einzusetzen, müssen Sie gute Programmierkenntnisse haben. Andere sind vergleichsweise intuitiv.

Serverseitige Technologien lassen sich auch daran messen, wie gut sie sich skalieren lassen. Was heißt das? Nun, nehmen wir einmal an, Sie betreiben eine Wissenschaftssite. Sie hat pro Stunde 100 Besucher, was fast keine der existierenden Technologien überfordern dürfte.

Dann entdecken Sie plötzlich ein Wundermittel gegen Haarausfall. Das spricht sich herum - und plötzlich stehen Ihnen pro Stunde zehntausend glatzköpfige Besucher auf der elektronischen Matte und wollen sich von Ihrer Website ein individuelles Behandlungsprogramm zusammenstellen lassen. Jetzt kommt es darauf an, ob Ihre Server-Belastung proportional zur Anzahl der Besucher wächst oder ob sie quadratisch oder gar exponentiell in die Höhe schnellt.

Je weniger sich zusätzliche Besucher auf Ihre Server-Belastung auswirken, desto skalierbarer ist Ihre Technologie. Wenn Sie damit rechnen müssen, dass Ihre Site einmal sehr populär wird, müssen Sie das berücksichtigen. Schließlich wollen Sie ja nicht, dass sie in der Stunde des größten Ruhms in die Knie geht.

Die folgenden Abschnitte geben einen Überblick über die beliebtesten serverseitigen Technologien. Sie werden in Tabelle 2-1 am Ende dieses Kapitels noch einmal zusammengefasst.

Common Gateway Interface (CGI)

Die älteste serverseitige Technologie ist das Common Gateway Interface (CGI). Das in der vom Webbrowser angeforderten URL angegebene CGI-Programm ist dabei ein externes Programm auf dem Webserver. Wenn der Webbrowser die URL anfordert, startet der Webserver das externe Programm. Wenn das Programm in einer Skriptsprache (z.B. Perl) geschrieben ist, spricht man von einem CGI-Skript.

Die vom Browser übergebenen Eingabedaten für das externe Programm werden diesem über Umgebungsvariablen zur Verfügung gestellt. Die Ausgabe des Programms wiederum wird vom Webserver gelesen und an den Browser weitergeleitet.

Das funktioniert nicht schlecht und wird von fast allen Webservern implementiert, hat aber ein paar Nachteile:

Trotzdem werden CGI-Skripte noch oft verwendet, weil sich viele Systemadministratoren mit dieser Technik gut auskennen.

Wie erkennen Sie ein CGI-Skript? Die meisten Skripte haben Dateiendungen wie .cgi, .pl oder .phtml. Die beliebtesten CGI-Sprachen sind Perl, C und diverse Unix-Shell-Skripte, aber auch andere Sprachen wie z.B. Delphi.

Active Server Pages (ASP)

ASP ist Microsofts Beitrag zu der wachsenden Familie von Lösungen, die versuchen, dynamische Elemente in ansonsten statische Webseiten einzubetten. Wie bei den meisten anderen Lösungen dieser Art werden bei ASP speziell markierte Tags in den HTML-Code eingefügt. In diesen Tags steht der Code zur Erzeugung der dynamischen Inhalte.

Wenn das entsprechende Dokument vom Browser angefordert wird, öffnet der Webserver (im Fall von ASP ist das im Regelfall ein Internet Information Server von Microsoft) die Datei und liest sie ein. Die statischen Teile werden unverändert an den Browser weitergereicht, während der Code in den speziellen Tags ausgeführt und durch seine Ausgabe ersetzt wird. Das funktioniert schneller und ressourcenschonender als bei CGI-Programmen, weil dafür kein eigener Prozess gestartet werden muss.

Der große (und nicht unumstrittene) Vorteil von ASP ist seine enge Anbindung an die Microsoft-Produktfamilie von Entwicklerwerkzeugen wie z.B. C# oder Visual Basic. Der Nachteil ist natürlich, dass ASP damit nicht so ohne weiteres unter Nicht-Windows-Systemen läuft.

ColdFusion

ColdFusion von Macromedia (http://www.macromedia.com) beruht auf dem gleichen Prinzip wie ASP - der Einbettung von speziellen Tags in HTML. In seinen Ursprüngen ist es etwas älter als ASP, JSP oder PHP und hat - unter anderem deshalb - große Verbreitung gefunden. Fast alle populären Betriebssysteme und Webserver werden unterstützt. Als kommerzielles Produkt ist es allerdings nicht kostenlos zu haben.

Java Servlets

Java Servlets sind eine neuere Technologie, die sich zunehmender Beliebtheit insbesondere im professionellen Bereich erfreut. Java Servlets werden nur von einigen speziell für diesen Zweck entwickelten Webservern unterstützt. Dank der plattformübergreifenden Sprache Java laufen diese Server aber auf allen gebräuchlichen Betriebssystemen.

Servlets sind im Prinzip spezielle Java-Objekte, die bei Anforderung durch einen Webbrowser in die parallel zum Server laufende Servlet-Engine geladen und dort vorübergehend gespeichert werden. Damit sind bei Aufrufen durch den Browser keine zusätzlichen Prozesse notwendig - die Servlet-Engine lädt einfach den Code und führt ihn aus.

Durch die vorübergehende Speicherung (Caching) der Servlets in der Engine müssen sie bei erneuter Anforderung nicht noch einmal neu geladen werden. Das bedeutet, dass sich Servlet-Lösungen ziemlich gut skalieren lassen.

Der Nachteil: Als Servlet-Programmierer müssen Sie Java können. Außerdem ist Java nicht unbedingt die schnellste Programmiersprache am Firmament. Die Erzeugung statischer Dokumentteile muss wie bei CGI durch spezielle Ausgabebefehle erfolgen, was auch nicht unkompliziert ist.

JavaServer Pages (JSP)

Zumindest auf das letzte angesprochene Problem bei Servlets gibt es eine Antwort: JSP - die JavaServer Pages. Im Prinzip handelt es sich dabei um eine Lösung nach dem ASP-Muster. Kleine Schnipsel mit Java-Code - so genannte Scriptlets - werden in speziellen Tags in einem ansonsten statischen Dokument untergebracht.

mod_perl

Bei diesem kryptischen Kürzel handelt es sich um ein Modul für den Apache-Webserver, das die Verwendung der Programmiersprache Perl in speziellen Tags in einem ansonsten statischen Dokument ermöglicht. Der Lösungsansatz ist somit der gleiche wie auch bei ASP und JSP. Ein Vorteil sowohl gegenüber ASP als auch JSP besteht in der schnellen Ausführung von Perl. Nachteile sind die enge Bindung an Apache und die Tatsache, dass Perl keine spezielle Websprache ist.

Die Vorteile von PHP

Damit wären wir bei der Technologie angelangt, die das zentrale Thema dieses Buchs ist: PHP - der »PHP Hypertext Preprocessor«. Das Kürzel erweitert sich dabei rekursiv, so wie auch bei GNU (»GNU's Not Unix«) oder wine (»wine is no emulator«). Damit ist auch klar, welchen Stallgeruch PHP hat: den der Open Source Community. Das heißt, PHP kostet Sie nichts und ist inzwischen so ausgereift, dass es für fast jedes Problem eine Lösung gibt.

Wie ASP, JSP oder mod_perl wird auch PHP im Regelfall in speziellen Tags innerhalb von statischen Dokumenten untergebracht. Diese Tags werden ebenfalls jedes Mal beim Aufruf des entsprechenden Dokuments ausgeführt. Das Prinzip ist in Abbildung 2-4 dargestellt.
Abbildung 2-4 Die Funktionsweise von PHP

PHP können Sie auf zwei Arten betreiben: als CGI-Skript (konventionell und schlecht skalierbar) oder als Server-Modul (effizienter, aber angeblich auf Windows noch nicht ganz ausgereift - obwohl diese Warnung nun inzwischen auch einen Bart hat). Die letztere Methode macht PHP damit genauso skalierbar wie ASP, JSP usw.

PHP hat gegenüber ASP und JSP eine ganze Reihe von Vorteilen:

Auf der Homepage von PHP, http://www.php.net, finden Sie neben sämtlichen Programm-Downloads auch verschiedene Versionen der umfangreichen PHP-Dokumentation. Diese gibt es sowohl online als auch als Download in HTML-, PDF-, Windows- und PalmPilot-Formaten in ca. einem Dutzend Sprachen, darunter auch in Deutsch.

Die Online-Versionen der Dokumentation haben noch ein kleines Extra zu bieten. Sie sind mit Anmerkungen, Kommentaren, Problembeschreibungen und Beispielen von Anwendern garniert. Dieses Feature ist äußerst hilfreich, wenn Sie einmal aus der heruntergeladenen Dokumentation nicht schlau werden.

Außerdem finden Sie auf der Homepage Links zu anderen PHP-Seiten, Tutorials, PHP-Applikationen und vielem mehr. Interessiert? Dann sollten Sie diese Site im Auge behalten.

In Tabelle 2-1 finden Sie noch einmal eine Zusammenfassung der wichtigsten Informationen zu serverseitigen Technologien:

Tabelle 2-1
Serverseitige Technologien im Überblick 
Technologie Plattformen Skalierbarkeit, Geschwindigkeit Sonstige Eigenschaften
CGI praktisch alle Server und Betriebssysteme schlecht skalierbar, Geschwindigkeit hängt von verwendeter Sprache ab Erzeugung statischer Inhalte umständlich; weit verbreitet
ASP MS-Windows, IIS (eingeschränkt auch unter Unix/Linux usw., mit Apache::ASP oder ChiliSoft) gut skalierbar, im Regelfall nicht die schnellste Lösung gute Anbindung an Microsoft-Software, Erzeugung statischer Inhalte einfach durch Einbettung in Tags
ColdFusion fast alle populären Server und Betriebssysteme mäßig skalierbar, mittelmäßig schnell einfache Programmiersprache, kommerzielles Produkt
Java Servlets fast alle Betriebssysteme, benötigt spezielle Webserver auf Java-Basis (z.B. Tomcat) gut skalierbar, mittelmäßig schnell relativ komplizierte Technologie, Erzeugung statischer Inhalte umständlich
JSP wie Java Servlets wie Java Servlets Erzeugung statischer Inhalte einfach durch Einbettung in Tags
mod_perl Apache unter Windows oder Unix schlecht skalierbar, relativ schnell Erzeugung statischer Inhalte einfach durch Einbettung in Tags
PHP fast alle wichtigen Webserver auf allen wichtigen Plattformen gut skalierbar, relativ schnell einfach erlernbare, aber leistungsfähige Technologie, Erzeugung statischer Inhalte einfach durch Einbettung in Tags

Bevor wir uns voll ins dynamische PHP-Vergnügen stürzen, sollten wir uns aber kurz einmal die Brot-und-Butter-Technologie für Webdokumente ansehen: HTML. Dazu finden Sie im nächsten Kapitel eine Beispiel-Webseite.

1Multipurpose Internet Mail Extensions - eine ursprünglich nur für E-Mail gedachte Codierungstechnik, die den Transport von Dokumenten in beliebigem Format ermöglicht.

TOC PREV NEXT INDEX

Copyright © 2004 by O'Reilly Verlag GmbH & Co.KG