TELEKOM

Common Gateway Interface


BUCH

Gerhard Poul

gp@atnet.at

TELEKOM

Common Gateway Interface

http://www.pcnews.at/poul/

Common Gateway Interface

Dynamisch, Praktisch, Gut

Gerhard Poul

Jeder, der heute mit dem Internet ernsthaft arbeiten will, kommt um das World Wide Web kaum herum. Egal ob man dabei einen Browser wie Lynx oder Mozilla einsetzt. Beide Browser können mit Formularen und ähnlichen interaktiven Inhalten umgehen.

Dynamisch erzeugte Web-Seiten scheinen heute schon fast wie ein Zwang im Internet zu sein. Jeder hat, auch wenn es noch so unnötig ist, auf seiner Homepage ein Guestbook und andere interaktive Elemente eingebaut.

Die sinnvollste Verwendung liegt, nach meiner bisherigen Erfahrung, aber im realisieren von Warenkorb-Systemen, dem ausfüllen von Formularen und dem integrieren von Datenbanken in die Web-Seiten.

Datenbanken sind bereits so verbreitet, dass sich der Aufwand zur Verwaltung der Homepage sehr gut durch ihre Verwendung minimieren lässt. Die Preisliste eines Computerhändlers muss man nicht mit table tags in HTML schreiben und sich dabei die Finger brechen. Es geht auch einfacher. Denn die Programme, die zwischen Datenbank und Web-Server stehen, erledigen die rasche Umsetzung der Inhalte nach HTML. Dadurch ist es auch möglich, eine sehr schnelle Änderung ohne Bearbeiten einer einzigen HTML Datei durchzuführen.

Funktionsweise

Das Common Gateway Interface (CGI) ist grundsätzlich keine Programmiersprache sondern nur eine Schnittstellendefinition der Kommunikation zwischen Web-Server und dem Programm.

Programm ist hier deshalb so allgemein gehalten, da es sich sowohl um ein kompiliertes Binärprogramm, als auch um ein interpretiertes Skript handeln kann. Grundsätzlich sind viele Programmiersprachen dazu geeignet um CGI-Skripte zu schreiben. Hauptsächlich werden heute allerdings Perl und C/C++ verwendet.

An dieser Stelle beginnt wieder der ewige Krieg zwischen Perl und C Anhängern. Ich will hier deshalb nur die Vor/Nachteile bei der Verwendung einer interpretierten Sprache andeuten.

Interpretierte Sprachen haben hauptsächlich den Nachteil, dass sie eine viel geringere Performance aufweisen wie kompilierte Programme. Dafür gewinnt man bei deren Verwendung ein paar Vorteile, wie etwa leichtere Wartbarkeit, da die Programme nicht nach jeder Änderung neu kompiliert werden müssen, sondern sofort in modifizierter Form zur Verfügung stehen. Dadurch entfallen auch die Probleme, die auftreten, wenn Web-Server und der Rechner des Entwicklers eine unterschiedliche Plattform verwenden.

Ein Beispiel

Stellen wir uns nun einmal vor, ein Kunde der Firma xy würde sich die neueste Preisliste auf seinen Schirm holen. Was passiert dabei am Web-Server der Firma xy unter der Annahme, dass die Firma xy ein Datenbanksystem mit einem CGI-Skript verwendet?

Zuerst wird das CGI-Skript aufgerufen und dieses mit den Daten des Users versorgt. Es werden also Username, IP-Adresse, Ausgefüllte Formularfelder u.a. weitergegeben. Das Skript sucht sich nun die für sich interessanten Informationen heraus, erkennt in welcher Situation es aufgerufen wurde, holt die Daten aus der Datenbank, konvertiert diese Daten und gibt sie wieder an den Web-Server zurück. Dieser puffert die Daten und liefert sie nach dem Erfolgreichen beenden des Skripts an den Web-Browser des Benutzers zurück.

In diesem Szenario sind sehr komplexe Details enthalten die ich jetzt nach und nach erklären werde. Denn um die Abläufe zu verstehen muss man zuerst einige Grundsätzliche Tatsachen verstehen die beim erstellen einer Web-Site eine Rolle spielen.

Das Skript muss vor der Bearbeitung von Daten zuerst seine Aufgabe erkennen. Denn meistens werden CGI-Skripte zur Datenbankabfrage rekursiv benutzt. Das Programm gibt in seiner Ausgabe, die es liefert, also wieder Links auf sich selbst aus, die eine andere Aktion auslösen. Ein gutes Beispiel hierfür ist etwa ein "Alle Anzeigen" oder "Weiter"-Button auf einer dynamischen Web-Seite. Dabei muss sich das Skript selbst mitteilen was getan werden muss. Denn das Programm läuft ja nur sehr kurz. Daher kann er sich seine Statusdaten nicht in einer Datei oder im RAM speichern.

Diese Laufzeitdaten werden dann meistens entweder als Cookies oder als verstecktes Formular übergeben damit das Skript so schnell wie möglich fortsetzen kann. Es muss aber auch darauf geachtet werden, dass das Skript auch keine Fehler produzieren darf wenn die Parameter durch fremde Einwirkungen modifiziert werden, da dies ein potentielles Sicherheitsrisiko darstellt.

Die Daten aus der Datenbank werden meistens mit einer Datenbankabfragesprache, genannt SQL, durchgeführt. Dadurch ist es möglich aus einer Web-Seite mit einer externen Datenbank zu kommunizieren.

Um die Rückgabe der Daten an den Web-Server zu realisieren werden die Daten einfach mit HTML-Tags versehen und nach STDOUT geschrieben. Dadurch werden diese vom Web-Server gepuffert, mit den richtigen Headern versehen und dann auf ihre mehr oder weniger lange Reise zum Web-Browser des Users geschickt.

Bild0.GIF

Das erste deutschsprachige Buch zum meistverbreiteten Web-Server. Der Autor, Web-Administrator bei der Unix-AG der Universität-Gesamthochschule Siegen, zeigt mit seiner fundierten und ausführlichen Darstellung, wie sich die enormen Möglichkeiten des Apache sinnvoll ausschöpfen lassen. Im ergänzten Anhang erfährt der Administrator sämtliche Neuerungen der aktuellen Apache 1.3 Distribution.

Aus dem Inhalt