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