[ zurück ]

Das Windows-CGI-Interface


Vorwort

Seit dem mit Windows-NT für den Netzwerksbetrieb eine leistungsfähige Betriebssystemplattform zur Verfügung steht, gibt es auch unter der Windows-Oberfläche laufende Webserver. Eine hervorragende Übersicht einschließlich Vergleichsmöglichkeiten und Links zu den entsprechenden Anbietern ist unter http://webcompare.iworld.com/intranet.shtml zu finden.

Alle diese Webserver unterstützen auch das Common-Gateway-Interface (CGI). Allerdings entstammt diese Technik zum Aufruf von Programmen auf dem Server durch den Client der UNIX-Welt und ist voll an den Möglichkeiten derartiger Systeme orientiert. Im Standard-CGI nimmt der Server die Anfragedaten des Client entgegen, dekodiert sie teilweise, übergibt sie als Environmentvariable und über die Standardeingabe an das auswertende Programm (CGI-Script), nimmt die Ergebnisdaten vom Script über dessen Standardausgabe entgegen und leitet sie bearbeitet an den Client weiter. Diese Arbeitsweise unterstützen die meisten Windows-Webserver, falls das CGI-Script ein DOS-Programm oder Konsolen-Prozeß ist oder zumindest die Standardein-/ausgabe nutzt. Der Server startet das Script dann in einer Umgebung mit allen notwendigen Umgebungsvariablen und exakter Behandlung der Ein- und Ausgabe.

Und hier liegt eine Quelle für viele Mißverständnisse: Diese klassische Technik müßte exakter Weise "Standard-CGI unter Windows" und nicht "Windows-CGI" heißen. Eine hervorragende Beschreibung incl. Programmierhilfen dazu bietet Stefan Müller an. Er betreut auch eine zum Thema passende Mailing-Liste (http://minerva.sozialwiss.uni-hamburg.de/webprog/index.html).

Allerdings versagt "Standard-CGI unter Windows" in einigen Fällen. 16-bit DOS-Programme als CGI-Script laufen auf 32-bit-WebServern meist nur holprig und 16-bit-Windows-Programme konnte man auf diese Art und Weise überhaupt nicht erzeugen. Windows 3 hat nun mal keine Standardein- und -ausgabe und keinen direkten Environmentbereich. Deshalb mußte mit dem Windows-CGI-Interface eine spezielle Schnittstelle geschaffen werden. Das Windows-CGI-Interface existiert inzwischen in der Spezifikationsversion 1.3a. Nach meinen Erkenntnissen ist das Interface kein offizieller Standard (und wird es wohl wegen seiner rückläufigen Bedeutung auch nicht mehr werden), sondern eher ein von den Herstellern entsprechender Webserver vorgeschlagener und allgemein anerkannter Ausweg.

Beachte: Nicht jeder Windows-Webserver beherrscht überhaupt Windows-CGI und nicht jeder Windows-CGI-fähige Server beherrscht alle Forderungen der Spezifikation 1.3. (Also nicht verzweifeln, wenn das selbst programmierte Script nicht so recht laufen will. Manchmal ist auch der Server schuld.)

"echtes" Windows-CGI

Die Hauptidee von Windows-CGI ist es, die Daten zwischen Webserver und CGI-Programm über temporäre Dateien zu übergeben, die die Umgebungvariablen und die Standardein- und -ausgabe ersetzen. Die Dateinamen für diese Dateien gibt der Server per Zufallsgenerator vor, das Übergabeverzeichnis wird zumeist das temporäre Verzeichnis des Servercomputers sein. Nach Abarbeitung einer Anfrage sorgt der Server für das automatische Löschen der Dateien.

An der Beantwortung einer Anfrage von einem Klientsystem sind stets mehrere temporäre Dateien beteiligt.

Eine erste Datei wird CGI-Data-File bezeichnet. Sie beinhaltet das, was beim Standard-CGI als Environmentvariablen zur Verfügung gestellt wird. Dazu wird die Datei wie eine INI-Datei in Abschnitte mit Schlüsseln und Werten gegliedert.

Beispiel für eine CGI-Daten-Datei:

[CGI]
Request Protocol=HTTP/1.0
Request Method=POST
Executable Path=C:\Dat\Prog\Cgi\CgiTest.exe
Document Root=C:\Programme\HTTPd\HTDocs
Logical Path=
Physical Path=
Query String=ProbeString
Referer=http://intra.net/TestWinCGI.htm
User Agent=Mozilla/2.0 (compatible; MSIE 3.0; Windows 95)
Content Type=application/x-www-form-urlencoded
Content Length=116
Content File=C:\Temp\OMNE023.TMP
Server Software=OmniHTTPd/1.0b4 (Win32; i386)
Server Name=127.0.0.1
Server Port=80
Server Admin=Papierkorb@net
CGI Version=CGI/1.3a (Win)
Remote Host=
Remote Address=127.0.0.1
Authentication Method=
Authentication Realm=
Authenticated Username=
Authenticated Password=

[Accept]
image/gif=Yes
image/x-xbitmap=Yes
*/*=Yes

[System]
GMT Offset=7200
Debug Mode=No
Output File=C:\Temp\OMNE024.TMP
Content File=C:\Temp\OMNE023.TMP

[Extra Headers]
Accept-Language=de, en

[Form Literal]
Programm=Fahrbuch
Angebot=Mail
Absender=Max Mustermann
eMail=max@net
Button=Absenden

Die einzelnen Schlüssel sind in http://website.ora.com/wsdocs/32demo/windows-cgi.html beschreiben (meine deutsche Übersetzung heißt cgi13doc.htm).

Beachte: Nicht jeder Server übergibt alle Schlüssel vollzählig.

Das CGI-Programm erhält Kenntnis von der CGI-Datendatei über den ersten Parameter der zum Aufruf benutzten Kommandozeile, weil der Server das CGI-Programm nicht nur mit seinem Namen aufruft sonderen meist bis zu 4 Kommandozeilenparameter mitgibt.

Beispiel für die Kommandozeile:

WinCGITest.exe C:\Temp\OMNE022.TMP C:\Temp\OMNE023.TMP C:\Temp\OMNE024.TMP ProbeString

Während bei Windows-CGI 1.1 noch zwingend von den ersten drei Parametern gesprochen wird, findet man bei Windows-CGI 1.3a meist nur noch den ersten Parameter als zwingend notwendig, obwohl viele Server auch unter der Version 1.3 nach wie vor 3 oder 4 Parameter übergeben.

Das ist aber nicht weiter problematisch, weil die Kommandozeilen-Parameter Nummer 2 bis 4 immer auch noch einmal in der CGI-Datendatei stehen, wo man sie sicher entnehmen kann.

Parameter 2 ist (sofern vorhanden) der Name des sogenannten Content-Files (Inhaltsdatei). Diese Datei liegt ebenfalls mit einem vom Server erdachten Namen im temporären Verzeichnis und beinhaltet die Formulardaten aus dem Eingabeformular des Klient in URL-kodierter Form. Statt aus dem zweiten Kommandozeilenparameter sollte man diesen Dateinamen besser aus der CGI-Datendatei, Abschnitt [System], Schlüssel "Content File" holen.

Beispiel für ein Contentfile:

Programm=Fahrbuch&Angebot=Mail&Absender=Max+Mustermann=&eMail=max@net&Button=Absenden

Der dritte Parameter der Kommandozeile bezeichnet den Namen der Ausgabedatei, in die das CGI-Programm seine Ergebnissmeldungen zu schreiben hat. Nur was in dieser Datei steht, wird im Anschluß an die vollendete Anfrage vom Server an den Klient zurückgegeben. Auch der Name dieser Datei ist in der CGI-Datendatei, Abschnitt [System], Schlüssel "Output File" sicher enthalten. Diese Datei muß sich in Aufbau und Inhalt an feste Regeln halten, damit die Daten vom Server und Klient richtig verstanden werden (Beispiele siehe cgi13doc.htm#8). In den meisten Fällen wird es sich um eine Datei vom "Content-type: text/html" mit entsprechend HTML-formatierten Rumpf handeln. Bei direkter Ausgabe an den Klient schreibt das CGI-Programm alle Angaben einschließlich komplettem Header in diese Ausgabedatei.

Der vierte eventuelle Kommandozeilenparameter ist der Anfragestring, der im Webbrowser des Klient eventuell nach einem "?" in der URL-Aufrufadresse eingegeben wurde. Dieser Parameter ist identisch mit dem "Query String" aus dem Abschnitt [CGI] des CGI-Data-Files. Man sollte lieber darauf als auf den vierten Kommandozeilenparameter zugreifen.

Damit ist das Wesentliche zu Windows-CGI gesagt. Den bescheidenen Rest muß nun das eigene CGI-Programm (siehe cgiprog.htm) erledigen.


[ Seitenanfang ] [ Win-CGI ]

J. Hummel,   1997