5/2 CGI-Programmierung

Transkript

1 CGI-Programmierung Teil 5/2.1 Seite 1 Kurzreferenz CGI 5/2 CGI-Programmierung 5/2.1 Kurzreferenz CGI

2 Teil 5/2.1 Seite 2 CGI-Programmierung Kurzreferenz CGI

3 CGI-Programmierung Teil 5/2.2 Seite 1 Einführung 5/2.2 Einführung Das Common Gateway Interface (CGI) bestimmt ein Protokoll, mit dem Browser, Server und Programme Daten austauschen. Ein CGI-Script ist ein Programm, das in fast jeder Programmiersprache wie C/C++, Perl, TCL usw. geschrieben sein kann. Dieses Programm muss in der Lage sein, eine Anwendereingabe über die Befehlszeile bzw. über die Standardeingabe zu bearbeiten und an die Standardausgabe eine Antwort zurückzuliefern. Mit CGI-Scripts auf Ihrer Webseite erzeugen Sie dynamische Seiten, die mit den Anwendern in Interaktion stehen. Die Entscheidung, wann Sie Scripts auf Ihrer Webseite verwenden sollen, ist einfach. Nehmen Sie z. B. einmal an, Sie möchten die Preise der Computerkomponenten sehen, die Ihre Firma verkauft. Nehmen wir weiter an, Ihre Firma verkauft Hunderte oder sogar Tausende von Komponenten, dann möchten Sie nicht einfach alle Komponenten und Preise auf einer riesigen, statischen Webseite aufgelistet haben. Man käme dem Problem schon eher bei (aber es gäbe immer noch Einschränkungen), wenn Hyperlinks in ein statisches HTML-Dokument eingebettet würden, mit denen der Anwender zu einer Stelle springen kann, an der sich eine spezielle Komponentenkategorie befindet, z. B. Monitore. Mit diesen Hyperlinks kann der Anwender schnell ein großes Dokument durchsuchen, um eine bestimmte Stelle zu finden. Will der Anwender gleichzeitig die Preise für Monitore und CPUs sehen, zwingt ihn die Hyperlink-Methode jedoch, zwischen mehreren Seiten hin- und herzuspringen. So ist Ihre Seite weniger attraktiv, als Ihr Kunde es wohl erwartet. Statt eingebetteter Hyperlinks sollten Sie in Erwägung ziehen, ein Programm zu erstellen, das dynamisch Informationen zusammenfasst und eine Webseite on the fly erzeugt, auf der die vom Anwender geforderte Information angezeigt wird. Oder anders ausgedrückt, wenn der Anwender die Webseite besucht, wird ein HTML-Formular angezeigt, in dem er einzelne Komponenten auswählen kann. Schickt er nun seine Funktionsweise von CGI Einsatzbereiche Vorteile dynamisch erstellter Web- Seiten Web-Sites on the fly

4 Teil 5/2.2 Seite 2 CGI-Programmierung Einführung Wünsche ab, erstellt das CGI-Script dynamisch ein HTML- Dokument, das die vom Benutzer angeforderten Elemente anzeigt. Das dynamische Erstellen von HTML-Dokumenten (Webseiten) ist somit das Herz des CGI-Scripting. Server-Side Die erzeugten CGI-Programme laufen auf Ihrem Computer (dem Webserver), und die Anwender (einschließlich Ihnen) sind in der Lage, mit diesem Kontakt aufzunehmen und die von Ihren CGI-Scripts erzeugten Webdokumente zu empfangen. Wie Sie aus Ihrem Computer mit Hilfe eines HTTP- Servers einen Webserver machen, erfahren Sie in Teil 8/3. CGI-Scripts Funktionsweise Formulare Wenn Sie im Internet surfen, sind Ihnen sicher schon Seiten begegnet, die ein Formular enthalten. Mit diesen Formularen stehen Webseiten in Interaktion mit dem Anwender. Hat der Anwender dieses ausgefüllt und abgeschickt, sendet der Browser die Antwort zurück an den Server. Dieser startet im Gegenzug ein Programm, das sich auf dem Server befindet und die Anwendereingabe bearbeitet. Meist wird die Eingabe über eine Datenbank ausgewertet und eine Antwort erzeugt. Hans Meier Name: Hans Meier weiterleiten MIME- Kopf Hans Meier Skript Browser Skript- Antwort Server Abbildung 5/2.2-1: Der Server bearbeitet die Ausgaben des CGI-Scripts und schickt sie zum Browser Für eine solche Antwort erzeugt das Programm eine HTML- Datei und gibt sie zurück an den Server. Dieser schickt sie wieder an den Browser, wo sie angezeigt wird. Anders gesagt, das Programm enthält Anweisungen (Programmcode), mit denen dynamisch HTML-Seiten erstellt werden können.

5 CGI-Programmierung Teil 5/2.2 Seite 3 Einführung Hans Meier lebt in Hamburg MIME- Kopf Skript- Antwort Browser Server Abbildung 5/2.2-2: Der Server überträgt die ASCII- HTML-Datei an den Browser des Anwenders CGI-Scripts unterscheiden sich von Java und von JavaScript, weil sie ausschließlich auf dem Server ablaufen. Java und JavaScript werden häufig als Client-seitige Programmiersprachen bezeichnet, während CGI der Server-seitigen Programmierung dient. Diese Scripts liegen auf dem Server und werden auch auf ihm ausgeführt, wobei Ein- und Ausgaben über den eingesetzten HTTP-Server (z. B. Apache) laufen. Damit der Anwender die vom Script erzeugten Ausgaben in seinem Browser betrachten kann, müssen das Script auf dem Server ausgeführt und seine Ergebnisse zum Browser des Anwenders übertragen werden. CGI-Scripts laufen nur auf dem HTTP-Server Ein Überblick über CGI Wenn ein Browser eine HTML-Seite laden will, führt er dazu vier Transaktionsschritte aus. Zuerst kontaktiert er den Server, auf dem das Dokument zu finden ist. Danach wird eine Verbindung aufgebaut, und der Browser sendet eine Anforderung für das Dokument (normalerweise mit der HTTP-Methode GET, siehe Teil 9/4.6). Als Nächstes schickt der Server das Dokument zum Browser, wenn es existiert. Schließlich baut der Server die Verbindung wieder ab. Transaktionsschritte

6 Teil 5/2.2 Seite 4 CGI-Programmierung Einführung 1. Verbinden 2. Anfordern 3. Antworten 4. Schließen Browser-Client HTTP-Server Abbildung 5/2.2-3: Die notwendigen Komponenten, um den vierstufigen Transaktionsprozess durchzuführen 1. Verbinden 2. Antworten Proceß-Skript 3. Antworten 4. Schließen Browser-Client HTTP-Server Abbildung 5/2.2-4: Die Stelle, an der die CGI-Scripts im vierstufigen Transaktionsprozess ausgeführt werden HTTP-Anforderung Bei einem CGI-Script gibt es nur auf der Serverseite eine Änderung. Der Browser weiß nicht, dass der Server ein CGI- Script aufruft, er fordert einfach unter Angabe einiger zusätzlicher Informationen im Body der MIME-Anforderung ein Dokument vom Server an. Wenn der Browser den Server kontaktiert und Daten anfordert, die von einem CGI-Script zurückgeschickt werden, lässt das Server-Programm einfach das CGI-Script laufen. Das CGI-Script übernimmt die gesamte Verarbeitung, um die vom Programmierer beabsichtigte Ausgabe zu erzeugen. Wenn der Server die Ausgabe des CGI-Scripts erhält (eine HTML-Datei), fügt er (falls nötig) die erforderlichen Köpfe hinzu. Anschließend sendet er die Kopfinformation zusammen mit den Daten des CGI-Scripts zurück zum Browser. Nun schließt der Server die Verbindung und wartet auf die nächste Anforderung.

7 CGI-Programmierung Teil 5/2.2 Seite 5 Einführung Aufruf von CGI-Scripts Wenn das Server-Programm ein CGI-Script aufruft, muss der Server das Script mit den erforderlichen Daten versorgen (sie wurden vom Browser geschickt) und die richtigen Werte für die Umgebungsvariablen sicherstellen, auf die das Script zugreifen kann. Darüber hinaus muss er die Script-Ausgaben verarbeiten und die Kopfinformationen hinzufügen, damit der Browser die Script-Daten richtig interpretieren kann. Sendet ein Server-Programm Daten an einen Browser, wird mit einer Reihe von Köpfen der Status der Daten, der Datentyp (der Inhalt der Datei) usw. mitgeteilt. Der Browser verwendet seinerseits den Inhalt des Content-Type-Kopfs, um den Inhalt der Datei weiterzuverarbeiten. Der Server ist dabei für das Bereitstellen der HTTP-Meta-Information verantwortlich (Informationen über die vom Server versendeten Daten), wenn er Daten an den Browser schickt. Datenübergabe Header Webserver-CGI-Script-Interface Die Common-Gateway-Interface-(CGI-)Spezifikation legt fest, dass der Server verantwortlich für die Weitergabe von Informationen an ein CGI-Script ist. Außerdem muss er die vom CGI-Script zurückgegebenen Informationen wieder entgegennehmen. Damit Ihre CGI-Scripts mit der CGI-Spezifikation übereinstimmen (und mit HTTP-Servern richtig zusammenarbeiten), müssen Sie sich an die Erfordernisse der CGI-Spezifikation halten. Klickt ein Webanwender auf einen Hyperlink, der unmittelbar den Server veranlasst, ein CGI-Script aufzurufen, muss der Server bestimmte Informationen (abhängig vom Script) zur Verfügung stellen. Der Server übergibt diese und weitere, allgemeinere Informationen an das Script. In der Regel werden einige Informationen innerhalb der Befehlszeile des Scripts, andere durch Senden der Daten an die Standardeingabe des Scripts, wieder andere durch mehrere Umgebungsvariablen übergeben. Eine nähere Beschreibung dieser Funktionalität finden Sie in Kapitel 5/2.3. CGI-Spezifikation Übergabe von Daten

8 Teil 5/2.2 Seite 6 CGI-Programmierung Einführung

9 CGI-Programmierung Teil 5/2.3 Seite 1 Protokoll 5/2.3 Protokoll Das Common Gateway Interface basiert einfach auf dem HTTP-Protokoll (s. 9/4.6). Der wichtigste Unterschied ist jedoch, dass der Client (also der Browser eines Users) je nach Formularmethode einen anderen Request abschickt. HTTP-Protokoll Wie in den nachfolgenden Beispielen dargestellt, existieren fünf grundsätzliche Methoden, ein CGI-Script aufzurufen: Über das ISINDEX-Tag: <ISINDEX prompt="eingabe: " action="/cgi-bin/cgi-script"> Über ein Formular mit der Methode GET: <FORM action="/cgi-bin/cgi-script" method=get>... </FORM> Über ein Formular mit der Methode POST: <FORM action="/cgi-bin/cgi-script" method=post>... </FORM> Über einen einfachen Hyperlink (Methode GET): <A HREF="/cgi-bin/cgi-script">... </A> Und über eine SRC-URL: <IMG SRC="/cgi-bin/cgi-script"> Aufruf eines CGI-Scripts über das ISINDEX-Tag CGI-Scripts verwenden normalerweise die Befehlszeileneingabe, wenn eine interaktive Suche mit ISINDEX erfolgen soll. Damit können Sie in HTML-Dokumenten relativ einfach eine interaktive Suche nach Schlüsselwörtern durchführen allerdings unterstützen nicht alle Serverprogramme die ISINDEX-Abfrage. Der Browser schickt die Befehlszeilen- Befehlszeileneingabe

10 Teil 5/2.3 Seite 2 CGI-Protokoll Protokoll eingabe an den Server. Das Serverprogramm identifiziert die Befehlszeileneingabe, indem er feststellt, ob der Browser eine HTTP-GET-Methode anforderte und ob der URI-Suchstring den Ausdruck uuencoded=characters enthält. GET-Methode Dekodierung Wenn der Browser mit der HTTP-GET-Methode etwas anfordert und der URI-Suchstring nicht den Ausdruck uuencoded=characters enthält, wird die Befehlszeileneingabe verwendet. Bevor das zugehörige CGI-Script gestartet werden kann, muss das Serverprogramm die Befehlszeileneingabe erst aufspalten. Dies geschieht durch die Pluszeichen (+), die die Parameter voneinander trennen. Der Server führt anschließend für jeden Parameter im URI-Suchstring zusätzliche Dekodierungen aus (falls nötig) und speichert jeden Parameterstring im ARGV-Array. Bei mehreren Eingabefeldern besteht die zusätzliche Dekodierung darin, dass die einzelnen Zeichenketten mit dem Kaufmanns-Und-Zeichen (&) getrennt werden. Aufgabe des CGI-Scripts ist es dann, diese Zeichenketten weiter aufzuspalten. Das Gleichheitszeichen (=) dient nun dazu, den Variablennamen (auf der linken Seite des Gleichheitszeichens, angegeben durch NAME= in <INPUT>) vom Variablenwert (auf der rechten Seite des Gleichheitszeichens) zu trennen. Abbildung 5/2.3-1: Formular mit ISINDEX Beispiel Ein Beispiel soll dies erläutern. Die im Bild dargestellte Ausgabe wird von folgender HTML-Seite erzeugt.

11 CGI-Programmierung Teil 5/2.3 Seite 3 Protokoll <HTML> <HEAD><TITLE>CGI-Test</TITLE></HEAD> <BODY BGCOLOR="#FFFFFF"> <H2>Formular-Test mit ISINDEX</H2> <ISINDEX prompt="geben Sie hier das Stichwort ein:" action="/cgi-bin/showmeall"> </BODY></HTML> Gibt man in dieses Feld den Text Hallo, Welt! Ein Test mit äöüß &+% ein, liefert das in 5/2.3 beschriebene showmeall -CGI-Script folgende Information: Environment-Variablen $ENV{DOCUMENT_ROOT} = /home/httpd/htdocs $ENV{GATEWAY_INTERFACE} = CGI/1.1 $ENV{HTTP_ACCEPT} = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* $ENV{HTTP_ACCEPT_CHARSET} = iso ,*,utf-8 $ENV{HTTP_ACCEPT_LANGUAGE} = en $ENV{HTTP_CACHE_CONTROL} = Max-age=0 $ENV{HTTP_HOST} = $ENV{HTTP_REFERER} = $ENV{HTTP_USER_AGENT} = Mozilla/4.04 [en] (Win95; I) $ENV{HTTP_VIA} = 1.0 gate.interest.de:8001 (Squid/1.1.14) $ENV{HTTP_X_FORWARDED_FOR} = unknown $ENV{PATH} = /sbin:/usr/sbin:/bin:/usr/bin $ENV{QUERY_STRING} = Hallo%2C+Welt%21+Ein+Test+mit+%E4%F6 %FC%DF+%26%2B%25 $ENV{REMOTE_ADDR} = $ENV{REMOTE_HOST} = gate.interest.de $ENV{REQUEST_METHOD} = GET $ENV{SCRIPT_FILENAME} = /home/httpd/cgi-bin/showmeall $ENV{SCRIPT_NAME} = /cgi-bin/showmeall $ENV{SERVER_NAME} = $ENV{SERVER_PORT} = 80 $ENV{SERVER_PROTOCOL} = HTTP/1.0 $ENV{SERVER_SOFTWARE} = Apache/1.1.3 Kommandozeilenargumente $ARGV[0] = (Hallo,) Feld 0: (Hallo,)

12 Teil 5/2.3 Seite 4 CGI-Protokoll Protokoll $ARGV[1] = (Welt!) Feld 0: (Welt!) $ARGV[2] = (Ein) Feld 0: (Ein) $ARGV[3] = (Test) Feld 0: (Test) $ARGV[4] = (mit) Feld 0: (mit) $ARGV[5] = (äöüß) Feld 0: (äöüß) $ARGV[6] = (\&+%) Feld 0: (\) Feld 1: (+%) Stdin Die Environment-Variable QUERY_STRING enthält den kompletten, FORM-codierten Eingabetext. Hallo%2C+ Welt%21+Ein+Test+mit+%E4%F6%FC%DF+%26%2B%25 Dieser String wird vom Server an den Leerzeichen getrennt und als Argumente übergeben. Das Script erhält auf Grund der hierbei benutzten GET-Methode keine Daten über STDIN. Aufruf eines CGI-Scripts über ein Formular mit POST Modifiziert man das HTML-Dokument zu <HTML> <HEAD><TITLE>CGI-Test</TITLE></HEAD> <BODY BGCOLOR="#FFFFFF"> <H2>Formular-Test mit FORM</H2> <FORM action="/cgi-bin/showmeall" method=post> Textfeld: <INPUT type="text" name="textfeld" size=25 value="eingabe"><br> </FORM> </BODY></HTML> <INPUT type="text" name=" " size=25 value="foo@bar.com"><br> <INPUT TYPE="SUBMIT" VALUE="Abschicken"><BR>

13 CGI-Programmierung Teil 5/2.3 Seite 5 Protokoll und schickt es ebenfalls ab, erkennt man den Unterschied zwischen ISINDEX und einem Formular mit mehreren Eingabefeldern. Im Folgenden sehen Sie die Ausgabe von showmeall auf Grund der in der Abbildung gezeigten Eingaben. Dargestellt sind hier nur die gegenüber oben unterschiedlichen Zeilen. Environment-Variablen $ENV{CONTENT_LENGTH} = 58 $ENV{CONTENT_TYPE} = application/x-www-form-urlencoded... $ENV{QUERY_STRING} =... $ENV{REQUEST_METHOD} = POST Kommandozeilenargumente Stdin Standardeingabe: (Textfeld=Eingabe+von+%E4%F6%FC+%26%2B%25& =foo@bar.com) Feld 0: (Textfeld=Eingabe von äöü &+%) Abbildung 5/2.3-2: Darstellung des FORM-Formulars

14 Teil 5/2.3 Seite 6 CGI-Protokoll Protokoll POST-Methode Bei der POST-Methode wird die gelieferte Information dem CGI-Script also via Standardeingabe und nicht über die Befehlszeile bzw. die Envioronmentvariable QUERY_STRING übergeben. Die Dekodierung bleibt aber gleich, d. h. + werden zu Leerzeichen und %xx zum Zeichen mit dem Hexadezimal-ASCII-Code xx. Das Zeichen & trennt dabei die Argumente der verschiedenen Felder, = trennt jeweils den im Formular mit NAME= angegebenen Feldnamen vom Inhalt (VALUE=). Aufruf eines CGI-Scripts über ein Formular mit GET Ändert man im vorhergehenden Beispiel nur die Methode von POST auf GET (<FORM action="/cgi-bin/showmeall" method=get>) und betrachtet die dazu differierenden Ausgaben von showmeall, so erkennt man, dass keine Environment-Variablen CONTENT_LENGTH und CONTENT_ TYPE mehr auftauchen, dafür aber der QUERY_STRING wieder den Text enthält. Environment-Variablen... $ENV{QUERY_STRING} = Textfeld=Eingabe+von+%E4%F6%FC+%26 %2B%25& =foo@bar.com... $ENV{REQUEST_METHOD} = GET... Kommandozeilenargumente Stdin Standardeingabe: () GET-Methode Bei der GET-Methode im Zusammenhang mit Formularen wird die gelieferte Information dem CGI-Script wieder wie bei ISINDEX über die Envioronmentvariable QUERY_ STRING, jedoch nicht parallel dazu über die Befehlszeile übergeben.

15 CGI-Programmierung Teil 5/2.3 Seite 7 Protokoll Aufruf eines CGI-Scripts über einen Hyperlink Man kann CGI-Scripts auch direkt durch einen Link aufrufen. Der Link <A HREF="/cgi-bin/showmeall/dir1/dir2?abc&def">Link</A> liefert zur eben dargestellten GET-Methode folgende unterschiedliche Ausgabe: Environment-Variablen... $ENV{PATH_INFO} = /dir1/dir2 $ENV{PATH_TRANSLATED} = /home/httpd/htdocs/dir1/dir2 $ENV{QUERY_STRING} = abc&def... $ENV{REQUEST_METHOD} = GET... Kommandozeilenargumente $ARGV[0] = (abc\&def) Feld 0: (abc\) Feld 1: (def) Stdin Standardeingabe: () Wir sehen also: Beim Aufruf eines CGI-Scripts über einen Link handelt es sich ebenfalls um einen Aufruf mit der GET- Methode. Allerdings können dem Script (wie auch mit FORM action=) zusätzliche Argumente mit übergeben werden. Hängt man an den Namen des Scripts zusätzlich noch einen Pfad an, so erhält es zwei zusätzliche Variablen, PATH_ INFO und PATH_TRANSLATED, die diese Information wiederspiegeln. Mit einem Split-Befehl unter Perl können wir diese Information leicht extrahieren. GET-Methode PATH_INFO und PATH_TRANSLATED

16 Teil 5/2.3 Seite 8 CGI-Protokoll Protokoll ($dummy,$path1,$path2) = split(/\//, $ENV{"PATH_INFO"}); Die vom Script-Namen und den zusätzlichen PATH_INFOs durch ein Fragezeichen getrennten Argumente werden wieder nach Leerzeichen in verschiedene Argumente aufgesplittet. Das Script erhält also wieder wie bei ISINDEX die Argumente sowohl als Befehlszeilenargumente als auch über die Environment-Variable QUERY_STRING. Aufruf eines CGI-Scripts über ein SRC-Attribut Dynamisch erzeugte Grafiken Eine weitere, sehr interessante Methode, CGI-Scripts aufzurufen, ist der indirekte Aufruf über das SRC-Attribut des IMG-Tags. Auf diese Weise lassen sich Grafiken dynamisch erzeugen,d. h. das CGI-Script liefert keinen HTML-Code zurück, sondern eine Grafik. Die folgende Zeile ruft das unten dargestellte Script showmeallasgif (s. Kapitel 5/5.2.4) auf: <IMG SRC="/cgi-bin/makeimage/pathinfo?arg1&1a+arg2"> showmeallasgif Dieses CGI-Script ist analog zu dem showmeall -Script aufgebaut, mit dem einzigen Unterschied, dass es unter Verwendung der pbm-tools (s. Teil 8/8.1) statt einer Textausgabe eine GIF-Datei erzeugt (siehe nächste Abbildung). Betrachtet man die Ausgaben dieses Scripts, so erkennt man, dass der Aufruf des CGI-Scripts über das SRC-Attribut analog zu dem über einen Hyperlink erfolgt: Es handelt sich um einen Aufruf mit der GET-Methode Die Argumente werden sowohl in der Environment- Variablen QUERY_STRING als auch über die Kommandozeilenargumente übergeben. Zusätzliche Pfadinformationen werden in PATH_INFO und PATH_TRANSLATED zurückgeliefert.

17 CGI-Programmierung Teil 5/2.3 Seite 9 Protokoll Abbildung 5/2.3-3: Ausgabe von showmeallasgif Eine GIF-Datei Interne Realisation von CGI-Aufrufen Wie man den obigen Beispielen entnehmen kann, existieren zwei grundsätzlich verschiedene Möglichkeiten ein CGI- Script aufzurufen: GET- und POST-Methode über die GET-Methode, bei der die gesamte Information in der URL des Scripts codiert wird über die POST-Methode, bei der zusätzlich zum Request Daten an den Server geschickt werden. Betrachtet man den genauen Ablauf der Client-Server-Kommunikation im HTTP-Protokoll (s. 9/4.6), so wird klar, wie die Requests des Clients an den Server in den beiden Fällen vor sich gehen.

18 Teil 5/2.3 Seite 10 CGI-Protokoll Protokoll GET Bei der GET-Methode wird vom Client ein ganz normaler GET-Request wie zum Anfordern jeder Seite an den Server geschickt. GET /cgi-bin/showmeall/pfad?arg HTTP/1.0 Der Server erkennt, dass es sich bei /cgi-bin um ein Script- Verzeichnis handelt, nimmt den Namen des Scripts (showmeall) und splittet den Rest der URL in zusätzliche Pfadinformationen und Argumente auf, setzt die Environment- Variablen entsprechend und startet das Script. Die Ausgaben des Scripts werden dann wieder vom Server an den Client weitergereicht und, falls es sich nicht um ein nph-script handelt, um zusätzliche Header-Informationen ergänzt. POST Bei der POST-Methode hingegen sendet der Client zusätzliche Informationen zum Server. POST /cgi-bin/showmeall/pfad?arg HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 58 Im Header werden zusätzlich der MIME-Type des Inhalts und seine genaue Länge (ohne die führende Leerzeile und den abschließenden CRLF) angegeben, dann trennt eine Leerzeile Header und Body der Message, und im Body erfolgt dann die Übergabe der Argumente aus dem Formular.

19 CGI-Programmierung Teil 5/2.5 Seite 1 CGI-Umgebungsvariablen 5/2.5 CGI-Umgebungsvariablen Ein HTTP-Server übergibt Informationen an ein CGI-Script mit Hilfe von Befehlszeilenargumenten, der Standardeingabe und Umgebungsvariablen. Der Server weist die Werte dabei zu, wenn er ein Script ausführt. Sie sollten mit jeder der anschließend beschriebenen CGI-Umgebungsvariablen experimentieren, damit Sie sie besser verstehen. Am Ende des Abschnitts finden Sie ein CGI-Script, das die Werte Ihres Servers für jede Variable anzeigt. Innerhalb eines Scripts können Sie die Werte jeder Variablen als Zeichenkette betrachten. Mit AUTH_TYPE wird ein Anwender authentifiziert, der den Zugriff auf ein Script versucht. Ist ein Server für die Unterstützung von Anwenderauthentifizierung konfiguriert (siehe Teil 8/3), so muss der Anwender, der versucht, auf das Script zuzugreifen, den Anwendernamen und ein Passwort zur Verfügung stellen. Im folgenden Beispiel legt die Variable fest, dass der Anwender ein Grundlevel der Autorisierung benötigt. AUTH_TYPE AUTH_TYPE = Basic CONTENT_LENGTH enthält die exakte Bytezahl der übermittelten Daten. Enthielte z. B. eine Abfrage ein 1024-Byte- Dokument, so hätte die Umgebungsvariable folgenden Wert: CONTENT_LENGTH CONTENT_LENGTH = 1024 CONTENT_TYPE wird für Abfragen benutzt, die verknüpfte Informationen enthalten, z. B. HTTP-POST-Operationen. Die in der Variablen enthaltene Information bestimmt den Medientyp des verknüpften Elements (siehe MIME, Teil 9/3.3). Besitzt z. B. die Abfrage ein verknüpftes HTML-Dokument, würde die Umgebungsvariable folgenden Wert enthalten: CONTENT_TYPE CONTENT_TYPE = text/html

20 Teil 5/2.5 Seite 2 CGI-Programmierung CGI-Umgebungsvariablen GATEWAY_ INTERFACE GATEWAY_INTERFACE enthält die Versionsnummer der CGI-Spezifikation, mit der der Webserver mit dem aktuellen Script kommuniziert. Das Format dieser Versionsnummer lautet CGI/Versionsnummer. GATEWAY_INTERFACE = CGI/1.1 SERVER_ SOFTWARE SERVER_NAME PATH_INFO SERVER_SOFTWARE, SERVER_NAME und GATEWAY_ INTERFACE sind nicht anforderungsspezifisch und nicht bei allen Anforderungen gesetzt. Die restlichen Umgebungsvariablen sind für die Anforderungen spezifisch, die das Gateway-Script erfüllt. Mit PATH_INFO wird eine zusätzliche Pfadinformation bestimmt, die vom Client zur Verfügung gestellt wird. Mit Hilfe dieser Variablen kann einem Script eine zusätzliche Information mitgegeben werden. In der Regel ist die Pfadinformation eine relative Angabe und bezieht sich auf den Pfad des Scripts. Als Beispiel nehmen wir den Pfad Der Wert für die Variable PATH_INFO würde dann lauten: PATH_INFO = /hallo.html PATH_TRANSLATED Mit der Umgebungsvariablen PATH_TRANSLATED erhält man die endgültige, nutzbare Form der PATH_INFO-Information. Der Server übersetzt die PATH_INFO-Information durch das Umsetzen aller notwendigen virtuellen Adressen in physikalische Adressen. PATH_TRANSLATED=/home/httpd/htdocs/hallo.html QUERY_STRING QUERY_STRING enthält die Argumente bei Aufruf mit der GET-Methode. Diese stehen z. B. hinter dem Fragezeichen (?) in der URL, die der Anwender angegeben hat, um das Script auszuführen. Die Zeichenkette enthält Eingaben für das Script. Der Server ersetzt jedes Leerzeichen in der Zei-

21 CGI-Programmierung Teil 5/2.5 Seite 3 CGI-Umgebungsvariablen chenkette durch ein Pluszeichen (+) und alle nicht druckbaren Zeichen durch %xx. Dabei ist x eine Hexadezimalziffer von 0 bis F. Das Script muss Code enthalten, um die Zeichenkette der Umgebungsvariablen QUERY_STRING dekodieren zu können (siehe 5/3.2.1). Der Server sollte auf keinen Fall diese Abfrageinformation entschlüsseln. Außerdem sollte der Server die Umgebungsvariable QUERY_STRING setzen, wenn der Anwender die Abfrageinformation zur Verfügung stellt. Lautet z. B. eine URL name=hallo+welt%21, (21 H =33 D =!, siehe ASCII-Tabelle 1/6.1), so enthält die Umgebungsvariable folgenden Wert: QUERY_STRING = name=hallo+welt%21 REMOTE_ADDR enthält die IP-Adresse des Remote-Hosts, der die Anforderung stellt. Beispielsweise könnte die Umgebungsvariable REMOTE_ADDR folgenden Wert enthalten: REMOTE_ADDR REMOTE_ADDR = In REMOTE_HOST steht der Name des Hosts, der die Anforderung stellt. Kennt der Server den Namen des anfordernden Hosts nicht, sollte er die Umgebungsvariable REMOTE_ ADDR setzen und der Variablen REMOTE_ HOST keinen Wert zuweisen. Kommt z. B. die Anfrage von einem T-Online-User, könnte die Umgebungsvariable REMOTE_HOST folgenden Wert enthalten: REMOTE_HOST REMOTE_HOST = ics1f.b.srv.t-online.de Mit REMOTE_IDENT erhält man den Namen des Remote- Anwenders, der an den Server eine Anforderung stellte. Unterstützt der HTTP-Webserver die Identifizierung nach RFC 931 (das Authentifizierungsserverprotokoll), setzt der Server die Umgebungsvariable REMOTE_IDENT auf den Remote- Anwendernamen. Scripts sollten die Umgebungsvariable RE- REMOTE_IDENT

22 Teil 5/2.5 Seite 4 CGI-Programmierung CGI-Umgebungsvariablen MOTE_IDENT nur zum Erstellen von Aufzeichnungen verwenden. Nehmen wir z. B. einen Remote-Anwender mit dem Anwendernamen luser vom Remote-Host Die Umgebungsvariable REMOTE_IDENT würde dann folgenden Wert enthalten: REMOTE_IDENT = luser. REMOTE_USER Die Umgebungsvariable REMOTE_USER enthält den Namen des Remote-Anwenders. Unterstützt der Server Anwenderauthentifizierung, und das Script ist (Basic-Authentication-)geschützt, so authentifiziert der Server den Namen des Remote-Anwenders und weist ihn dieser Variablen zu. Nehmen wir an, der Name des Remote-Anwenders wäre luser, so würde die Umgebungsvariable folgenden Wert enthalten: REMOTE_USER = luser REQUEST_ METHOD REQUEST_METHOD enthält die Art der HTTP-Anforderung (wie GET, HEAD oder POST), die der Browser zum Server schickt. Sendet der Browser z. B. eine GET-Methode, enthält die Umgebungsvariable den folgenden Wert: REQUEST_METHOD = GET SCRIPT_NAME Mit der Umgebungsvariablen SCRIPT_NAME wird der virtuelle Pfad zum Script bestimmt, das der Server ausführt. Bei einer URL enthielte die Umgebungsvariable SCRIPT_NAME folgenden Wert: SCRIPT_NAME = /cgi-bin/showmeall SERVER_NAME SERVER_NAME gibt den Hostnamen, den Domänennamen oder die IP-Adresse des eigenen Webservers an. SERVER_NAME =

23 CGI-Programmierung Teil 5/2.5 Seite 5 CGI-Umgebungsvariablen Analog liefert die Environment-Variable SERVER_PORT den Port des aktuellen Servers zurück (normalerweise 80 für HTTP). SERVER_PORT SERVER_PORT = 80 Der Webserver startet das CGI-Script und bearbeitet die zurückgegebenen Informationen, bevor er sie an den Browser des Anwenders weitergibt. Da ein Script auf verschiedenen Servern unterschiedlich ausgeführt werden kann, wird mit der Umgebungsvariablen SERVER_SOFTWARE der Name des Webserverprogramms und dessen Versionsnummer dem Script mitgeteilt. Das Format der beiden Elemente wird dem CGI-Script als Name/Version zur Verfügung gestellt. SERVER_ SOFTWARE SERVER_SOFTWARE = Apache/1.1.3 Die Umgebungsvariable HTTP_ACCEPT bestimmt, welchen MIME-Typ ein Browser akzeptiert. Sie wird durch HTTP- Köpfe spezifiziert, die der Browser an den Server schickt. Ein MIME-Typ wird mit type/subtype angegeben. Mehrere MIME-Typen werden durch Kommas getrennt. Die Umgebungsvariable HTTP_ACCEPT könnte z. B. folgenden Wert enthalten: HTTP_ACCEPT HTTP_ACCEPT = audio/aif, text/html, text/plain, */* Meist enthält eine normale Anfrage den MIME-Typ */*, der angibt, dass hier beliebige MIME-Typen geliefert werden können. Wird jedoch ein CGI-Script über das <IMG SRC=>- Tag aufgerufen, steht hier im Allgemeinen eine deutlich begrenztere Auswahl. HTTP_ACCEPT = image/gif, image/x-bitmap, image/jpeg, image/pjpeg, image/png

24 Teil 5/2.5 Seite 6 CGI-Programmierung CGI-Umgebungsvariablen

25 CGI-Programmierung Teil 5/2.6 Seite 1 CGI-Köpfe 5/2.6 CGI-Köpfe CGI-Scripts erzeugen eine Ausgabe, die der Server interpretiert und zurück zum Browser schickt. Der Vorteil, die Ausgabe von einem CGI-Script an einen Server zu senden, liegt darin, dass für jede Anforderung nicht jedes Mal vom CGI- Script ein vollständiger HTTP-Kopf generiert werden muss. Im Gegensatz dazu schicken einige CGI-Scripts ihre Ausgabedaten direkt zum Browser, um über selbst generierte Köpfe größeren Einfluss nehmen zu können. Um Scripts, die ihre Ausgabedaten direkt zum Browser schicken, von denen zu unterscheiden, die sie zum Server schicken, verlangt das CGI-Protokoll, dass die Namen der direkt geschickten Scripts mit den Buchstaben nph- (Not to Parse the Header = den Kopf nicht zerlegen) beginnen. Beginnt also ein CGI-Script mit nph-, zerlegt der Server den Kopf nicht. In diesem Fall liegt es in der Verantwortung des Script-Schreibers, dass an den Browser eine gültige Anwort geschickt wird. Das CGI-Script beginnt mit einem Kopf (Head), der aus Textzeilen besteht, die das gleiche Format aufweisen wie ein HTTP-Kopf (s. 9/4.6). Zwischen Head und Body (den zu ü- bertragenden Daten, s. 9/3.3 MIME) steht eine Leerzeile, d. h. eine Zeile, die nur aus Carriage-Return Line-Feed (CRLF) besteht. Gibt ein CGI-Script Kopffelder aus, die keine Serveranweisungen sind, werden sie vom Server direkt zum Browser weitergeleitet. Die CGI-Spezifikation definiert drei Serveranweisungen: Direkte CGI-Ausgabe nph-scripts CGI-Köpfe Content-Type Location Status Das Feld Content-Type im CGI-Kopf gibt den MIME-Type der im Body enthaltenen Daten an. Im Normalfall erzeugen CGI-Scripts ein HTML-Dokument. In diesem Fall würde Content-type im CGI-Kopf Folgendes enthalten: Content-Type Content-type: text/html

26 Teil 5/2.6 Seite 2 CGI-Programmierung CGI-Köpfe Dieses Feld ist zwingend immer anzugeben. Deshalb beginnt jedes CGI-Programm mit einem Befehl der Art print "Content-Type: text/html\n\n" Dabei besteht der gesamte Kopf nur aus dem Content-Type- Feld, die beiden \n liefern die den Kopf abschließende Leerzeile. Falls ein CGI-Script wie in 5/5.2.4 showmeallasgif ein Bild zurückliefern soll, ist analog ein Content-Type von z. B. Content-Type: image/gif zu setzen. Location Das Feld Location in einem CGI-Kopf spezifiziert eine Referenz auf ein anderes Dokument. Scripts verwenden dieses Feld, um dem Server eine Referenz auf ein Dokument anzugeben. Ist die Location eine Remote-URL (das Dokument befindet sich also nicht auf dem lokalen Server, auf dem das CGI-Script läuft), leitet der Server den Browser zu der entsprechenden Stelle um. Ist das Argument des Feldes Location ein virtueller Pfad (die Datei existiert auf dem Server), holt der Server das angegebene Dokument, als hätte der Browser das Dokument im Original angefordert. Ein Remote-Dokument könnten Sie z. B. mit folgendem Wert für Location angeben: Location: Status Das Feld Status in einem CGI-Kopf enthält einen HTTP- Statuswert, den der Server vom Script an den Browser weiterleitet. Der Server, der das CGI-Script aufruft, verwendet viele HTTP-Statuscodes (s. 9/4.6). Es könnte sein, dass Sie die HTTP-Statuscodes direkt an den Browser weiterleiten möchten, besonders dann, wenn ein Fehler passiert.

27 CGI-Programmierung Teil 5/2.6 Seite 3 CGI-Köpfe Das folgende Beispiel zeigt die typische Ausgabe, die ein CGI-Script erzeugen muss, um Daten an einen Server zu schicken. Nachdem die Daten das Serverprogramm erreicht haben, leitet der Server die Daten an den Browser weiter. Beispiel Content-type: text/html <HTML> <HEAD> <TITLE>Dies ist der Titel</TITLE> </HEAD> <BODY> Text der HTML-Seite </BODY> </HTML> Beachten Sie in diesem Beispiel die Leerzeile zwischen dem Feld Content-type und dem <HTML>-Tag. Diese Leerzeile ist unbedingt notwendig. Fügen Sie sie nicht ein, kann der Server das Dokument nicht korrekt bearbeiten. Das folgende Fragment aus C-Code verwendet für die Erstellung des vorigen HTML-Dokuments die Funktion printf. Leerzeile trennt Head und Body printf("content-type: text/html\n"); //Diese Leerzeile ist unbedingt erforderlich printf("\n"); printf("<html>\n"); printf("<head>\n"); printf("<title> Dies ist der Titel </TITLE>\n"); printf("</head>\n"); printf("<body>\n"); printf("text der HTML-Seite\n"); printf("</body>\n"); printf("</html>\n");

28 Teil 5/2.6 Seite 4 CGI-Programmierung CGI-Köpfe

29 CGI-Programmierung Teil 5/2.7 Seite 1 Cookies 5/2.7 Cookies Cookies (eigentlich Persistant Client State HTTP-Cookies) sind ein Mechanismus, Informationen dauerhaft auf Client- Rechnern zu speichern. Im Normalfall wird diese Methode von CGI-Scripts angewendet. Ebenso ist es aber auch möglich, Cookies via JavaScript (s. 6/2) zu setzen und wieder auszulesen. Ein Server, insbesondere ein CGI-Script, kann einem Client bei der Lieferung einer Antwort ein Header-Feld mitsenden, das diesen dazu auffordert, ein Cookie für diesen Server zu speichern. Dabei kann angegeben werden, wann dieses Cookie bei Anfragen an diesen Server vom Client mitversandt werden soll. Auf diese Weise ist es trotz des verbindungslosen HTTP-Protokolls möglich, bestimmte User bzw. Verbindungen eindeutig zuzuordnen. Eine wichtige Anwendung ist die Speicherung von Benutzereinstellungen oder Kundeninformationen wie Kundennummern etc. Ein anderer interessanter Einsatzzweck ist, einen Warenkorb anzulegen, den der Kunde dann, sogar über mehrere Sitzungen hinweg, füllen kann (s. auch 6/3). Persistant Client State HTTP- Cookies Arbeitsweise Anwendungen Realisation Ein Cookie wird von einem Server gesetzt, indem dieser beim Senden einer vom Client angeforderten Antwort im Header einen Set-Cookie HTTP-Response Header einfügt. Setzen eines Cookies Set-Cookie: NAME=WERT; expires=datum; path=pfad; domain=domain-name; secure NAME=WERT gibt sowohl den Namen als auch den Inhalt des zu setzenden Cookies an. Benutzt werden dürfen alle Zeichen außer :,, und white space, also Leerzeichen, Zeilentrennzeichen und Tabulatoren. Sollten solche Zeichen doch benötigt werden, können sie HTTP-konform, z. B. %xx NAME=WERT

30 Teil 5/2.7 Seite 2 CGI-Programmierung Cookies (oder auch beliebig anders) codiert werden. NAME=WERT ist dabei das einzige zwingend vorgeschriebene Attribut. expires=datum expires setzt das Datum im Standarddatumformat (s. 9/3.2), ab dem das Cookie verfällt und nicht mehr herausgegeben wird. Das Datum besitzt folgenden Aufbau: Tag, TT-Mon-JJJJ HH:MM:SS GMT Achtung Im Gegensatz zu den Datumsformaten nach RFC 822, 850, 1036 und 1123, die in 9/3.2 beschrieben werden, ist hier ist nur die Zeitzone GMT gültig und als Datumsseparator nur der -. Dieses Attribut ist wie alle folgenden optional. Wird es nicht mit angegeben, erlischt das Cookie direkt nach der Session. Auf Grund eines Fehlers in Netscape Navigator 1.1 und älteren Versionen wird expires nur bei Cookies mit einem expliziten Pfad / korrekt behandelt. domain= DOMAIN-NAME path=pfad Bei Anfragen an einen Server wird das entsprechende Cookie nur mitgeschickt, falls das Ende des angefragten Servers mit DOMAIN-NAME übereinstimmt. So wird ein Cookie mit domain=.interest.de sowohl an als auch an gandalf.interest.de gesandt. Ein Server kann ein Cookie nur setzen, wenn der DOMAIN-NAME für ihn gültig ist und mindestens zwei bzw. drei Punkte enthält (also kein.com, um das Cookie an alle.com-sites zu schicken). Falls dieses Argument nicht angegeben wird, wird der komplette Servername benutzt. Analog zu domain legt path fest, bei welchen Requests das Cookie mitgeschickt wird. Umgekehrt muss hier allerdings wie bei domain der Pfadanfang übereinstimmen. path=/pub bedeutet also, dass das Cookie bei Requests für die Seiten /pub/index.html, aber auch bei /public mitgeschickt wird, nicht jedoch bei /PUB. Wird dieses Argument nicht angegeben, wird das Verzeichnis des Dokuments benutzt, das das Cookie gesetzt hat.

31 CGI-Programmierung Teil 5/2.7 Seite 3 Cookies Bei der Angabe von secure wird das Cookie nur über sichere Übertragungswege (S-HTTP bzw. HTTPS, also HTTP über SSL) verschickt. Bei der Anfrage eines Dokuments prüft der Client, ob auf die anzufragende URL eines der lokal gespeicherten Cookies (unter Berücksichtigung der jeweiligen domain- und path- Attribute) passt. In diesem Fall wird dem Server mit der Anfrage des Dokuments im Header eine Zeile mit allen passenden Cookies geschickt. secure Rückmeldung eines Cookies Cookie: NAME1=WERT1; NAME2=WERT2... Das explizite Löschen von Cookies ist nicht vorgesehen. Man kann aber ein Cookie löschen, indem man z. B. ein neues Cookie mit dem gewünschten Namen setzt (und somit das alte überschreibt) und dabei ein expire angibt, das in der Vergangenheit liegt. Dabei ist zu beachten, dass die Cookies auch nach den Pfaden unterschieden werden. In einer Server-Antwort können gleichzeitig mehrere Cookies gesetzt werden. Bei der Verwendung mehrerer Cookies werden solche mit gleichem Pfad und Namen überschrieben. Es können allerdings Cookies mit verschiedenen Namen benutzt werden. Wenn mehrere Cookies mit verschieden detaillierten Pfadangaben existieren, sollte der Client zuerst die Cookies mit der genauesten Pfadangabe übergeben. Clients sollten normalerweise insgesamt 300 cookies (20 je Domain) von maximal je 4 kb (Name und Wert zusammen) speichern. Clients können Cookies jederzeit, auch vor dem Erreichen des Verfallsdatums, löschen. Proxies sollten Cookie- und Set-Cookie-Headers weiterreichen. Passiert dies nicht korrekt, können über diesen Proxy keine Cookies verwendet werden. Ebenso kann nicht davon ausgegangen werden, dass alle Clients Cookies unterstützen. Auch haben viele User das automatische Setzen von Cookies aus Sicherheitsbedenken in ihrem Browser abgeschaltet. Löschen von Cookies Mehrere Cookies Grenzen Proxies

32 Teil 5/2.7 Seite 4 CGI-Programmierung Cookies Beispiel Warenkorbsystem Ein Warenkorbsystem kann z. B. ein Cookie Warenkorb benutzen. Dabei ist es ratsam, zuerst zu prüfen, ob der Client Cookies unterstützt (s. 5/5.2.4). Legt der Kunde nun etwas in den Warenkorb, z. B. über den Link <A HREF= /cgi-bin/inwarenkorb?4711 > sendet das Script inwarenkorb an den Client einen Reply der Art HTTP/ OK Date: Thu, 18 Jun :42:01 GMT Set-Cookie: Warenkorb= (Rest vom Header und Dokument folgt)... zurück. Bei jedem weiteren Aufruf des Scripts bekommt es ein Headerfeld Cookie: Warenkorb=4711 übergeben. Dieser übergebene String kann dann vom Script geändert und wieder dem Client zurückgeliefert werden.

33 CGI-Programmierung Teil 5/2.8 Seite 1 Öffentliche CGI-Dienste 5/2.8 Öffentliche CGI-Dienste Im Internet existieren neben unzähligen frei verfügbaren CGI- Scripts für die verschiedensten Bedürfnisse auch so genannte öffentliche CGI-Dienste, die sich vor allem an Web-Site- Betreiber richten, die keine Möglichkeit des Einsatzes von CGI-Scripts haben. CGI-Scripts für alle Diese Dienste stellen allgemein verwendete Scripts meist kostenlos oder gegen eine geringe Gebühr auf ihrem Server zur Verfügung, sodass ein Web-Site-Betreiber ohne CGI- Möglichkeit von seinen HTML-Dokumenten aus die Scripts auf den Rechnern dieser Dienste nutzen kann. Dazu erhält er meist von den Dienstbetreibern vorgefertigten HTML-Code, den er direkt in seine Seiten einbinden kann. Im Folgenden finden Sie eine Auswahl solcher Dienste. HTML-Code Zuriffszähler Name/URL 123 India Aussie Coxco CyberHits Der m.o.p.s.-counter Digits Beschreibung Indien, kostenlos, zwei Stile, gut erreichbar und relativ schnell Schweiz (deutsch), Gästebuch, SMS, Counter, Anmeldung via Schwedisch, kostenlos, 20 Stile, Anmeldung via . Schwedisch, 10 Zählertypen mit diversen Rändern, relativ langsam, Anfangszählerstand einstellbar, Digitale Uhrzeit und Datum als Grafik, Statistiken Viele Stile und Parameter, kostenlos für private Homepages, gewerblich gegen geringe Gebühr, Uhrzeit und das Datum als Grafik

34 Teil 5/2.8 Seite 2 CGI-Programmierung Öffentliche CGI-Dienste Name/URL DUX FixWeb Free and Fun FWM Counter Hot-Count Icount icount.com Internet-Audit-Bureau KbCount Link It NedStat PAGECOUNT Tec-Online TH-Zwickau WebHits WebTracker Beschreibung Russisch, über 340 Stile, antwortet manchmal nicht, falls aber doch, dann sehr schnell Frei, aber Gegenlink erwartet deutsch, kostenlos, Statistik (passwortgeschützt, Provider-Auswertung, Rekordliste), Reload-Sperre verhindert, dass Besucher bei einem Neuladen doppelt gezählt werden Erst auf Icon klicken, dann Besucherzahl und Statistik Ausführliche Statistik, nicht nur einfacher Counter kostenloses Verzeichnis von Homepages, begrenzte Anzahl von kostenlosen Zählern kostenlose Echtzeitstatistik, nicht öffentlich, nur gegen Bezahlung (90 Gulden/Jahr) Kostenlos, große Grafik mit Werbung, exakte Statistik über die letzten hundert Zugriffe max. 500 kostenlose Zähler einfacher Besucherzähler Umfangreiche Statistik (auch nach Domains), Einschränkungen: nicht mehr als 500 Abrufe pro Tag und keine sexuellen Inhalte

35 CGI-Programmierung Teil 5/2.8 Seite 3 Öffentliche CGI-Dienste Gästebücher Name/URL Aussie Guestbook III Personal Edition developers/bgiel/www/gbfiles/ Guestbook-Central GuestPAD Internet Want Ads Guestbook www. internetwantads.com/ add-books/visitors/ auto-guestadd.html LPage Pagetools Pergatory Guestbook Server System Piett Productions SPiN Goodies: Multi Guest Book World Wide Guestbook Beschreibung Schweiz, deutsches Gästebuch, JavaScript Java-Applet, Datenbank auf WebWare Online kostenlos, englisch, wenig Gestaltungsmöglichkeiten (4 Hintergrundbilder, Titelzeile, Überschrift), schnelle und zuverlässige Verbindung, kostenlose Homepage Die Mutter aller Gästebücher, internationale/kundenspezifische Formulare, - Form-Mailer, Server oft nicht ansprechbar Logo als Gegenleistung, kaum Gestaltungsmöglichkeiten einmalige Gebühr von 5 US$ für Gästebuch, Zähler etc. Schweden, gut zu konfigurieren, mehrere Sprachen (auch Deutsch), Server gut erreichbar auf englisch! Ein großes öffentliches Gästebuch

36 Teil 5/2.8 Seite 4 CGI-Programmierung Öffentliche CGI-Dienste -Services Name/URL CWAK Mailservice NetMind Beschreibung Formulare per CGI verarbeiten und zuschicken lassen Anwender automatisch per über Änderungen auf einer WWW-Seite informieren All4Free Aktuelle Informationen zu kostenlosen Service-Diensten im Internet finden Sie unter den Webindex-Tipps von Wilfried Arimont und Ehrenfried Ehrenstein unter und unter dem All4Free-Projekt von Markus Buschmann unter