Von: Ulrich Schmitz
Als interaktives Medium beschränkt sich das World Wide Web nicht nur auf die Präsentation von Daten, sondern tritt auch mit dem Benutzer in Dialog, wenngleich dieser Aspekt vielen Web-Sites in der Praxis abgeht. Standardmechanismus ist dabei die Eingabe über Formulare, in die der Benutzer seine Wünsche, Meinungen und ähnliche Informationen eingeben kann.
Prinzipiell stellt HTML einiges an Kommunikationsmöglichkeiten zur Verfügung. In Präsentationsrichtung, also vom Server zum Browser, bleiben kaum Wünsche offen: Mit Text, Grafik, Sound, Animationen, der Möglichkeit für aktive Komponenten und vielem anderen mehr sind die Optionen für die Überbringung und Darstellung von Informationen reichhaltig. In der Gegenrichtung, also vom Browser zum Server, besteht jedoch ein Defizit. Die dafür vorgesehenen HTML-Formulare, die mit dem <FORM>-Tag gekennzeichnet werden und mittels diverser Typen von <INPUT>-Tags Eingaben entgegennehmen, haben einige konzeptionelle Schwächen.
Aus Sicht des Web-Designers ist es eine starke Einschränkung, daß - abhängig von der jeweiligen Browser-Implementation - Formularelemente jedwede Art von Formatierung ignorieren und meist in einer Courier-ähnlichen Standardschriftart und -größe angezeigt werden. In einer aufwendig grafisch und typografisch gestalteten Seite können Formularelemente wie Fremdkörper wirken.
Aber selbst aus rein technischer Sicht lassen die Eingabeelemente (<INPUT ...>) von HTML einiges an Funktionalität vermissen. Daß komplexere Kontrollelemente wie editierbare Tabellen, Strukturansichten (Treeviews) und ähnliches fehlen, ist zur Not noch akzeptabel; solche Interaktionsmechanismen sind meist anwendungsspezifisch, so daß man sie ohnehin selbst programmieren muß, etwa in Java.
Einbahnstraße für Datentaxis
Wesentlich einschränkender ist die fehlende Möglichkeit, eine Datei vom Browser aus zum Server zu übertragen. Das Problem ist sicherlich nicht neu, die Standardlösung bisher war der Datentransfer via File Transfer Protocol (FTP). Ob dies mit einer FTP-Clientsoftware, die vom Anwender bedient werden mußte, oder mit einem Browser-Plugin für diese Aufgabe geschah, ist dabei irrelevant. Dieser Ansatz ist aber aus diversen Gründen auf lange Sicht unbrauchbar:
Zielsetzung bei Intranet-Lösungen ist es in der Regel, den Web-Browser als das einzige Front-end auf dem Rechner des Anwenders zu verwenden.
Der Benutzerzugang über FTP ist schwierig zu administrieren. Dabei ist es gerade das Ziel, den Anwender von den Komplexitäten des Web-Servers zu befreien, auch um zu verhindern, daß versehentlich destruktive Manipulationen vorgenommen werden. Der typische "WWW-Gelegenheitssurfer" sieht sich mit einer FTP-Software völlig überfordert.
Dieses Problems hat sich die Internet Engineering Taskforce (IETF, http://www.ietf.org) schon vor einiger Zeit angenommen. Die IETF ist ein loser Zusammenschluß von Mitgliedern der Internet-Industrie, die sich aus diversen Unternehmen und unabhängigen Teilnehmern rekrutieren. Schon im November 1995 hat eine Arbeitsgruppe des IETF unter Larry Masinter (http://www.parc.xerox.com/istl/members/masinter/), die bei der Xerox Corporation angestellt sind, einen Entwurf für eine Erweiterung von HTML und HTTP vorgestellt. Er wurde unter der Bezeichnung RFC 1867 (http://info.internet.isi.edu/in-notes/rfc/files/rfc1867.txt und http://www.faqs.org/rfcs/rfc1867.html) veröffentlicht.
"RFC" steht dabei für einen Schritt des üblichen IETF-Publikationsmechanismus, nämlich für "Request For Comments".
Daß der RFC 1867 immer noch mit dem Status "Experimental" gekennzeichnet ist, kann vielleicht als Indiz dafür gewertet werden, daß dieser Konsolidierungsmechanismus nicht immer konsequent greift, ändert aber nichts an der Substanz des Entwurfs, der sehr weit ins Detail geht. Dabei werden mit tiefschürfenden Begründungen, Analysen und Kompatibilitätsbetrachtungen sowohl HTML-Mechanismen für die entsprechenden Browsererweiterungen diskutiert, als auch die HTTP-Protokollerweiterungen, die von den Servern berücksichtigt werden müssen.
Einfach für Anwender
Für die Browserseite reduziert sich aus Anwendersicht die Anwendung von File-Uploads auf ein neues <INPUT>-Tag für Formulare mit der Syntax
<input NAME="FeldName"
TYPE="file">
sowie einen neuen Kodierungstyp für das Formular, auf den wir gleich zurückkommen.
Die etablierten Browser unter Windows zeigen, sofern sie dieses Tag unterstützen, an der entsprechenden Stelle ein Eingabefeld für den Dateipfad sowie einen Button, der dann "Browse" oder "Durchsuchen" heißt. Dieser Button öffnet den Windows-typischen "Datei öffnen"-Dialog, erspart dem Anwender also gegebenenfalls die manuelle Eingabe des Pfads der Datei, die er kopieren möchte. Unter anderen Betriebssystemen soll dieser Tag äquivalente Benutzerinteraktion ermöglichen.
Mime-Modifikation angezeigt
Die zweite Frage, um die sich auch ein großer Bereich von RFC 1867 kümmert, dreht sich darum, in welchem Format der Browser einen Formularinhalt, der auch Daten aus einer Datei enthält, an den Server übertragen soll.
Wenn der Server zur Entgegennahme des Datenstroms ein CGI-Programm (CGI = Common Gateway Interface) verwendet, muß es den Datenstrom anhand dieser Trenner auseinandernehmen. Innerhalb der Segmente sind die Daten der normalen Felder im Klartext lesbar enthalten. Eine gewisse Ausnahme stellen Segmente mit Dateiinhalten dar. Die Optik mit den diversen Sonderzeichen läßt schon vermuten, was "Multipart/Form-Data" gegenüber anderen Internet-Verfahren ungewöhnlich erscheinen läßt: Die Daten der Dateien werden tatsächlich roh binär in den Datenstrom einkodiert und nicht in Base64 oder UUEncode-Format.
Dies ist auch der Aspekt, der dieses Format für die Auswertung auf dem Server etwas unhandlich macht. So kann ein CGI-Programm die Daten einfach standardmäßig über den Eingabestrom stdin entgegennehmen, wenn man daran denkt, diesen auf Binärmodus umzuschalten. Man muß sich aber darauf verlassen, daß die von der Servervariable CONTENT_LENGTH gelieferte Größenangabe korrekt ist, da man wegen des binären Charakters der Daten nicht auf das EOF-Zeichen prüfen kann.
Weiterhin hat man die Unannehmlichkeit, daß die "normalen" Daten am einfachsten durch zeilenweises Lesen der Daten zu bekommen sind, andererseits aber die Binärdaten auf einen Rutsch gelesen werden müssen. Dann muß in den Binär-Daten noch nach der abschließenden Boundary gesucht werden, um dieses Segment korrekt als Binärdatei auf dem Server ablegen zu können. Diese Suche kann aber nicht über die String-Funktionen von C erfolgen, da diese durch die Null-Bytes in den Binärdaten ausgehebelt werden.
Übrigens stellen auch "Active Server Pages" (ASP) keinen Königweg dar, weil sie zwar mit Request.BinaryRead() den Datenstrom entgegennehmen, ihn aber wegen einer Typinkompatibilität nicht direkt verarbeiten können. Der Datenstrom ist letztlich ein Array von Bytes, den die ASPs aber gerne als Array von Variants interpretieren möchten. Diese Byte-Fummelei und das damit verbundene Debugging einer Serveranwendung ist ein unerquickliches Thema, weshalb das abgedruckte Listing wmupload.c sich damit begnügt, den Datenstrom exemplarisch entgegenzunehmen, in einer Zwischendatei abzulegen und die weitere Arbeit an eine ASP zu delegieren, denn sie ist einfacher zu handhaben.
Posting Acceptor und anderes
Es ist sicherlich nicht jedermanns Sache, solche Serveranwendungen selbst zu implementieren. Für die meisten Server stehen auch fertige Lösungen entweder kostenlos oder gegen einen Obolus zur Verfügung.
Für den "Internet Information Server" (IIS) steht schon seit geraumer Zeit der "Microsoft Posting Acceptor" frei zur Verfügung.
Neben diversem "Krimskrams" installiert der Posting Acceptor auf dem Server eine DLL namens cpshost.dll, die eben jene Funtionen enthält, multipart/form-data-kodierte Datenströme korrekt aufzusplitten und auf dem Server abzulegen. Als Vorlagen für eigene Anwendungen kann man vom Posting Acceptor auf dem Server installierte ASPs verwenden, die verschiedene Einsatzgebiete des Uploads abdecken. Ein einfaches, leicht anzupassendes Beispiel für File-Upload mit dem Posting Acceptor findet man in http://servername/siteser ver/publishing/uploadnd.asp.
Die Konfiguration des Posting Acceptor geschieht über eine Datei namens PASetup.inc, die von den Upload-ASPs eingeschlossen wird. Diese Vorgehensweise ist unter Umständen ungewohnt für jemanden, der nicht schon seit längerem mit ASPs arbeitet. Letztlich reduziert es sich aber meist darauf, die dort definierte Variable TargetURL so zu modifizieren, daß damit das gewünschte Zielverzeichnis definiert wird. In der Voreinstellung ist TargetURL so besetzt, daß sich ein Pfad nach dem Schema http://servername/SiteServer/Publishing/Users/benutzername/ ergibt, wobei servername und benutzername dynamisch anhand der aktuellen Servervariablen eingesetzt werden.
Dieses Schema ist wohl am ehesten geeignet für Personal Homepages bei einem Provider oder ähnliche Zwecke, demonstriert aber gut, wie man dy-namisch konfigurierte Upload-Pfade mit dem Posting Acceptor realisieren kann. Gegebenenfalls kann man dort auch einfach einen Pfad eintragen. Für die Antwortseite, die zum Beispiel eine upgeloadete Grafikdatei auch gleich anzeigen kann, muß lediglich die Variable RepostURL in PASetup.inc passend gesetzt werden.
Bei der Einrichtung ist dann nur noch zu beachten, daß die definierten Verzeichnisse auch existieren, und vor allem, daß die Schreibrechte auf diese Verzeichnisse auch richtig gesetzt sind, so daß der Posting Acceptor auf dem Web-Server, der ja einen speziellen anonymen Account verwendet, die entsprechenden Dateien auch schreiben kann.
Danach steht eigentlich nichts mehr im Wege, die Sites auf dem eigenen Server um diesen neuen Kommunikations- und Datenkanal zu erweitern. (us)