Was ist ein CGI-Skript?

CGI-Skripten benutzen?

Die Anatomie eines CGI-Skripts

Probleml÷sungen

CGI-Variablen

Programme zum Dekodieren

Non-processed Header-Skripts - (NPH-Skripts)

Zusammenfassung

Fragen und Antworten

Tag 10

Kapitel 19 - CGI-Programmierung

CGI steht fⁿr Common Gateway Interface, eine Methode, Programme auf einem Web-Server entsprechend den Eingaben eines Web-Browsers auszufⁿhren. Gateway-Skripten erlauben Ihren Lesern, Ihre Webseiten zu beeinflussen - um in einer Datenbank nach einem Eintrag zu suchen, um das, was Sie geschrieben haben, zu kommentieren oder um einzelne Punkte in einem Formular auszuwΣhlen und dann eine entsprechend zusammengestellte Antwort zu erhalten. Wenn Ihnen im Web schon jemals ein auszufⁿllendes Formular oder eine Suchabfrage untergekommen ist, dann haben Sie ein CGI-Skript benutzt. Vielleicht ist Ihnen das nicht einmal aufgefallen, weil die meiste Arbeit auf dem Web-Server hinter den Kulissen erledigt wird. Sie sehen nur das Ergebnis.

Als Web-Autor erzeugen Sie alle Seiten des Gateways: die Seite, welche die Leser sehen, die Programmierung auf der Server-Seite, um die Lesereingaben zu verarbeiten, und das Resultat, das an die Leser zurⁿckgemeldet wird. CGI-Skripten sind ein extrem wirkungsvolles Feature der Interaktion zwischen Web-Browsern und Servern, die Ihre Meinung, eine Web-PrΣsentation betreffend, komplett Σndern k÷nnen.

Dieses Kapitel erklΣrt eine Menge ⁿber CGI-Skripte, unter anderem

• Was ein Gateway-Skript ist und wie es funktioniert
• Wie die Ausgaben eines Gateway-Skripts aussehen sollten
• Wie Sie CGI-Skripten mit und ohne Argumente erzeugen
• Wie Sie Skripten erzeugen, die bestimmte Antworten zurⁿckliefern
• Wie Sie Skripten erzeugen, die die Eingabe von Formularen verarbeiten
• Wie Sie Probleme beim Ausfⁿhren von CGI-Skripten l÷sen
• Welche CGI-Variablen Sie in Ihren Skripten anwenden k÷nnen
• Was Skripten sind, deren Header-Elemente kein Parsing anwenden
• Wie Sie mit <ISINDEX> suchen

Was ist ein CGI-Skript?

Ein CGI-Skript ist, einfach ausgedrⁿckt, ein Programm, das auf dem Web-Server ablΣuft, ausgel÷st durch Eingaben, die in einem Browser gemacht werden. Das Gateway-Skript stellt ⁿblicherweise eine Verbindung dar zwischen dem Server und einem anderen Programm, das auf dem System lΣuft, beispielsweise einer Datenbank.

Gateway-Skripten mⁿssen nicht unbedingt Skripten sein - je nachdem, was Ihr Server unterstⁿtzt, k÷nnen es kompilierte Programme sein, Batch-Dateien oder etwas anderes Ausfⁿhrbares. Um der einfachen Ausdrucksweise willen nenne ich sie in diesem Kapitel jedoch einfach Skripte.

CGI-Skripten k÷nnen auf zwei Arten verwendet werden: als die ACTION eines Formulars oder als direktes Link auf eine Seite. Skripten zur Formularverarbeitung unterscheiden sich geringfⁿgig von normalen CGI-Skripten, jedoch haben beide eine sehr Σhnliche Erscheinung und ein Σhnliches Verhalten. Im ersten Teil dieses Kapitels werden Sie etwas ⁿber allgemeine (generic) CGI-Skripten lernen und sich dann zu Skripten weiterbewegen, die Formulare verarbeiten.

Wie funktionieren CGI-Skripte?

Gateway-Skripten werden vom Server aufgerufen, basierend auf den Angaben des Browsers. Abbildung 19.1 zeigt den Weg zwischen Browser, Server und dem Skript.

Hier eine kurze Beschreibung dessen, was tatsΣchlich vor sich geht:

1. Eine URL verweist auf ein CGI-Skript. Die URL eines CGI-Skripts kann ⁿberall da auftreten, wo eine normale URL sein k÷nnte, z.B. in einem Link oder in einem Bild. Meistens tritt eine URL jedoch als ACTION eines Formulars auf. Der Browser kontaktiert den Server dann mit dieser URL.

2. Der Server empfΣngt die Anforderung, erkennt, da▀ die URL auf ein Skript verweist (je nach Server abhΣngig vom Ablageort des Skripts oder seiner Endung) und fⁿhrt das Skript aus.

3. Gesteuert von den Eingaben des Browsers, soweit es diese gibt, fⁿhrt das Skript eine Aktion durch. Diese Aktion kann aus dem Durchsuchen einer Datenbank bestehen, dem Berechnen eines Werts oder einfach dem Aufruf eines anderen Programms auf dem System.

4. Das Skript formatiert seine Ergebnisse in einer Weise, die der Web-Server verstehen kann.

5. Der Web-Server erhΣlt das Ergebnis vom Skript und reicht es zum Browser weiter, der es fⁿr die Leser formatiert und anzeigt.

Verstanden? Nein? Macht nix, es kann ein verwirrender Ablauf sein. Lesen Sie weiter, es wird mit den nΣchsten paar Beispielen klarer werden.

Ein einfaches Beispiel

Hier haben wir ein einfaches Beispiel mit einer Schritt-fⁿr-Schritt-ErklΣrung dessen, was auf allen Seiten des Prozesses passiert. In Ihrem Browser sto▀en Sie auf eine Seite wie jene, die in Abbildung 19.2 dargestellt ist.

Die Verbindung zu ╗Display the Date½ ist eine Verknⁿpfung mit einem CGI-Skript, eingebettet in den HTML-Code der Seite, wie es bei jeder anderen Verbindung auch der Fall wΣre. K÷nnten Sie den HTML-Code der Seite sehen, wⁿrde er ungefΣhr so aussehen:

<A HREF="http://www.somesite.com/cgi-bin/getdate">Display the Date</A>

Der Umstand, da▀ da cgi-bin im Pfad-Namen auftaucht, ist ein starkes Indiz dafⁿr, da▀ es sich um ein Gateway-Skript handelt, weil dies bei vielen Servern der einzige Ort ist, an dem CGI-Skripten abgelegt werden k÷nnen.

Wenn Sie die Verbindung anwΣhlen, fordert der Browser die URL vom Server des Systems www.somesite.com an. Der Server nimmt die Anfrage entgegen und erkennt anhand seiner Konfiguration, da▀ die ⁿbermittelte URL ein Skript namens getdate.cgi ist, und fⁿhrt das Skript aus.

Das Skript, in diesem Falle ein unter Unix ausfⁿhrbares Shell-Skript, sieht etwa so aus:

#!/bin/sh

echo Content-type: text/plain
echo

/bin/date

Dieses Skript erledigt zwei Dinge: Es gibt die Zeile Content-type: text/plain und danach eine Leerzeile aus, und es ruft das Unix-date-Programm auf, welches das Datum und die Uhrzeit ausgibt. Daher wⁿrde die komplette Ausgabe des Skripts etwa so aussehen:

Content-type: text/plain
Tue Oct 25 16:15:57 EDT 1994

Was hat es mit dem Content-type (Inhaltstyp) auf sich? Das ist eine Art Spezialcode, den der Server an den Browser weiterreicht, um ihm mitzuteilen, um welche Art von Dokument es sich handelt. Der Browser verwendet diesen Code dann, um herauszufinden, ob er das Dokument anzeigen kann oder nicht oder ob er dafⁿr ein externes Programm (Viewer) starten mu▀. Die Besonderheiten dieser Zeile lernen Sie spΣter in diesem Kapitel kennen.

Nachdem die Ausfⁿhrung des Skripts beendet ist, erhΣlt der Server das Ergebnis und gibt es an den Browser weiter. Der Browser hat die ganze Zeit geduldig auf irgendeine Reaktion gewartet. Und wenn der Browser sie erhΣlt, zeigt er einfach Datum und Uhrzeit an (Abbildung 19.3).

Das ist also die Grundidee. Obgleich die Dinge auch sehr viel komplizierter werden k÷nnen, ist es doch diese Wechselwirkung zwischen Browser, Server und Skript, die den Kern dessen ausmacht, wie ein CGI-Skript funktioniert.

CGI-Skripten benutzen?

Bevor Sie CGI-Skripten in Ihren Web-PrΣsentationen anwenden k÷nnen, mⁿssen mehrere grundlegende Bedingungen von Ihnen und Ihrem Server erfⁿllt werden. CGI-Skripting ist ein erweitertes Web-Feature und erfordert Wissen auf Ihrer Seite und Kooperation auf seiten des Web-Server-Anbieters. Vergewissern Sie sich, da▀ Sie alle Fragen in diesem Abschnitt beantworten k÷nnen, bevor Sie weitermachen.

Ist Ihr Server dazu konfiguriert, CGI-Skripten zuzulassen?

Um CGI-Skripten zu schreiben und auszufⁿhren, brauchen Sie einen Web-Server. Im Unterschied zu regulΣren HTML-Dateien k÷nnen Sie CGI-Skripten nicht auf Ihrem lokalen System schreiben und testen; Sie mⁿssen dies durch einen Web-Server erledigen.

Aber sogar wenn Sie einen Web-Server haben, mu▀ dieser auf spezielle Weise konfiguriert sein, um CGI-Skripten verarbeiten zu k÷nnen. Das bedeutet normalerweise, da▀ alle Ihre Skripten in einem speziellen Verzeichnis namens cgi-bin aufgehoben werden.

Bevor Sie CGI-Skripten ausprobieren, sollten Sie Ihren Server-Administrator fragen, ob Sie CGI-Skripten installieren und ausfⁿhren dⁿrfen, und wenn ja, wo Sie sie speichern k÷nnen. Au▀erdem mu▀ es sich bei dem Server um einen echten Web-Server handeln - wenn Sie Ihre Webseiten auf einem FTP- oder Gopher-Server publizieren, k÷nnen Sie CGI nicht anwenden.

Wenn Sie Ihren eigenen Server verwalten, mⁿssen Sie ein spezielles cgi-bin-Verzeichnis erzeugen und Ihren Server so konfigurieren, da▀ er dieses Verzeichnis als Skript-Verzeichnis erkennt (was ein Teil der Serverkonfiguration ist, die sich natⁿrlich von Server zu Server unterscheidet). Doch bedenken Sie die folgenden Punkte, die von CGI-Skripten aufgeworfen werden:

• Jedes Skript ist ein Programm, und es lΣuft auf Ihrem System, wenn ein Browser es anfordert, und es verbraucht Rechenzeit und Arbeitsspeicher wΣhrend seiner Ausfⁿhrung. Was passiert mit Ihrem System, wenn Dutzende oder Hunderte dieser Skripten zur selben Zeit laufen? Es k÷nnte sein, da▀ Ihr System das nicht verkraftet und zusammenbricht oder da▀ Ihr System unbenutzbar wird.
• Solange Sie nicht sehr vorsichtig mit den Skripten sind, die Sie schreiben, ÷ffnen Sie sich wom÷glich fⁿr jemanden, der in Ihr System einbricht oder es beschΣdigt, indem er Aufrufparameter an Ihr Skript ⁿbergibt, die anders sind als jene, die erwartet werden.

K÷nnen Sie programmieren?

Achtung, AnfΣnger! Damit Sie mit Hilfe von CGI Formulare verarbeiten oder irgendeine interaktive Aktion im World Wide Web vornehmen k÷nnen, sollten Sie ein grundlegendes VerstΣndnis fⁿr Programmierkonzepte und Methoden mitbringen. Au▀erdem sollten Sie mit Ihrem System gut vertraut sein. Wenn Sie diesen Hintergrund nicht mitbringen, sollten Sie entweder jemand anderen um Hilfe bitten, ein Buch ⁿber Programmiergrundlagen lesen oder einen Programmierkurs belegen. Dieses Buch kann nicht gleichzeitig Programmiergrundlagen und CGI-Programmierung beschreiben. Fⁿr dieses Kapitel setze ich voraus, da▀ Sie den Beispielcode lesen k÷nnen und ihn auch verstehen.

Welche Programmiersprache sollten Sie verwenden?

Sie k÷nnen so gut wie jede Programmiersprache anwenden, mit der Sie vertraut sind, um CGI-Skripten zu schreiben, solange Sie dabei die Regeln aus dem nΣchsten Abschnitt befolgen und solange diese Sprache mit dem Betriebssystem Ihres Web-Servers kompatibel ist. Manche Server unterstⁿtzen nur Programme, die in einer bestimmten Sprache geschrieben sind. Beispielsweise benutzen MacHTTP und WebStar AppleSkript fⁿr Ihre CGI-Skripte; WinHTTPD und WebSite verwenden Visual Basic. Um CGI-Skripten fⁿr Ihren Server zu schreiben, mⁿssen Sie in einer Programmiersprache schreiben, die von Ihrem Server akzeptiert wird.

In diesem Kapitel und auch im weiteren Verlauf des Buches werde ich diese CGI-Skripten in zwei Sprachen schreiben: in der Unix Bourne Shell und in Perl. Die Bourne Shell gibt es fast auf jedem Unix-System. Sie ist zwar verhΣltnismΣ▀ig einfach zu lernen, jedoch kann es schwierig sein, etwas Kompliziertes mit ihr anzufangen. Perl andererseits ist kostenlos erhΣltlich, Sie mⁿssen es jedoch herunterladen und auf Ihrem System kompilieren. Die Sprache selbst ist sehr flexibel und leistungsfΣhig (vergleichbar einer Programmiersprache wie C), ist aber auch sehr schwierig zu erlernen.

Ist Ihr Server richtig konfiguriert?

Um CGI-Skripten auszufⁿhren, seien diese nun sehr einfache Skripten oder Skripte, die Formulare verarbeiten, mu▀ Ihr Server ausdrⁿcklich dazu konfiguriert sein. Dies kann bedeuten, da▀ Ihre Skripten in einem speziellen Verzeichnis aufbewahrt werden oder eine besondere Dateierweiterung haben mⁿssen, je nachdem, welchen Server Sie verwenden und wie er konfiguriert ist.

Wenn Sie Platz auf einem Web-Server mieten oder wenn jemand anderer dafⁿr zustΣndig ist, Ihren Web-Server zu administrieren, sollten Sie die zustΣndige Person fragen, ob CGI-Skripten zulΣssig sind, und wenn ja, wo sie hingeh÷ren.

Wenn Sie Ihren eigenen Server verwalten, prⁿfen Sie die Dokumentation fⁿr diesen Server, um zu sehen, wie er mit CGI-Skripten umgeht.

Was, wenn Sie kein Unix verwenden?

Wenn Sie nicht mit Unix arbeiten, geben Sie nicht gleich auf. Sie werden hier noch genⁿgend allgemeine Informationen finden, die auf Ihren Server anwendbar sein k÷nnten. Und um Ihnen noch ein wenig allgemeinen Hintergrund zu geben, kommen hier noch ein paar Informationen ⁿber CGI auf gew÷hnlichen Web-Servern.

WinHTTPD fⁿr Windows 3.x und WebSite fⁿr Windows 95 und NT enthalten beide CGI-FΣhigkeiten, mit denen Sie Formular- und CGI-Eingaben verarbeiten k÷nnen. Beide Server beinhalten auch einen CGI-Modus fⁿr DOS und Windows. Letzterer erlaubt es Ihnen, CGI mit Visual Basic zu schreiben. Der DOS-Modus kann dazu konfiguriert werden, mit CGI-Skripten von Perl oder Tcl (oder jeder anderen Sprache) fertigzuwerden. WebSite hat auch einen CGI-Modus, mit dem Sie Perl und Windows-Shell-Skripten anwenden k÷nnen.

Ganz Σhnlich verhΣlt es sich mit Netscape's Web-Server-Linie, FastTrack und Enterprise Web-Server eingeschlossen. Diese unterstⁿtzen die gesamte Bandbreite der CGI-M÷glichkeiten. Der Enterprise Server z.B. unterstⁿtzt den Shell CGI-, den normalen CGI- und den Windows CGI-Modus. Dies gibt Ihnen die FlexibilitΣ,t den besten Ansatz fⁿr Ihre Bedⁿrfnisse zu wΣhlen. Auch die aktuelle Version des Internet Information Server von Microsoft (Version 3.0) unterstⁿtzt CGI in verschiedenen Formen.

MacHTTP bekommt seine CGI-FΣhigkeiten von AppleSkript-Skripten. (MacHTTP ist die ursprⁿngliche Shareware Version des kommerziellen Web-Servers WebStar, der bei StarNine erhΣltlich ist.) John Wiederspan hat ein ausgezeichnetes Tutorial ⁿber die Anwendung von AppleSkript-CGI geschrieben, welches in der MacHTTP-Dokumentation enthalten ist.

Die Anatomie eines CGI-Skripts

Wenn Sie es so weit geschafft und die Warnungen und Konfiguration hinter sich haben, Glⁿckwunsch! Jetzt k÷nnen Sie CGI-Skripten und Formulare fⁿr Ihre PrΣsentationen schreiben. In diesem Abschnitt werden Sie erfahren, wie Ihre Skripten sich verhalten sollten, so da▀ der Server sich mit ihnen unterhalten und die korrekte Antwort zurⁿckerhalten kann.

Ausgabe-Header

Ihre CGI-Skripten werden normalerweise irgendeine Art von Eingabe vom Browser ⁿber den Server bekommen. Sie k÷nnen mit den erhaltenen Informationen im Inhaltsteil Ihres Skripts anfangen, was Sie wollen, solange die Ausgabe des Skripts einer speziellen Form folgt.

Als erstes sollte Ihr Skript einen speziellen Header ausgeben, der dem Server und schlie▀lich dem Browser Informationen ⁿber die restlichen Daten gibt, die Ihr Skript erzeugen wird. Der Header ist nicht wirklich Teil des Dokuments; er wird nie irgendwo angezeigt. TatsΣchlich senden Web-Server und -Browser die ganze Zeit ⁿber derartige Angaben hin und her; Sie sehen sie jedoch nie.

Es gibt drei Arten m÷glicher EintrΣge im Header, die Sie mit Skripten erzeugen k÷nnen: Content-type, Location und Status. Content-type ist der meistverbreitete, daher erklΣre ich ihn hier; ⁿber Location und Status erfahren Sie spΣter in diesem Kapitel etwas.

Sie haben den Content-type-Header bereits vorher in diesem Buch kennengelernt; Inhalts-Typen werden von den Browsern verwendet, um herauszufinden, was fⁿr einen Datentyp sie empfangen. Da Skript-Ausgabe keine Dateierweiterung hat, mⁿssen Sie dem Browser ausdrⁿcklich mitteilen, was fⁿr eine Art von Daten Sie zurⁿcksenden. Dazu setzen Sie den Content-type-Header ein.

Ein Content-type-Header besteht aus den W÷rtern ╗Content-type½, einem speziellen Code zur Beschreibung der Dateiart und einer Leerzeile, wie hier:

Content-type: text/html

In diesem Beispiel sind die auf den Header folgenden Daten vom Typ text/html; mit anderen Worten, es ist eine HTML-Datei. Jedes Datei-Format, mit dem Sie arbeiten, wenn Sie Web-PrΣsentationen erzeugen, besitzt einen entsprechenden Inhaltstyp, daher sollte das Format der Ausgabe Ihres Skripts damit zusammenpassen. Tabelle 19.1 zeigt die gebrΣuchlichen Formate und die entsprechenden Inhaltstypen.

Tabelle 19.1: Dateiformate und Inhaltstypen

Beachten Sie, da▀ die Content-type-Zeile von einer Leerzeile gefolgt werden mu▀. Der Server kann nicht erkennen, wo der Header aufh÷rt, und die Daten beginnen, wenn Sie diese Leerzeile nicht einfⁿgen.

Ausgabedaten

Der Rest, den Ihr Skript erzeugt, sind die wirklichen Daten, die Sie zum Browser schicken wollen. Der Inhalt, den Sie in diesem Teil ausgeben, sollte zu dem Inhaltstyp passen, den Sie (im Header) dem Server mitgeteilt haben, d.h. wenn Sie den Inhaltstyp text/html benutzen, dann sollte der Rest der Ausgabe eine HTML-Datei sein. Wenn Sie einen Inhaltstyp image/gif verwenden, sollte die restliche Ausgabe eine binΣre GIF-Datei sein usw., mit allen anderen Inhaltstypen.

▄bung 19.1: Probieren Sie's

Diese ▄bung Σhnelt dem einfachen Beispiel weiter vorne in diesem Kapitel - jenem, welches das Datum ausgab. Das CGI-Skript prⁿft, ob ich in meinen Web-Server eingeloggt bin, und sendet dann einen Bericht darⁿber zurⁿck, was es gefunden hat (wie es in Abbildung 19.4 gezeigt wird).

Dies ist die einfachste Form eines CGI-Skripts, das von einer Webseite durch ein einfaches Link aufgerufen werden kann, so wie hier:

<A HREF="http://www.lne.com/cgi-bin/pinglaura">Is Laura Logged in?</A>

Wenn Sie ein CGI-Skript so verknⁿpfen, wird das Skript ausgefⁿhrt, wenn Sie das Link auswΣhlen. Es erfolgt keine Eingabe in das Skript; es lΣuft einfach ab und sendet Daten zurⁿck.

ZunΣchst legen wir den Inhaltstyp der Ausgabe fest. Da dies ein HTML-Dokument sein wird, ist der Inhaltstyp text/html. Damit erstellt der erste Teil Ihres Skripts also eine Zeile mit dem Inhaltstyp und danach eine Leerzeile (vergessen Sie blo▀ die Leerzeile nicht!):

#!/bin/sh
echo "Content-type: text/html"
echo

Nun ergΣnzen wir den Rest des Skripts: den Inhalt des HTML-Dokuments, den Sie selbst innerhalb des Skripts zusammenbauen mⁿssen. Im wesentlichen ist es das Folgende, was Sie zu tun haben:

• Die HTML-Tags ausgeben, die den ersten Teil des HTML-Dokuments bilden
• Testen, ob ich online bin, und eine entsprechene Nachricht ausgeben
• Die letzten paar HTML-Tags ausgeben, die das Dokument abschlie▀en

Beginnen wir mit dem ersten HTML-Teil. Die folgenden Befehle erledigen dies in der Unix-Shell:

echo "<HTML><HEAD>"
echo "<TITLE>Is Laura There?</TITLE>"
echo "</HEAD><BODY>"

Testen Sie jetzt, ob ich im System angemeldet bin, indem Sie den who-Befehl eingeben (meine ID ist lemay), und speichern Sie das Ergebnis als die Variable ison. Wenn ich eingeloggt bin, wird die ison-Variable einen Inhalt haben, andernfalls wird sie leer sein.

ison='who | grep lemay'

Testen Sie das Ergebnis, und schicken Sie dann die entsprechende Nachricht als Teil der Skript-Ausgabe:

if [ ! -z "$ison" ]; then
echo "<P>Laura is logged in."
else
echo "<P>Laura isn't logged in."
fi

Dann schlie▀en Sie die restlichen HTML-Tags ab:

echo "</BODY></HTML>"

Sie sind fertig! Wenn Sie jetzt das Programm fⁿr sich alleine von einer Kommandozeile aus testen wⁿrden, um die Ausgabe herauszufinden, bekΣmen Sie als Ergebnis, da▀ ich nicht in Ihr System eingeloggt bin, was ungefΣhr so aussΣhe (es sei denn, natⁿrlich, da▀ ich online bin):

Content-type: text/html

<HTML><HEAD>
<TITLE>Are You There?</TITLE>
</HEAD><BODY>
<P>Laura is not logged in.
</BODY></HTML>

Sieht aus wie ein normales HTML-Dokument, nicht wahr? Das soll es auch. Die Ausgabe von Ihrem Skript wird zum Server und von da zum Browser geschickt, so da▀ es in einem Format sein sollte, das der Browser verstehen kann - in diesem Fall eine HTML-Datei.

Nun installieren Sie das Skript an der richtigen Stelle auf Ihrem Server. Dieser Schritt unterscheidet sich je nach der Plattform, auf der Sie arbeiten, und dem Server, den Sie benutzen. Meistens befindet sich auf Unix-Servern ein spezielles cgi-bin-Verzeichnis fⁿr Skripte. Kopieren Sie das Skript dorthin, und machen Sie es ausfⁿhrbar.

Nachdem Sie nun ein lauffΣhiges Skript haben, k÷nnen Sie es von einer Webseite aus aufrufen, indem Sie ein Link dorthin erzeugen, wie ich bereits erwΣhnt habe. Nur zum Vergleich hier nochmals das fertige Skript:

#!/bin/sh

echo "Content-type: text/html"
echo
echo "<HTML><HEAD>"
echo "<TITLE>Is Laura There?</TITLE>"
echo "</HEAD><BODY>"

ison=[ag]who | grep lemay[ag]

if [ ! -z "$ison" ]; then
echo "<P>Laura is logged in"
else
echo "<P>Laura isn't logged in"
fi

echo "</BODY></HTML>"

Skripten mit Parametern

CGI-Skripten sind am nⁿtzlichsten, wenn sie so allgemein wie m÷glich geschrieben werden. Wenn Sie beispielsweise herausfinden wollten, ob verschiedene Leute im System eingeklinkt sind, und dabei das Skript aus dem vorigen Beispiel anwenden wollen, mⁿssen Sie vielleicht verschiedene Versionen davon schreiben (pinglaura, pingeric, pingelsa usw.). Es wΣre sinnvoller, ein einzelnes allgemeines Skript zu schreiben und dann den Namen, den man prⁿfen will, als Parameter an das Skript zu senden.

Um Parameter (auch Argumente genannt) an ein Skript zu senden, spezifizieren Sie sie in der URL des Skripts mit einem Fragezeichen (?), das den Namen des Skripts von den Parametern trennt, und mit Pluszeichen (+), die alle individuellen Parameter voneinander trennen, so wie hier:

<A HREF="/cgi-bin/myScript?arg1+arg2+arg3">run my Script</A>

Wenn der Server die Anforderung des Skripts erhΣlt, leitet er arg1, arg2 und arg3 an das Skript als Parameter weiter. Sie k÷nnen diese Argumente dann aufteilen und im Inhalt des Skripts verwenden.

Diese Methode, Argumente an ein Skript weiterzuleiten, wird manchmal Anfrage (query) genannt, da Browser in frⁿheren Versionen dieser Suchen, die ISINDEX-Suchen genannt wurden, auf diese Weise Suchschlⁿssel weitergeleitet haben (darⁿber erfahren Sie spΣter noch mehr). Heutzutage werden die meisten Suchen mit Formularen durchgefⁿhrt, trotzdem wird diese Form der Kodierung von Parametern noch angewandt; Sie sollten damit vertraut sein, wenn Sie CGI-Skripten ÷fters verwenden.

▄bung 19.2: Prⁿfen, ob jemand online ist

Jetzt, wo Sie wissen, wie man Argumente an ein Skript weiterleitet, lassen Sie uns das pinglaura-Skript so modifizieren, da▀ es allgemeiner verwendet werden kann. Wir werden dieses Skript pinggeneric nennen.

Beginnen Sie mit dem Anfang des Skripts aus dem letzten Beispiel mit einem etwas unterschiedlichen Titel:

#!/bin/sh
echo "Content-type: text/html"
echo
echo "<HTML><HEAD>"
echo "<TITLE>Are You There?</TITLE>"
echo "</HEAD><BODY>"

Im vorigen Beispiel war der nΣchste Schritt, zu testen, ob ich online war. An dieser Stelle wird das Skript jetzt allgemein. Anstatt den Namen lemay direkt in das Skript einzufⁿgen, benutzen Sie ${1}, wobei ${1} der erste Parameter ist, ${2} der zweite, ${3} der dritte usw.

ison='who | grep "${1}"'

Jetzt mu▀ nur das restliche Skript so angepa▀t werden, da▀ es statt des im Code spezifizierten Namens das Argument verwendet:

if [ ! -z "$ison" ]; then
echo "<P>$1 is logged in"
else
echo "<P>$1 isn't logged in"
fi

Und jetzt noch die abschlie▀enden HTML-Tags:

echo "</BODY></HTML>"

Nachdem das Skript nun vollstΣndig ist, lassen Sie uns die HTML-Seite modifizieren, die das Skript aufruft. Das pinglaura-Skript wurde durch ein HTML-Link aufgerufen, und zwar folgenderma▀en:

<A HREF="http://www.lne.com/cgi-bin/pinglaura">Is Laura Logged in?</A>

Die allgemeine Version wird auf Σhnliche Weise aufgerufen, mit dem Argument am Ende der URL, wie hier (wobei diesmal eine Person namens John gesucht wird):

<A HREF="http://www.lne.com/cgi-bin/pinggeneric?john">Is John Logged in?</A>

Versuchen Sie es auf Ihrem eigenen Server, mit Ihrem eigenen Einlog-ID im URL des Skripts, um zu sehen, was fⁿr ein Ergebnis Sie erhalten.

Dem Skript weitere Informationen ⁿbergeben

Neben den an das Skript ⁿbergebenen Argumenten gibt es noch eine M÷glichkeit, einem CGI-Skript Informationen mitzuteilen (und es handelt sich dabei immer noch nicht um Formulare). Die zweite Methode ist die sogenannte Pfadinformation. Sie wird fⁿr Argumente verwendet, die zwischen den verschiedenen Aufrufen des Skripts nicht verΣndert werden k÷nnen, etwa der Name einer temporΣren Datei oder der Name einer Datei, die das Skript selbst angelegt hat. Wie Sie im nΣchsten Abschnitt, der sich mit Formularen beschΣftigt, sehen werden, k÷nnen die Argumente hinter dem Fragezeichen gemΣ▀ der Eingabe des Anwenders verΣndert werden. Die Pfadinformationen werden dazu verwendet, dem Skript weitere Informationen mitzuteilen (und Sie k÷nnen sie tatsΣchlich fⁿr beliebige Zwecke nutzen).

Um Pfadinformation zu verwenden, hΣngen Sie die Informationen, die Sie einfⁿgen wollen, ans Ende des URL des Skripts, nach dem Skript-Namen, aber vor dem ? und dem Rest des Parameters, so wie im folgenden Beispiel:

http://myhost/cgi-bin/myscript/remaining_path_info?arg1+arg2

Wenn das Skript ablΣuft, werden die Informationen aus dem Pfad in die Umgebungsvariable PATH_INFO hineingesteckt. Sie k÷nnen diese Informationen dann, wie Sie wollen, im Inhalt des Skripts verwenden.

Sagen wir mal, Sie hΣtten verschiedene Links von verschiedenen Seiten zum selben Skript. Sie k÷nnten dann die Pfad-Information verwenden, um den Namen der HTML-Datei anzuzeigen, von der das Link ausging. Wenn Sie dann mit der Verarbeitung Ihres Skripts fertig sind und eine HTML-Datei zurⁿcksenden, k÷nnten Sie ein Link von dieser Datei zurⁿck zur Seite einsetzen, von der Ihr Leser herkam.

Besondere Skriptausgaben erzeugen

In den paar Beispielen, die Sie bisher in diesem Kapitel erstellt haben, haben Sie Skripten geschrieben, die Daten ausgeben, und zwar meistens HTML-Daten, und dann wurden diese Daten zum Browser zwecks Interpretation und Darstellung geschickt.

Was aber, wenn Sie keinen neuen Datenstrom als Ergebnis einer Skript-Aktion versenden wollen? Was, wenn Sie statt dessen eine bereits existierende Seite laden m÷chten? Was, wenn Sie m÷chten, da▀ das Skript irgend etwas tut, aber gar nichts an den Browser zurⁿckmeldet?

Keine Sorge, Sie k÷nnen solche Sachen machen. Dieser Abschnitt beschreibt, wie's geht.

Mit einem anderen Dokument antworten

CGI-Ausgabe braucht kein Datenstrom zu sein. Manchmal ist es einfacher, dem Browser anzugeben, er solle zu einer anderen Seite gehen, die Sie auf Ihrem Server gespeichert haben (oder irgendeinem anderen Server; wie dem auch sei). Um diese Anweisung zu senden, verwenden Sie eine Zeile, die der folgenden Σhnelt:

Location: ../docs/final.html

Die Location-Zeile wird anstelle der normalen Ausgabe verwendet; d.h. wenn Sie Location verwenden, brauchen Sie keinen Inhaltstyp zu bezeichnen und keine weiteren Daten fⁿr die Ausgabe zu erzeugen (tatsΣchlich k÷nnen Sie gar keine anderen Daten in die Ausgabe einfⁿgen). Wie bei der Content-type-Zeile mⁿssen Sie jedoch auch auf die Location-Zeile eine Leerzeile folgen lassen.

Der Pfad-Name der Datei kann entweder ein vollstΣndiger URL sein oder ein relativer Pfad-Name. Alle relativen Pfad-Namen sind hier relativ zum Ort des Skripts selbst.

Dieser hier sucht nach dem Dokument final.html in einem Verzeichnis namens doc eine Ebene oberhalb des aktuellen Verzeichnisses:

echo Location: ../docs/final.html
echo

Keine Antwort

Bisweilen mag es fⁿr CGI-Skripten angemessen sein, gar keine Ausgaben zurⁿckzugeben. Manchmal wollen Sie einfach nur Informationen von den Lesern entgegennehmen. Sie wollen wom÷glich kein neues Dokument laden, weder durch die Ausgabe von Ergebnissen noch durch das ╓ffnen bereits vorhandener Dateien. Das Dokument, das zuvor auf dem Browser-Bildschirm angezeigt wurde, soll einfach so bleiben, wie es war.

Glⁿcklicherweise ist es ziemlich einfach, so etwas zu bewerkstelligen. Anstelle eines Headers mit Content-type oder Location benutzen Sie die folgende Zeile (wie immer wieder mit einer Leerzeile danach):

Status: 204 No Response

Dieser Status-Header meldet dem Server (und dem Browser) einen Status-Code. Der besondere Status-Code 204 wird an den Browser weitergegeben, und der Browser sollte, wenn er wei▀, was er damit machen soll, einfach gar nichts tun.

Sie brauchen, da Sie ja nicht wollen, da▀ der Browser irgend etwas damit macht, keine weiteren Ausgaben Ihres Skripts - einfach die eine Status-Zeile und eine Leerzeile. SelbstverstΣndlich sollte Ihr Skript irgend etwas tun, denn weshalb sonst beschΣftigen Sie sich ⁿberhaupt mit einem Skriptaufruf?

Skripte, die Formulare verarbeiten

Die meisten CGI-Skript-Anwendungen heutzutage sind fⁿr die Verarbeitung von Formular-Eingaben gedacht. Wenn Sie ein Skript direkt von einem Link aufrufen k÷nnen Sie dadurch nur dieses Skript mit den direktkodierten Argumenten ausfⁿhren. Formulare hingegen erlauben es, eine beliebige Menge Informationen vom Leser in das Formular eintragen zu lassen, es zum Server zurⁿckzuschicken und von einem CGI-Skript verarbeiten zu lassen. Es sind dieselben Skripte, und sie funktionieren genauso. Sie verwenden immer noch Inhaltstyp und Location-Header, um eine Antwort an den Browser zurⁿckzuschicken. Es gibt jedoch einige Unterschiede darin, wie beispielsweise die CGI-Skripten aufgerufen werden und wie die Daten vom Browser zum Server gesendet werden.

Erinnern Sie sich, da▀ die meisten Formulare aus zwei Teilen bestehen: dem HTML-Layout des Formulars und dem CGI-Skript, das die Formulardaten verarbeitet. Das CGI-Skript wird durch Attribute der Formular-Kennung aufgerufen.

Formular-Layout und Formular-Skripten

Wie Sie gestern gelernt haben, besteht jedes Formular auf dem Web aus zwei Teilen: dem HTML-Code des Formulars, der im Browser abgebildet wird, und dem Skript, das sich auf dem Server befindet und den Inhalt des Formulars verarbeitet. Beide sind durch den HTML-Code miteinander verbunden.

Das <ACTION>-Attribut innerhalb der <FORM>-Kennung enthΣlt den Namen des Skripts, das das Formular verarbeiten soll:

<FORM ACTION="http://www.myserver.com/cgi-bin/processorscript">

ZusΣtzlich zu diesem Verweis auf das Skript hat jedes Eingabefeld des Formulars (Textfelder, Options-Felder usw.) ein NAME-Attribut, welches das Formularelement benennt. Wenn die Formulardaten an das CGI-Skript weitergeleitet werden, das Sie durch ACTION bestimmt haben, werden die Namen der Tags und der Inhalt des Felds an das Skript in Form eines Name/Wert-Paars weitergeleitet. In Ihrem Skript k÷nnen Sie dann den Inhalt (den Wert) jedes Felds bekommen, indem Sie sich auf den Namen dieses Felds beziehen.

GET und POST

Ein Aspekt von Formularen, den ich gestern nicht erwΣhnt habe (h÷chstens flⁿchtig), ist das Attribut METHOD. METHOD gibt die Methode an, mit der Formulardaten vom Browser zum Server und dann zum Skript geleitet werden. METHOD kann einen von zwei Werten annehmen, GET oder POST.

GET funktioniert so wie die CGI-Skripten, die Sie im vorigen Abschnitt kennengelernt haben. Die Formulardaten werden verpackt und ans Ende der URL angehΣngt, den Sie im ACTION-Attribut als Parameter bestimmt haben. Wenn Ihr ACTION-Attribut also folgenderma▀en aussieht:

ACTION="/cgi/myscript"

und Sie die gleichen zwei Eingabe-Tags wie im vorigen Abschnitt verwenden, wird der endgⁿltige URL, der vom Browser zum Server gesendet wird, wenn das Formular ⁿbermittelt wird, ungefΣhr so aussehen:

http://myhost/cgi-bin/myscript?username=Agamemnon&phone=555-6666

Beachten Sie, da▀ diese Formatierung sich etwas von den Argumenten unterscheidet, die Sie von Hand an das CGI-Skript weitergeleitet haben; dieses Format wird URL-Kodierung genannt und spΣter in diesem Kapitel noch detailliert besprochen.

Wenn der Server Ihr CGI-Skript zur Verarbeitung Ihres Formulars ausfⁿhrt, setzt er die Umgebungsvariable QUERY_STRING auf den gesamten Eintrag, der im URL hinter dem Fragezeichen steht.

POST macht fast dasselbe wie GET, au▀er da▀ es die Daten separat vom eigentlichen Aufruf des Skripts sendet. Ihr Skript erhΣlt die Formulardaten dann ⁿber die Standardeingabe. (Einige Web-Server speichern sie statt dessen in einer temporΣren Datei, vor allem Unix-Server). Die Umgebungsvariable QUERY_STRING wird bei POST nicht verwendet.

POST stellt die sicherere Methode dar, insbesondere wenn Sie sehr viele Formulardaten erwarten. Bei der Verwendung von GET weist der Server der Variablen QUERY_STRING die kodierten Formulardaten zu, und m÷glicherweise gibt es BeschrΣnkungen, wie viele Daten Sie in dieser Variablen ablegen k÷nnen. Mit anderen Worten, wenn Sie sehr viele Formulardaten haben und GET verwenden, k÷nnte es sein, da▀ Sie einige Daten verlieren.

Bei der Verwendung von POST k÷nnen Sie beliebig viele Daten haben, weil diese als separater Stream geschickt und keiner Variablen zugewiesen werden.

URL-Kodierung

URL-Kodierung ist das Format, mit dem der Browser die Eingabe fⁿr das Formular packt, wenn er es an den Server sendet. Der Browser ermittelt alle Namen und Werte der Formulareingabe, kodiert sie als Name/Wert-Paare, ⁿbersetzt alle Zeichen, die nicht ⁿbertragen werden k÷nnen, organisiert die Daten und sendet sie - abhΣngig davon, ob Sie GET oder POST verwenden - als Teil der URL oder separat ⁿber eine direkte Verknⁿpfung an den Server. In jedem Fall erreicht die Formularseite die Server-Seite (und damit in Ihrem Skript) als Kauderwelsch, das irgendwie so aussieht:

theName=Ichabod+Crane&gender=male&status=missing&headless=yes

Die URL-Kodierung unterliegt den folgenden Regeln:

• Die einzelnen Name/Wert-Paare werden durch ein Ampersandzeichen (&) getrennt.
• Die Name/Wert-Paare aus dem Formular werden durch ein Gleichheitszeichen (=) getrennt. Wenn der Benutzer des Formulars fⁿr ein bestimmtes Tag keinen Wert eingegeben hat, erscheint der Name trotzdem in der Eingabe, aber ohne einen Wert (wie in ╗name=½).
• Alle Sonderzeichen (Zeichen, die nicht durch 7-Bit-ASCII dargestellt werden k÷nnen) werden hexadezimal kodiert, wobei ihnen ein Prozentzeichen (%) vorangestellt wird (%NN). Sonderzeichen sind unter anderem auch =, & und %, wenn sie in der eigentlichen Eingabe erscheinen.
• Leerzeichen in der Eingabe werden durch Pluszeichen (+) dargestellt.

Als erstes mu▀ Ihr Skript also alle Daten dekodieren, so da▀ Sie sie besser verwalten k÷nnen. Im nΣchsten Abschnitt lernen Sie mehrere Programme kennen, die zur Dekodierung der Formulareingabe verwendet werden k÷nnen.

Da die Formular-Eingabe an Ihr Skript in dieser URL-kodierten Form weitergeleitet wird, mⁿssen Sie sie selber dekodieren, bevor Sie sie verwenden k÷nnen. Da die Dekodierung dieser Informationen jedoch eine gew÷hnliche Aufgabe ist, gibt es dafⁿr eine Menge Werkzeuge. Es gibt keinen Grund fⁿr Sie, Ihre eigenes Dekodierungsprogramm zu schreiben, wenn Sie nicht gerade etwas sehr Ungew÷hnliches machen m÷chten. Die Dekodierungsprogramme, die bereits fertig zur Verfⁿgung stehen, k÷nnen diesen Job gut erledigen und ziehen vielleicht Dinge in Betracht, an die Sie nicht gedacht haben, z.B. wie Sie den Absturz Ihres Skripts verhindern k÷nnen, wenn jemand etwas Seltsames in Ihr Formular eingegeben hat.

Ich habe weiter hinten in diesem Kapitel einige Programme fⁿr die Dekodierung von Formulareingaben aufgefⁿhrt, aber das Programm, das ich fⁿr die Beispiele in diesem Buch verwenden werde, hei▀t uncgi. Es dekodiert die Eingabe einer Formularⁿbermittlung fⁿr Sie und erzeugt Umgebungsvariablen von den Namen/Wert-Paaren. Jede Umgebungsvariable hat denselben Namen wie der Name des Name/Wert-Paars, wobei das Prefix www_ davorgesetzt wird. Jeder Wert eines Name/Wert-Paars wird dann seiner entsprechenden Umgebungsvariablen zugeordnet. Wenn Sie z.B. ein Formular mit einem Namen darin hΣtten, der username lautet, wΣre die resultierende Umgebungsvariable, die von uncgi erzeugt wird, www_username, und der dazugeh÷rige Wert wΣre, was auch immer der Leser in dieses Formularelement eingetippt hat. Nachdem Sie die Umgebungsvariablen haben, k÷nnen Sie sie genauso testen, wie Sie es mit jeder anderen Variablen tΣten.

Sie k÷nnen den Quellcode fⁿr uncgi unter http://www.hyperion.com/~koreth/uncgi.html erhalten. Kompilieren Sie uncgi mit den Instruktionen, die dem Quellcode beiliegen, installieren Sie es in Ihrem cgi-bin-Verzeichnis, und Sie k÷nnen loslegen.

▄bung 19.3: Sag mir Deinen Namen, Teil 2

Erinnern Sie sich an das Formular, das Sie gestern erzeugt haben, das Sie nach Ihrem Namen fragt? Lassen Sie uns das Skript erzeugen, das dieses Formular verarbeitet (das Formular wird noch mal in Abbildung 19.5 gezeigt, falls Sie es vergessen haben sollten). Mit diesem Formular wⁿrden Sie Ihren Namen eintippen und dann das Formular mit dem Submit-Button ⁿbermitteln.

Die Eingabe wird zum Skript gesandt, welches ein HTML-Dokument mit einer Hallo-Nachricht darin, die Ihren Namen enthΣlt, zurⁿcksendet (siehe Abbildung 19.7).

Was wⁿrde passieren, wenn Sie bei der Aufforderung ╗Sag mir Deinen Namen½ nichts eingΣben? Das Skript wⁿrde Ihnen die Antwort ╗Du hast keinen Namen?½ senden (siehe Abbildung 19.6).

VerΣndern Sie den HTML-Code des Formulars

In den gestrigen Beispielen benutzten wir ein Testprogramm namens post-query als Skript, um das ACTION-Attribut der Formular-Kennung aufzurufen. Jetzt, da wir mit echten Skripten arbeiten, werden wir das Formular dahingehend modifizieren, da▀ es auf ein echtes CGI-Skript hinweist. Der Wert von ACTION kann ein vollstΣndiger URL oder ein relativer Pfad-Name zu einem Skript auf Ihrem Server sein. So wⁿrde beispielsweise die folgende <FORM>-Kennung ein Skript namens form-name in einem cgi-bin-Verzeichnis eine Ebene ⁿber dem aktuellen Verzeichnis aufrufen:

<FORM METHOD="post" ACTION="../cgi-bin/form-name.cgi">
</FORM>

Wenn Sie uncgi benutzen, um Formular-Eingaben zu dekodieren, so wie ich es in den Beispielen hier tue, sehen die Dinge etwas anders aus. Damit uncgi richtig funktioniert, rufen Sie es zuerst auf und hΣngen dann den Namen des eigentlichen Skripts hintendran, als ob uncgi ein Verzeichnis wΣre:

<FORM METHOD="post" ACTION="../cgi-bin/uncgi/form-name.cgi">
</FORM>

Abgesehen von dieser einen VerΣnderung brauchen Sie den HTML-Code fⁿr das Formular nicht anzurⁿhren. Lassen Sie uns deshalb nun mit dem Skript weitermachen, das das Formular verarbeitet.

Das Skript

Das Skript, mit dem Sie die Formulareingabe verarbeiten, ist meistens ein CGI-Skript, genauso wie diejenigen, die Sie bisher in diesem Kapitel erzeugt haben. Es gelten dieselben Regeln fⁿr Content-type-Header und fⁿr das Zurⁿcksenden der Daten zum Browser.

Der erste Schritt in einem Formular-Skript besteht darin, die Angaben zu dekodieren, die Ihrem Skript durch die POST-Methode ⁿbermittelt wurden. Da wir in unserem Beispiel jedoch uncgi benutzen, um die Formulareingabe zu dekodieren, ist dieser Teil der Arbeit bereits erledigt. Erinnern Sie sich, wie Sie uncgi in das ACTION-Attribut Ihres Formulars gesteckt haben, gefolgt vom Namen Ihres Skripts? Was dort passiert, ist folgendes: Wenn die Formulareingabe ⁿbermittelt wird, leitet der Server diese Eingabe zum uncgi-Programm weiter, welches dann die Formulareingabe fⁿr Sie dekodiert und danach Ihr Skript aufruft, wenn alles bereits dekodiert ist. Wenn also Ihr Skript beginnt, stehen alle Name/Wert-Paare bereits zu Ihrer Verfⁿgung.

Lassen Sie uns fortfahren, indem wir die normalen CGI-Header und den HTML-Code, der die Seite einleitet, angeben:

echo Content-type: text/hvml
echo
echo "<HTML><HEAD>"
echo "<TITLE>Hello</TITLE>"
echo "</HEAD><BODY>"
echo "<P>"

Jetzt kommt das Kernstⁿck des Skripts. Sie mⁿssen sich mit zwei Verzweigungen abgeben: die eine weist den Leser darauf hin, da▀ er keinen Namen eingegeben habe, und die andere sagt ╗hallo½, wenn er es tut.

Der Wert des Elements theName, wie Sie das erste Textfeld in Ihrem Formular genannt haben, wird innerhalb der www_theName-Umgebungsvariablen angegeben. Indem Sie einen einfachen Bourne Shell Test verwenden (-z), k÷nnen Sie herausfinden, ob diese Umgebungsvariable leer ist, und dann eine angemessene Antwort in die Ausgabe einfⁿgen:

if [ ! -z "$WWW_theName" ]; then
echo "Hello, "
echo $WWW_theName
else
echo "You don't have a name?"
fi

Schlie▀lich fⁿgen Sie das letzte bi▀chen HTML-Code ein, um das ╗go back½-Link einzusetzen. Dieser URL zeigt auf den URL des originalen Formulars zurⁿck (das hier name1.html hei▀t und sich in einem Verzeichnis oberhalb von cgi-bin befindet):

echo "</P><P><A HREF="../lemay/name1.html">Go Back</A></P>"
echo "</BODY></HTML>"

Und damit wΣren wir soweit! Mehr ist da nicht dran. Der schwierige Teil ist, zu lernen, wie man CGI-Skripten erzeugt; sie dann mit den Formularen zu verknⁿpfen, ist einfach. Auch wenn Sie vielleicht verwirrt sind und es nicht so ganz mitgekriegt haben, bleiben Sie dran; morgen k÷nnen Sie noch einen ganzen Haufen Beispiele ansehen und durcharbeiten.

Probleml÷sungen

Im folgenden finden Sie einige der hΣufigsten Probleme mit CGI-Skripten und entsprechende L÷sungsvorschlΣge.

• Der Inhalt des Skripts wird angezeigt, aber nicht ausgefⁿhrt.

Haben Sie Ihren Server so konfiguriert, da▀ er CGI-Skripten akzeptiert? Sind Ihre Skripten im richtigen CGI-Verzeichnis abgelegt (normalerweise ist das cgi-bin)? Wenn Ihr Server CGI-Dateien mit der Dateinamenerweiterung .cgi erlaubt, hat Ihr Skript diese Erweiterung?

• 
  

• Error 500: Server doesn't support POST

Diesen Fehler erhalten Sie von Formularen, die die POST-Methode einsetzen. Er bedeutet oft, da▀ Sie entweder die CGI-Skripten auf Ihrem Server nicht eingerichtet haben oder da▀ Sie versuchen, auf ein Skript zuzugreifen, das nicht in einem CGI-Verzeichnis enthalten ist (siehe oben).

• 
  

  Dies kann jedoch auch bedeuten, da▀ Sie den Pfad fⁿr das Skript falsch geschrieben haben. ▄berprⁿfen Sie den Pfad-Namen in Ihrem Formular. Falls er korrekt ist, stellen Sie sicher, da▀ sich Ihr Skript im richtigen CGI-Verzeichnis (normalerweise cgi-bin) befindet und da▀ es die Erweiterung .cgi besitzt (falls Ihr Server das unterstⁿtzt).

   

• Document contains no data

Stellen Sie sicher, da▀ Sie zwischen Ihren Headern und den Skriptdaten eine Leerzeile eingefⁿgt haben.

• 
  

• Error 500: Bad Skript Request

Stellen Sie sicher, da▀ Ihr Skript ausfⁿhrbar ist (unter Unix: Stellen Sie sicher, da▀ Sie fⁿr das Skript chmod + x IhrSkript.cgi gesetzt haben). Prⁿfen Sie das, indem Sie es von der Befehlszeile aus aufrufen.

• 
  

CGI-Variablen

CGI-Variablen sind besondere Variablen, die in einer Umgebung verwendet werden, wenn ein CGI-Skript aufgerufen wird. Sie k÷nnen alle diese Variablen in Ihr Skript einsetzen, wie Sie m÷chten. Tabelle 19.2 gibt eine Zusammenfassung dieser Variablen.

Tabelle 19.2: CGI-Umgebungsvariablen

Programme zum Dekodieren

Der wichtigste Unterschied zwischen einem einfachen CGI-Skript und einem CGI-Skript, das ein Formular verarbeitet, ist, da▀ Sie fⁿr das letztere eine Methode zur Decodierung der Daten ben÷tigen, die Sie vom Formular in URL-kodiertem Format zurⁿckerhalten. Weil das aber jeder mu▀, der CGI-Skripten zur Verarbeitung von Formularen verwendet, gibt es Programme, die es fⁿr Sie erledigen und die die Name/Wert-Paare in etwas umwandeln, mit dem Sie einfacher weiterarbeiten k÷nnen. Ich bevorzuge zwei Programme: uncgi fⁿr universelle Aufgaben und cgi-lib.pl, eine Perl-Bibliothek, die Sie zu Rate ziehen k÷nnen, wenn Sie Skripten in Perl schreiben. Sie k÷nnen jedoch Ihre eigenen Programme schreiben, wenn Ihnen die hier erwΣhnten nicht ausreichen.

Es gibt auch Programme, die Daten dekodieren, die formularbasiert hochgeladen wurden, obwohl die Auswahl da nicht so gro▀ ist. Am Ende dieses Abschnitts werde ich einige erwΣhnen, die ich dafⁿr gefunden habe.

uncgi

uncgi von Steven Grimm ist ein C-Programm, das die Formulareingaben fⁿr Sie dekodiert. Informationen sowie den Quellcode fⁿr uncgi erhalten Sie unter http://www.hyperion.com/~koreth/uncgi.html.

Sie sollten uncgi im Verzeichnis cgi-bin installieren. Stellen Sie sicher, da▀ Sie Ihr Makefile entsprechend angepa▀t haben, bevor Sie die Datei kompilieren, so da▀ es auf dieses Verzeichnis auf Ihrem System zeigt und Ihre Skripten gefunden werden.

Wenn Sie uncgi in einem Formular einsetzen wollen, mⁿssen Sie das ACTION-Attribut im FORM-Tag leicht modifizieren. Statt Ihr CGI-Skript direkt in ACTION aufzurufen, rufen Sie uncgi auf, wobei der Name des Skripts an den Aufruf angehΣngt wird. Wenn Sie z.B. ein CGI-Skript namens sleep2.cgi aufrufen wollten, wⁿrden Sie normalerweise so verfahren:

<FORM METHOD=POST ACTION="http://www.myserver.com/cgi-bin/sleep2.cgi">

Wenn Sie uncgi verwenden wⁿrden, wⁿrde das so aussehen:

<FORM METHOD=POST ACTION="http://www.myserver.com/cgi-bin/uncgi/sleep2.cgi">

Das Programm uncgi liest die Formulareingabe entweder von der GET- oder von der POST-Eingabe aus (das wird automatisch ermittelt), decodiert sie und erzeugt einige Variablen mit demselben Namen, den auch Werte jedes NAME-Attributs haben, wobei www_ davorgesetzt wird. Wenn z.B. Ihr Formular ein Textfeld mit dem Namen derName enthielte, wΣre die uncgi-Variable mit dem Wert fⁿr derName www_derName.

Wenn es in der Eingabe mehrere Name/Wert-Paare mit demselben Namen gibt, erzeugt uncgi nur eine Umgebungsvariable mit durch Doppelkreuze (#) getrennten Werten. Wenn die Eingabe beispielsweise die Name/Wert-Paare shopping=butter, shopping=milk und shopping=beer enthΣlt, enthΣlt die resultierende Umgebungsvariable FORM_shopping den Wert butter#milk#beer. Es bleibt Ihnen ⁿberlassen, diese Information in Ihrem Skript korrekt zu verarbeiten.

cgi-lib.pl

Das Paket cgi-lib.pl von Steve Brenner enthΣlt eine Menge Routinen fⁿr die Sprache Perl, die Sie bei der Verwaltung von Formulareingaben unterstⁿtzen sollen. Es kann Eingaben von GET oder POST entgegennehmen und sie in eine Perl-Liste oder ein assoziatives (wechselseitiges) Array einfⁿgen. Neuere Versionen k÷nnen auch Dateien verarbeiten, die von Formularen hochgeladen wurden. Informationen ⁿber cgi-lib.pl (und den Quellcode) erhalten Sie unter http://www.bio.cam.ac.uk/cgi-lib. Wenn Sie Ihre Formulareingaben mit Hilfe von Perl verarbeiten wollen, sollten Sie sich die Bibliothek cgi-lib.pl unbedingt besorgen.

Um cgi-lib.pl zu verwenden, besorgen Sie sich den Quellcode unter der im letzten Abschnitt beschriebenen URL-Adresse und legen ihn in Ihrem Verzeichnis mit den Perl-Bibliotheken ab. Anschlie▀end geben Sie in Ihrem Perl-Skript die folgende Zeile an:

require 'cgi-lib.pl';

um die Unterroutinen aus der Bibliothek in Ihr Skript aufzunehmen.

Es gibt zwar in cgi-lib.pl mehrere Unterroutinen fⁿr die Verwaltung von Formularen, aber die wichtigste davon ist ReadParse. ReadParse liest GET- oder POST-Eingaben und speichert die Name/Wert-Paare unverΣndert in einem assoziativen Perl-Array. Normalerweise wird es in Ihrem Perl-Skript etwa folgenderma▀en aufgerufen:

&ReadParse(*in);

Dieses Beispiel verwendet den Arraynamen in, Sie k÷nnen aber einen beliebigen Namen wΣhlen.

Nachdem die Formulareingabe decodiert wurde, k÷nnen Sie in Ihrem Perl-Skript die Name/Wert-Paare durch den Zugriff auf die Namenskomponente lesen und verarbeiten, etwa wie folgt:

print $in{'theName'};

Dieses Beispiel gibt den Wert des Paares mit dem Namen theName aus.

Wenn es mehrere Name/Wert-Paare mit demselben Namen gibt, trennt cgi-lib.pl die Werte im Array durch Nullzeichen (\0). Es bleibt Ihnen ⁿberlassen, diese Information in Ihrem Skript korrekt zu verarbeiten.

Dekodieren der Eingabe hochgeladener Dateien

Da das formularbasierte Hochladen von Dateien ein neueres Feature darstellt, das eine unterschiedliche Methode der Formulareingabe erfordert, gibt es nur wenige Programme, die fⁿr Sie die Eingabe dekodieren, die Sie von einem Formular erhalten, von dem aus lokale Dateien hochgeladen wurden.

Neuere Versionen von cgi-lib.pl kommen mit dem Hochladen von Dateien sehr gut zurecht, indem sie sie in assoziative Arrays kodieren, ohne da▀ Sie noch irgendetwas dazu tun mⁿ▀ten. Wenden Sie sich an die Homepage von cgi-lib.pl fⁿr zusΣtzliche Informationen: http://www.bio.cam.ac.uk/cgi-lib/.

Eine andere Bibliothek fⁿr die Behandlung von CGI-Daten in Perl 5 names CGI.pl, die Ihnen ebenfalls beim Hinaufladen von Dateien behilflich ist, finden Sie unter http://valine.ncsa.uiuc.edu/cgi_docs.html.

Formulareingaben selbst decodieren

Die meisten Leute ⁿberlassen die Decodierung von Formulareingaben einem der hier beschriebenen Programme. Falls Ihnen keines dieser Programme zur Verfⁿgung steht, Ihr System diese Programme nicht unterstⁿtzt oder Sie glauben, Sie k÷nnten ein besseres schreiben, finden Sie hier einige nⁿtzliche Informationen.

Als erstes sollte Ihr Decoder-Programm prⁿfen, ob die Formulareingabe mit der POST- oder der GET-Methode gesendet wurde. Das ist aber ganz einfach. Die CGI-Umgebungsvariable REQUEST_METHOD, die vom Server vor dem Aufruf Ihres Programms gesetzt wird, gibt an, welche Methode verwendet wurde und wie Sie weiterarbeiten sollten.

Wenn die Formulareingabe ⁿber die GET-Methode an den Server gesendet wird, wird sie in der Umgebungsvariablen QUERY_STRING abgelegt.

Wenn die Formulareingabe ⁿber die POST-Methode an den Server gesendet wird, wird sie ⁿber die Standardeingabe an Ihr Skript geschickt. Die Umgebungsvariable CONTENT_LENGTH gibt an, wie viele Bytes der Browser ⁿbertragen hat. Sie sollten in Ihrem Decoder sicherstellen, da▀ nur die in CONTENT_LENGTH enthaltene Anzahl an Bytes verarbeitet wird. Einige Browser schlie▀en die Standardeingabe m÷glicherweise nicht fⁿr Sie ab.

Ein typisches Decoder-Skript geht folgenderma▀en vor:

• Trennen der einzelnen Name/Wert-Paare (durch &)
• Trennen des Namens vom Wert (durch =)

Wenn es mehrere Namensschlⁿssel mit unterschiedlichen Werten gibt, sollten Sie eine Methode bereithalten, all diese Werte aufzubewahren.

• Ersetzen Sie alle Pluszeichen durch Leerzeichen.
• Decodieren Sie die Hexadezimalzahlen (%NN) in ihre ASCII-─quivalente auf Ihrem System.

Sind Sie daran interessiert, den Input vom Dateihochladen zu dekodieren? Dann mⁿssen Sie anders vorgehen. Vor allem wird die Eingabe, die Sie von solchen formularbasierten Dateiⁿbertragungen bekommen, mit dem Standard von mehrteiligen MIME-Botschaften ⁿbereinstimmen, so da▀ Sie es mit vielen verschiedenen Datentypen zu tun haben. Wenn Sie das interessiert, sollten Sie sich die Spezifikationen fⁿr formularbasiertes Hochladen von Dateien ansehen, die mehr Einzelheiten erklΣren werden. Sie finden diese Angaben unter ftp://ds.internic.net/rfc/rfc1867.txt.

Non-processed Header-Skripts - (NPH-Skripts)

Wenn Sie den in diesem Abschnitt vorgestellten Grundregeln beim Schreiben eines CGI-Skripts gefolgt sind, wird die Ausgabe Ihres Skripts (Header und gegebenenfalls Daten) vom Server gelesen und ⁿber das Netzwerk an den Browser zurⁿckgeschickt. In den meisten FΣllen ist das so in Ordnung, weil der Server alle notwendigen ▄berprⁿfungen ausfⁿhren und Ihren Headern seine eigenen hinzufⁿgen kann.

In einigen FΣllen will man jedoch den Server umgehen und die Ausgabe direkt an den Browser senden. Das k÷nnte zum Beispiel sein, wenn Sie die Ausgabe an den Browser beschleunigen wollen oder wenn Daten an den Browser geschickt werden sollen, die der Server nicht versteht. Bei den meisten Formularen und CGI-Skripten brauchen Sie jedoch kein Skript, das dies tut.

CGI-Skripten fⁿr diesen Zweck hei▀en NPH-Skripts (non-processed headers, nichtausgewertete Header). Wenn Sie ein NPH-Skript ben÷tigen, Σndern Sie einfach Ihr normales Skript leicht ab:

• Das Skript sollte das PrΣfix nph- haben, beispielsweise nph-pinglaura oder nph-fixdata.
• Ihr Skript mu▀ statt der Header fⁿr Inhalt, Position und Status zusΣtzliche HTTP-Header senden.

Die Header stellen die offensichtlichste VerΣnderung dar, die Sie an Ihrem Skript vornehmen mⁿssen. Insbesondere sollte der erste ausgegebene Header ein HTTP/1.0-Header mit einem Statuscode sein, etwa folgenderma▀en:

HTTP/1.0 200 OK

Dieser Header mit dem Statuscode 200 bedeutet ╗alles in Ordnung, die Daten sind unterwegs½. Ein anderer m÷glicher Statuscode wΣre

HTTP/1.0 204 No Response

Wie Sie in diesem Abschnitt bereits erfahren haben, hei▀t das, da▀ keine Daten von Ihrem Skript zurⁿckgeschickt werden, der Browser also keine Aktion ausfⁿhren soll (etwa den Versuch, eine neue Seite zu laden).

Als zweiten Header sollten Sie wahrscheinlich den Server-Header aufnehmen. Es gibt gewisse Unstimmigkeiten darⁿber, ob dieser Header wirklich erforderlich ist, aber auf alle FΣlle ist es nicht schlecht, ihn aufzunehmen. Schlie▀lich geben Sie durch die Verwendung eines NPH-Skripts vor, ein Server zu sein, dann kann es nicht schaden, diesen Header zu verwenden.

Der Server-Header gibt einfach nur die Version des ausgefⁿhrten Servers an, wie im folgenden Beispiel gezeigt:

Server: NCSA/1.3
Server: CERN/3.0pre6

Nach diesen beiden Headern folgen alle anderen Header, die fⁿr Ihr Skript notwendig sind, unter anderem fⁿr Inhalt und Position. Der Browser ben÷tigt diese Informationen immer noch, damit er verstehen kann, wie er die gesendeten Daten behandeln soll.

Auch hier gilt, da▀ Sie die NPH-Skripten gr÷▀tenteils nicht brauchen. Normale CGI-Skripten sollten in der Regel ausreichend sein.

<ISINDEX>-Skripten

Um die Diskussion ⁿber CGI abzuschlie▀en, lassen Sie uns ⁿber das reden, was <ISINDEX>-Suche genannt wird. Die Verwendung des <ISINDEX>-Tags war die Methode, mit der Browser in den Anfangszeiten des Web Informationen (meistens Suchschlⁿssel) an den Server sendeten. Suchen mit <ISINDEX> kommt heutzutage fast nicht mehr vor; statt dessen werden Formulare angewendet, da diese viel flexibler sowohl im Layout als auch in der Verschiedenheit ihrer Elemente und in den zu ihrer Verarbeitung anwendbaren Skripten sind. Da ich aber eine VollstΣndigkeitsfanatikerin bin, werde ich hier auch noch eine kurze Beschreibung der Funktionsweise von <ISINDEX>-Suchen geben.

<ISINDEX>-Suchen sind CGI-Skripte, die Argumente annehmen, genauso wie die Skripte, die Sie bereits in diesem Kapitel geschrieben haben, um herauszufinden, ob jemand online war. Das CGI-Skript fⁿr eine <ISINDEX>-Suche funktioniert auf zwei Arten:

• Wenn das Skript ohne Argumente aufgerufen wird, sollte das zurⁿckgesendete HTML den Leser nach Suchschlⁿsseln fragen. Dann wenden Sie die <ISINDEX>-Kennung an, um Ihrem Leser zu erm÷glichen, die Suchschlⁿssel einzugeben (dies war vor der Einfⁿhrung von Formularen).
• Wenn der Leser die Suchschlⁿssel ⁿbermittelt, wird das ISINDEX-Skript wieder aufgerufen, wobei die Suchschlⁿssel als dessen Argumente auftreten. Ihr ISINDEX-Skript verarbeitet dann diese Argumente irgendwie und sendet die entsprechende HTML-Datei zurⁿck.

Was macht <ISINDEX> also? Es schaltet die Suche in dem Browser ein, der das entsprechende Dokument liest. Je nach Browser kann dies das Erscheinen eines Such-Buttons im Browser-Fenster zur Folge haben (siehe Abbildung 19.8). Bei neueren Browsern kann es das Auftauchen eines Eingabefelds auf der Seite bewirken (siehe Abbildung 19.9). Der Leser kann dann die Zeichenfolge eingeben, nach der er sucht, und danach die Eingabetaste drⁿcken oder den Button anklicken, um die Anfrage an den Server zu ⁿbermitteln.

GemΣ▀ den HTML-2.0-Spezifikationen geh÷rt das <ISINDEX>-Tag in die <HEAD>-Sektion des HTML-Dokuments (es ist eines der wenigen Tags, das in den Kopfteil geh÷rt - <TITLE> ist das andere offensichtliche Beispiel). In Σlteren Browsern, wo es nur einen einzigen Ort fⁿr die Suchaufforderung gab, ergab dies Sinn, da weder die Suchaufforderung noch das <ISINDEX>-Tag ein Teil der eigentlichen Daten des Dokuments war. Da jedoch neuere Browser das Eingabefeld auf der HTML-Seite selber darstellen, ist es nⁿtzlich, wenn man <ISINDEX> in den Inhaltsteil des Dokuments stecken kann, so da▀ man kontrollieren kann, wo auf der Seite das Eingabefeld erscheint (wenn es sich im <HEAD> befindet, wird es ganz oben auf der Seite dargestellt). Die meisten Browser akzeptieren das <ISINDEX>-Tag inzwischen an beliebigen Stellen innerhalb eines HTML-Dokuments und werden auch das Eingabefeld dort erscheinen lassen, wo das Tag sitzt.

Schlie▀lich gibt es eine HTML-Erweiterung zum <ISINDEX>-Tag, die inzwischen Bestandteil von HTML 3.2 ist und es Ihnen erlaubt, die Suchaufforderung zu definieren. Auch hier gab es bei Σlteren Browsern eine EinschrΣnkung: Die Suchaufforderung war unverΣnderbar (es war meistens etwas Σhnlich Verwirrendes wie: ╗This is a searchable index. Enter keywords.½). Mit dem neuen PROMPT-Attribut zu <ISINDEX> k÷nnen Sie die Zeichenfolge festlegen, mit der das Eingabefeld angezeigt wird, so wie im folgenden Codebeispiel. Abbildung 19.10 zeigt das Ergebnis dieses Tags in Netscape.

<P> To search for a student in the online directory,
enter the name (last name first):
<ISINDEX PROMPT="Student's name: ">

<ISINDEX> ist nur im Zusammenhang mit einer ISINDEX-Suche nⁿtzlich. Obwohl Sie es in jedes beliebige HTML-Dokument stecken k÷nnen, wird es wirkungslos bleiben, wenn diese Seite nicht ursprⁿnglich von einem CGI-Skript erzeugt wurde.

Meistens ist es eine wesentlich einfachere Methode, den User um Informationen zu bitten, nΣmlich HTML-Formulare zu erzeugen.

Zusammenfassung

Gateway-Skripten, manchmal auch Server-Skripten oder CGI-Skripten genannt, erm÷glichen es, Programme auf dem Server ablaufen zu lassen und dabei ╗auf die Schnelle½ HTML- oder andere Dateien zu erzeugen.

Dieses Kapitel behandelt die Grundlagen der Erzeugung von CGI-Skripten: sowohl einfache Skripte, als auch Skripten zur Verarbeitung von Formularen, einschlie▀lich der speziellen Header, die Sie in Ihren Skripten verwenden, den Unterschied zwischen GET und POST bei der Formulareingabe und wie Sie die Informationen, die Sie von der Formulareingabe bekommen, dekodieren. Au▀erdem erhielten Sie Extrainformationen ⁿber Pfadinformation, URL-Kodierung, <ISINDEX>-Suchen und die verschiedenen CGI-Variablen, die Sie in Ihren CGI-Skripten verwenden k÷nnen. An diesem Punkt sollten Sie dazu in der Lage sein, CGI-Skripten zu schreiben, um so gut wie alles zu erreichen.

Fragen und Antworten

Frage:

Was ist, wenn ich gar nicht programmieren kann? Kann ich trotzdem CGI-Skripten benutzen?

Antwort:

Wenn Sie ⁿber einen kommerziellen Internet-Anbieter Zugang zum Web haben, k÷nnen Sie vielleicht von ihm Hilfe bei Ihren CGI-Skripten erhalten (gegen Gebⁿhr, versteht sich). Doch wenn Sie ein wenig programmieren k÷nnen, aber bei dem, was Sie tun, unsicher sind, so gibt's ⁿblicherweise als Teil der Server-Distribution oder an derselben FTP-Quelle viele Beispiele fⁿr die Plattform, auf der Sie arbeiten. Schauen Sie in die Dokumentation des Servers, mit dem Sie arbeiten; dort sind hΣufig Hinweise auf weitere Informationsquellen zu finden. Es k÷nnte fⁿr die Operation, die Sie durchfⁿhren wollen, sogar schon ein fertiges Skript geben, das Sie mit wenigen ─nderungen benutzen k÷nnen. Seien Sie aber vorsichtig, Sie k÷nnen schnell bis ⁿber den Hals in den Schlamassel geraten, wenn Sie nicht wissen, was Sie tun.

Frage:

Mein Web-Server besitzt ein cgi-bin-Verzeichnis, jedoch habe ich darauf keinen Zugriff. Deshalb erstellte ich mein eigenes cgi-bin-Verzeichnis und legte mein Skript dort hinein, konnte es jedoch nicht von meinen Webseiten her aufrufen. Was habe ich falsch gemacht?

Antwort:

Web-Server mⁿssen auf spezielle Weise konfiguriert werden, um CGI-Skripten auszufⁿhren, und das bedeutet meistens, da▀ bestimmte Verzeichnisse oder Dateien markiert werden mⁿssen, die als Skripten agieren sollen. Sie k÷nnen nicht einfach ein Verzeichnis oder eine Datei mit einer speziellen Erweiterung erzeugen, ohne zu wissen, wie Ihr Web-Master den Server konfiguriert hat; meistens werden Sie falsch liegen, und Ihre Skripten werden nicht funktionieren. Bitten Sie Ihren Web-Master bei der Installation Ihrer Skripten um Hilfe.

Frage:

Mein Web-Master behauptet, ich k÷nne einfach ein cgi-bin-Verzeichnis in meinem Home-Verzeichnis erzeugen, meine Skripten dort installieren und sie dann mit einer speziellen URL namens cgiwrap aufrufen. Sie haben diese Art pers÷nlicher cgi-bin-Verzeichnisse nicht erwΣhnt.

Antwort:

cgiwrap  ist ein hⁿbsches Programm, das eine sichere Umhⁿllung fⁿr CGI-Skripten bietet und es Anwendern von ÷ffentlichen Unix-Systemen erm÷glicht, ihre eigenen pers÷nlichen CGI-Verzeichnisse zu besitzen. Ihr Web-Master mu▀ cgiwrap jedoch speziell fⁿr Ihren Server einrichten und konfigurieren, bevor Sie es anwenden k÷nnen. Herzlichen Glⁿckwunsch, wenn Ihr Web-Master die Verwendung von cgiwrap erlaubt hat. Dann werden CGI-Skripten fⁿr Sie leicht zu installieren und anzuwenden sein. Wenn Sie selbst der Web-Master sind und mehr herausfinden m÷chten, besuchen Sie http://wwwcgi.umr.edu/~cgiwrap/.

Frage:

Meine Skripten funktionieren nicht!

Antwort:

Haben Sie den Abschnitt ⁿber Probleml÷sungen mit den Fehlermeldungen und ihren m÷glichen Abhilfen durchgesehen? Ich habe dort die meisten gew÷hnlichen Probleme, die auftreten k÷nnen, behandelt.

Frage:

Mein Web-Anbieter will mir keinen Zugriff auf das cgi-bin-Verzeichnis erlauben. Absolut unter keinen UmstΣnden. Ich m÷chte aber unbedingt Formulare verwenden. Gibt es da noch irgendeine M÷glichkeit?

Antwort:

Es gibt noch eine M÷glichkeit; sie hei▀t Mailto-Formular. Bei Mailto-Formularen benutzen Sie einen Mailto-URL mit Ihrer E-Mail-Adresse im ACTION-Teil des Formulars, und zwar folgenderma▀en:

<FORM METHOD=POST ACTION="mailto:lemay@lne.com"> ... </FORM>

Wenn dann das Formular von Ihrem Leser eingesendet wird, wird der Inhalt des Formulars Ihnen per E-Mail zugeschickt (oder zumindest dann, wenn Sie statt meiner E-Mail-Adresse Ihre eigene im mailto einsetzen). Sie ben÷tigen dazu keine Server-Skripte.

• 
  

  Es gibt bei dieser L÷sung jedoch einige bedeutende Probleme. Das erste ist, da▀ die E-Mail, die Sie bekommen werden, alle Formulareingaben in kodierter Form enthalten wird. Manchmal k÷nnen Sie es trotzdem lesen, es ist aber alles durcheinandergeworfen. Um ums URL-Dekodieren herumzukommen, gibt es spezielle Programme, die die Eingabe aus den Mailto-Formularen fⁿr Sie dekodieren. Sehen Sie sich http://homepage.interaccess.com/~arachnid/mtfinfo.html an, wenn Sie mehr Informationen m÷chten.

  
  

  Das zweite Problem mit Mailto-Formularen ist, da▀ sie keinen Hinweis darauf geben, da▀ das Formular abgesendet wurde. Es wird keine Seite zurⁿckgeschickt, die sagt: ╗Danke, ich habe die Formulareingabe erhalten.½ Ihre Leser werden einfach den ▄bermittlungs-Button anklicken, und es wird so aussehen, als geschΣhe nichts. Da es kein Feedback an Ihre Leser gibt, geben sie dieselbe Information vielleicht nochmal ein. Es k÷nnte hilfreich sein, auf der Seite eine Warnung an Ihre Leser zu richten, um sie wissen zu lassen, da▀ sie kein Feedback erhalten werden.

  
  

  Das drittte Problem mit Mailto-Formularen ist, da▀ sie nicht von allen Browsern unterstⁿtzt werden, so da▀ Ihre Formulare nicht von allen Lesern verwendet werden k÷nnen. Die meisten wichtigen kommerziellen Browser unterstⁿtzen jedoch Mailto-Formulare.

  
  

Frage:

Ich schreibe ein Decoder-Programm fⁿr die Formulareingabe. Das letzte Name/Wert-Paar in meiner Liste enthΣlt lauter Mⁿll.

Antwort:

Lesen Sie wirklich nur die Anzahl der Bytes aus, die in der Umgebungsvariablen CONTENT_LENGTH  angegeben sind? Prⁿfen Sie diesen Wert ab, und beenden Sie das Auslesen, wenn Sie das Ende erreicht haben, um nicht zu weit zu lesen. Nicht alle Browser schlie▀en die Standardeingabe fⁿr Sie ab.

Copyright ⌐1998 by SAMS, einem Imprint der Markt&Technik Buch- und Software-Verlag GmbH.
Elektronische Fassung des Titels: HTML 4 in 14 Tagen, ISBN: 3-8272-2019-X