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).
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.
