wichtige Bemerkungen zum Quelltextarchiv UpLoad



Das Projekt UpLoad zeigt Musterlösungen für die Entwicklung einer Servererweiterung für Windows-Webserver, mit der der Datei-Upload in den Webbereich per HTML-Formular ermöglicht wird. Dem liegen die Vorgaben aus dem Memo RFC 1867 zugrunde.

Eine wiederverwendbare Bibliotheksfunktion namens GetPostedContent() in der Delphi-Unit PostContent.pas kapselt den Kern von RFC 1867 und vereinfacht so eigene Upload-Lösungen.

die Versionen der Delphi-Musterquelltexte

Das Archiv Upload.zip beinhaltet die Programm-Quelltexte zu meinem Artikel "Datei-Upload einmal anders" in der Zeitschrift "Der Entwickler" Heft 06/2001.

Als Programmierer finden Sie sowohl eine Version für die Profiprogrammierung mit der Client-Server- bzw. Enterprise-Version von Delphi als auch eine Variante für Programmierer, die nur über Delphi-Standard verfügen. Pro Entwicklungsplattform ist je eine CGI- als auch eine gleich funktionierende ISAPI-Webapplikation als Muster enthalten.

Die Profi-Versionen finden Sie im Ordner Profi. Sie sind auf Delphi 5 Enterprise abgestimmt. Falls Sie mit Delphi 4 Client/Server arbeiten, müssen Sie vor dem Compilieren der Projektdatei UpLoad.dpr deren Zeile
  uses WebBroker
durch
  uses HTTPApp
ersetzen.

Die Standard-Versionen wurden unter Delphi 3 Standard entworfen und bei gleichem Leistungsumfang auf einem niedrigeren Programmierniveau ohne die speziellen Web-Applikations-Objekte realisiert. Sie sind aufwärtskompatibel und in moderneren Delphi-Versionen zu verarbeiten. Sollte Ihr Compiler ab Delphi 5 einen Typfehler bei Parametern bemängeln, ändern Sie an den entsprechenden Stellen die Integer-Variablen in Cardinal-Werte. Delphi 3 seinerseits benötigt den Integer-Typ.

die Parameterdatei UpLoad.ini

Die Servererweiterungen UpLoad.exe und UpLoad.dll benötigen eine Hilfsdatei zur korrekten Arbeit. Das ist die Parameterdatei UpLoad.ini im Ini-Stil. Sie muß im selben Arbeitsverzeichnis wie die Webapplikation liegen.

Die Datei UpLoad.ini enthält zwei allgemeine Parameter sowie die Daten der berechtigten Benutzer nach folgendem Muster:

 [Settings]
 TempDir=E:\Temp
 Answer=C:\Web\cgibin\UpLoad.htm

 [Einkauf]
 Pass=geheim
 UserDir=C:\Web\www\einkauf\aktuell

 [Verkauf]
 Pass=pssst
 UserDir=C:\Web\www\verkauf\aktuell

TempDir gibt den temporären Pufferspeicher für hochzuladende Dateien auf dem Servercomputer an. Beim Fehlen dieser Angabe wird das systemeigene Temp-Verzeichnis benutzt.

Answer gibt Ort und Namen der HTML-Schablone für die Antwort auf den Upload-Versuch an. Beim Fehlen dieser Angabe wird nach einer Default-Schablone namens Upload.htm im selben Verzeichnis gesucht, in dem auch die Servererweiterung liegt. Fehlt auch diese, wird ohne jede Vorlage eine primitive Not-Antwortseite generiert.

Alle weiteren Abschnitte sind Benutzerdaten. Für jeden Benutzer mit Upload-Berechtigung ist eine gesonderte Sektion vorzusehen. Der Benutzername ist mit dem Abschnittsnamen identisch. Pro Benutzer ist ein Wert Pass mit dem Passwort und ein Wert UserDir mit dem persönlichen Upload-Verzeichnis vorzusehen.

Sicherheitshinweis: Das Demo verwendet keine verschlüsselten Passwörter. Deshalb darf die Datei UpLoad.ini nie für Surfer im Web sichtbar sein. Sperren Sie unbedingt die Lese-Rechte für das Serververzeichnis, in dem die Anwendung und die Ini-Datei liegen.

die Antwortschablone UpLoad.htm

Als Reaktion auf den Dateitransfer soll dem Benutzer eine dynamisch generierte Antwortseite angeboten werden. Name und Ordner der entsprechenden Schablone sind im Abschnitt [Settings] der Datei Upload.ini eingetragen. Defaultmäßig heißt die HTML-Vorlage UpLoad.ini und liegt im selben Verzeichnis wie die Webapplikation.

Die Antwortschablone ist eine ganz gewöhnliche HTML-Datei und kann frei nach Ihren Vorstellungen gestaltet sein. Sie darf lediglich an beliebiger Stelle die drei Spezial-Tags <#msg>, <#date> und <#time> enthalten. Diese werden bei der Ausgabe durch konkrete Werte ersetzt. <#msg> ist dabei die Meldung über den Erfolg oder Misserfolg der Upload-Aktion.

das Start-Formular FileUp.htm

Das Startformular ist die Einstiegsseite in den Dateitransfer. Es ist ein übliches HTML-Formular, dass Sie nach eigenen Wünschen gestalten können.

Als Formularaktion ist die Webapplikation als CGI-Programm oder als ISAPI-Servererweiterung sowie der Kodierungstyp der Formulardaten anzugeben. Entweder mit
  <form action="/cgi-bin/UpLoad.exe" method="POST" enctype="multipart/form-data">
oder mit
  <form action="/cgi-bin/UpLoad.dll" method="POST" enctype="multipart/form-data">

Das Formular muss unbedingt die folgenden drei Formularfelder enhalten, die auch genau so benannt werden:

  <input type="text" name="user">
  <input type="password" name="pass">
  <input type="file" name="upfile">

Anderenfalls müssen Sie im Quelltext der Webapplikation entsprechende Veränderungen vornehmen.

Hinweis: Prinzipiell ist es auch möglich, mehrere Dateifelder in das Formular einzubauen und so mehrere Dateien mit einem Mal zu übertragen. Dazu sind vergleichsweise nur geringfügige Modifikationen am Programmtext der Delphi-Projektdateien notwendig.

Installation der compilierten Programme

Die fertigen Webapplikationen legen Sie bitte gemeinsam mit der Ini-Datei und der HTML-Antwortschablone in ein Verzeichnis Ihres Webs, das Ausführen-Rechte aber keine Lese-Rechte besitzt. Üblicherweise ist hierfür das /cgi-bin-Verzeichnis bereits vorhanden.

Desweiteren legen Sie ein HTML-Formular ähnlich meinem Muster FileUp.htm in ein passendes Dokumententverzeichnis des Webs. Weitergehende Installationsarbeiten sind nicht notwendig.

bekannte Probleme auf diversen Webservern

Die insgesamt 4 unterschiedlichen Varianten (Profi und Standard sowie CGI und ISAPI) der UpLoad-Software wurden ausgiebig auf folgenden Servern getestet und auf deren Besonderheiten abgestimmt: Folgende Probleme wurden erkannt und in den Programmlösungen berücksichtigt:
  1. Bei den Microsoft-Servern sowie beim Apache führen bei CGI Leseversuche von mehr als 4 KByte Daten pro Lesezugriff zum Absturz der Server. Deshalb ist der Pufferspeichers in der Funkion GetPostedContent() nicht größer gewählt.
  2. Bei den Microsoft-Servern und ISAPI wurden pro Lesezugriff tatsächlich zwischen 2...8 KByte Daten gelesen (Intranet mit 100 MBit/s Ethernet-Verbindung), selbst wenn der Pufferspeicher 32 KByte groß war und 32 KByte angefordert wurden. Es wurde deshalb die Puffergröße von 4 KByte aus der CGI-Lösung beibehalten.
  3. Der Sambar-Server 4.4 stellt im Gegensatz zu allen anderen Servern die gesamten Empfangsdaten als zusammenhängenden Block beim ersten Leseaufruf zur Verfügung. Dazu muß bei der Konfiguration des Servers allerdings angegeben werden, welche maximale Content-Länge er entgegen nehmen soll. Bei Versuchen, größere Datein als vereinbart im Upload-Verfahren zu übertragen, stürzt der Server (nicht die Servererweiterung) ab.
  4. Der Apache 1.3.20 arbeitet nicht korrekt mit den ISAPI-Objekten von Delphi 5 zusammen. Es wird ein falscher Wert für TWebRequest.ContentLength geliefert (die Einerstelle des Zahlenwertes wird abgeschnitten). Mit der handprogrammierten ISAPI-Lösung von Delphi 3 hingegen arbeitet Apache korrekt.
  5. Der Apache 1.3.20 liefert bei CGI keinen Wert für die Umgebungsvarialble TEMP. Setzen Sie deshalb unbedingt einen Wert für TempDir in der Datei UpLoad.ini.

Insgesamt mußte der an sich korrekte Code in der Bibliothek PostContent.pas an einigen Stellen mehrmals verändert werden, weil einige Webserver damit funktionierten, andere nicht. Es zeigt sich, dass die Hersteller der Webserver bei der Implementierung der ungeheuren Vielfalt von Funktionen in den Servern einige Spezifikationen recht eigensinnig ausdeuten.

Falls Sie eine der vorgestellten Lösungen verwenden wollen, empfehle ich dringend, die von mir handprogrammierten Standard-Varianten ohne die Spezialobjekte von Delphi 5 zu verwenden. Diese Programme liefen auf allen getesteten Serverplattformen problemfrei und sind zudem ca. 5x schlanker als die analog unter Verwendung der Enterprise-Objekte programmierten Profi-Beispiele.


Aug. 2001       J. Hummel       www.hummel1.de