Download im CGI-Kontext: Probleme mit unterschiedlichen Browsern

[Sabine]

Hallo allerseits,
ich habe ein Problem beim Senden einer .zip-Datei in einem CGI-Download-Kontext:

print "content-type: application/octet-stream\n";
print "location: ../software/spring.zip\n\n";

Netscape und MS IE klappen brav ihren Dialog auf und speichern die Datei unter ihrem richtigen Namen dahin, wohin man sie haben will. Konqueror erkennt den MIME-Type und schiebt die Datei ohne zu fragen in den Cache (ganz blöd - weg is sie).

Ich habe das Gleiche vorher mit einer etwas komplizierteren Lösung versucht:
Datei binär gelesen und gepuffert weitergereicht mit dem HTTP-Header

print "content-type: application/octet-stream\n";
print "content-disposition: filename=../software/spring.zip\n\n";

Netscape und Konqueror legen die Datei unter ihrem richtigen Namen ab. MS IE ignoriert leider völlig die content-disposition und will die Datei unter dem Namen des Skripts ablegen - ganz dumme Idee.

Weiß jemand Rat?

Sabine

[Cheatah]

Hi,

print "content-type: application/octet-stream\n";

schreib bitt mindestens "Content" groß.

print "location: ../software/spring.zip\n\n";

Dieser Header _muss_ (in Worten: MUSS) eine absolute URL beinhalten, beginnend beim Protokoll. Schreib bitte "Location" groß.

print "content-disposition: filename=../software/spring.zip\n\n";

"Content-disposition: attachment; filename=spring.zip"

Der Filename _muss_ (in Worten: MUSS) ein Dateiname sein und darf _keine_ Pfadinformation o.ä. beinhalten. Zweck des ganzen ist, dass in einem Speicher-Dialog innerhalb eines Verzeichnisses das als Dateiname (vor-) gewählt wird, was Du vorschlägst - und ich habe noch nie einen Dateinamen "../software/spring.zip" gesehen. Bedenke bitte auch, dass der "/" nicht in allen Filesystemen der Verzeichnistrenner ist; unter MacOS ist es beispielsweise der ":".

Netscape und Konqueror legen die Datei unter ihrem richtigen Namen ab. MS IE ignoriert leider völlig die content-disposition und will die Datei unter dem Namen des Skripts ablegen - ganz dumme Idee.

Wenn der Scriptname auf ".pl" endet und auf dem System mit dem IE Perl installiert ist, versucht er, die Scriptausgabe in den Perl-Interpreter zu jagen - _ganz_ ganz dumme Idee. Andererseits: Der IE hat bereits Probleme mit korrektem HTTP; erwarte bitte nicht, dass er sich bei falschem HTTP richtig verhält.

Cheatah

[Sabine]

Hi Cheetah,

print "content-type: application/octet-stream\n";

schreib bitt mindestens "Content" groß.

Wenns dich glücklich macht - an der Sachlage ändert es leider rein gar nichts. ;-)

print "location: ../software/spring.zip\n\n";

Dieser Header _muss_ (in Worten: MUSS) eine absolute URL beinhalten, beginnend beim Protokoll.

Hab ich mir auch schonmal gedacht, nur hat es am Verhalten der Browser nichts geändert.

Schreib bitte "Location" groß.

Siehe oben.

print "content-disposition: filename=../software/spring.zip\n\n";

"Content-disposition: attachment; filename=spring.zip"

Der Filename _muss_ (in Worten: MUSS) ein Dateiname sein und darf _keine_ Pfadinformation o.ä. beinhalten. Zweck des ganzen ist, dass in einem Speicher-Dialog innerhalb eines Verzeichnisses das als Dateiname (vor-) gewählt wird, was Du vorschlägst - und ich habe noch nie einen Dateinamen "../software/spring.zip" gesehen. Bedenke bitte auch, dass der "/" nicht in allen Filesystemen der Verzeichnistrenner ist; unter MacOS ist es beispielsweise der ":".

Das ist natürlich etwas, was mir eher hätte auffallen müssen. Ist es deswegen nicht, weil ich eine vorbelegte Variable des längeren nicht mehr angesehen habe. Und die war eigentlich für das open vorgesehen. :-(

Leider - hat auch diese Korrektur die Lage nicht entscheidend verbessert. :-((

Netscape und Konqueror legen die Datei unter ihrem richtigen Namen ab. MS IE ignoriert leider völlig die content-disposition und will die Datei unter dem Namen des Skripts ablegen - ganz dumme Idee.

Wenn der Scriptname auf ".pl" endet und auf dem System mit dem IE Perl installiert ist, versucht er, die Scriptausgabe in den Perl-Interpreter zu jagen - _ganz_ ganz dumme Idee. Andererseits: Der IE hat bereits Probleme mit korrektem HTTP; erwarte bitte nicht, dass er sich bei falschem HTTP richtig verhält.

Fazit des Ganzen: nix hat wirklich geholfen - trotzdem dankeschön! Werde dann wohl mal wieder jeden Browser einzeln behandeln müssen.

Sabine

[Cheatah]

Hi,

schreib bitt mindestens "Content" groß.
Wenns dich glücklich macht

mich nicht, aber einige Browser ;-)

Hab ich mir auch schonmal gedacht, nur hat es am Verhalten der Browser nichts geändert.

Nun ja, immerhin hast Du damit eine Fehlerquelle ausgeschaltet, die vielleicht anderen Clients Probleme machte.

Der Filename _muss_ (in Worten: MUSS) ein Dateiname sein und darf _keine_ Pfadinformation o.ä. beinhalten.
Das ist natürlich etwas, was mir eher hätte auffallen müssen. Ist es deswegen nicht, weil ich eine vorbelegte Variable des längeren nicht mehr angesehen habe. Und die war eigentlich für das open vorgesehen. :-(

Bedenke dabei bitte, dass im CGI-Kontext der Begriff "aktuelles Verzeichnis" undefiniert ist. Was auf Deinem Server (momentan) funktioniert, muss unter anderen Umständen noch lange nicht die richtigen Ergebnisse produzieren. Zu Lösungsansätzen siehe Arhiv.

Leider - hat auch diese Korrektur die Lage nicht entscheidend verbessert. :-((

Möglicherweise ist Dein Konqueror fehlkonfiguriert. Die Probleme im IE liegen an dessen HTTP-Untauglichkeit.

Werde dann wohl mal wieder jeden Browser einzeln behandeln müssen.

Normalerweise muss man nur den IE einzeln behandeln - indem man ihn ein ZIP-Archiv schickt. Das allerdings mit dem für ZIP passenden Content-Type, nicht mit application/octet-stream. Möglicherweise solltest Du in diese Richtung nachdenken.

Cheatah