Dieser Standard, momentan CGI/1.0, ist für den WWW-Server ab httpd 1.0 implementiert, d.h. ab Hyper Text Transfer Protocol (HTTP) 1.0, und wurde durch Rob McCool vom NCSA, der gleichzeitig für die Entwicklung des NCSA-httpd verantwortlich zeichnet, entwickelt. CGI stellt nun einen Mechanismus für die Abarbeitung externer Programme, sprich Gateways, unter Steuerung eines Informationsservers (WWW-Server) bereit. Somit kann der Server z.B. Informationen behandeln, welche in einer für den Klienten nicht lesbaren Form vorliegen. Generell bietet es sich bei Vorhandensein eines die HyperText Markup Language (HTML) interpretierenden und darstellenden WWW-Klienten auf der Benutzerseite an, die Ergebnisse unterschiedlichster Recherchen, z.B. in einer ARCHIE-Datenbank, in das HTML-Format zu konvertieren und dem Nutzer so zu übergeben. Im folgenden soll vom Vorhandensein des WWW-Klienten Mosaic ausgegangen werden. Weitere wesentliche Anwendungsgebiete solcher Gatewayprogramme sind:
Das CGI-Programm erhält seine Parameter grundsätzlich über Umgebungsvariablen. Deren Werte werden durch den Server beim Aufruf des CGI-Skrips gesetzt. Einzige Ausnahme sind sog. Isindex-Anfragen - hier können Parameter als Kommandozeilen-Argumente übergeben werden. An einem praktischen Beispiel werden der Übergabemechanismus sowie die Bedeutung der Environmentvariablen diskutiert.
Häufigste und beliebteste Anwendung von CGI sind zweifelsohne die sogenannten Isindex- und Form- Anforderungen der interaktiven Formulare. Jeder Mosaic-Benutzer ist einem solchen Formular sicherlich schon begegnet. Der durch das URZ betriebene WWW-Server stellt Formulare z.B. für die FTP-Suche auf ftp.tu-chemnitz.de, für den Zugriff auf ein Archie-Gateway oder für die Kursanmeldung des URZ bereit. Neben dem visuellen Eindruck ist auch der funktionelle Nutzen enorm: Der Nutzer kann vom WWW-Klienten aus sowohl umfangreiche Recherchen vornehmen als auch Informationen weitergeben, ohne dazu andere Dienste oder Instanzen bemühen zu müssen. - Was verbirgt sich nun hinter einem solchen Formular ?
Generell lassen sich Formulare mit HTML spezifizieren. Voraussetzung für deren Verwendung ist somit, wie bereits oben erwähnt, das Vorhandensein eines hypertextfähigen WWW-Klienten auf Benutzerseite. Für das Erstellen eines Formulars stellt HTML einige Sprachkonstrukte, sog. Tags, bereit. Ist man beim Browsen mit Mosaic auf ein Formular gestoßen, so sollte man sich unbedingt einmal dessen HTML-Quelle ansehen (Eingabe: d) ! Hier ein Beispiel für ein simples (fiktives) Formular:
<HEAD>
<TITLE>Formularbeispiel</TITLE>
</HEAD>
<BODY>
<H1>Example</H1>
Dieses Formular dient zur Demonstration.<P>
<FORM ACTION="http://www.tu-chemnitz.de/cgi-bin/example-cgi"><BR><PRE>
<INPUT NAME="input1" VALUE="default">
<INPUT TYPE="checkbox" NAME="button1" VALUE="on" CHECKED> <INPUT TYPE="submit" VALUE="Senden"><BR></PRE>
</FORM>
</BODY>
Am Anfang erfolgt die Titelangabe des HTML-Dokuments innerhalb des HEAD-Konstrukts. Der Titel sollte aussagekräftig sein, da er für die Arbeit bestimmter Tools im WWW immense Bedeutung hat. Danach erfolgt die Angabe einer Überschrift (Example). Es folgt eine Textzeile. Die Formulardeklaration in einem HTML-Dokument wird stets mit dem FORM-Tag eingeleitet. Zunächst erfolgt hierbei die Angabe des CGI-Skripts mittels Universal Resource Locator (URL). Dieser stellt eine weltweit eindeutige Adresse eines (HTML-) Files dar. Das so adressierte Skript soll die per Formular übermittelten Daten verarbeiten. Im Beispiel wird das (nicht reale) Skript example-cgi aufgerufen. Die PRE-Angabe dient dazu, die nachfolgenden Anweisungen "vorformatiert" darzustellen. Die nun folgenden INPUT-Tags werden im Mosaic als Motif-Widgets dargestellt und dienen, wie der Name bereits andeutet, der Eingabe bestimmter Werte durch den Benutzer. Mit dem TYPE-Attribut gibt man den "Typ" des Eingabefeldes an, z.B. ein Textfeld, eine Check- (on/off) oder Radiobox (one of many) oder ein Pushbutton, der zur Übermittlung der eingegebenen Werte an das Skript (submit) bzw. deren Löschung (reset) dient.
Im ersten Eingabefeld ist "text" der Eingabetyp und kann, da Standard, weggelassen werden. Es folgt eine obligatorische Namensangabe, welche für die Parameterübergabe von Bedeutung ist. Das VALUE-Attribut ermöglicht die Vorgabe eines Default-Wertes, welcher vom Nutzer ggf. überschrieben werden kann (default). Das zweite Eingabefeld ist vom Typ "Checkbox", trägt den symbolischen Namen "button1" und hat den Default-Wert "on". Nur für Checkboxen und Radiobuttons kann der Tag "CHECKED" spezifiziert werden. Damit gibt man an, daß das entsprechende Widget aktiviert ist - in diesem Fall erscheint es im Mosaic gelb ausgefüllt. Die Funktion des letzten Eingabefeldes liegt auf der Hand: das "Senden" der Daten (TYPE submit) an das CGI-Skript. Der entsprechende Pushbutton hat die Aufschrift "Senden" im Mosaic, was jedoch für die weitere Verarbeitung keine Bedeutung hat. - Es lassen sich natürlich noch viel komplexere Formulare erzeugen - hier sollte jedoch nur das Verständnis für das Prinzip geweckt werden.
Das so spezifizierte, wie erwähnt sehr einfache Formular hat folgendes Layout im Mosaic:
Jetzt weiß man das Allernötigste, um den Zusammenhang zu
CGI herzustellen: Beläßt es der Benutzer beim
voreingestellten Wert des Textfeldes
und klickt anschließend den "Senden"-Pushbutton, so
wird das CGI-Skript "example-cgi" mittels als ACTION angegebenem URL aufgerufen, wobei der URL jetzt folgenden Wert hat:
http://www.tu-chemnitz.de/cgi-bin/example-cgi?input1=eingabe&button1=on
D.h., die durch den Nutzer eingegebene Information wurde "dynamisch" nach '?' an den Urprungs-URL "angefügt" und kann nun vom aufgerufenen Skript bearbeitet werden. Die einzelnen Parameter sind jeweils durch '&' getrennt. Das CGI-Skript erhält solche Information über die Environmentvariable QUERY_STRING. Bei der Übermittlung wird die Information durch den Klienten kodiert, so daß das Skript für die Dekodierung selbst "verantwortlich" ist. Dafür gibt es aber bereits zahlreiche Programme. Weitere Environmentvariablen ermöglichen die Auswertung noch vieler weiterer Informationen. Es ist wichtig zu wissen, daß, wie bereits eingangs erwähnt, ein CGI-Skript die vom Klienten übergebene Information grundsätzlich durch die Auswertung verschiedenster Environmentvariablen erhält !
Das Skript könnte nunmehr die empfangenen Daten verarbeiten und z.B. ein HTML-Dokument mit den gewünschten Informationen erzeugen und dieses an den Klienten zurücksenden. Für diesen Fall schreibt der CGI-Standard vor, die so gesendete Information mit einem Header zu versehen, welche den MIME-Typ des Dokuments (z.B. Content-type: text/html), gefolgt von einer Leerzeile, enthält; somit wird der Klient über den Typ des zu empfangenen Dokuments unterrichtet. CGI sieht hier auch die Variante vor, daß z.B. bei bestimmten durch ein Skript vorgenommenen Recherchen, welche einen bestimmten Filenamen eines gewünschten Dokuments zum Ergebnis haben, die Angabe eines sog. partiellen URL's als alleinige erzeugte Skriptausgabe ausreicht:
Location: /dir1/dir2/found_file.html
Der Server behandelt diesen URL so, als hätte der Klient von vornherein die Anfrage nach
http://www.tu-chemnitz.de/dir1/dir2/found_file.html
gestellt. Somit braucht sich das CGI-Programm um die Auflösung des angegebenen URL's überhaupt nicht zu kümmern.
Das Erzeugen eines "Antwortdokuments" erfolgt auch bei zahlreichen, auf unserem WWW-Server per Formular aufgerufenen Skripten, so auch bei der schon erwähnten lokalen FTP-Suche: Der Nutzer gibt die gewünschte Software in ein Textfeld ein. Das aufgerufene Skript initiiert die Suche und generiert schließlich ein HTML-Dokument, welches eine Liste gefundener "Treffer" enthält. Der Nutzer kann nun wiederum durch Anklicken eines als Hypertextlinks generierten Eintrags dieses Paket direkt "laden", ohne daß er irgendwann die Dienste eines FTP-Servers inclusive umständlicher Suchaktionen in Anspruch nehmen mußte - WWW und CGI machen's möglich ! Voraussetzung ist natürlich, daß das adressierte File für den Server auch erreichbar ist. Auf diese Weise kann sogar ein, wenn auch eingeschränkter und in gewisser Weise vordefinierter, Dialog zwischen Nutzer und WWW-Server zustande kommen.
Man kann bereits erahnen, welche immensen Möglichkeiten sich aus der CGI-Programmierung und Formularen als ein spezieller Anwendungsfall von CGI ergeben. Interessenten an weiterführenden Informationen empfehle ich insbesondere folgende "Quellen" für weitere Recherchen: