fileupload geht mit netscape aber nicht mit ie

[alex]

Howdy

also ich benutzte das skript von der seite:
http://selfaktuell.teamone.de/artikel/cgiperl/file-upload/index.htm

und wollte damit files auf dne server laden. Das skript funktioniert mit netscape (4 und 6 unter win und linux) wie gewünscht doch ie und auch opera schreiben nur eine leere datei auf den server...

weiss jemand rat?

danke alex

[Michael Schröpl]

Hi alex,

also ich benutzte das skript von der seite:
http://selfaktuell.teamone.de/artikel/cgiperl/file-upload/index.htm
und wollte damit files auf dne server laden. Das skript funktioniert mit netscape (4 und 6 unter win und linux) wie gewünscht doch ie und auch opera schreiben nur eine leere datei auf den server...

hm. Das klingt allerdings verblüffend.

Christians Skript ist sehr kurz und sehr abstrakt gehalten. Das ist in Deinem Fall leider ein Nachteil.

Im Wesentlichen passiert folgendes:

a) Der Browser bastelt ein MIME-Multipart-Paket zusammen, welches u. a. den Dateinamen und den Inhalt per Auswahldialog bestimmten Datei enthält.

b) Beim Absenden des Formulars werden diese Daten als HTTP-POST-Request zum Server übertragen.

c) Dort wird das beschriebene CGI-Skript aufgerufen, wobei ihm die POST-Daten über stdin angeboten werden.

d) Statt nun aber stdin zu lesen und zu verarbeiten (wofür das Skript u. a. wissen müßte, _daß_ es via POST aufgerufen wurde), überläßt Christian sowohl das Finden der Daten als auch die Zerlegung derselben dem Standardmodul CGI und greift lediglich auf das Ergebnis der Zerlegung zu. Dadurch wird sein Skript so kurz. Und solange der Browser ein korrektes MIME-Multipart-Paket liefert, klappt das auch tadellos - wie Du mit bestimmten Browsern ja ausprobieren konntest.

Was das Skript allerdings nicht gut anbietet, das ist eine Debug-Schnittstelle.
Statt die CGI-Methoden zu verwenden, könntest Du mit einem abgewandelten Skript die gesamten stdin-Daten in eine Datei auf dem Server speichern und dann mal mit einem Editor hinein sehen.
Die Struktur von MIME Multipart besteht aus Blöcken und Trennlinien - bei einem Datei-Upload sind die Daten relativ einfach zu verstehen. Mit etwas Glück kannst Du den Daten, die bei einem Upload via M$IE gegenüber Netscape entstehen, ansehen, in welcher Art und Weise sie sich unterscheiden - falls sie das tatsächlich tun. Nimm dazu eine möglichst kleine, einfach aufgebaute Datei.

All dies würde aber voraussetzen, daß entweder das (bewährte und seit Jahren gut getestete) CGI-Modul einen Fehler enthält oder aber Deine Browser die Datei in einem untauglichen Format auf den Server liefern - was ich beides für unwahrscheinlich halte.
Deshalb beschreibe ich Dir diese Debug-Ansicht der tatsächlich ankommenden Daten eigentlich eher mit der Absicht, diese beiden Möglichkeiten damit auszuschließen und einen Denkfehler an einer anderen Stelle Deiner Version des Upload-Skripts zu suchen.

Es sieht für mich so aus, als müßtest Du Dein Skript ganz normal debuggen.
Dafür gilt generell: Versuche, an möglichst vielen Stellen des Skripts zu erkennen, welche Annahmen dort Deiner Meinung nach erfüllt sein sollten, und überprüfe durch einfache Zwischenausgaben nach stdout, ob der Inhalt Deiner Variablen mit Deinen Erwartungen übereinstimmt.

Und wenn Dein Skript wirklich exakt das von Christian geschriebene ist und Du einen Fehler darin nachweisen können solltest, dann wäre es nett, diesen Fehler hier wieder zu posten (mit entsprechender Begründung).

Viele Grüße
      Michael

[i-netlab]

moin,

also ich benutzte das skript von der seite:
http://selfaktuell.teamone.de/artikel/cgiperl/file-upload/index.htm
und wollte damit files auf dne server laden. Das skript funktioniert mit netscape (4 und 6 unter win und linux) wie gewünscht doch ie und auch opera schreiben nur eine leere datei auf den server...

hm. Das klingt allerdings verblüffend.

Christians Skript ist sehr kurz und sehr abstrakt gehalten. Das ist in Deinem Fall leider ein Nachteil.

Im Wesentlichen passiert folgendes:

a) Der Browser bastelt ein MIME-Multipart-Paket zusammen, welches u. a. den Dateinamen und den Inhalt per Auswahldialog bestimmten Datei enthält.

b) Beim Absenden des Formulars werden diese Daten als HTTP-POST-Request zum Server übertragen.

c) Dort wird das beschriebene CGI-Skript aufgerufen, wobei ihm die POST-Daten über stdin angeboten werden.

d) Statt nun aber stdin zu lesen und zu verarbeiten (wofür das Skript u. a. wissen müßte, _daß_ es via POST aufgerufen wurde), überläßt Christian sowohl das Finden der Daten als auch die Zerlegung derselben dem Standardmodul CGI und greift lediglich auf das Ergebnis der Zerlegung zu. Dadurch wird sein Skript so kurz. Und solange der Browser ein korrektes MIME-Multipart-Paket liefert, klappt das auch tadellos - wie Du mit bestimmten Browsern ja ausprobieren konntest.

Was das Skript allerdings nicht gut anbietet, das ist eine Debug-Schnittstelle.
Statt die CGI-Methoden zu verwenden, könntest Du mit einem abgewandelten Skript die gesamten stdin-Daten in eine Datei auf dem Server speichern und dann mal mit einem Editor hinein sehen.
Die Struktur von MIME Multipart besteht aus Blöcken und Trennlinien - bei einem Datei-Upload sind die Daten relativ einfach zu verstehen. Mit etwas Glück kannst Du den Daten, die bei einem Upload via M$IE gegenüber Netscape entstehen, ansehen, in welcher Art und Weise sie sich unterscheiden - falls sie das tatsächlich tun. Nimm dazu eine möglichst kleine, einfach aufgebaute Datei.

All dies würde aber voraussetzen, daß entweder das (bewährte und seit Jahren gut getestete) CGI-Modul einen Fehler enthält oder aber Deine Browser die Datei in einem untauglichen Format auf den Server liefern - was ich beides für unwahrscheinlich halte.
Deshalb beschreibe ich Dir diese Debug-Ansicht der tatsächlich ankommenden Daten eigentlich eher mit der Absicht, diese beiden Möglichkeiten damit auszuschließen und einen Denkfehler an einer anderen Stelle Deiner Version des Upload-Skripts zu suchen.

Es sieht für mich so aus, als müßtest Du Dein Skript ganz normal debuggen.
Dafür gilt generell: Versuche, an möglichst vielen Stellen des Skripts zu erkennen, welche Annahmen dort Deiner Meinung nach erfüllt sein sollten, und überprüfe durch einfache Zwischenausgaben nach stdout, ob der Inhalt Deiner Variablen mit Deinen Erwartungen übereinstimmt.

Und wenn Dein Skript wirklich exakt das von Christian geschriebene ist und Du einen Fehler darin nachweisen können solltest, dann wäre es nett, diesen Fehler hier wieder zu posten (mit entsprechender Begründung).

Fehler hab ich nicht gefunden aber 2 Verbesserungen
1.
use CGI; verändern zu
use CGI qw(-private_tempfiles );

Damit werden auf jedem System die Tempfiles welche beim Upload angelegt wurden wieder ordentlich gelöscht, außerdem ein Lauschangriff während des Uploads verhindert ,
siehe

http://i-netlab.de/hints/cgi.htm

2.
Die Begrenzung der Dateigröße im HTML Form ist ... naja ;-)
Verbesserung:
die read() Funktion hat einen Rückgabewert! Diesen nutzen und die Buffers aufsummieren - bei Überschreitung entspr. Fehlermeldung.

Schönen Tag, Rolf

Viele Grüße
      Michael

[alex]

Howdy, danke für die ausführliche Antwort.

Ich habe den Fehler / die Ursache entdeckt:
Ich benutze im Formular method="get" und es soll ja method="post" sein.
Bei "post" geht es auch mit IE...

Der Grund warum ich "get" benutzte ist, das ich das Skript in ein CMS einsetzen muss und das geht dann nur per SSI und "get", limitierung des CMS.., aber da werde ich noch mal nachbohren .-)

Vielen Dank
Alex

[Michael Schröpl]

Hi Alex,

Ich benutze im Formular method="get" und es soll ja method="post" sein.
Bei "post" geht es auch mit IE...

Hoppla - auf die Idee, einen Upload mit GET zu machen, wäre ich im Leben nicht gekommen.
Wie willst Du denn den Inhalt der Datei innerhalb eines URL darstellen? Das kann nicht funktionieren.
(Könnte es sein, daß der Mozilla das merkt und automatisch auf POST umstellt? Hast Du Lesezugriff auf das access_log der Zielmaschine? Da steht der dort angekommene Zugriff samt Methode drin ...)

Viele Grüße
      Michael