Probleme mit Download von Zip-Dateien

Beitrag von **Melegrian** » 19.01.2009, 14:58

Wollte einige Zip-Dateien zum Download bereitstellen (PHP 5.1.2 ist vorhanden), dabei traten folgende Probleme auf:

Erster Versuch, die Dateien per readfile mit geänderten Namen auszugeben, schlug fehl. Dabei stellte sich heraus, eine Ausführung der PHP-Funktion readfile ist nicht möglich. Ein einfacher Test mit einer einfachen Datei: readfile('test.html');

Ergebnis: Bei Strato, all-inkl und Loswebos keine Probleme, nur beim Server des Hosters, auf dem diese Website mit dem Zip-Dateien eigentlich liegen sollte, keine Ausgabe.

Daraufhin die Zip-Ordner direkt verlinkt. Ergebnis: Download über dem Firefox keine Probleme, doch beim Download über dem IE werden die Dateien irgendwie zerschossen. Was auf dem Desktop ankommt, dass sind Zip-Ordner, die nur eine einzige Datei mit einem nichtlesbaren Text enthalten.

Nächster Versuch, die Zip-Ordner bei Strato, all-inkl und Loswebos abgelegt, Download über IE und Firefox ohne Probleme möglich. Nur bei dem einem, hier nicht genannten Hoster, werden die Zip-Ordner beim Download über dem IE zerschossen.

Den Support angeschrieben und als Antwort erhalten, dass es an den Servereinstellungen nicht liegen könnte. Bei einem Test mit einer Zip-Datei auf einem Testaccount hätte es keine Probleme beim Download gegeben.

Könnte jetzt die Zip-Dateien auf einem anderen Server ablegen, würde dennoch gerne wissen, woher diese Probleme mit dem einen Server kommen könnten.

MfG Mele

von **Anzeige von ABAKUS** »

Content Erstellung von ABAKUS Internet Marketing
Ihre Vorteile:

einzigartige Texte
suchmaschinenoptimierte Inhalte
eine sinnvolle Content-Strategie
Beratung und Umsetzung

Jetzt anfragen: 0511 / 300325-0

Beitrag von **Mork vom Ork** » 19.01.2009, 15:32

Melegrian hat geschrieben:Download über dem Firefox keine Probleme, doch beim Download über dem IE werden die Dateien irgendwie zerschossen. Was auf dem Desktop ankommt, dass sind Zip-Ordner, die nur eine einzige Datei mit einem nichtlesbaren Text enthalten.

Nächster Versuch, die Zip-Ordner bei Strato, all-inkl und Loswebos abgelegt, Download über IE und Firefox ohne Probleme möglich. Nur bei dem einem, hier nicht genannten Hoster, werden die Zip-Ordner beim Download über dem IE zerschossen.

Grundsätzlich hat der IE die Angewohnheit, ankommende Daten zu untersuchen und gegebenenfalls etwas anderes damit zu machen als serverseitig angedacht war. Aus diesem Grund müssen Daten, die zum Download gedacht sind, explizit als application/x-ms-download gekennzeichnet werden, damit der IE auch wirklich den Downloaddialog anzeigt („Speichern als …“).

Dein Problem dürfte mit dieser Eigenart zusammenhängen, hat aber sicher noch irgendeinen kleinen Haken auf Serverseite, denn andernfalls würde es ja bei allen Hostern nicht funktionieren.

Schau dir an, mit welchen Zusatzdaten im HTTP-Kopf die Hoster deine Datei ausliefern; hierfür eignet sich zum Beispiel die Firefox-Erweiterung LiveHTTPHeaders. Interessant sind insbesondere die Content-Zeilen. Falls du damit nichts anfangen kannst, zitiere hier einfach sämtliche HTTP-Kopfdaten, einmal von Strato o.ä. und einmal von Dem-der-nicht-genannt-werden-soll.

Beitrag von **Melegrian** » 19.01.2009, 16:14

Danke für die Antwort. Was ich jetzt nicht ganz verstehe, wo ich mit der Angabe application/x-ms-download hin soll, weil ich die Zip-Ordner zur Zeit direkt verlinke? Mit readfile und Header-Angaben/Content-type wurde ja garnichts ausgegeben.

Beim ersten haut es nicht hin mit dem Download über dem IE. Kann den Hoster nennen, wollte nur keinen Hoster hier negativ umschreiben und am Ende handelt es sich nur um eine Unkenntnis von Zusammenhängen meinerseits. Die anderen drei haben zwei Zeilen weniger und sehen für mich identisch aus. Mit den beiden Zeilen, die der erste mehr hat Vary: Accept-Encoding und Content-Encoding: gzip, kann ich nichts anfangen, soll heißen, kenne mich nich aus.

HTTP/1.1 200 OK
Date: Mon, 19 Jan 2009 14:40:04 GMT
Server: Donald Duck
Last-Modified: Sun, 18 Jan 2009 11:08:11 GMT
ETag: "113815c-190b-d25a5cc0"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 4930
Content-Type: application/zip

------

HTTP/1.1 200 OK
Date: Mon, 19 Jan 2009 14:50:03 GMT
Server: Apache
Last-Modified: Mon, 19 Jan 2009 14:48:11 GMT
ETag: "32c322-1342-460d702f9c0c0"
Accept-Ranges: bytes
Content-Length: 4930
Content-Type: application/zip

------

HTTP/1.1 200 OK
Date: Mon, 19 Jan 2009 14:52:28 GMT
Server: Apache/1.3.37 (Unix)
Last-Modified: Mon, 19 Jan 2009 14:48:51 GMT
ETag: "3ed64f8-1342-497492d3"
Accept-Ranges: bytes
Content-Length: 4930
Content-Type: application/zip

------

HTTP/1.1 200 OK
Date: Mon, 19 Jan 2009 14:54:29 GMT
Server: Apache
Last-Modified: Mon, 19 Jan 2009 14:48:30 GMT
ETag: "aac999-1342-41bab80"
Accept-Ranges: bytes
Content-Length: 4930
Content-Type: application/zip

von **Anzeige von ABAKUS** »

Beitrag von **Mork vom Ork** » 19.01.2009, 17:12

Melegrian hat geschrieben:Danke für die Antwort. Was ich jetzt nicht ganz verstehe, wo ich mit der Angabe application/x-ms-download hin soll

War nur ein Beispiel dafür, dass man dem IE ganz besonders genau erzählen soll, was er machen soll, weil er sich sonst selbständig macht. Diese Selbständigkeit scheint aber entgegen meiner Vermutung nicht das Problem zu sein.

Content-Encoding: gzip
Content-Length: 4930
Content-Type: application/zip

Da haben wir's. Der Server, bei dem es nicht funktioniert, meldet, dass die Daten mit gzip komprimiert seien - was aber wohl nicht stimmt (Dein ZIP-Archiv ist 4930 Bytes groß? Dann wird es nicht weiter komprimiert worden sein.). Ich vermute, dass Firefox die Daten nicht dekomprimieren kann (eben weil sie nicht gzip-komprimiert sind) und sie daraufhin so speichert, wie sie reinkommen, während der IE sie irgendwie doch durch seinen gzip-Dekomprimierer gequetscht kriegt und dementsprechend am Ende nur Müll rauskommt.

Falls sich hinter „Donald Duck“ ein Apache verbirgt, hat Der-Hoster-der-nicht-genannt-werden-soll, höchstwahrscheinlich eine Zeile à la AddEncoding gzip .zip in seiner Konfiguration, die da ganz und gar nicht hingehört.
ZIP und gzip hängen zwar eng zusammen, sind aber nicht dasselbe. ZIP ist ein Archivformat, d.h. speichert viele Dateien in einer, gzip ist ein Komprimierungsformat, d.h. speichert einen komprimierten Datenstrom. Sowohl ZIP als auch gzip verwenden zum Komprimieren ihrer Inhalte die deflate-Methode, das war's aber auch schon. Insofern kann es passieren, dass sich ein ZIP-Archiv irgendwie mit gzip dekomprimieren lässt, aber was dabei rauskommt, hast du ja gesehen.

Kurzum: Weise Den-Hoster-der-nicht-genannt-werden-soll, darauf hin, dass er ZIP-Archive mit falscher Kodierungsmeldung ausliefert.

Beitrag von **Melegrian** » 19.01.2009, 19:12

Danke! Das hilft mir doch schon sehr, zumindest um die Probleme erst einmal besser zu verstehen. Erscheint mir eigentlich alles sehr einleuchtend. Habe noch einmal den Support benachrichtigt, mit einem Hinweis auf diese Antwort. Bin jetzt gespannt, was für eine Reaktion von Seiten des Hosters erfolgt.

MfG Mele

Beitrag von **Melegrian** » 21.01.2009, 12:43

Die Angelegenheit scheint noch etwas verwickelter zu sein, als ursprünglich gedacht. Die Datei, die ich für zerschossen hielt, ist eigentlich nicht zerschossen, nur doppelt verpackt. Nach dem Download lässt sich das Zip-Archiv entpacken und man erhält eine Datei ohne Endung. Hängt man an dieser Datei manuell als Endung .zip an, so lässt sie sich wie ein normales Zip-Archiv entpacken.

Fand in einem anderen Forum einen etwas älteren Thread dazu, mit einer Lösung:

apache liefert fehlerhafte zip dateien an den IE

Im Bereich des modules deflate :

<IfModule mod_deflate.c>
steht eine Linie:

BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

Einfach das ! vor dem no-gzip wegmachen, speichern, apache neustarten und funktioniert.

Das nun wieder den Support mitgeteilt und als Antwort erhalten, so ein Eintrag würde auf ihren Servern nicht existieren.

Nun habe ich nebenher noch diese Seite gefunden: https://httpsd.apache.org/docs/2.0/mod/mod_deflate.html

Meine Kenntnisse in Bezug auf Server sind eigentlich gegen Null, doch verstehe ich dass hier richtig, dass es sich dabei um einen Fehler handelt, bis zu Apache Version 2.0.48 und man halt gerade deshalb diese Zeile einfügen sollte? Nur eben wie im anderen Thread erwähnt, ohne ! vor dem no-gzip? In meiner PHPinfo steht Server API Apache 2.0 Handler.

# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
# the above regex won't work. You can use the following
# workaround to get the desired effect:
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

Mal sehen, was sich nun der Support einfallen lässt. Lange warte ich wohl nicht mehr mit einem KK-Antrag, wenn das so weiter geht.

Beitrag von **Mork vom Ork** » 21.01.2009, 23:01

Melegrian hat geschrieben:Die Angelegenheit scheint noch etwas verwickelter zu sein, als ursprünglich gedacht. Die Datei, die ich für zerschossen hielt, ist eigentlich nicht zerschossen, nur doppelt verpackt.

Wie groß ist denn das Original aus deinem Beispiel oben? Mir kommt das etwas merkwürdig vor, denn wenn die Datei doppelt verpackt ist, warum liefern dann die anderen Server diese Datei nicht doppelt verpackt (Content-Encoding: gzip fehlt) mit exakt der gleichen Länge aus? Nach meinem halbwegs gesunden Menschenverstand müsste sie sich zumindest um ein paar Bytes unterscheiden.

Wie dem auch sei, grundsätzlich macht es eh herzlich wenig Sinn, eine ZIP-Datei nochmals zu verpacken, das Gleiche gilt für JPEG- und PNG-Bilder. Mit anderen Worten: mod_deflate pauschal auf sämtliche Daten loszulassen ist Unsinn, der Hoster-der-nicht-genannt-werden-soll täte gut daran, mod_deflate auf Textdaten zu beschränken (zum Beispiel mit der Zeile AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript).

apache liefert fehlerhafte zip dateien an den IE

BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

Einfach das ! vor dem no-gzip wegmachen, speichern, apache neustarten und funktioniert.

Kein Wunder, mit no-gzip schaltet man die Kompression gänzlich ab. Das kann's nicht sein, sondern fällt eher in die Kategorie Rumdokterei. Und die Erklärung, die dort gegeben wird, halte ich in der Form für falsch.

Das nun wieder den Support mitgeteilt und als Antwort erhalten, so ein Eintrag würde auf ihren Servern nicht existieren.

Wie, und das ist alles? Toller Kundendienst :/

Meine Kenntnisse in Bezug auf Server sind eigentlich gegen Null, doch verstehe ich dass hier richtig, dass es sich dabei um einen Fehler handelt, bis zu Apache Version 2.0.48 und man halt gerade deshalb diese Zeile einfügen sollte?

Das, was dort beschrieben wird, besteht aus drei Zeilen (ist auch in den Beispielen zu mod_deflate zu finden):

# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# MSIE masquerades as Netscape, but it is fine
# BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48
# the above regex won't work. You can use the following
# workaround to get the desired effect:
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html

Die ersten zwei schalten für die alten Netscape-4-Krücken die Komprimierung ab, und weil der IE sich als Netscape-4-Krücke ausgibt, aber diese Probleme nicht hat, wird in der dritten Zeile die Komprimierung für den IE wieder eingeschaltet (!no-gzip = nicht kein-gzip = gzip)

Der Fehler, der dort angesprochen wird, bestand in dem Modul, das die Browserkennung vergleicht, nicht in dem Komprimierungsmodul; der IE wurde nicht erkannt wurde und entsprechend die Kompprimierung nicht wieder eingeschaltet. Die Problematik war also quasi genau andersrum: Der IE wurde wegen des Fehlers ausgenommen. Du hast aber ein Problem, weil der IE einbezogen wird, weil er komprimierte Daten erhält.

Dass die Dame die Funktionsweise nicht ganz verstanden hat, lässt sich auch daran erkennen, dass sie genauso gut hätte raten können, die IE-Zeile ganz wegzulassen. Denn mit ihrer vorgeschlagenen Änderung macht sie nichts weiter, als die schon abgeschaltete Komprimierung nochmals abzuschalten - sinnlos.

In meiner PHPinfo steht Server API Apache 2.0 Handler.

Interessant wäre, welche Serverversion dort angegeben wird. Falls größer als .0.48 hat das eh nix mit dir zu tun.

Mal sehen, was sich nun der Support einfallen lässt. Lange warte ich wohl nicht mehr mit einem KK-Antrag, wenn das so weiter geht.

Das sehe ich auch so. Ein Woche für die Behebung solches Kleckerkrams zu brauchen lässt auf wenig Engagement schließen - oder wenig Kompetenz.

Beitrag von **Melegrian** » 22.01.2009, 14:36

Hallo Mork vom Ork,

das sind jetzt alle Angaben, die ich der PHPinfo entnehmen kann:

Server API Apache 2.0 Handler
Apache Version Donald Duck
Apache API Version 20051115

Zu den verwendeten Dateien:

Größe unverpackt: 11.845
Größe verpackt: 4.930
Größe nach Download über Firefox: 4.930
Größe nach Download über IE: 4.800

Werde wohl mit der Domain umziehen.

Beitrag von **Mork vom Ork** » 22.01.2009, 17:38

Melegrian hat geschrieben:Werde wohl mit der Domain umziehen.

Das ist wohl die beste Möglichkeit. Bis dahin müsste eigentlich eine der folgenden Zeilen in /.htaccess Abhilfe schaffen:

RemoveOutputFilter zip
(entfernt mod_deflate-Kompression für ZIP-Dateien)

oder

RemoveEncoding zip
(entfernt Meldung, Daten aus ZIP-Dateien wären gzip-komprimiert)

Probier' das doch nochmal aus, täte mich interessieren, was hilft.

Beitrag von **Melegrian** » 23.01.2009, 17:41

Habe beide Varianten probiert, auch in Kombination, gebracht hat es nichts. Gestern erhielt ich noch eine Nachricht vom Chef. Er hatte jetzt auch noch einmal Tests durchgeführt. Meine Ergebnisse beim Download über dem IE konnte er bestätigen, doch dieses Problem soll nur bei meinem Webspace auftreten.

Seit heute befindet sich die Domain im Transit-Zustand, das hatte ich mir auch etwas anders vorgestellt. Der neue Hoster gab mir den Rat, nicht auf die Zusendung eines Passwortes von der Denic zu warten, sondern einen KK-Antrag an den Direct Services zusenden. Etwas wird es wohl dennoch dauern, hoffentlich nicht zu lange.

Beitrag von **Mork vom Ork** » 23.01.2009, 19:33

Mysterien der Informationstechnik ...