nicht angemeldet
Hi,
ich habe alle CSS und JS-Dateien natürlich
ausgeschlossen. Genau wie alle NE kleiner/gleich 4.0
Netscape kleiner/gleich 4.03 sendet ohnehin keine "Accept-Encoding: gzip"-Header.
Aber 4.06 bis 4.08 solltest Du ausschließen, die sind ziemlich kaputt.
Die Anwendung teste ich mit IE 6.0. Sobald aber ein
Formular geschickt wird, wird doch gzip aktiv
.. weil es bestimmte Informationen über die spätere Entscheidung, zu komprimieren oder nicht, _nur_ aus dem ankommenden HTTP-Header entnehmen kann - und zwar die Kriterien für alle "mod_gzip_item_**clude reqheader"-Regeln.
Beispielsweise findet es nur dort den Namen des UserAgent.
Also muss es mit dem Modul zusammenhängen.
Vielleicht gibt es da irgendeine Einstellung bzgl.
der zu verwendenden Dateigröße, die es zu beachten
gilt?
Mir ist nicht in Erinnerung, daß schon jemand diesen Effekt im Detail verstanden hat. So tief drin bin ich nicht in der Logik der Apache-internen Abläufe, daß ich wüßte, wer da wann seine Finger in welchen Daten hat.
192.168.6.6 - - [07/Mar/2002:13:21:45 +0100]
"www.meine_domain.de POST save_customer.cfm
HTTP/1.1" 200 753 mod_gzip: DECLINED:TOO_SMALL
In:521 -< Out:0 = 0 Prozent.
Diese Datei, die die eigentliche auszuführende
Datei einbindet, wird ebenfalls vom gzip
ausgeschlossen (was doppelt seltsam ist, denn,
wenn diese ausgeschlossen wird, dann aber eine
einbindet, die von der größer her wieder
auszuführen wäre, warum kommt es dann zum Fehler?)
Da müßte ich jetzt verstehen, was Du mit "einbinden" meinst.
Vielleicht liegt Dein Problem überhaupt in der Art und Weise, wie ColdFusion sich dem Apache gegenüber verhält? Wenn das nicht einfach die normale Handler-Schnittstelle bedient (ähnlich wie etwa mod_ssl), kann es ggf. mit mod_gzip Probleme geben. (Hast Du andere ColdFusion-Seiten, die funktionieren?)
Im Gegensatz zu den gif's, die auch augeschlossen
werden, erscheint nicht folgender Eintrag im Logfile
des gzip: DECLINED:EXCLUDED In:0 -< Out:0 = 0
Prozent. Ich würde eigentlich erwarten, dass bei
"In:xxx" im oberen Fall ebefalls 0 Bytes stehen
sollte.
Diese beiden Meldungen entstehen zu unterschiedlichen Zeitpunkten.
DECLINED:EXCLUDED finden lange _vor_ der Ausführung des eigentlichen HTTP-Requests statt, kann deshalb auch nicht aufgrund einer Regel aus Filterphase 2 entstanden sein.
DECLINED:TOO_SMALL dagegen kann wiederum erst nach der Verarbeitung des HTTP-Requests festgestellt werden, deshalb ist zu diesem Zeitpunkt auch das Log-Feld mit der Eingabegröße schon gesetzt.
Schau Dich mal unter
http://www.schroepl.net/projekte/mod_gzip/status_codes.shtml
um ...
Das Apache Log-File liefert mir übrigens: "[error]
mod_gzip: TRANSMIT_ERROR:10054"
Ups - da bist Du dann mitten drin in der Verarbeitung, und mod_gzip stellt fest, daß die Zahl der gerade gesendeten Bytes nicht mit der Zahl der zu senden versuchten Bytes übereinstimmt ... das ist einer der "this can't happen"-Fehler.
Und das Cold Fusion Log File gibt "Warning","TID=
864","03/07/02","11:40:53","(Apache) A network I/O
error occurred while writing the reply back to the
web server." raus.
Eben - so was Ähnliches halt. Vielleicht hat irgendwer (Coldfusion?) bereits die Verbindung zugeklappt, auf der mod_gzip jetzt senden möchte oder was auch immer.
Es ist leider _nicht_ so, daß sich sämtliche Apache-Module (vor allem die 3rd-party-Teile) zwingend an irgendwelche Apache-API-Spielregeln halten würden ...
Viele Grüße
Michael