Überblick

1. Einleitung/Motivation
2. Anwendungsmöglichkeiten
3. Prinzipielle Funktionsweise
4. Vorrausetzungen für den Einsatz
5. Implementation
6. Installation
7. Standard/Spezifikationen
8. Geschwindigkeit/Sicherheit
9. Beispiele
10.Quellen

1. Einleitung

Häufig findet man heutzutage dynamische Inhalte auf WWW-Seiten. Sie tragen dazu bei das WWW flexibler zu gestalten und dynamisch auf Benutzeraktionen zu reagieren. Eine Möglichkeit um dies zu realisieren bietet CGI – Das Common Gateway Interface. Der Begriff bedeutet im weiteren Sinne übersetzt „Allgemeine Weiterleitungsschnittstelle“. Mit CGI ist es also möglich Prozesse (Programme) auf einem fernen WWW-Server zu starten und sich deren Ausgabe z.B. in Form einer HTML-Seite zurückgeben zu lassen. Das heißt dass man mit CGI eine Schnittstelle des WWW-Servers zu einer Applikation bezeichnet. Die Zugriffsmethoden über diese Schnittstelle sind standardisiert. CGI-Programme (Skripts) sind weiterhin plattformunabhängig und an keine spezielle Programmiersprache gebunden. Ein bekanntes Beispiel für deren Anwendung ist die Suche nach einem Schlüsselwort in einer Datenbank (Google, oder ähnliche Suchmaschinen).

Zurück zum Überblick

Aus oben genannten Vorteilen der dynamischen Webseitengestaltung ergeben sich eine Vielzahl an verschiedenen Anwendungen. Denkbar wäre wie schon gesagt das Durchsuchen einer Datenbank auf dem Server und die Ausgabe der Ergebnisse in Form einer HTML-Seite. Dabei wird der doch erheblich große Datenbestand auf dem Server durchsucht und nur die relevanten Informationen dem Client übers Netz geschickt. Das alles geschieht völlig transparent für den Client, d.h. er bekommt nicht mit, dass im Hintergrund CGI zum Einsatz kommt. Für ihn steht ein grafisches Frontend in Form eines Textfeldes im Vordergrund. Weiterhin findet man nahezu überall dort CGI-Skripte wo mit Formulareingaben umgegangen wird. CGI-Skripte werten die Eingaben aus und speichern sie auf dem Serverrechner zum Beispiel in einer Datei ab. Das wohl bekannteste Beispiel für diese Art der Anwendung sind Gästebücher oder Foren im Internet über die die Webgemeinde ihre Meinungen schreiben kann. Häufig lassen sich auch dort CGI-Skripte finden wo es darum geht Besucherzähler einzurichten. Dabei wird der aktuelle Zählerstand in einer Datei auf dem Webserver gespeichert und mit jedem Besuch aktualisiert. Über Server Side Includes ist es dann auch relativ einfach möglich diesen Zählerstand innerhalb der Webseite einzubinden. Eine weitere Möglichkeit CGI einzusetzen wäre, dass PDF-Dokumente(Handbücher) on the fly in HTML-Dateien konvertiert und dem Client präsentieren werden. In Verbindung mit Online-Shops sind CGI-Skripte auch häufig zu finden. Hierbei spielt der Warenkorb eine entscheidende Rolle. Bereits eingekaufte Produkte werden über ein CGI-Skript auf dem Server gespeichert bis der Client die Bestellung endgültig aufgibt. (Bemerkung: Prinzipiell wäre es auch möglich den Warenkorb über Cookies zu implementieren wobei diese dann wiederum auf dem Clientrechner gespeichert werden müssten)

Zurück zum Überblick

Zunächst möchte ich mich bei der Funktionsweise auf das Beispiel der Übermittlung von Formulardaten beziehen. Der Client gibt seine Informationen in die einzelnen Formularfelder ein. Danach bestätigt er mit ein Klick auf einen 'Absenden' – Button das er seine Daten gerne versenden möchte. Der Browser verschlüsselt die eingegebenen Daten (z.B. in der URL) und schickt diese zum WWW-Server. (Übertragung der Daten ist abhängig von der gewählten Methode, POST oder GET) Der Server empfängt die Daten und leitet sie ans CGI-Skript weiter. Dieses generiert in Abhängigkeit von den Eingabewerten z.B. eine HTML Datei, Textdatei,... (auch Bilder oder ähnliches sind möglich) und schickt diese an den WWW-Server zurück. Dieser wiederum reicht das Dokument zum Client durch.

Zurück zum Überblick

Was benötigt man um eigene CGI-Skripts zu verwenden? Zunächst hängt das davon ab wo man die eigene Seite gehostet hat. Das heißt also, dass man zunächst entweder einen eigenen Webserver hat oder den eines Providers nutzen kann. Als Software bietet sich hierbei z.B. der Apache, Microsoft Personal Webserver oder auch der Internet Information Server an. Besitzt man einen eigenen Webserver auf dem heimischen Rechner so hat man quasi alle Freiheiten. Hier hat man unter anderem auch die Möglichkeit das Modul mod_perl in den Apache zu integrieren was die Laufzeit von Perl-CGI-Skripten deutlich verkürzt. Anders sieht das bei öffentlichen Webservern aus. Kostenlose Angebote bei denen man einen bestimmten Webspace zur Verfügung gestellt bekommt, bieten oft nicht die Möglichkeit CGI zu nutzen. Feststellen kann man dies in dem man schaut ob sich in seinem „public-html“ Verzeichnis ein Ordner namens „cgi“ oder auch „cgi-bin“ befindet. Ist das nicht der Fall so wird CGI meistens auch nicht unterstützt. Ein nachträgliches Anlegen dieser Verzeichnisse bringt oft auch nicht den gewünschten Erfolg. Man muss in diesem Falle auf die Verwendung von CGI verzichten. Wird CGI von Seiten des Webservers unterstützt so sollte man schauen welche Compiler bzw. Interpreter auf dem System installiert sind. Danach richtet sich dann meist auch die Sprache die man für seine Skripts verwendet. Grundlegende Kenntnisse in einigen Programmiersprachen sind dabei unerlässlich.

Zurück zum Überblick

Grundsätzlich sind CGI-Skripte/Programme an keine spezielle Programmiersprache gebunden. Jedoch sollten folgende Punkte beachtet werden. In der jeweiligen Sprache sollte das Lesen und Schreiben von und auf die Standardein- und ausgabe möglich sein. Weiterhin sollte man in seinem Programm die Möglichkeit haben auf Umgebungsvariablen zurückgreifen zu können. Diese beiden Punkte sind Teil der CGI 1.0 Spezifikation. Man hat die Wahl sich zwischen einer interpretierenden Skriptsprache(Perl, Python, Tcl, Shell Skripte,...) und einer Compilersprache(C, C++, Pascal,...) zu entscheiden. Java enthält beide Elemente. Es wird ein binärer Zwischencode generiert der anschließend durch eine Java Runtime Engine wieder interpretiert wird. Dies garantiert die Plattformunabhängigkeit. Bei der Wahl zwischen Compiler- und Interpretersprache sollte man stets den Anwendungszweck des CGI-Programms im Blick haben. Kommt es auf Zeitabhängigkeiten und Performance an so sollte man sich doch für eine Compilersprache entscheiden. Skriptsprachen werden häufig dort bevorzugt wo es darum geht Anwendungen zu schreiben die häufig neu angepasst und verändert werden müssen. Wie schon im vorangegangenen Abschnitt erwähnt sendet die CGI-Applikation an den Webserver einen Output zurück. Allen Daten die vom Programm über den Webserver an den Client zurückgesendet werden wird ein sogenannter CGI-Header vorangestellt. Was enthält nun ein solcher Header? Die wichtigsten Felder habe ich hier noch einmal zusammengefasst.

• Content-type : Mime-Type des Dokumentes
• Location: erlaubt Weiterleitung auf externe Inhalte
• Status: Status setzen (200 OK, 404 – Page not found)
• Extension Header Felder: selbst definierte Felder, die mit X-CGI- beginnen sollten
• HTTP Header Felder: andere, im HTTP Protokoll definierten Header Elemente

• aus Verweisen <a href='/cgi-bin/statistik.cgi'>Statistik ansehen</a>
• als Grafik<img src='/cgi-bin/grafik.cgi'> -> Skript muss hierbei Grafik erzeugen
• aus SSI's <!-- #exec cgi='/cgi-bin/counter.cgi' -> Textcounter
• automatisch: <meta http-equiv="refresh" content="0; URL=/cgi-bin/welcome.pl"> wird beim Aufruf der Seite gestartet

Zurück zum Überblick

Nach einer mehr oder weniger langen Entwicklungszeit eines CGI-Programmes folgt meist die Veröffentlichung und Freistellung im Netz. Hierbei sollte man jedoch noch folgende Dinge beachten. Bevor das Skript der Allgemeinheit bereitgestellt wird sollte man es in einer möglichst separaten Testumgebung ausführlich testen. Geschwindigkeit, Effizienz und Sicherheit spielen hierbei eine entscheidende Rolle. Hier könnte zum Beispiel ein eigener lokaler Webserver zum Einsatz kommen. Nach erfolgreicher Testphase kann die Anwendung dann der Öffentlichkeit zugänglich gemacht werden. Dies geschieht meist dadurch, dass das Skript auf den Webserver ins CGI-Verzeichnis kopiert wird und diesem dann die erforderlichen Rechte verliehen werden. (chmod 755)

Zurück zum Überblick

Wie bei vielen Dingen im Leben besitzt CGI natürlich auch einen eigenen Standard. Doch dies war nicht immer so. In der Anfangsphase implementierten die Webserver-Hersteller die CGI-Funktionalität oft nach eigenem Gutdünken. Aber bald darauf kamen die ersten Probleme auf. Skripte die für den NCSA-httpd geschrieben wurden funktionierten auf einmal nicht mehr auf dem CERN-httpd. Außerdem gab es keinerlei Möglichkeiten Informationen über den Client herauszubekommen. Letztendlich entschloss man sich einen eigenen Standard zu entwickeln, der dann auch als CGI Version 1.0 in den NCSA-httpd eingeflossen ist. Hier wurden Informationen über den Client und den eingesetzten Server selbst über Umgebungsvariablen dem Skript bereitgestellt. Seit 1995 gibt es mittlerweile schon die Version 1.1. und derzeit ist Version 1.2 in Entwicklung. Größtenteils stützt sich nun alles auf diese Standards. Die veralteten Mechanismen wie sie es früher gab werden nur noch aus Kompatibilitätsgründen unterstützt.

Zurück zum Überblick

Ein weiterhin wichtiger Aspekt bei der Entwicklung von CGI-Anwendungen ist die Betrachtung der Geschwindigkeit mit der eine solche Anwendung ausgeführt werden muss. Besonders wichtig ist dieser Punkt bei stark frequentierten Servern. Jeder Aufruf eines Skripts auf dem Server belegt bestimmte Ressourcen auf ihm, auch CGI-Overhead genannt. Ein Perl Skript zum Beispiel wird initialisiert, liest die übergebenen Parameter und muss danach eventuell noch einen Interpreter starten, der wiederum Ressourcen benötigt. Ein Ausweg aus diesem Dilemma wäre die Integration von zusätzlichen Modulen in den Webserver z.B. mod_perl in Apache. Hierbei ist der Perl-Interpreter schon im Webserver integriert und muss nicht jedes mal neu gestartet werden. Das bringt in punkto Geschwindigkeit enorme Leistungssteigerung. Zusätzlich ergibt sich hier dann die Möglichkeit die Skripts zu cachen, so dass sie bei erneutem Aufruf nicht noch einmal interpretiert werden müssen. Denkbar wäre auch die Programmierung mit so genannten Server-API's (NSAPI (Netscape), ISAPI (Microsoft), API für Apache). Das ist eine Art direkte Programmierung auf dem Webserver. Nachteil hierbei ist, dass diese Anwendungen im selben Prozess wie der Webserver laufen und nicht mehr programmiersprachenunabhängig sind. Ein weiteres Konzept ist der Einsatz von Fast-CGI Anwendungen. Unterstützt wird dies von Apache, Netscape sowie Microsoft. Fast-CGI ist eine Entwicklung von OpenMarket und ist eine API für verschiedene Sprachen. Der Server erzeugt zur Startzeit eine Art Pool von Fast-CGI Prozessen. Diese Anwendungen laufen dann persistent und jeweils in einem eigenständigen Prozess. Bei Aufruf einer Anwendung erzeugt der Server eine bidirektionale Verbindung.

Bei der Entwicklung von CGI-Anwendungen sollte man auch den Sicherheitsaspekt nicht vernachlässigen. Ein Webserver kann noch so sicher sein – ein schlecht programmiertes CGI-Skript ist immer eine Schwachstelle. Prinzipiell sind Programme sicherer als Skripte. Hier jetzt noch ein paar Hinweise worauf man achten sollte. Bei der Übergabe der Parameter mit der Methode POST sollte man unbedingt die Umgebungsvariable CONTENT_LENGTH auswerten. Hier besteht das Risiko eines Buffer-Overflows der dann die Türe zum System möglicherweise öffnen könnte. Außerdem sollte man eventuell die Umgebungsvariable HTTP_REFERER sich anschauen um zu prüfen von welcher Seite der Request kommt. Bei Eingaben in Formularen (z.B.: Gästebüchern, Foren) sollte darauf geachtet werden die HTML-Darstellung von Userbeiträgen zu filtern. Weiterhin sollten Usereingaben nie ungefiltert in irgendeiner Art und Weise an die Shell zur Verarbeitung übergegeben werden. Dies birgt ein großes Sicherheitsrisiko. CGI-Anwendungen laufen wenn sie ausgeführt werden häufig unter der Benutzerkennung mit der der Webserver gestartet wurde (häufig root). Eine Möglichkeit um dies zu verhindern ist der Einsatz von CGI-Wrappern (cgi-wrap). Mit diesen Tools ist es möglich die Anwendung auch unter einem anderen Namen als root auszuführen. Außerdem führt es noch zusätzliche Sicherheitsprüfungen durch.

Zurück zum Überblick

Besucher-Counter (Perl Skript)

Zurück zum Überblick

Ed Tittel/Mark Gaither/Sebastian Hassinger/Mike Erwin - WWW-Programmierung mit CGI ISBN: 3-8266-0266-8

Zurück zum Überblick