Auf dem Server sollen die Eingabedaten aus dem Formular mit Hilfe eines Scriptes verarbeitet werden. Um dieses zu ermöglichen, muß der Server erst speziell konfiguriert werden, denn normale HTTP-Server erlauben es aus Sicherheitsgründen nicht, daß Programme auf ihnen gestartet werden können. Es muß ein Verzeichnis auf dem Server als "ausführbares" EXEC-CGI Verzeichnis definiert werden. Dieses Verzeichnis wird aber aus Sicherheitsgründen nur über virtuelle Pfade angesprochen. Die ScriptAlias-Direktive verbindet dann erst den physischen mit dem logischen Pfadnamen. Das physische Verzeichnis beinhaltet die Script-Files, die dann nicht wie normale HTML-Seiten zum Client gesandt werden, sondern anstatt dessen ausgeführt, und erst deren Ergebnisse als HTML-Seiten zum Client gesandt werden.
Bevor jedoch die eigentliche Verarbeitung beginnen kann, müssen die Formulareingabedaten, die vom WWW-Browser codiert worden sind, auf dem Server wieder entcodiert und dem CGI-Skript zur Verfügung gestellt.
Die Angabe aus dem Formular method= gab dazu die Methode an, mit der die Formulardaten an den Server-Rechner übermittelt wurden. Möglich waren die Varianten method=post oder method=get.
die Daten des ausgefüllten Formulars werden an die URL-Angabe angehängt (URL-Encodeing) und dann vom Server in der Standard-Umgebungsvariablen QUERY_STRING gespeichert. Das CGI-Programm muß den Inhalt dieser Umgebungsvariablen auslesen und verarbeiten.
die Daten des ausgefüllten Formulars werden als eigenständiger Datenstrom an den Server-Rechner gesandt. Der Server stellt die Daten dem CGI-Programm über die Standardeingabe "stdin" bereit, und das Skript muß die Daten wie eine Benutzereingabe behandeln, die auf der Kommandozeile gemacht wurde. Da in diesem Fall kein EndOfFile-Signal (EOF) gesendet wird, muß das CGI- Programm die Standard-Umgebungsvariable CONTENT_LENGTH auslesen, um die Länge der übermittelten Daten und damit deren Ende zu ermitteln.
HTML-Formulare werden als Name/Wert-Paare zum CGI-Programm gesandt:
name1=value1&name2=value2&name3=value3&name4=value4& etc...
Beim Parsen wird der Datenstrom in Namen- und Wertfelder wie folgt aufgespalten:
Sind die Eingabedaten erst einmal in Namen und Werte aufgespalten, müssen die Sonderzeichen wieder in die ASCII-Zeichen umgewandelt werde:
Bei einem DOS/Windows-Server wird das Parsen z.B. wie folgt realisiert :
Zahlreiche Informationen über sich selbst und über den vom Client empfangenen Request vermittelt der Server dem CGI-Skript in Form von Environment-Variablen. CGI spezifiziert die Namen und Inhalte dieser Variablen.
Folgende Variablen besitzen unabhängig vom jeweiligen Zugriff für einen bestimmten Server stets einen festen Wert:
Bezeichnung des WWW-Servers, der die Ausführung des CGI-Skripts
veranlaßte.
Format: name/version
Beispiel: CERN/3.0pre6
Name der Maschine, auf der der Server läuft. Die Angabe erfolgt
als Hostname, DNS-Alias oder IP-Adresse.
Beispiel: tisch.fh-wedel.de
Version der CGI-Spezifikation, die dieser Server unterstützt.
Format: CGI/version
Beispiel: CGI/1.1
Name und Version des Protokolls, über das der Zugriff erfolgte.
Vorsicht ist bei HTTP/0.9 angebracht, da diese Protokollversion
veraltet ist und keine Request- und Response-Header á la HTTP 1.0
unterstützt.
Format: HTTP/version
Beispiel: HTTP/1.0
Der Port, auf dem der Request hereinkam.
Beispiel: 80
Die Zugriffsmethode des Requests.
Beispiele: GET, POST, PUT, DELETE.
Der Zugriff auf ein CGI-Skript erfolgt über den (virtuellen) Pfadnamen der Skript-Datei, beispielsweise >>/CGI/CGI<<. Daran kann der Client zusätzliche Parameter, sogenannte Path-Informationen, anhängen, etwa »/CGI/CGI/Beispiel+f%FCr+Path-Informationen«. Diese Path-Informationen erscheinen in der Variablen PATH_INFO. Der Server dekodiert die im URL mittels Prozentzeichen verschlüsselten Zeichen, läßt alle übrigen Zeichen jedoch unverändert. Insbesondere bleiben Zeichen, die in URLs eine Sonderbedeutung besitzen, unverändert. Das wichtigste Beispiel hierfür ist das Pluszeichen, das im URL das dort nicht erlaubte Leerzeichen ersetzt.
Diese Festlegung im CGI-Standard ist unsauber und kann zu Mehrdeutigkeiten führen. Ein Beispiel: Will man die Zeichenfolge »Dies ist ein Pluszeichen (+)« als Parameter an ein CGI-Skript übergeben, muß man für die Darstellung im URL die Leerzeichen in Pluszeichen umwandeln und die Sonderzeichen »(«, »+« und »)« in ihre Hexadezimaldarstellungen »%28«, »%2B« und »%29« bringen. Der partielle URL lautet folglich »/CGI/CGI/Dies+ist+ein+Pluszeichen+%28%2B%29«. Der WWW-Server wandelt die mittels Prozentsymbol kodierten Zeichen gemäß CGI-Spezifikation wieder zurück in ihre urspüngliche Form, und PATH_INFO erhält den Wert »/Dies+ist+ein+Pluszeichen+(+)«. Und das ist nicht konsistent: Das CGI-Skript hat keine Möglichkeit, zwischen »echten« Pluszeichen und verschlüsselten Leerzeichen zu unterscheiden. Besser wäre gewesen, die Pfadinformation entweder komplett oder überhaupt nicht zu dekodieren. PATH_INFO eignet sich auf Grund dieser Einschränkung nicht zur Übergabe beliebig komplexer Parameter an CGI-Skripts, sondern nur für einfache Anwendungen.
Bei der Spezifikation der Variablen PATH_INFO dachte man vor allem an die Möglichkeit, im Skript-URL einen Dateinamen als Parameter zu übergeben. PATH_INFO verrät allerdings nicht, an welcher Stelle im Filesystem diese Datei zu finden ist. Diese Aufgabe übernimmt PATH_TRANSLATED. Der Server leitet den Wert von PATH_INFO durch sein Mapping-System, mit dem er üblicherweise aus einem virtuellen einen physischen Dateinamen generiert. Beispiel: bei einem Mapping von »/*« auf »file:/usr/local/WWW/pub/*« in der Konfigurationsdatei des HTTP-Servers und PATH_INFO mit dem Wert »Example« liefert PATH_TRANSLATED »/usr/local/WWW/pub/Example«.
ist in folgenden Fällen gesetzt:
In diesen Fällen hängt der WWW-Client an den URL ein Fragezeichen an, gefolgt von den Parametern der jeweiligen Aktion. Das sind der Suchbegriff bei ISINDEX-Dokumenten, die Mauskoordinaten bei anklickbaren Bildern oder die vom Benutzer ausgefüllten Felder von Online-Formularen. Die Parameterübergabe erfolgt außerdem auf der Kommandozeile, soweit diese hinreichend Platz dafür bietet.
Name des Rechners, von dem der Request stammt. Falls der Server diese
Information nicht besitzt, weil zum Beispiel die zugreifende Maschine über
keinen Domain-Eintrag verfügt, ist diese Variable leer. In diesem
Fall hilft REMOTE_ADDR weiter.
Beispiel: tisch.fh-wedel.de
IP-Adresse des Client-Rechners.
Beispiel: 194.45.129.131
Falls das Skript geschützt ist, informiert diese Variable über
die zu verwendende Authentisierungsmethode.
Beispiel: Basic
Benutzername bei per Kennung geschützten Dokumenten; nicht notwendigerweise identisch mit der Unix-Benutzerkennung des Anwenders.
Falls auf dem Client-System ein Authentisierungs-Server nach RFC 931 läuft, kann der WWW-Server die Benutzerkennung des Klienten ermitteln und dem CGI-Skript in REMOTE_IDENT mitteilen. Da solche Authentisierungs-Server aber nicht in jedem Fall glaubwürdig sein müssen, sollte man diese Angaben mit Vorsicht genießen und allenfalls für Logging-Zwecke verwenden.
Bei Requests, die dem Server Daten übermitteln, wie etwa die HTTP-Anforderungen
PUT und POST, enthält diese Variable Angaben über den Typ dieser
Daten.
Beispiel (Online-Formular): application/x-www-form-urlencoded
Bei METHOD="PUT" Länge der auf der Standardeingabe verfügbaren Daten in Bytes laut Angaben des Client. Bei GET leer.
Zusätzlich zu den obigen Environment-Variablen vermittelt ein CGI/1.1-kompatibler Server dem Skript diejenigen Header-Zeilen des HTTP-Requests, die oben keine Entsprechung haben, über entsprechende Variablen. Dazu setzt er den Namen des Header-Elementes in Großbuchstaben um und ersetzt alle Bindestriche durch »_«-Zeichen. Dem Ergebnis wird die Zeichenfolge »HTTP_« vorangestellt. Aus dem Header »Accepted-Language: de« beispielsweise wird so die Environment-Variable HTTP_ACCEPTED_LANGUAGE mit dem Wert »de«. Weitere typische Beispiele sind HTTP_ACCEPT und HTTP_USER_AGENT. Die erste Variable listet alle MIME-Content-Types, die die Client akzeptiert. Der Server sollte nur ein solches Dokument schicken, dessen Format in dieser Liste enthalten ist. HTTP_USER_AGENT nennt das WWW-Client-Programm, mit dem der Anwender den Request abgeschickt hat.
Hier zwei Beispiel-Skripte, die die Environment Variablen auswerten: als DOS-Skript
und als Shell-Skript
Ein vergleichbares Skript ließt hier die Environment-Variablen aus: test-cgi?var=hallo (incl.Parameterübergabe => QUERY_STRING beachten)