2.1 HTML ist langweilig (S. 27-28)

Bevor Sie beginnen, die ersten Skripte zu schreiben, denken Sie einen Moment darüber nach, wie ein Webserver arbeitet. Wenn Sie den Browser öffnen, und eine Adresse eingeben, zerlegt der Browser diese zuerst in zwei Teile. Betrachten Sie folgende Adresse:

http://www.php.comzept.de/php-lernen/index.php

Diese Angabe besteht zum einen aus dem Protokoll: http. Dies steht für Hypertext Transfer Protocol und definiert die »Sprache«, in der Webserver und Browser miteinander reden. Danach folgt die Adresse des Servers, bestehend aus seinem eigenen Namen »www.php« und der Domäne »comzept.de«. Dieser Name wird zuerst in eine IP-Nummer, die weltweit eindeutig ist, aufgelöst. Das passiert aber transparent im Hintergrund und wird normalerweise vom Benutzer nicht wahrgenommen. Der dritte Teil enthält nun Pfad- und Dateiangaben, hier »phplernen/ index.php«. Diesen Teil sendet der Browser mit dem entsprechenden HTTP-Kommando GET an den Server. Der reagiert darauf entweder mit der Auslieferung der angeforderten Datei oder einer Fehlerinformation, wenn die Datei nicht gefunden wurde.

So war das Web ursprünglich konzipiert worden. HTML-Seiten sollten nur durch Hyperlinks verbunden werden. Das genügte, um Informationen strukturiert darzustellen und Designern eine gewisse Freiheit bei der Darstellung zu erlauben.

2.1.1 Mysterium CGI

Das Ziel einer solchen Anforderung kann auch ein Skript auf dem Webserver sein. Der Webserver ruft dann das mit der Dateierweiterung verbundene Programm auf. Dessen Ausgabe wiederum wird an den Browser gesendet. Praktisch können Sie also mit einem Skript alles kontrollieren was zum Browser geht. Die Schnittstelle zwischen Webserver und solchen Programmen zur Ausführung von Skripten ist sehr alt, sehr gut dokumentiert, sehr bekannt und sehr langsam. Ihr Name ist CGI – Common Gateway Interface. CGI selbst macht nichts. Die erste Skriptsprache, die sich CGI bediente, war Perl. Perl ist sehr weit verbreitet und kann virtuos mit Zeichen umgehen. Leider ist Perl auch sehr schwer zu erlernen und für Anfänger nicht zu empfehlen.

Mit CGI ist es möglich, die Anforderungen eines Browsers auf ein Skript umzuleiten. Solche Anforderungen können neben der Adresse einer Datei auch die Inhalte eines Formulars sein. Damit besteht nun die Möglichkeit, den Inhalt eines Formulars, das der Benutzer ausgefüllt hat, zu verarbeiten und darauf gezielt zu reagieren. Diese Reaktion kann sehr vielfältig ausfallen. Sie können das CGI-Skript veranlassen, die Daten zu überprüfen und dem Benutzer eine Fehlermeldung zurückzusenden, wenn er etwas vergessen hat. Oder Sie legen die Daten in einer Textdatei ab, die Sie sich später anschauen. Wenn Sie schon etwas professioneller programmieren, werden Sie dagegen eine Datenbank verwenden.

Über CGI wurden viele Dinge geschrieben. Ein wichtiger Kritikpunkt ist die Geschwindigkeit. CGI startet mit jeder Anforderung einen so genannten Prozess auf dem Server, also eine Instanz des Skript-Interpreters. Wenn gleichzeitig 50 Benutzer zugreifen, werden 50 Instanzen gestartet, jede mit einigen Megabyte Speicherverbrauch. Ganz realistisch muss man heute sagen, hat die Entwicklung der Hardwareressourcen diesen Nachteil fast beseitigt. 50 Megabyte Speicher sind sehr wenig und 50 gleichzeitige Besucher sind verdammt viel. PHP kann man deshalb gut – sowohl auf der Entwicklungsmaschine auch auf einem Server im Netzwerk, als CGI-Applikation laufen lassen. Damit ist auch klar, das CGI nicht gleich Perl ist, in diesem Buch ist CGI gleich PHP.

Ein anderer Nachteil ist die Arbeitsweise des Protokolls HTTP. Jede Anforderung des Browsers ist ein für sich abgeschlossener Prozess. Da CGI den Interpreter jedes mal startet und danach wieder aus dem Speicher entfernt, gehen auch alle Einstellungen verloren. Das »Wiedererkennen« des Benutzers auf der nächsten Seite stellt deshalb ein Problem dar. Dank PHP stehen dafür aber spezielle Funktionen zur Verfügung – die Sessionfunktionen. Darauf wird selbstverständlich detailliert eingegangen. Also ist auch dieser Nachteil nicht wirklich schlimm.

2.1.2 Was Webserver noch können

Webserver bieten eigene Schnittstellen. Diese sind – im Gegensatz zu CGI – von Server zu Server verschieden. Glücklicherweise gibt es heute nicht mehr sehr viele konkurrierende Webserver. In der PHP-Welt, wo Produktionsserver überwiegend unter Linux laufen und für Entwicklungsumgebungen Windows verwendet wird, dominiert der Apache Webserver, gefolgt von dem Internet Information Server von Microsoft. Beide eignen sich für den Betrieb von PHP und für beide gibt es neben der CGIVersion auch eine spezielle Variante, die auf die jeweiligen proprietären Schnittstellen zugreift. Damit beschäftigt sich dieses Buch aber nicht, weil es nicht beim Programmieren hilft und meist keinen Unterschied macht, ob das Skript mit einer Webserverschnittstelle oder CGI läuft. Die zusätzlichen Möglichkeiten der Webserverschnittstellen mögen Profis zu schätzen wissen, die eigene Server betreiben und ihre Applikationen darauf optimieren. Wenn Sie mit Ihren Skripten zu irgendeinem Provider gehen, werden Sie jedoch oft auf Server mit CGI treffen und solche optimierten Skripten funktionieren dann nicht. Beschäftigen Sie sich damit erst, wenn Sie PHP richtig gut können und ein eigener Server zur Verfügung steht.