gzip Module unter Apache erzeugt Fehler bei großen Formularen

[Mike]

Hallo liebe Fachwelt,

ich nutze das gzip Modul für den Apache (unter Windows 2000 / Cold Fusion) und die Komprimierung läuft an sich hervorragend. Alle Einstellungen sind richtig gewählt (hoffe ich). Allerdings erhalte ich ab und an folgende Fehlermeldung:

"Error Occurred While Processing Request

Error Diagnostic Information
Request canceled or ignored by serverServer busy or unable to fulfill request. The server is unable to fulfill your request due to extremely high traffic or an unexpected internal error. Please attempt your request again (if you are repeatedly unsuccessful you should notify the site administrator). (Location Code: 26)"

Meine Vermutung geht dahingehend, dass bei Formularen mit zu großem Inhalt das Modul nicht richtig ausgeführt wird. Sobald ich nämlich ein Textfeld mit sehr großem Inhalt ausfülle, funktioniert es nicht. Bleibt der Inhalt gering, dann führt Apache das Formular aus. Ohne das gzip läuft die Anwendung einwandfrei. Hat jemand damit schon mal Erfahrungen gemacht? Gibt es bestimmte Konfigurationseinstellungen, die es zu beachten gilt?

Hier noch einige Daten:

mod_gzip_min_http 1000
mod_gzip_minimum_file_size    1000
mod_gzip_maximum_file_size 1000000
mod_gzip_maximum_inmem_size   60000

Danke im Voraus für die Hilfe

Gruß

Mike

[Sven Rautenberg]

Moin!

Meine Vermutung geht dahingehend, dass bei Formularen mit zu großem Inhalt das Modul nicht richtig ausgeführt wird. Sobald ich nämlich ein Textfeld mit sehr großem Inhalt ausfülle, funktioniert es nicht. Bleibt der Inhalt gering, dann führt Apache das Formular aus. Ohne das gzip läuft die Anwendung einwandfrei. Hat jemand damit schon mal Erfahrungen gemacht? Gibt es bestimmte Konfigurationseinstellungen, die es zu beachten gilt?

Beim Schicken der Formulare wird doch mod_gzip nicht aktiv. Daran sollte es eigentlich nicht liegen.

Die Error-Logs sind dein Freund.

Hier noch einige Daten:

mod_gzip_min_http 1000
mod_gzip_minimum_file_size    1000
mod_gzip_maximum_file_size 1000000
mod_gzip_maximum_inmem_size   60000

Ich hoffe, du hast Javascript- und CSS-Dateien von der Komprimierung ausgeschlossen, sonst kommt Netscape 4 durcheinander. Der dekomprimiert nämlich wirklich nur HTML-Dateien bzw. den Mime-Typ text/html.

Alternativ könntest du den HTTP-Versionslevel auf 1001 setzen, damit nur HTTP/1.1-fähige Browser (das ist Netscape 4 nicht) komprimierte Inhalte erhalten. Was aber irgendwie doof wäre. Teste am besten anhand von den mod_gzip-Logfiles und mgstat (Statistikauswertung für diese Files im Stile von Webalizer), was am besten geeignet ist.

- Sven Rautenberg

[Mike]

Hallo Sven,

zunächst Danke für die Antwort.

ich habe alle CSS und JS-Dateien natürlich ausgeschlossen. Genau wie alle NE kleiner/gleich 4.0 Die Anwendung teste ich mit IE 6.0. Sobald aber ein Formular geschickt wird, wird doch gzip aktiv, da es sich ja um eine Datei handelt, die der Server an den anfragenden Browser rausschickt. Wie schon gesagt: Ohne gzip läuft alles spitze. Mit gzip ebenfalls. Nur eben bei dieser einen Anwendung nicht, bei der eine menge Formular mit sehr viel Inhalt aktiviert wird. Ohne gzip läuft eben auch diese Anwendung, auch auf anderen Betriebssystemen und Webservern. 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?

Folgenden Eintrag liefert mir bspw. das logfile:

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

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.

Das Apache Log-File liefert mir übrigens: "[error] mod_gzip: TRANSMIT_ERROR:10054"

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.

Was war das?

Gruß

Mike

P.S.: Die Uhrzeit kann man vernachlässigen

Moin!

Meine Vermutung geht dahingehend, dass bei Formularen mit zu großem Inhalt das Modul nicht richtig ausgeführt wird. Sobald ich nämlich ein Textfeld mit sehr großem Inhalt ausfülle, funktioniert es nicht. Bleibt der Inhalt gering, dann führt Apache das Formular aus. Ohne das gzip läuft die Anwendung einwandfrei. Hat jemand damit schon mal Erfahrungen gemacht? Gibt es bestimmte Konfigurationseinstellungen, die es zu beachten gilt?

Beim Schicken der Formulare wird doch mod_gzip nicht aktiv. Daran sollte es eigentlich nicht liegen.

Die Error-Logs sind dein Freund.

Hier noch einige Daten:

mod_gzip_min_http 1000
mod_gzip_minimum_file_size    1000
mod_gzip_maximum_file_size 1000000
mod_gzip_maximum_inmem_size   60000

Ich hoffe, du hast Javascript- und CSS-Dateien von der Komprimierung ausgeschlossen, sonst kommt Netscape 4 durcheinander. Der dekomprimiert nämlich wirklich nur HTML-Dateien bzw. den Mime-Typ text/html.

Alternativ könntest du den HTTP-Versionslevel auf 1001 setzen, damit nur HTTP/1.1-fähige Browser (das ist Netscape 4 nicht) komprimierte Inhalte erhalten. Was aber irgendwie doof wäre. Teste am besten anhand von den mod_gzip-Logfiles und mgstat (Statistikauswertung für diese Files im Stile von Webalizer), was am besten geeignet ist.

• Sven Rautenberg

[Sven Rautenberg]

Re-Moin!

zunächst Danke für die Antwort.

Michael hat ja geschrieben, es gäbe da noch Bugs in mod_gzip.

Warum ich zumindest irritiert bin: mod_gzip sollte eigentlich nur bei vom Webserver gesendeten Daten aktiv sein (irre ich mich da?). Formulardaten werden vom Browser gesendet und sollten eigentlich irgendwie an mod_gzip vorbei zum Webserver und dem passenden Skript gelangen, um dann eine Ergebnisseite zu produzieren, die natürlich wieder gezippt werden darf.

Ich kann nicht nachvollziehen, warum es an mod_gzip liegen soll, wenngleich ich es absolut nicht ausschließen will. Von daher interessiert mich die Geschichte schon.

- Sven Rautenberg

[Mike]

Re-Moin!

Auch Re-Moin, wobei der Morgen schon bald zu ende ist...

tja, so gesehen scheinst Du recht zu haben. Das ist nicht unbedingt einsichtig, warum es so ist. Ich würde ja auch gerne andere Fehlerquellen ausschließen (vielleicht fällt Dir spontan auf die Entfernung noch eine mögliche Fehlerquelle ein), aber wenn da wohl schon ähnliche Fehler woanders aufgetreten sind, dann scheint es doch mit den Formularen zusammenzuhängen. Das wäre nicht so doll. Weißt Du, mit welcher Syntax man ganze Verzeichnisse ausschließen kann? Geht es überhaupt via "file", da man damit eigentlich nur Dateitypen und einzelne Dateien ansprechen kann (denke ich)?

Gruß

Fady

zunächst Danke für die Antwort.

Michael hat ja geschrieben, es gäbe da noch Bugs in mod_gzip.

Warum ich zumindest irritiert bin: mod_gzip sollte eigentlich nur bei vom Webserver gesendeten Daten aktiv sein (irre ich mich da?). Formulardaten werden vom Browser gesendet und sollten eigentlich irgendwie an mod_gzip vorbei zum Webserver und dem passenden Skript gelangen, um dann eine Ergebnisseite zu produzieren, die natürlich wieder gezippt werden darf.

Ich kann nicht nachvollziehen, warum es an mod_gzip liegen soll, wenngleich ich es absolut nicht ausschließen will. Von daher interessiert mich die Geschichte schon.

• Sven Rautenberg

[Sven Rautenberg]

Re-Moin!

Auch Re-Moin, wobei der Morgen schon bald zu ende ist...

Es heißt immer "Moin!". :)

tja, so gesehen scheinst Du recht zu haben. Das ist nicht unbedingt einsichtig, warum es so ist. Ich würde ja auch gerne andere Fehlerquellen ausschließen (vielleicht fällt Dir spontan auf die Entfernung noch eine mögliche Fehlerquelle ein), aber wenn da wohl schon ähnliche Fehler woanders aufgetreten sind, dann scheint es doch mit den Formularen zusammenzuhängen. Das wäre nicht so doll. Weißt Du, mit welcher Syntax man ganze Verzeichnisse ausschließen kann? Geht es überhaupt via "file", da man damit eigentlich nur Dateitypen und einzelne Dateien ansprechen kann (denke ich)?

Von der mod_gzip-Site hab ich das hier:
mod_gzip_item_include file .htm$
mod_gzip_item_exclude file .css$

Tja, was sehen ich? Reguläre Ausdrücke beschreiben ein Dateinamensmuster.

Die offizielle Beschreibung ist nicht wirklich erklärend:

mod_gzip_item_include ARG1 ARG2
ARG1=[mime,handler,file,uri,reqheader,rspheader]
ARG2=[Name of item to INCLUDE in list of things that should be compressed]

mod_gzip_item_exclude ARG1 ARG2
ARG1=[mime,handler,file,uri,reqheader,rspheader]
ARG2=[Name of item to EXCLUDE from list of things that should be compressed]

Da steht nicht genau drin, was ARG2 genauer ist. Aber im Zweifel kann man einen bestimten Dateinamen damit ganz sicher ausschließen. Also z.B. alles, was um das Formular herumliegt.

- Sven Rautenberg

[Michael Schröpl]

Hi,

Die offizielle Beschreibung ist nicht wirklich erklärend:
Da steht nicht genau drin, was ARG2 genauer ist.

Du hast zielsicher erkannt, woran es bei mod_gzip vorrangig krankt: Dem Entwickler sind solche Sachen natürlich klar - _der_ weiß, was zu diesem Zeitpunkt in irgendwelchen internen Apache-Records zur Repräsentation eines HTTP-Requests steht ...

Viele Grüße
      Michael
(der in dieser Hinsicht bereits einen Stapel Engelszungen verbraucht hat)

P.S.: Für die ganz Hartgesottenen:
      mod_gzip.c Zeile 118ff.:

/*
 * Turn MOD_GZIP_DEBUG1 switch ON to include debug code.
 * This is normally OFF by default and should only be
 * used for diagnosing problems. The log output is
 * VERY detailed and the log files will be HUGE.
 */

/*
#define MOD_GZIP_DEBUG1
*/

/*
 * Turn MOD_GZIP_DEBUG1_VERBOSE1 switch ON to include
 * some VERY 'verbose' debug code such as request record
 * dumps during transactions and hex dumps of data.
 * This is normally OFF by default. MOD_GZIP_DEBUG1
 * switch must also be 'on' for this to have any effect.
 */

#ifdef  MOD_GZIP_DEBUG1
#define MOD_GZIP_DEBUG1_VERBOSE1
#endif

/*
 * Turn this 'define' on to send all log output to
 * Apache error_log instead of a flat file. "LogLevel debug"
 * must be set in httpd.conf for log output to appear in error_log.
 */

/*
#define MOD_GZIP_LOG_IS_APACHE_LOG
*/

Also: Scharf machen, neu übersetzen und dann in Debug-Meldungen ertrinken ... _dann_ lernt man, was wer wann wie warum tut.

[Mike]

Na dann hole ich mal einen ganz tiefen Schluck und hoffe, dass ich noch Luft holen kann. Mal sehen, ob ich es am Ende auch ganz verstanden habe.

danke Euch Beiden für die Hilfe

Gruß

Mike

Hi,

Die offizielle Beschreibung ist nicht wirklich erklärend:
Da steht nicht genau drin, was ARG2 genauer ist.

Du hast zielsicher erkannt, woran es bei mod_gzip vorrangig krankt: Dem Entwickler sind solche Sachen natürlich klar - _der_ weiß, was zu diesem Zeitpunkt in irgendwelchen internen Apache-Records zur Repräsentation eines HTTP-Requests steht ...

Viele Grüße
      Michael
(der in dieser Hinsicht bereits einen Stapel Engelszungen verbraucht hat)

P.S.: Für die ganz Hartgesottenen:
      mod_gzip.c Zeile 118ff.:

/*
* Turn MOD_GZIP_DEBUG1 switch ON to include debug code.
* This is normally OFF by default and should only be
* used for diagnosing problems. The log output is
* VERY detailed and the log files will be HUGE.
*/

/*
#define MOD_GZIP_DEBUG1
*/

/*
* Turn MOD_GZIP_DEBUG1_VERBOSE1 switch ON to include
* some VERY 'verbose' debug code such as request record
* dumps during transactions and hex dumps of data.
* This is normally OFF by default. MOD_GZIP_DEBUG1
* switch must also be 'on' for this to have any effect.
*/

#ifdef  MOD_GZIP_DEBUG1
#define MOD_GZIP_DEBUG1_VERBOSE1
#endif

/*
* Turn this 'define' on to send all log output to
* Apache error_log instead of a flat file. "LogLevel debug"
* must be set in httpd.conf for log output to appear in error_log.
*/

/*
#define MOD_GZIP_LOG_IS_APACHE_LOG
*/

Also: Scharf machen, neu übersetzen und dann in Debug-Meldungen ertrinken ... _dann_ lernt man, was wer wann wie warum tut.

[Michael Schröpl]

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

[Michael Schröpl]

Hi Mike,

Meine Vermutung geht dahingehend, dass bei
Formularen mit zu großem Inhalt das Modul nicht
richtig ausgeführt wird. Sobald ich nämlich ein
Textfeld mit sehr großem Inhalt ausfülle,
funktioniert es nicht. Bleibt der Inhalt gering,
dann führt Apache das Formular aus.
Ohne das gzip läuft die Anwendung einwandfrei.

dieser Effekt wurde auf der mod_gzip-Mailingliste
in der Tat schon ein paarmal gemeldet - immer bei
Formularen, die via POST übertragen wurden und recht
große Inhalte hatten.

Das ist m. E. einer von zwei offenen Bugs in mod_gzip 1.3.19a. (Der andere ist, daß sehr lange Cookies abgeschnitten werden, weil ein entsprechender Puffer für HTTP-Header-Zeilen anscheinend nur 2 kb lang ist statt etwa 5 kb.)
Ich würde daher vorschlagen, den URL zur Annahme dieses Formulars via "file" oder "uri" von der Komprimierung gezielt auszuschließen.

Ausschluß via Methode geht bisher nicht per Konfiguration - mod_gzip verarbeitet genau GET und POST. Allerdings könntest Du dazu im Quelltext genau _eine_ Zeile anpassen und das Modul neu übersetzen ...

Viele Grüße
      Michael

[Mike]

Hi Michael,

vielen Dank für die Antwort. Wiedereinmal hilft Du mir mit Knowe How aus den Schwierigkeiten.

Ich würde am liebsten ein ganzes Verzeichnis ausschließen, ohne jede einzelne Datei zu benennen. Geht das?

Und was meinst Du mit "Allerdings könntest Du dazu im Quelltext genau _eine_ Zeile anpassen und das Modul neu übersetzen ..."?

Das hört sich auch praktikabel an.

Gruß

Mike

Hi Mike,

Meine Vermutung geht dahingehend, dass bei
Formularen mit zu großem Inhalt das Modul nicht
richtig ausgeführt wird. Sobald ich nämlich ein
Textfeld mit sehr großem Inhalt ausfülle,
funktioniert es nicht. Bleibt der Inhalt gering,
dann führt Apache das Formular aus.
Ohne das gzip läuft die Anwendung einwandfrei.

dieser Effekt wurde auf der mod_gzip-Mailingliste
in der Tat schon ein paarmal gemeldet - immer bei
Formularen, die via POST übertragen wurden und recht
große Inhalte hatten.

Das ist m. E. einer von zwei offenen Bugs in mod_gzip 1.3.19a. (Der andere ist, daß sehr lange Cookies abgeschnitten werden, weil ein entsprechender Puffer für HTTP-Header-Zeilen anscheinend nur 2 kb lang ist statt etwa 5 kb.)
Ich würde daher vorschlagen, den URL zur Annahme dieses Formulars via "file" oder "uri" von der Komprimierung gezielt auszuschließen.

Ausschluß via Methode geht bisher nicht per Konfiguration - mod_gzip verarbeitet genau GET und POST. Allerdings könntest Du dazu im Quelltext genau _eine_ Zeile anpassen und das Modul neu übersetzen ...

Viele Grüße
      Michael

[Michael Schröpl]

Hi Mike,

Ich würde am liebsten ein ganzes Verzeichnis
ausschließen, ohne jede einzelne Datei zu benennen.
Geht das?

alle Muster bei "item"-Regeln werden als reguläre Ausdrücke interpretiert.

Und was meinst Du mit "Allerdings könntest Du dazu
im Quelltext genau _eine_ Zeile anpassen und das
Modul neu übersetzen ..."?
Das hört sich auch praktikabel an.

mod_gzip.c, Zeile 2250ff:

if ( ( r->method_number != M_GET  ) &&
      ( r->method_number != M_POST ) )
   {
    #ifdef MOD_GZIP_USES_APACHE_LOGS
    ap_table_setn( r->notes,"mod_gzip_result",ap_pstrdup(r->pool,"DECLINED:NOT_GET_OR_POST"));
    #endif

#ifdef MOD_GZIP_DEBUG1
    mod_gzip_printf( "%s: r->method_number is NOT M_GET or M_POST",cn);
    mod_gzip_printf( "%s: Ignoring this request...",cn);
    mod_gzip_printf( "%s: Exit > return( DECLINED ) >",cn);
    #endif

return DECLINED;
   }

klingt für mich so, als würde man dort 'M_POST' problemlos herausnehmen können (also nur 'M_GET' drin lassen), indem man die "if"-Bedingung ändert.

Viele Grüße
      Michael