Home
Dokumentation
Einführungskurs: CGI-Programmierung mit der tdbengine

Die Lektionen des Kurses:

  1. Grundlagen / Was ist CGI
  2. Die Programmierumgebung der tdbengine
  3. Die Aufbereitung der CGI-Informationen mit der tdbengine
  4. Grundlagen der EASY-Programmierung
  5. Die Standardbibliothe von EASY
  6. Die Datenbank der tdbengine
  7. Die Bearbeitung von HTML-Formularen
  8. Eine komplette Adressdatenbank im Internet
Lektion 1: Grundlagen / Was ist CGI

Client Side - Server Side
Was ist CGI
Statische und dynamische Anfragen
So werden die Daten übertragen
Die CGI-Envionment-Variablen
Die Ein- und Ausgabekanäle
Aufgaben

In diesem Kurs geht es um die Bereitstellung von Funktionaltität in der http-Welt über die CGI-Schnittstelle. Das betrifft sowohl Internet als auch Intranet. Der Kurs besteht aus 8 Lektionen. In der ersten werden wir zunächst die wichtigsten Grundbegriffe kennenlernen und dann den Informationsfluss zwischen Browser und http-Server diskutieren.

Client Side Server Side

Immer dann, wenn Funktionen benötigt werden, die über den HTML-Standard hinausgehen, wird zusätzliche Programmkapazität benötigt. Dabei ist zunächts einmal zu unterscheiden, wo das Programm ausgeführt wird. Läuft das Programm auf der Klienten-Seite (also auf dem Gast-Rechner), so muß der entsprechende Programmcode in das HTML-Dokument eingebunden sein. Beispiele hierfür sind Javascript, Java-Applets und ActiveX-Komponenten. Aus Sicherheitsaspekten sind jedoch die Möglichkeiten dieser Programme sehr stark eingeschränkt. Sie laufen in einer völlig abgekapselten Umgebung (Beispiel: Java-Sandbox) und dürfen keine Systemfunktionen ausführen, wie etwa Anlegen oder Löschen von Dateien. Die einzigen Informationen, auf die ein eingebettetes Programm zugreifen darf, sind die Elemente des (einbettenden) HTML-Dokuments.

Beispiel: Ein Shopping-System, das auf Java-Applets basiert, muss mit dem äusseren HTML-Dokument den gesamten Warenbestand zum Klienten übertragen.

Zudem muss ein eingebettetes Programm in plattformübergreifender Form präsentiert werden, damit die Anwendung nicht auf einzelne Betriebssysteme (und/oder CPUs) beschränkt bleibt. Unter diesem Gesichtspunkt bleiben nur noch Javascript und Java über: Im Fall von Javascript wird der Quelltext des Programms übertragen, bei Java ist es ein portierbarer Pseudo-Code (Byte-Code). In jedem Fall muß ein weiteres Programm auf der Klientenseite den Code erst interpretieren und dann ausführen. Das Ganze kann freilich nur dann im gewünschten Maße funktionieren, wenn die Interpreter verschiedener Klienten gleiche (oder wenigstens sehr ähnliche) Ergbnisse liefern. Leider ist es derzeit nicht so.

Trotz alledem sind Klienten-Programme prinzipiell verführerisch, da damit die Ressourcen im Netz wesentlich besser ausgenützt werden können.

Programme, die auf dem Server laufen, sind keinen solchen Beschränkungen unterworfen. Hier stellt sich die Sicherheitsfrage prinzipiell anders. Auf hierzu relevante Fragen gibt ein Anschlußkurs Auskunft. Server-Programme können demnach (in einem genau definierten Rahmen) auf vielfältige Systemressourcen zugreifen:

  • Datenbanken
  • Dateien
  • Kommunikationsmittel (wie E-Mail-Versand)
  • Weitere Programme
Zudem kann das Programm in jeder Form vorliegen, die der Server ausführen kann. Es besteht demnach keine Notwendigkeit, den Code portierbar zu machen, sondern er Programmierer kann sozusagen den Rechner komplett ausreizen. Auch spielt die Programmiersprache, in der die Programme geschrieben werden, keine Rolle. (Der Grund, weshalb in der Literatur immer von CGI-Scripten gesprochen wird, liegt allein daran, daß ursprünglich die meisten CGI-Programme eben in einer Scriptsprache wie Perl geschrieben wurden. Als Script-Sprachen werden solche Programmiersprachen bezeichnet, bei denen der Quelltext immer erst zur Laufzeit analysiert, interpretiert und schließlich ausgeführt wird)

Probleme bekommen Server-Programme immer dann, wenn viele Anfragen beantwortet werden müssen, da ja (meist) nur ein Rechner zur Verfügung steht, dessen Kapazität auf die eingegangenen Anfragen verteilt werden muß. Zudem muss die Ausgabe jedes Programms zum Klienten übertragen werden, wodurch eine nicht unerhebliche Netzbelastung entstehen kann.

Hier noch einmal kurz Besonderheiten, sowie Vor- und Nachteile von Klienten- und Server-Programmen:

Klienten-Programme:

Vorteile: Das Programm kann (in einem ingeschränkten Maße) die Ressouren des Gastrechners benutzen, wodurch der Server entlastet wird. Das kann bei rechenintensiven Programmen ein Vorteil sein. Zudem können beispielsweise Grafik- und Soundfunktionen des Gastrechners besser ausgenutzt werden. Zur Interaktion mit dem Anwender sind keine zusätzlichen Übertragungen nötig (Beispiel: Fehleingaben können direkt beim Klienten angemahnt und korrigiert werden)

Nachteile: Alle benötigten Informationen (inklusive dem Programm selbst) müssen erst einmal übertragen werden. Das Programm darf keine Dateien anlegen und hat somit keinen permanenten Speicher, also kein "Gedächtnis". Datenbankabfragen sind immer mit weiteren Übertragungen von einem Server-Programm verbunden. Die Programm-Interpreter sind teilweise inkompatibel.

Einsatzgebiete: Derzeit werden Klienten-Programme vorwiegend zur grafischen Gestaltung eingesetzt (OnMouseOver...), in manchen Fällen werden auch schon Formulare voraufbereitet. Es ist jedoch durchaus möglich (und auch erstrebenswert), wirklich funkionale GUIs (grafische Benutzerschnittstellen) zu schaffen, über die dann auf Serverprogramme zugegriffen werden kann. (Leider ist die Java-Programmierung nicht so einfach wie HTML-Design)

Server-Programme:

Vorteile: Das Programm kann auf Datenbanken zugreifen, Dateien lesen und schreiben. Es läuft in einer definierten Umgebung, unterschiedliche Klienten-Umgebungen spielen keine Rolle. Es liefert seine Ergebisse an alle Klienten, die HTML verarbeiten können, vom Großrechner über sämtliche PCs bis hin zum WAP-Handy. Die Resssourcen des (Wirt-)Rechners können hocheffizient genutzt werden.

Nachteile: Die Resourcen des Wirt-Rechners sind beschränkt (auch wenn es sich um ein noch so leistungsfähiges System handelt), weshalb es bei vielen gleichzeitigen Anfragen zu Performance-Einbrüchen kommen kann. Der Dialog mit dem Klienten erfordert immer Informationsübertragungen und belastet dadurch das Netz (vor allem, wenn die Antworten "grafisch gut aufgemacht" sein sollen).

Einsatzgebiete: Alle Programme, die auf Datenbanken oder sonstige zentral gehaltene Datenbestände zugreifen müssen.

Was ist CGI

CGI steht für Common Gateway Interface und definiert einen Standard zum Informationsaustausch zwischen einer Anfrage (Request) und der diese Anfrage bearbeitenden Applikation, wobei sich beide Seiten des http-Protokolls (http = hypertext tranfer protocol) bedienen.

Im Normalfall gestaltet sich der Infomationsfluss so:

Der Klient setzt mit einem http-Browser (Netscape Navgator, Microsoft Internet Explorer) eine Anfrage in Form eines Dateinamens an den http-Server ab. In den meisten Fällen handelt es sich dabei um eine HTML-Seite, die der http-Server direkt an den Klienten senden kann. Durch bestimmte Auszeichnungen der Anfrage erkennt der http-Server jedoch, daß er die Anfrage an ein anderes Programm weiterleiten muß. Diese Auszeichnungen sind normalerweise direkt aus der Adressierung der Anfrage (also dem Dateinamen bzw. dem kompletten Pfad zu diesem Datenamen) zu erkennen:

Aus einer Adresse wie http://www.tdb-engine.de/demos/hello.pl werden die einzelnen Komponenten extrahiert:

http: das Protokoll (und damit der entsprechende http-Server
//www.tdb-engine.de der zu dieser Domain (IP-Adresse) gehörende Netzwerk-Server
/demos/ der (virtuelle) Pfad auf dem Server zur gewünschten Datei
hello.pl die gewünschte Datei

Die Programmklasse der Anfrage bestimmt der http-Server nun

a) aus der Namenserweiterung der gewünschten Datei

Beispiele:
 
 .pl   Perl-Programme 
 .prg   tdbengine-Programme 
 .cgi   Unix-Shell-Skripten 

b) durch das Verzeichnis, in dem sich die gewünschte Datei befindet

Beispiele:
 
 /cgi-bin/   Standard-CGI-Verzeichnis auf Unix/Linux-Rechnern 
 /scripts/   Standard-CGI-Verzeichnis bei Windows NT 
 /cgi-tdb/   beliebtes Verzeichnis für tdbengine-Programme 

Welche Dateianfrage der http-Server als externen Programmaufruf erkennt und welche nicht, wird in der jeweiligen Server-Konfiguration festgelegt.

Statische und dynamische Anfragen

http-Anfragen, die der http-Server unmittelbar, also ohne auf weitere Programm-Ressourcen zuzugreifen, beantworten kann, indem er einfach die angeforderten Dateien an den Klienten überträgt, werden als statische Anfragen bezeichnet. Es handelt sich dabei vorwiegend um

HTML-Dokumente .htm, .html
Text-Dokumente .txt
Bilder .gif, .jpg, .jepg
Sounds .mp3, .wav, .au

Anfragen, die nur unter Mithilfe weitere Programme beantwortet werden können, werden als dynamische Anfragen bezeichnet. Hierzu zählen unter anderem

CGI-Programme (siehe oben)
ISAPI-Anwendungen .isa (werden hier nicht behandelt)
NSAPI-Anwendungen .nsa (werden hier nicht behandelt)

Es existiert bei allen gängigen http-Servern noch eine Mischform, bei der in statische HTML-Dokumente dynamische Inhalte eingebettet sind. Es handelt sich bei diesen Einbettungen um sogenannte "server side includes", die äußeren HTML-Dokumente erkennt man an Namenswerweiterungen wie .shtm oder .shtml. Server side includes sind nicht Thema dieses Einführungskurses.

So werden die Daten übertragen

In jedem Fall nimmt erst einmal der http-Server die Anfrage entgegen. Erkennt er darin den Aufruf eines CGI-Programms, so richtet er eine sogenannte Programmumgebung (Environment) ein. Diese besteht aus

  • einem Satz von Environment-Variablen
  • einem Satz von Ein- und Ausgabekanälen
Environment-Variablen sind nicht anderes als über festgelegte Namen ansprechbare Zeichenketten. Auch die Shell (Kommandoprozessor) hat einen Satz von Environment-Variablen, den man sich mit dem Befehl "set" ansehen kann. Wechseln Sie hierfür auf ein Terminal (MS-DOS-Eingabeaufforderung unter Windows) und geben Sie dort folgendes ein:

set [RETURN]

Sie erhalten eine Auflistung aller Environment-Variablen Ihrer Shell (hier nur ein Beispiel):
 
TMP=C:\WINDOWS\TEMP
TEMP=C:\WINDOWS\TEMP
PROMPT=$p$g
winbootdir=C:\WINDOWS
COMSPEC=C:\WINDOWS\COMMAND.COM
PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;C:\PP\BIN\GO32V2
windir=C:\WINDOWS
BLASTER=A220 I5 D1 T4
...

Oder unter Linux
 
BASH=/bin/bash
BASH_VERSINFO=([0]="2" [1]="03" [2]="0" [3]="1" [4]="release" [5]="i686-pc-linux-gnu")
BASH_VERSION='2.03.0(1)-release'
COLORTERM=1
COLUMNS=80
ENLIGHTENMENT_ROOT=/usr/X11R6/lib/X11/enlightenment
EUID=0
GNOMEDIR=/opt/gnome
GS_FONTPATH=/usr/share/lilypond/afm:/usr/share/lilypond/pfa
HISTCONTROL=ignoredups
HISTFILE=/root/.bash_history
HISTFILESIZE=500
HISTSIZE=500
HOME=/home/tdbengine
HOSTNAME=uli
HOSTTYPE=i686
...

Da Programme solche Envionment-Variablen sowohl lesen als auch setzen können, sind sie sehr beliebt bei der Informationsübertragung von einem Programm zu einem weiteren (ähnlich der bei vielen Anwendern beliebten "Zwischenablage").

Der http-Server richtet also einen Satz von Environment-Variablen ein, wobei vor allem die vom Klienten übertragenen Informationen brücksichtigt werden. Zusätzlich teilt der http-Server über die Environment-Variablen auch seine Eigenschaften an das aufzurufende Programm mit.

Die CGI-Envionment-Variablen

Hinweis: Sie müssen die folgende Aufzählung nicht im verinnerlichen, denn einerseits bereitet die tdbengine die wichtigsten für Sie vollständig auf, und andererseits können die Variablen bei Bedarf jederzeit auch online eingesehen werden.

Laut CGI-Spezifikation müssen mindestens folgende Environment-Variablen angelegt werden:

Server-spezifische Umgebungsvariablen

GATEWAY_INTERFACE

In dieser Umgebungsvariablen steht die Revision der CGI-Spezifikation, die dieser Server unterstützt.
Format: CGI/<revision>

SERVER_NAME

Der Name des Rechners (der Maschine), auf dem die Server-Software läuft, steht in der Variablen SERVER_NAME. Die Angabe erfolgt als Hostname des Servers, als DNS-Alias oder als IP-Adresse. Beispiel: www.cs.tu-berlin.de

SERVER_SOFTWARE

Diese Variable enthält Name und Version des WWW-Servers, der die Ausführung des CGI-Skripts veranlaßt hat.
Format: <name>/<version>

DOCUMENT_ROOT

Diese Variable enthält den Pfadnamen des Dokumentenverzeichnisses des WWW-Servers, wie er auch in der Server-Konfigurationsdatei spezifiziert wurde. Beispiel: /usr/local/www/doc

Anfrage-spezifische Umgebungsvariablen

Die Werte der Umgebungsvariablen in diesem Abschnitt sind anfrage-spezifisch. Sie werden also in Abhängigkeit von der, an den Server gerichteten, Anfrage gesetzt.

AUTH_TYPE

Bei geschützten Skripten informiert diese Variable über die zu verwendende Authentifizierungsmethode.  Beispiel: Basic

CONTENT_LENGTH

Bei METHOD="PUT" oder "POST" steht in CONTENT_LENGTH die Länge der auf der Standardeingabe verfügbaren Daten in Bytes, laut Angabe des Clients. Bei METHOD="GET" ist CONTENT_LENGTH leer.

CONTENT_TYPE

Bei Requests, die dem Server Daten übermitteln, wie etwa die HTTP-Anforderungen PUT oder POST, enthält diese Variable Angaben über den Typ dieser Daten (MIME-Type).  Beispiel (Online-Formular): application/x-www-form-urlencoded

HTTP_ACCEPT

In dieser Variablen steht eine Liste mit den MIME-Content-Types, die der Client versteht - so wie sie im HTTP-Header angegeben wurden. Die einzelnen Listenelemente sind durch Kommata getrennt. Format: /, /, ...

HTTP_FROM

In dieser Variablen steht die e_mail-Adresse des Benutzers, der den Request ausgelöste hat. Nicht alle Browser unterstützen die Übermittlung der User-e_mail-Adresse.

HTTP_REFERER

In dieser Variablen steht der URL desjenigen Dokuments, das der Client angefordert hatte bevor er das CGI-Skript referenziert hat.

HTTP_USER_AGENT

Diese Variable gibt Auskunft darüber, mit welcher Client-Software (Netscape, Mosaic, ...)der Request auf dieses CGI-Skript ausgelöst wurde. Beispiel: Mozilla/2.0 (Win16; I)

PATH_INFO

Es gibt mehrere Möglichkeiten, beim Aufruf eines CGI-Skripts gleichzeitig Parameter an das Skript übergeben zu können. Eine davon ist das Anhängen dieser Informationen an den das Skript referenzierenden URL (getrennt durch '/'). Diese Informationen (inklusive führendem '/') stehen dann in der Umgebungsvariablen PATH_INFO.

Leider ist diese Methode der Parameterübergabe die unsicherste und unsauberste. Diese Variable war ursprünglich dazu gedacht, einen im Anschluß an den virtuellen CGI-Skript-Pfad stehenden Dateinamen zu übernehmen.

Der Zugriff auf ein CGI-Skript erfolgt über einen virtuellen Pfadnamen (z.B.: '/CGI/'). Wird eine Skript-Datei nun mit dem URL 'http:/<server>/CGI/datei' referenziert, dann enthält PATH_INFO den Wert '/datei'. Dieser Wert wird aber URL-kodiert, was bedeutet, daß alle Sonderzeichen, die in einem URL vorhanden sein können, 'verschlüsselt' werden. Beispielsweise ersetzt ein +-Zeichen im URL das dort verbotene Leerzeichen, und folglich werden Leerzeichen in den Parametern in Pluszeichen umkodiert, so daß es keine Möglichkeit mehr gibt, zwischen echten +-Zeichen und dem '+' als Leerzeichenersatz zu unterscheiden.

Die Parameterübergabe mittels PATH_INFO sollte also vermieden werden, zumal es mit der Parameterübergabe in der Umgebungsvariablen QUERY_STRING eine wesentlich komfortablerere Methode gibt.

PATH_TRANSLATED

Wie eben schon erwähnt, wurde bei der Spezifikation der Variablen PATH_INFO vor allem daran gedacht, Dateinamen in dieser Variablen zu übergeben. Diese Dateinamen nützen aber wenig, wenn nicht gleichzeitig die Stelle im Filesystem, an der diese Datei liegt, übergeben wird. Diese Aufgabe sollte PATH_TRANSLATED übernehmen. Der Server leitet den Inhalt der Variablen PATH_INFO durch sein Mapping-System und ersetzt dabei alle virtuellen durch physische Pfadangaben. So wird beispielsweise bei '/datei' als Wert von PATH_INFO und einem Mapping von '/*' auf '/usr/local/WWW/pub/*' die Variable PATH_TRANSLATED den Wert '/usr/local/WWW/pub/datei' liefern.

QUERY_STRING

Die Umgebungsvariable QUERY_STRING wird in den drei folgenden Fällen gesetzt:

1.Der Aufruf des CGI-Skripts erfolgt aus einem Dokument, das die Eingabe eines Suchindex mittels des ISINDEX-Tags erlaubt. Der Suchindex wird dann in der Umgebungsvariablen QUERY_STRING zur Verfügung gestellt. 2.Der Aufruf des CGI-Skripts erfolgt aus einem anklickbaren (sensitiven) Inline-Bild. In diesem Fall stehen in QUERY_STRING die Bild-Koordinaten des Mausklicks. 3.Das Skript ist der Empfänger der Daten eines Online-Formulars, die mittels der Methode "GET" an das Skript geschickt wurden. In allen drei Fällen hängt der WWW-Client an den, das Skript referenzierenden, URL ein Fragezeichen, gefolgt von den jeweiligen Daten an.

Bei ISINDEX wären diese Daten der Suchbegriff, bei sensitiven Bildern die Mauskoordinaten und bei Online-Formularen die Formulardaten.

REMOTE_ADDR

Diese Variable enthält die IP-Adresse des Client-Rechners. Beispiel: 130.149.18.37

REMOTE_HOST

Der Name des Rechners, von dem der Request stammt, steht in der Umgebungsvariablen REMOTE_HOST. Falls der Server diese Information nicht besitzt, weil z.B. die zugreifende Maschine über keinen Domain-Eintrag verfügt, ist diese Variable leer. In diesem Fall hilft REMOTE_ADDR weiter. Beispiel: quofum.cs.tu-berlin.de

REMOTE_IDENT

Falls auf dem Client-System ein Authentifizierungsserver nach RFC 931 läuft, kann der WWW-Server die Benutzerkennung des Clients ermitteln und sie dem CGI-Skript in REMOTE_IDENT mitteilen.

Da solche Authentifizierungsserver aber nicht in jedem Fall glaubwürdig sein müssen, sollte man diese Angaben mit Vorsicht behandeln und allenfalls für Logging-Zwecke benutzen.

REMOTE_USER

Bei per Kennung geschützten Dokumenten gibt diese Variable den Benutzernamen an. Dieser muß nicht notwendigerweise mit der UNIX-Benutzerkennung identisch sein.

REQUEST_METHOD

Die Methode, mit der die Anfrage erfolgte, ist in der Umgebungsvariablen REQUEST_METHOD zu finden. Bei HTTP als Server-Protokoll wären "GET", "HEAD", "PUT", "POST", usw. als Beispiele zu nennen.

SCRIPT_NAME

Diese Umgebungsvariable enthält den Dateinamen des Skripts inklusive des virtuellen Pfads. Diese Variable wird hauptsächlich für Selbstreferenzierungen des Skripts benötigt, da die Skriptdateien selbst nicht wissen können, daß sie über einen virtuellen Pfadnamen zu erreichen sind.

SERVER_PORT

In dieser Variablen steht die Portnummer, an die die Anfrage gesendet wurde (im allgemeinen: Port 80).

SERVER_PROTOCOL

Der Name und die Version des Protokolls, mit dem die Anfrage an den Server gestellt wurde, sind in der Umgebungsvariablen SERVER_PROTOCOL zu finden. Format: <protocol>/<revision>

Für den CGI-Programmierer sind zunächst nur folgende davon wichtig:

SCRIPT_NAME welches Script muss ausgeführt werden
PATH_EXPANDED der reale Pfad zur gewünschten Datei
QUERY_STRING die über die URL übertragenen Zusatzinformationen

Hinweis: Die tdbengine bereitet diese Informationen vollautomatisch auf.

Die Ein- und Ausgabekanäle

Diese Informationen reichen jedoch nicht aus. Insbesondere hat das CGI-Programm auf diese Weise noch keine Möglichkeit, seine Ergebnisse (Ausgaben) dem Klienten mitzuteilen. Es wäre nun zwar denkbar, dass das CGI-Programm eine der Environment-Variablen ändert (und dorthin seine Ausgabe schreibt), woraufhin der http-Server diese an den Klienten überträgt. Das hätte allerdings zwei gravierende Nachteile: Der Speicherplatz für das Envorinment ist begrenzt, wodurch auch die Antworten des CGI-Programms begrenzt wären. Und schließlich müsste der http-Server die Datenübermittlung übernehmen und wäre an dieser Stelle für andere Aufgaben nur eingeschränkt einsetzbar. Deshalb sieht der CGI-Standard vor, dass dem CGI-Programm direkt der Ausgabekanal zum Klienten übergeben wird. Die Beschränktheit des Environments hat auch zur Folge, daß für größere Informationsübertragungen vom Klienten zum CGI-Programm ein zusätzlicher Übertragungskanal eingerichtet wird. Somit werden also beim Start des CGI-Programms zwei Informationskanäle eingerichtet:

  • StdOut zur Übertragung von Informationen vom CGI-Programm zum Klienten
  • StdIn zur Übertragung von Informationen vom Klienten zum CGI-Programm
Während aber StdOut immer eingesetzt wird (ein CGI-Programm muss eine Antwort liefern), wird StdIn nur in ganz speziellen Fällen verwendet.

get und post

Für die Übertragung von Informationen vom Klienten zum Server sieht der CGI-Standard zwei Methoden vor:

get

hier werden alle Informationen in der URL übergeben. Dabei werden die Zusatzinformationen von der ursprünglichen URL durch ein Fragezeichen "?" abgetrennt Alles was nach dem Fragezeichen kommt, überträgt der http-Server in die Envonment-Variable QUERY_STRING. Einzelne Teilinformationen werden durch das "&"-Zeichen voneinander abgetrennt.

Beispiel: http://www.tdb-engine.de/cgi-tdb.prg?command=read&page=main.
QUERY_STRING=command=read&page=main.

post

hier werden alle Informationen in den StdIn-Kanal des Servers übertragen

Daraus folgt schon, dass ein normaler Link <a href="..."> nur die get-Methode verwenden kann (weil hier ja nur die URL übertragen wird). Nur in Formularen kann man wählen welche Methode eingesetzt werden soll:

<form method="get"... -> get
<form method="post" -> post

Hinweis: In Formularen ist sogar eine gemischte Form möglich, weil hier einerseits die URL für den Programmaufruf angegeben wird (action="...) und damit get-Zusätze enthalten kann, andererseits die Formularfelder mit der Methode "post" übertragen werden können.

Und so werden Formularfelder und deren Inhalte an den Server (und damit auch an das CGI-Programm) übertragen:
 

<input type="text" name="xyz"> xyz=Eingabe des Benutzers
<input type="hidden" name="xyz"> xyz=Eingabe des Benutzers (unverschlüsselt!)
<input type="checkbox" name="xyz" value="1"> xyz=1, wenn vom Benutzer ausgewählt
<input type="radio" name="yxz" value="1"> xyz=1, wenn diese Option ausgewählt wurde
<input type="radio" name="xyz" value="2"> xyz=2, wenn diese Option ausgewählt wurde
<select name="xyz"> xyz=1, wenn diese Option ausgewählt wurde
<option value="1">
<option value="2">...
</select>
<select name="xyz" multiple> xyz=1&xyz=2.. wenn diese Optionen ausgewählt wurden
<option value="1">
<option value="2">...
</select>
<textarea name="xyz">...</textarea> xyz=Inhalt des Textfeldes
<input type="submit" name="xyz" value="done"> xyz=done, wenn dieser Schalter betätigt wurde

Beispiel: In einem HTML-Dokument steht folgendes Formular

<form action="http://www.tdb-engine.de/cgi-tdb/savemail.prg" method="get">
E-Mail: <input type="text" name="email"><br>
Name: <input type="text" name="name"><br>
<input type="submit" name="done" value="absenden">
</form>

Der Anwender füllt die beiden Felder aus mit "info@tdb-engine.de" und "Webmaster".
Der Brower schickt demnach folgende URL an den http-server:

http://www.tdb-engine.de/cgi-tdb/savemail.prg?email=info@tdb-engine.de &name=Webmaster&done=absenden

Wenn im Formular nichts anderes angegeben wird, werden die vom Benutzer eingegeben Daten in eine spezielle Form gebracht, die mit url-encoding bezeichnet wird. Denn damit die Daten über eine normale URL übertragen werden können, dürfen viele Zeichen nicht verwendet werden (Beispiel: Leerzeichen, Umlaute, &/?...). Aus diesem Grund werden solche Zeichen vor der Übertragung in URL-zugelassene Zeichen(-Folgen) umgewandelt. Da die Codierung (zumindest bei Formularen) vom Browser erledigt wird, und die Decodierung auf der Server-Seite komplett von der tdbengine (nicht jedoch vom http-Server!) erledigt wird, wollen wird dieses Thema hier nicht weiter vertiefen.

Sie können sich die Codierung ansehen, wenn Sie beispielsweise eine der vielen Suchmaschinen verwenden, Suchbegriffe mit Umlauten eingeben und die resultierenden URLs genauer betrachten.

Hinweis: Das erweiterte Protokoll multipart/form-data wird in diesem Kurs nicht behandelt.

Zusammenfassung

In dieser Lektion ging es um die wesentlichen Grundbegrife. Sie sollten jetzt wissen, was ein CGI-Programm ist, wo es läuft, und wie der Informationsaustausch zwischen Klient und Server prinzipiell funktioniert.

Aufgaben:

1. Woran erkennt ein http-Server, dass es sich einer URL um einen CGI-Aufruf handelt?

2. Rufen Sie im Internet folgende URL auf: http://www.tdb-engine.de/scripts/set.prg
Sie erhalten eine Liste mit (fast) allen Environment-Variablen, die der http-Server (in diesem Fall der Internet Information Server) einem CGI-Programm zur Verfügung stellt. Aus welcher dieser Environment-Variablen kann man die Browser-Software des Klienten erkennen? Wie lautet diese Angabe für Ihren Browser.

3. Wie heißt das CGI-Programm, das bei Yahoo eine Suchanfrage beantwortet?

4. Sie haben folgendes Formular in einer HTML-Seite:

<form action="http://www.meinedomain.de/cgi-tdb/anmeldung.prg" method="get">
Vorname: <input type="text" name="Vorname"><br>
Name: <input type="text" name="Name"<br>
<input type="submit" name="command" value="absenden">
</form>

Der Anwender füllt die Felder mit "Hans" und "Müller" aus und drückt den "absenden"-Schalter.
Wie lautet die URL, die der Klient an den server schickt?

5. Was enthält in diesem Fall (Aufgabe 4) die Environment-Variable QUERY_STRING?