Einführungskurs: Lektion 1 [tdbengine.org]

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 übrig: 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) Ergebnisse 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:

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 der 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 eingeschrä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 PC's 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.

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

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.

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.

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:

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
...

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.

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

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 EMail-Adresse des Benutzers, der den Request ausgelöst hat. Nicht alle Browser unterstützen die Übermittlung der User-EMail-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 komfortablere 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

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:

Während aber StdOut immer eingesetzt wird (ein CGI-Programm muss eine Antwort liefern), wird StdIn nur in ganz speziellen Fällen verwendet.

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.

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

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.

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?

<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?