PHP: File upload an IE über HTTPS
FMFlash 26.01.2005 - 16:52 714 6
FMFlash
tranceCoder
|
Folgende Situation: Ein php Skript generiert eine Datei (.csv textfile), nur im Speicher, setzt anschließend die header und gibt es an den client aus: header("Content-Type: text/plain");
header("Content-Length: ".strlen($file['contents']));
header("Content-Disposition: attachment; filename=\"".$file['dlfilename']."\"");
print $file['contents'];
Das Skript liegt im HTTPS Bereich eines Apache Servers. Verwende ich Firefox (genauer gesagt "nicht den IE") funktioniert alles bestens: Der "speichern unter..." Dialog poppt auf, Dateiname passt, direkt in Excel öffnen kein Problem. Nur MUSS es mit dem IE auch funktionieren, aber alles was ich von dem bekomme ist ein "xxx.php konnte nicht geöffnet werden" und weder "öffnen" noch "speichern" funktioniert. Kennt zufällig jemand einen Workaround für dieses schwerwiegende Problem? Edit: Seltsamerweise lösen sich die Probleme immer ziemlich schnell auf nachdem ich mich erstmal dazu entschlossen habe hier zu posten. Die Lösung: Folgende header müssen noch dazugefügt werden damits der IE auch wirklich kapiert: header("Pragma: public");
header("Cache-Control: max-age=0");
Bearbeitet von FMFlash am 26.01.2005, 17:06
|
Rektal
Here to stay
|
Reine Neugier: hast du eine Session verwende, spricht session_start() bevor du das File anbietest?
|
FMFlash
tranceCoder
|
Natürlich nicht. Die header kann man schließlich nur einmal setzen.
|
Ringding
Pilot
|
Hast du geschaut, ob dadurch noch irgendwelche anderen Header beeinflusst werden. Das ist ja total bescheuert! Was haben die Cache-Einstellungen damit zu tun, ob der IE das speichern kann oder nicht? Ok, es wäre nicht das erste Mal, dass sich der IE bescheuert verhält.
|
Rektal
Here to stay
|
Hmn, naja. Ich kenn das Problem u.A. mit Sessions, darum hab ich gefragt. Die default Parameter bei sessions schicken Header mit, die den IE verhindern, Inhalte zu Cachen (oder so ...?), ich bin zu faul es jetzt genau zu analysieren. Beruehmtes Beispiel sind POST requests, im browser auf back -> *bam*. Und ich hab was im Hinterkopf dass der IE mit den Session einstellungen Files nicht im Cache ablegt und dadurch sie nicht fuer den "save as" dialog anbieten kann .. aber hier duerft das eh nicht zutreffen, aber aehnliche Probleme bei HTTPS mit sich bringen (Security-Feature)?
Ich hab ganz sicher dazu Eintraege in der msdn mal gesehen.
|
FMFlash
tranceCoder
|
Hast du geschaut, ob dadurch noch irgendwelche anderen Header beeinflusst werden. Das einzige was beeinflusst wird ist der no-cache header den php üblicherweise automatisch einfügt. Dieser wird durch das Pragma: public setting quasi ersetzt. Das ist ja total bescheuert! Was haben die Cache-Einstellungen damit zu tun, ob der IE das speichern kann oder nicht? Da HTTPS sowieso nie gecached wird seh ich auch keinen logischen Zusammenhang, aber offensichtlich muss man dem IE immer wieder mit Prügeln beibringen was er zu tun hat. Ok, es wäre nicht das erste Mal, dass sich der IE bescheuert verhält. Wem sagst du das .... ![:o](/images/smilies/redface.gif) PS: In normaler HTTP Umgebung funktioniert es auch ohne diesen "Workaround".
|
watchout
Legendundead
|
Hmn, naja. Ich kenn das Problem u.A. mit Sessions, darum hab ich gefragt. Die default Parameter bei sessions schicken Header mit, die den IE verhindern, Inhalte zu Cachen (oder so ...?), ich bin zu faul es jetzt genau zu analysieren. Beruehmtes Beispiel sind POST requests, im browser auf back -> *bam*. Und ich hab was im Hinterkopf dass der IE mit den Session einstellungen Files nicht im Cache ablegt und dadurch sie nicht fuer den "save as" dialog anbieten kann .. aber hier duerft das eh nicht zutreffen, aber aehnliche Probleme bei HTTPS mit sich bringen (Security-Feature)?
Ich hab ganz sicher dazu Eintraege in der msdn mal gesehen. es könnte aber natürlich auch so sein, dass php in der art eingerichtest ist, dass automatisch eine session eröffnet wird
|