Seminar Internet Technologien SS 98
Ausarbeitung zum Thema:
Common Gateway Interface

Michael Gründler

Zusammenfassung:

CGI - dieses Kürzel taucht im Zusammenhang mit dem Internet immer wieder auf. CGI ist eine Schnittstelle, die es ermöglicht, externe Programme oder Skripte von HTML-Dokumenten aus zu starten. CGI-Programme kommen im Internet vielfältig zum Einsatz. Hinter den meisten Zugriffszählern, Gästebüchern, Suchmaschinen und Uhren verbergen sich CGI-Skripte. Hauptsächlich wird CGI als Gateway zu Datenbanken eingesetzt. Diese Ausarbeitung, im Rahmen eines Seminares als Vortrag gehalten, soll einen Einblick in die Anwendung der CGI-Schnittstelle und der CGI-Programmierung verschaffen.


Inhalt

1. Einleitung

Das Common Gateway Interface ist eine Schnittstelle zwischen einem WWW-Server und einem Programm oder Skript. CGI ermöglicht es, Programme oder Skripte aus einem WWW-Browser heraus, über das Internet, auf einem Server auszuführen. Abbildung 1 zeigt den Ablauf einer CGI-Anforderung. Nachdem ein WWW-Browser mit dem HTTP-Protokoll eine Anfrage an einen WWW-Server gestellt hat, reicht dieser die Daten an das angegebene CGI-Programm weiter. Dieses verarbeitet die Daten und generiert z.B. eine SQL-Anfrage an eine Datenbank aus den übersendeten Parametern. Nachdem die Datenbank das Ergebnis der Anfrage an das CGI-Programm zurückgeliefert hat, generiert dieses eine HTML-Seite, die über den WWW-Server an den WWW-Browser gesendet wird. Dadurch ist es möglich, nicht nur statische, sondern auch dynamisch zur Laufzeit erzeugte Dokumente anzufordern.


  
Abbildung 1: Ablauf einer CGI Anforderung

2. Eingabe an das CGI

Die CGI-Schnittstelle beschreibt Abschnitt 2.1. Im Abschnitt 2.3 werden die für den Informationsaustausch zwischen WWW-Browser und WWW-Server wichtigen Umgebungsvariablen erläutert. CGI-Programme oder Skripte können über HTML-Formulare aufgerufen werden. Ein Exkurs im Abschnitt 2.2 gibt einen Überblick über einige HTML-Tags, die zur HTML-Formularprogrammierung wichtig sind. Das HTTP-Protokoll, das Standardtransferprotokoll im WWW, wird im Abschnitt 2.4 vorgestellt. Das HTTP-Protokoll verfügt über mehrere Methoden zur Datenübertragung. Abschnitt 2.5 beschreibt die für CGI-Programme relevanten Methoden der Datenübertragung an CGI-Programme. Da das HTTP-Protokoll nur ASCII-Zeichen zur Übertragung zulässt, werden die zu übertragenden Daten kodiert. Die dabei eingesetzten Regeln zeigt Abschnitt 2.6.

  
2.1 Die Schnittstelle

Derzeit liegt die CGI-Schnittstellendefinition in der Version 1.1 [Mue98] vor. Kommerzielle Hersteller, wie Netscape oder Microsoft, haben eigene, auf ihre Produkte optimierte, Schnittstellen auf den Markt gebracht. Diese erreichen oft ein Vielfaches der Performance der CGI-Schnittstelle. Ein entscheidender Vorteil der CGI-Schnittstelle bleibt jedoch die Tatsache, daß es sich, ähnlich wie bei HTML, um einen kommerziell unabhängigen, kostenlosen, produktübergreifenden Standard handelt.
Um CGI-Skripte oder Programme ausführen zu können, wird ein WWW-Server benötigt, der CGI unterstützt, was aber heute bei allen handelsüblichen WWW-Servern der Fall ist. In den Konfigurationsdateien des WWW-Servers wird vom WWW-Administrator ein Verzeichnis festgelegt, das die CGI-Programme oder Skripte enthält. Als Standardeintrag wird meist cgi-bin oder cgi-local gewählt. Desweiteren muß der Benutzer der CGI-Programme die Berechtigung haben, diese ausführen zu dürfen [Gun96].

   
2.2 Exkurs zu HTML-Formularen

HTML bietet die Möglichkeit, mit Hilfe spezieller Befehle Formulare zu erstellen. In Formularen kann der Benutzer Eingabefelder ausfüllen, in mehrzeiligen Textfeldern Text eingeben und aus Listen Einträge auswählen. Wenn das Formular fertig ausgefüllt ist, kann der Benutzer auf einen Button klicken, um das Formular abzusenden. Formulare können sehr unterschiedliche Aufgaben haben, so werden sie zum Beispiel eingesetzt: Um ein Formular zu erzeugen, stehen folgende HTML-Tags zur Verfügung: Auf jedem CGI-Formular sollten zwei Buttons vorhanden sein, einerseits der Submit-Button, um die Daten mit der gewählten Methode zu übermitteln, und andererseits der Reset-Button, um fehlerhafte Eingaben zu löschen.

  
2.3 Umgebungsvariablen

Der WWW-Server nutzt für seine Dienste Umgebungsvariablen, die ihm das Betriebssystem zur Verfügung stellt. Über diese Variablen können WWW-Browser und CGI-Programm Informationen austauschen. Da WWW-Browser unterschiedlicher Hersteller keinen identischen Funktionsumfang aufweisen, werden nicht immer alle Umgebungsvariablen unterstützt. Tabelle 1 zeigt einen Überblick über die wichtigsten Umgebungsvariablen [Gun96].


 
Tabelle 1: Die wichtigsten Umgebungsvariablen
Umgebungsvariablen Beschreibung
CONTENT_LENGTH Die Anzahl der Zeichen, die dem CGI-Programm über die Standardeingabe übergeben werden, wenn die Post Methode gewählt wurde
CONTENT_TYPE MIME-Typ der Abfrage
DOCUMENT_ROOT Verzeichnis, aus dem Web-Dokumente gelesen werden
HTTP_ACCEPT Liste der MIME-Typen, die der Client akzeptiert
HTTP_REFERER URL des Dokuments, auf das der WWW-Browser zugegriffen hat, bevor er das CGI-Programm aufgerufen hat
HTTP_COOKIE Daten, die auf der Clientseite in einem Cookie gespeichert sind
HTTP_USER_AGENT vom Client verwendete Browser
QUERY_STRING Zeichenkette mit Daten, die bei der Get Methode an den URL angehängt wird.
REQUEST_METHOD Methodenart der Anforderung
 

  
2.4 Das HTTP-Protokoll

Das Hypertext Transfer Protokoll HTTP ist in der Version 1.0 in einem Internet Draft von Tim Berners-Lee , Roy Fielding und Hendrik Nielsen festgelegt worden [BL92]. Das HTTP legt das Format, den Inhalt von Mitteilungen zwischen Client und Server sowie deren Abfolge fest. Alle Mitteilungen werden als ASCII-Zeichenketten ausgetauscht, wodurch HTTP unabhängig von maschinenspezifischen Darstellungen von Zahlen ist. Der Ablauf einer Kommunikation zwischen WWW-Browser und WWW-Server ist immer derselbe: Der Browser schickt eine Request-Mitteilung (für ,,Anforderung``) an den Server, die dieser mit einer Response-Mitteilung (für ,,Antwort``) beantwortet. Das HTTP legt den Aufbau dieser Mitteilungen fest.

  
2.5 Die Methoden Get und Post

Die Anfrage an das CGI kann mit zwei unterschiedlichen Methoden erfolgen, die im HTTP-Protokoll festgelegt sind. Die Methode Get übermittelt die Anfrage durch konkatenieren der Anfragedaten an den URL. Die Anfrage und die Adresse sind durch ein Fragezeichen getrennt. Der WWW-Server überträgt diesen String dann in die Umgebungsvariable QUERY_STRING.

Diese Methode hat den Vorteil, daß nicht erst ein Formular programmiert werden muß, sondern daß die Abfrage direkt an den URL angehängt werden kann. Get eignet sich nur bei geringen Datenmengen, da die Gefahr besteht, daß der WWW-Browser oder der WWW-Server zu lange Strings ,,abschneidet``. Außerdem leidet die Lesbarkeit der URLs beachtlich.
Bei der Methode Post ist dieses nicht der Fall, denn der String wird nicht transparent über den URL, sondern über die Standardeingabe übertragen. Es werden genau so viele Zeichen gelesen, wie in der Umgebungsvariablen CONTENT_LENGTH vereinbart wurde. Die Menge der zu übertragenden Daten ist im Gegensatz zu Get nicht begrenzt.

  
2.6 Kodierung der Daten

Um aus einem Formular heraus Daten an den WWW-Server zu übertragen, müssen Key/Value-Paare, aus den Elementnamen und den in das Formular eingegebenen Werten, gebildet werden. Damit dem CGI-Programm eine eindeutige Zuordnung zwischen Key und Value möglich ist, werden diese kodiert. Dabei gelten folgende Regeln: Beispiel: 
vorname=Michael+J%FCrgen&nachname=Gr%FCndler&

3. Das CGI-Programm

CGI-Programme werden vom WWW-Browser genauso wie andere Dokumente angefordert. Der Unterschied besteht darin, daß nicht sofort ein bereits vorhandenes Dokument zurückgeliefert wird, sondern ein Programm oder Skript ausgeführt wird.
Im ersten Kapitel wurde darauf hingewiesen, daß das HTTP-Protokoll zur Datenübertragung nur ASCII-Zeichen erlaubt. Ein CGI-Programm oder Skript, das diese Daten erhält, muss diese dekodieren, um sie verarbeiten zu können. Im Abschnitt 3.1 wird ein Dekodierungs-Algorithmus vorgestellt.
CGI-Programme oder Skripte können Informationen in Form von virtuellen Dokumenten an den WWW-Browser senden. Abschnitt 3.2 erläutert, wie virtuelle Dokumente erzeugt und wie sie an den WWW-Browser übermittelt werden.
Neben den eigentlichen Daten müssen auch Informationen über das virtuelle Dokument übermittelt werden. Diese Informationen, Header genannt, werden im Abschnitt 3.3 behandelt.

  
3.1 Dekodierung der Eingabedaten

Um die Daten vom WWW-Browser verarbeiten zu können, muß das CGI-Programm die übergebenen Daten dekodieren. Dazu kann der folgende Algorithmus verwendet werden:
1.
Ermittle das Request-Protokoll (Post oder Get) durch Überprüfung der Umgebungsvariablen REQUEST_METHOD.
2.
Wird die Get-Methode verwendet, lese den QUERY_STRING und die zusätzlichen Pfadinformationen aus der Umgebungsvariablen PATH_INFO.
3.
Wird die Post-Methode verwendet, lese die Umgebungsvariable
CONTENTH_LENGTH aus, und lese von der Standardeingabe einen Datenblock dieser Größe.
4.
Zerlege den QUERY_STRING beim &-Zeichen, und erhalte die KEY/VALUE-Paare.
5.
Dekodiere die Hexadezimal- und Pluszeichen in jedem KEY/VALUE-Paar.
An dieser Stelle sei erwähnt, daß es mit allen Programmiersprachen möglich ist, CGI-Programme zu erstellen, die die folgenden Vorbedingungen erfüllen: Das Lesen von der Standardeingabe (STDIN), das Schreiben auf die Standardausgabe (STDOUT) und der Zugriff auf Umgebungsvariablen muß möglich sein. Im einfachsten Fall kann das Programm unter UNIX ein Shell-Script bzw. unter DOS eine Batch-Datei sein. Es können aber auch höhere Programmiersprachen wie C, Pascal oder Fortran benutzt werden. Am häufigsten wird die Interpreter-Sprache Perl, die kostenlos im Internet erhältlich ist, für die CGI-Programmierung verwendet. Perl ist für Verarbeitung von Textdateien, dem Filtern von Informationen aus diesen Dateien und der Ausgabe von auf diesen Informationen basierenden Berichten optimiert. Perl bietet Funktionen an, die Datenmanipulationen und Zugriff auf externe Programme und Anwendungen stark vereinfachen.

  
3.2 Erzeugung von HTML-Dokumenten

Soll das CGI-Programm oder Skript eine Antwort wie z.B. das Ergebnis einer Datenbankanfrage an den WWW-Browser zurückliefern, wird ein virtuelles Dokument erzeugt. Virtuelle Dokumente sind nicht physisch auf einem Speichermedium vorhanden, sondern werden vom CGI-Programm auf die Standardausgabe geschrieben. Der WWW-Server leitet alles, was vom CGI-Programm auf die Standardausgabe geschrieben wird, an den WWW-Browser weiter. Die meisten WWW-Browser sind in der Lage, mehrere unterschiedliche Datenformate zu verarbeiten, die als MIME-Typen bezeichnet werden. MIME (Multipurpose Internet Mail Extensions) ist eine Spezifikation, die ursprünglich für das Versenden verschiedener Datenformate mit E-Mail entworfen wurde. MIME-Typen werden benutzt um den WWW-Browser mitzuteilen welche Art von Dokument vom WWW-Server übermittelt wird. Welche MIME-Typen vom WWW-Browser angezeigt werden können, wird als Liste in der Umgebungsvariablen HTTP_ACCEPT vom WWW-Browser gespeichert. Ein Beispiel wie in Perl eine Ausgabe aussehen kann zeigt das Beispiel in Abschnitt 3.3.

  
3.3 Header

Alle HTTP-Mitteilungen bestehen aus einer Reihe von Kopfinformationen und einem davon mit einer Leerzeile getrennten Inhalt. Die Kopfinformationen, genannt Header, geben Auskunft über die Mitteilung, die Art der Anforderung oder der Antwort und über den Inhalt selber [Mue97]. Mögliche Headerattribute zeigt Tabelle 2.

 
Tabelle 2: Header
Header Beschreibung
Content-length Länge des Ausgabestreams (in Byte)
Content-type MIME-Inhaltstyp des Ausgabestreams
Location Server-Umleitung
Pragma schaltet das Caching des Dokumentes ein bzw. aus
Status Status der Anforderung
 


Die Anzahl und Reihenfolge der Header ist nicht festgelegt. Wichtig ist, daß die Header mit einer Leerzeile abgeschlossen werden. Fehlt die Leerzeile als Trennung zwischen Header und Daten, liest der WWW-Server auch die Daten als Header ein und geht in einen Fehlerzustand.
Beispiel in Perl: 
#!/usr/bin/perl
print "Content-type: text/plain","\n";
print "pragma: no-cache";
print status: 200 Success","\n\n";
print "Erfolgreicher Verbindungsaufbau!";
exit (0);
Ist nur der Content-type Header angegeben, handelt es sich um einen korrekten, aber partiellen Header. Ein vollständiger Header enthält mindestens die Version des HTTP-Protokolls, den Status des Programms, den Namen oder die Version des WWW-Servers und den MIME-Typ der Daten [Gun96]. Aus einem partiellen Header generiert der Server einen vollständigen Header, was aber einen zusätzlichen Overhead bedeutet. Sollte das Skript so implementiert sein, das es einen vollständigen Header generiert, und beginnt der Skriptname mit dem Präfix nph-(für ,, Non-Parsed Header``), so ist beispielsweise der NCSA-Server in der Lage, das virtuelle Dokument direkt vom CGI-Skript zum WWW-Browser schicken zu lassen. Der erzielte Geschwindigkeitsgewinn steht einem Verlust der Korrekturmöglichkeit des WWW-Servers, fehlerhafte Header zu korrigieren, gegenüber.

  
3.4 Statuscodes

Das HTTP-Protokoll verwendet Statuscodes, um den Status einer Anforderung zurückzuliefern. Dieser Status-Header, bestehend aus einem dreistelligen numerischen Wert, dem ein kurzer Kommentar folgt, kann mit dem virtuellen Dokument ausgegeben werden. Tabelle 3 zeigt einige der gängigsten Statuscodes.
 
Tabelle 3: Statuscodes
Statuscode Meldung
200 Success
204 No Response
301 Document Moved
401 Unauthorized
403 Forbidden
404 Internal Server Error
501 Not Implemented
 

4. Methoden der Zustandsspeicherung

Zwischen WWW-Browser und WWW-Server besteht keine permanente Verbindung. Wird ein neues Dokument angefordert oder ein ausgefülltes Formular abgeschickt, muß eine neue Verbindung hergestellt werden. Erst dann ist ein Datenaustausch möglich. Nach dem Datenaustausch wird die Verbindung und ein eventuell aufgerufenes Programm auf dem WWW-Server beendet. Wenn ein komplexer Dialog zwischen Serverprogramm und WWW-Browser geführt wird, ist es oft notwendig, daß Informationen gesammelt werden. Für ein zweites Formular werden z.B. Informationen aus dem ersten Formular benötigt. Es gibt unterschiedliche Strategien, diese Informationen weiterzureichen. Eine einfache Methode, die Speicherung von Daten in versteckten Feldern, zeigt Abschnitt 4.1. Sollen Daten über die Verweildauer im Internet hinaus gespeichert werden, ist es möglich, Daten auf der Festplatte des Benutzers zu speichern. Diese besonderen Daten werden Cookies genannt und im Abschnitt 4.2 behandelt.

  
4.1 Versteckte Felder

Das CGI Programm schreibt Informationen, die es dem ersten, vom Benutzer ausgefüllten Formular entnommen hat, in versteckte Felder des zweiten Formulars. So können Informationen von einer Instanz zur nächsten weitergereicht werden, indem sie im nächsten Formular versteckt werden. Da der WWW-Browser alle Felder gleich behandelt, werden die Daten der versteckten Felder genauso kodiert und an den Server gesandt, wie die Daten der anderen Felder. Bei sehr vielen Formularen mit vielen Informationen hat dieses Verfahren den Nachteil, daß die zurückgelieferten Dokumente immer größer werden, was zu Performance-Problemen führen kann. Für den Benutzer bleibt dieses Verfahren transparent, es sei denn, er schaut sich den Quelltext der Formulare an.

  
4.2 Persistent Cookies

Eine weitere Methode zur Zustandsspeicherung ist die der Persistent Cookies. Diese Technologie, die ursprünglich von Netscape eingeführt wurde, wird heute von den wichtigsten WWW-Browsern unterstützt. Ein Cookie ist eine Textdatei, welche vom WWW-Server auf der Festplatte des Benutzers abgespeichert wird, in der begrenzt Daten gespeichert werden können. Tabelle 4 zeigt den Datenaufbau eines Cookies [Sch97].
 
Tabelle 4: Aufbau eines Cookies
Datenfeld Beschreibung
Domain Domain, an welche dieser Cookie gesendet wird, diese kann sich von der Domain unterscheiden die den Cookie angelegt hat
Tail matching wenn der Wert gesetzt ist, wird ein tail-matching durchgeführt
Path Pfad, der den Gültigkeitsbereich des Cookies auf dem jeweiligen Server definiert
Secure wenn der Wert gesetzt ist, wird der Cookie nur bei einer HTTPS-Verbindung gesendet
Expires gibt das Haltbarkeitsdatum des Cookies an, ist das Datum erreicht oder überschritten, wird der Cookie nicht länger gespeichert und ausgegeben
Name Name des Wertfeldes
Value Inhalt des Wertfeldes
 

Die maximale Anzahl und Größe der Cookies ist beschränkt. Ein WWW-Server darf auf einem Rechner maximal 20 Cookie-Einträge speichern. Jeder Eintrag kann eine maximale Größe von 4 KB haben, und die Gesamtzahl der gespeicherten Cookies darf 300 nicht überschreiten.
Das folgende Beispiel in Perl zeigt, wie ein Cookie angelegt wird.
print "Content-type: text/html", "\n";
print Set-Cookie : Name = Michael; 
expires = Mo, 27-Oct-98; path = \","\n\n";
Die neueren WWW-Browser gestatten eine Wahl, ob man Cookies akzeptiert oder sich vor ihnen warnen läßt. Ist das Abspeichern von Cookies erlaubt, dann kann ein CGI-Programm Daten auf der Client Seite speichern. Wird ein Folgedokument oder ein zweites Formular angefordert, werden die Key/Value-Paare der Cookies, durch Semikolons voneinander getrennt, an die Umgebungsvariable HTTP_COOKIE gesendet. Bevor der Inhalt der Cookies übermittelt wird, werden noch die Domain und die Gültigkeit des Pfades überprüft.
Mit Hilfe der Persistent Cookies ist es möglich, bestimmte Informationen über den Benutzer zu speichern. Eine auf der Serverseite betriebene Datenbank, die eine eindeutige Kennung des Benutzers generiert und diese als Wert in einem Persistent Cookie speichert, bietet hinreichend Möglichkeiten, Informationen über den Besuch des Benutzers zu speichern. Oft wird auch das Verfallsdatum der Cookies in einen weit entfernten Zeitpunkt in der Zukunft gesetzt. Somit ist der Benutzer, sollte es immer der gleiche sein, auf der WWW-Serverseite bekannt und kann gegebenenfalls mit Namen begrüßt werden.

5. Sicherheitsaspekte

Neben den in den vorigen Kapiteln genannten Funktionen gibt es auch Sicherheitsprobleme im Umgang mit der CGI-Schnittstelle. Abschnitt 5.1 erläutert die Gefahren, die durch fahrlässige CGI-Programmierung entstehen. Auch eine falsche Konfiguration des WWW-Servers durch den WWW-Administrator kann zu einer Sicherheitslücke führen. Ein bekanntes Risiko und dessen Behebung schildert Abschnitt 5.2 . Das HTTP ist kein sicheres Protokoll zur Übertragung vertraulicher Daten. Abschnitt 5.3 behandelt die unsichere Passwortübertragung. Täglich steigt die Anzahl der WWW-Server die Cookies anlegen wollen. Welche Gefahren von Cookies ausgehen und wie man sich vor ihnen schützt, zeigt Abschnitt 5.4 .

5.1 Gefährliche Eingabe

CGI-Programme können dynamisch Dokumente erzeugen. Doch ist auch Vorsicht geboten. Der wohl fahrlässigste Fehler ist der, ungeprüft Eingaben des WWW-Benutzers auf die Standardeingabe zu senden.
Beispiel in Perl:
print ´$query_string´;
Die Gefahr besteht darin, das der WWW-Benutzer nicht, wie vielleicht gefordert, eine Eingabe als Parameter für einen Befehl, sondern 
 ;rm -fR /;
eingibt. Je nach Benutzerrechten kann das Ergebnis katastrophale Folgen haben. Gerade Perl bietet umfangreiche Möglichkeiten, einen Ausdruck zu überprüfen.

5.2 Benutzerkennung von Prozeßen

Auf Unix-Betriebssystemen werden Programme in der Regel mit den Rechten ihrer Benutzer betrieben. Da im WWW die Benutzer anonym und selten identisch mit lokalen Benutzern sind, laufen die CGI-Programme unter der gleichen Benutzerkennung wie der WWW-Server. Der TCP Port 80 ist der Standard-Port für den WWW-Server. Auf diesem Port tauschen WWW-Browser und WWW-Server über das HTTP Protokoll Daten aus. Normalerweise können Ports mit einer Nummer unter 1024 nur mit Systemadministratorrechten betrieben werden. Deswegen werden viele WWW-Server unter der Systemadministrator-Kennung betrieben. Das ist ein hohes Sicherheitsrisiko! Zur Lösung dieses Problems gibt es sogenannte Wrapper. Diese erhalten, nachdem sie unter Systemadministratorrechten gestartet wurden, die Rechte eines beliebigen Nutzers, unter der dann der WWW-Server betrieben wird. Das wäre z.B. user:nobody und group: nobody. Diesem Benutzer können dann eingeschränkte Rechte gegeben werden, um die normalen Unix-Schutzmechanismen wieder herzustellen. Diese ist allerdings nicht unter DOS oder Windows möglich, da es sich nicht um Multi User Betriebssysteme handelt.

5.3 Paßwörter

Ein weiterer Nachteil bei der CGI Programmierung ist die nicht sichere Übermittlung von vertraulichen Daten (z.B. Passwörter). Es existiert zwar ein HTML-Tag in HTML-Forms, der es erlaubt, ein Passwort unsichtbar einzugeben, doch dieses wird unverschlüsselt gesendet. Wenn der CGI-Aufruf mit der Methode Get erfolgt, wird das Passwort sogar sichtbar hinter der URL übertragen. Hier ist größte Vorsicht geboten, wenn es um vertrauliche Daten geht.

  
5.4 Cookies

Über Cookies wird kontrovers diskutiert. Einerseits werden sie für harmlos gehalten, andererseits für gefährlich. Im zunehmenden Maße werden Benutzerprofile gespeichert, die das Benutzerverhalten offenlegen sollen. Sofern der WWW-Browser die Umgebungsvariable HTTP_REFERER beschreibt, ist es möglich, Wege zum eigenen Webserver nachzuvollziehen. Wenn Benutzerverhalten vorrausberechenbar wird, ist es auch möglich, dieses zu manipulieren. Sinnvoll ist es auf jeden Fall, den Browser anzuweisen, vor Cookies zu warnen, und diese regelmäßig zu überprüfen. Der WWW-Browser von Netscape, unter Windows betrieben, speichert Cookies in einer Datei names Cookies.txt. Diese Datei kann z.B. auch mit dem Attribut ,, schreibgeschützt `` versehen werden, um das Anlegen der Cookies zu verhindern.

6. Abschließende Anmerkungen

Ein wesentlicher Vorteil von CGI ist, daß es sich um einen kostenlosen, kommerziell unabhängigen und produktübergreifenden Standard handelt. Andere kommerzielle Hersteller haben eigene auf ihre Produkte optimierte Schnittstellen auf den Markt gebracht. Zu nennen wäre die NSAPI Schnittstelle von Netscape und die ISAPI Schnittstelle von Microsoft. Eine weitere Neuerung ist FastCGI, eine Schnittstelle die weitgehend auf CGI aufbaut, aber die Geschwindigkeitsnachteile zu anderen Schnittstellen aufhebt. Als Erweiterung, zum derzeitigen CGI, sind Unterstützung von Authorisierungstechniken und eine Datentypkonvertierung geplant. Weiterhin gibt es Vorschläge, die CGI-Programme näher an den WWW Server Prozeß zu koppeln, indem beispielsweise dynamisch Module gelinkt werden (ähnlich dem shared library Prinzip). Nachteilig ist hier, daß unsauber programmierte CGI Programme den Absturz des gesamten WWW Servers nach sich ziehen können [Wer97].
Andere Entwicklungen gehen so weit, daß über spezielle HTML-Tags direkt Datenbankzugriffe möglich sind. Eine Erweiterung von HTML durch SQL-Befehle könnte direkt aus dem Dokument heraus Datenbankanfragen ermöglichen.

Literatur

BL92
Tim Berners-Lee.
HTTP.

http://www.w3.org/hypertext/WWW/Protocols/HTTP/HTTP2.htm, 1992.

Gun96
Shishir Gundavaram.
CGI Programmierung im World Wide Web.
O Reilly International Thomson Verlag, 1996.

Mue97
Stefan Muenz.
HTML Dateien richtig erstellen 6.1.

http://www.teamone.de/download/selfhtml.zip, 1997.

Mue98
Stefan Muenz.
HTML Dateien richtig erstellen 7.0.

http://www.teamone.de/download/selfhtml.zip, 1998.

Sch97
Stefan Schlosske.
Cookies.

http://heus/techfreak.uni-bielefeld.de/ausarbeitungen/ss97/www/cookies_text.html, 1997.

Wer97
H. Werner.
WWW.

http://gryps2.rz.uni-greifswald.de/werner/tutorial.html, 1997.

Über dieses Dokument ...

Seminar Internet Technologien SS 98
Ausarbeitung zum Thema:
Common Gateway Interface

This document was generated using the LaTeX2HTML translator Version 98.1p1 release (March 2nd, 1998)

Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were:
latex2html -split 2 -show_section_numbers -ps_images semcgi.tex.

The translation was initiated by root on 1998-08-24

next up previous
root
1998-08-24