Downloadverhalten des Internet Explorer bei SSL
Im Rahmen eines Kundenprojekts haben uns zwei IE-Besonderheiten Kopfzerbrechen bereitet, die möglicherweise auch in anderen Projekten auftreten könnten.
In besagtem Projekt werden Reports dynamisch per XSL erzeugt und als HTML am Bildschirm dargestellt. Dasselbe Resultat kann auch als XLS-Datei heruntergeladen werden (es handelt sich also technisch um HTML, welches von Excel interpretiert werden kann).
Besonderheit #1:
Der Internet Explorer (getestete Versionen 6-8) weigerte sich bei Verwendung von HTTPS standhaft, die Datei herunterzuladen und bemängelte, dass der Server nicht erreichbar sei.
Das Problem lag letztendlich darin, dass in den Response-Headern die Caching-Parameter ungünstig gesetzt waren:
_res.addHeader(”Pragma”,”no-cache”);
_res.setHeader(”Content-Disposition”, “attachment; filename=”test.xls”“);.
Die Folge davon ist, dass der IE den Download selbst nicht mehr in seinen temporären Ordner schreiben darf und daher die Datei selbst auch nicht herunterladen kann. Die Lösung ist also einfach: falls man Downloads über content-disposition attachment im IE und per HTTPS anbieten möchte, dann darf der Pragma-Header nicht gesetzt sein (oder auf “public” bzw. “private”), und cache-control sollte nicht “no-cache” beinhalten.
Dies gilt im Übrigen primär für Office-Dateien, das wird von Microsoft als gewünschtes Verhalten deklariert und in folgendem Artikel erläutert: https://support.microsoft.com/de-de/
Besonderheit #2:
Der Download wurde zunächst so gelöst, dass in einem unsichtbaren IFrame ein POST-Request per Formular an das entsprechende Downloadservlet durchgeführt wurde. Dies führte dazu, dass der IE eine Browserleiste mit einer Sicherheitswarnung einblendete, da der Download indirekt gestartet wurde. POST war nötig, da wir potentiell eine sehr große Menge an Parametern übergeben haben.
Lösung: Der Download muss direkt gestartet werden, indem die Useraktion (also der Klick) unmittelbar das Zielservlet aufruft. Es läuft also notwendigerweise auf einen GET-Request hinaus. Leider ist die Länge einer GET-URL begrenzt, je nach Browser gelten hier unterschiedliche Limits (IE: 2048 Zeichen, vgl. http://support.microsoft.com/kb/208427). Es sollte also dringend vermieden werden, Downloadrequests mit langen Parameterlisten auszustatten. Dies sollte von vornherein in der technischen Konzeption berücksichtigt werden, um nicht später auf solche Probleme zu stoßen.
