mod_gzip Status-Codes
Author: Michael Schröpl
Description: Eine Aufzählung aller von mod_gzip erzeugten Status-Codes und ein Versuch, ihre Bedeutung zu erklären
Keywords: Apache, HTTP, Kodierung, gzip, Komprimierung

# Beschreibung sämtlicher `mod_gzip`-Status-Codes

Dieses Dokument beschreibt die Menge aller Status-Codes, welche `mod_gzip` 1.3.26.1a über seine Verarbeitung liefert und über die Feldbeschreibung `%{mod_gzip_result}n` zur Verwendung in Protokoll-Formaten bereit stellt.

Die Zeilennummern stammen noch aus `mod_gzip` 1.3.19.1a und werden wahrscheinlich demnächst verschwinden, da sich ihre Wartung seit der Verfügbarkeit von `mod_gzip` via CVS nicht mehr lohnt.

## DECLINED:UNHANDLED_SUBREQ

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Es liegt eine Apache-interne Teil-Anforderung vor, ausgelöst durch die Verarbeitung einer 'normalen' Anforderung. Nur deren endgültiges Ergebnis wird von `mod_gzip` geprüft (und möglicherweise komprimiert).

## DECLINED:UNHANDLED_REDIR

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Es liegt eine Apache-interne Weiterleitung vor, ausgelöst durch die Verarbeitung einer 'normalen' Anforderung. Nur deren endgültiges Ergebnis wird von `mod_gzip` geprüft (und möglicherweise komprimiert).

## DECLINED:INIT1

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Das scheint eine Wertebelegung als Initialisierung zu sein - jedenfalls hat es keine unmittelbare Auswirkung auf den Lauf der Verarbeitung.

## DECLINED:STATIC_GZ_FOUND

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Zu der angeforderten Datei wurde eine statisch komprimierte Version (mit der hart-codierten Dateinamens-Endung `.gz`) gefunden und durfte an den UserAgent ausgeliefert werden, anstatt die Original-Datei dynamisch komprimieren zu müssen.
mod_gzip_handler

## DECLINED:FEXT_GZ

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Die Anforderung bezieht sich explizit auf eine statisch komprimierte Datei (mit der hart-codierten Dateinamens-Endung `.gz`); der Inhalt solcher Dateien wird unverändert ausgeliefert.
mod_gzip_handler

## DECLINED:NO_DCONF

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Der `dconf`-Pointer hat den Wert NULL. `mod_gzip` kann seine Konfigurations-Struktur nicht ansprechen und damit die gesetzten Werte seiner Direktiven nicht abfragen.

## DECLINED:OFF

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Der Komprimierung ist für den Definitionsbereich dieser Datei nicht eingeschaltet (`mod_gzip_on No` für die komplette Apache-Konfiguration, diesen Virtual Host, diesen Verzeichnisbaum oder diese `.htaccess`-Datei)

## DECLINED:NOT_GET_OR_POST

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Die Anforderung verwendet keine der HTTP-Methoden `GET` bzw. `POST`, aber nur Daten dieser Methoden können sinnvollerweise komprimiert werden.

## DECLINED:HEAD_REQUEST

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Diese Anforderung verwendet die HTTP-Methode `HEAD`; eine solche Anforderung bewirkt nicht die Erzeugung eines (komprimierbaren) Dokument-Inhalt, sondern lediglich die Erzeugung eines (nicht komprimierbaren) HTTP-Headers.

## DECLINED:HTTP_LEVEL_TOO_LOW

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Die Anforderung verwendet eine HTTP-Protokoll-Version, die nicht so hoch ist, wie durch die Direktive `mod_gzip_min_http` mindestens gefordert wurde.

## DECLINED:NO_GZIP

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Die Anforderung enthält zwar einen `Accept-Encoding`-Header, aber in dessen Liste der (von diesem UserAgent unterstützten) Kodierungen ist die Kodierung `gzip` nicht enthalten - der UserAgent versteht also offenbar keine gzip-komprimierten Daten.

## DECLINED:NO_ACCEPT_ENCODING

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Die Anforderung enthält keinen `Accept-Encoding`-Header - der UserAgent versteht also offenbar keine gzip-komprimierten Daten.

## DECLINED:NO_ITEMS_DEFINED

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Die Liste der Regeln (zur Entscheidung, ob der Inhalt der angeforderten Datei komprimiert werden soll) ist leer (weder `mod_gzip_include_item` noch `mod_gzip_exclude_item` wurden verwendet). Damit ist der normale Entscheidungsprozeß nicht durchführbar.

## DECLINED:REQ_HEADER_FIELD_EXCLUDED

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Diese Anforderung wurde während der Analyse der Filter-Regeln (`mod_gzip_validate1 (header_name, header_value, MOD_GZIP_REQUEST)`, Zeile 2511) von der Komprimierung ausgeschlossen. (Es muß eine Regel vom Typ `mod_gzip_exclude_item reqheader` erfüllt gewesen sein - ein Fehlen jeglicher `mod_gzip_include_item`-Regeln kann nicht vorliegen, weil noch weitere Tests folgen werden.)

## DECLINED:EXCLUDED

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | Die Anforderung wurde während der Analyse der Filter-Regeln (`mod_gzip_validate1 (file, uri, content_type, handler)`, Zeile 2612) von der Komprimierung ausgeschlossen, wobei die empfangenen HTTP-Header-Felder der Anforderung bereits erfolgreich gegenüber `mod_gzip_exclude_item` geprüft waren. (Das ist leider nicht sehr aussagekräftig ... wenn hier wenigstens klar wäre, ob ein explizites `mod_gzip_exclude_item` vorlag - und ggf. von welcher Klasse - oder nur kein `mod_gzip_include_item` gefunden wurde ... !)

## COMMAND:VERSION

Verursacher | Bedeutung
--- | ---
mod_gzip_do_command | Diese Anforderung bewirkte die Ausführung des mit der Direktive `mod_gzip_command_version` definierten Kommandos zur Status-Anzeige von `mod_gzip` selbst (Versionsnummer und '`on`'/'`off`'). Die Ausgabe dieses Kommandos ist so kurz (weniger als 100 Bytes), daß sich eine Komprimierung des Inhaltes nicht lohnt.

## DECLINED:INVALID_COMMAND

Verursacher | Bedeutung
--- | ---
mod_gzip_do_command | Irgendwas muß bei der Ausführung des internen Status-Kommandos schief gegangen sein. (Mir ist aber nicht klar, ob und wann dieser Fall jemals auftreten kann.)

## INIT2

Verursacher | Bedeutung
--- | ---
mod_gzip_handler | Das scheint eine Wertebelegung als Initialisierung zu sein - jedenfalls hat es keine unmittelbare Auswirkung auf den Lauf der Verarbeitung.

## DECLINED:OFF2

Verursacher | Bedeutung
--- | ---
mod_gzip_handler | Der Komprimierung ist für den Definitionsbereich dieser Datei nicht eingeschaltet (`mod_gzip_on No` für die komplette Apache-Konfiguration, diesen Virtual Host, diesen Verzeichnisbaum oder diese `.htaccess`-Datei)

## DECLINED:EXCLUDED_BY_HANDLER

Verursacher | Bedeutung
--- | ---
mod_gzip_handler | Die Anforderung wurde während der Analyse der Filter-Regeln (`mod_gzip_validate1 (file, uri, content_type, handler)`, Zeile 3091) von der Komprimierung ausgeschlossen, wobei die empfangenen HTTP-Header-Felder der Anforderung bereits erfolgreich gegenüber `mod_gzip_exclude_item` geprüft waren. (Das ist leider auch nicht besonders aussagekräftig; außerdem ist mir nicht klar, wieso das jetzt der Handler gewesen sein muß bzw. wieso dann die vier anderen Parameter noch an `mod_gzip_validate1` übergeben wurden.)

## RECOVERY

Verursacher | Bedeutung
--- | ---
mod_gzip_handler | Irgendwas ist bei der Ausführung von `mod_gzip_redir1_handler` schiefgegangen ... aber was? Wir werden jetzt einen internen Redirect machen müssen, wieso auch immer ... und in Zeile 3310 sogar dessen Statuscode über unseren eigenen drüber schreiben.

## DECLINED:DYN1_OPENFAIL_BODY

Verursacher | Bedeutung
--- | ---
mod_gzip_redir1_handler | `mod_gzip_dyn1_getfdo1` hat vergeblich versucht, eine neue Datei anzulegen. (Dieser Zugriff wird in einem HTTP_INTERNAL_SERVER_ERROR enden - ein vernünftiges Ergebnis bekommen wir nicht mehr hin ... äh, wieso eigentlich? Können wir den Versuch einer Komprimierung schon nicht mehr abbrechen? Außerdem hätten wir an dieser Stelle eigentlich genauere Informationen, was passiert ist ... warum werden die nicht in den Status hinein codiert?)

## STAT_FAILED

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Die zu sendende Datei ist nicht vorhanden (`stat()`-Returncode != 0); das ist wohl eines der "this can't happen"-Ereignisse.

## CAP_FILE_EMPTY

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Wir haben eine zu sendende Datei (der `stat()`-Aufruf hat funktioniert), aber ihre Größe beträgt weniger als 1 Byte. Der zu komprimierende Inhalt des Dokuments scheint also irgendwie nicht bei uns angekommen zu sein, wieso auch immer.

## CAP_FOPEN_FAILED

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Wir haben eine zu sendende Datei (der `stat()`-Aufruf hat funktioniert), aber der Versuch, sie zum Lesen zu öffnen (`fopen(name,"rb")`), ist gescheitert.

## NO_HTTP_EOH

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Der HTTP-Header des während der aktuellen Anforderung erzeugten Ergebnisses wurde nicht korrekt abgeschlossen. (Beim Parsen des HTTP-Headers hätten wir in Zeile 5957 eine Leerzeile finden müssen.) Einen solchen Header können wir nicht verarbeiten (wir müssen ihn ja für die Komprimierung teilweise umschreiben).

## NO_HTTP_RESP_CODE

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Der HTTP-Header des während der aktuellen Anforderung erzeugten Ergebnisses enthält keinen Statuscode. (In der 1. Zeile des HTTP-Headers hätten wir in Zeile 5983 einen HTTP-Statuscode finden müssen.) Etwas später werden wir aber genau diesen Statuscode prüfen wollen - das wird dann sicherlich nicht funktionieren können.

## SEND_AS_IS:NO_200

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Der HTTP-Statuscode der erzeugten Antwort hat nicht den Wert `200` - und nur bei diesem Wert kann ein zu komprimierender Dokumentinhalt vorliegen. (Hm ... und was ist mit den ganzen 404-Fehlerdokumenten?)

## SEND_AS_IS:RESPONSE_FIELD_EXCLUDED

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Die Anforderung wurde während der Analyse der Filter-Regeln (`mod_gzip_validate1 (header_name, header_value, MOD_GZIP_RESPONSE)`, Zeile 6081) von der Komprimierung ausgeschlossen. (Das war jetzt offenbar ein HTTP-Header des Antwortdokuments, denn der Rest wurde nicht geprüft. Für ein DECLINED ist es bereits zu spät, das macht anscheinend nur vor dem eigentlichen Request Sinn ... ?)

## SEND_AS_IS:NO_BODY

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Wir haben zwar einen Inhalt mit einem brauchbaren HTTP-Header, aber dieser Inhalt ist weniger als 1 Byte lang. Es ist einfach nichts da zum Komprimieren. (Dieser Statuscode tritt beispielsweise auf, wenn eine Datei mit 0 Bytes Inhalt angesprochen wird, etwa eine Dummy-`robots.txt`-Datei etc.)

## SEND_AS_IS:UNKNOWN_TE_VALUE

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Im HTTP-Header des Ergebnisses der Anforderung ist ein `Transfer-Encoding` angegeben, und zwar ein anderes als `chunked`, welches das einzige wäre, mit dem wir fertig werden könnten (indem wir aus den chunks ein einziges Paket machen und dieses dann komprimieren).

## SEND_AS_IS:HAS_CE

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Im HTTP-Header des Ergebnisses der Anforderung ist ein `Content-Encoding` angegeben, Theoretisch könnte man in HTTP mehrere Content-Encodings ineinander schachteln; die praktische Erfahrung zeigt allerdings, daß damit keiner der verfügbaren UserAgents vernünftig umgehen kann. Also lassen wir den Inhalt besser unverändert.

## SEND_AS_IS:NO_CONTENT_TYPE_IN_RESPONSE_HEADER

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Der HTTP-Header des Ergebnisses der Anforderung enthält keinen `Content-Type`. (Beim Parsen der HTTP-Headers hätten wir in Zeile 6034 einen Content-type finden sollen.) Nun ist allerdings ein Content-type laut HTTP kein Pflichtfeld; tatsächlich darf der UserAgent sogar einen Content-type raten, wenn vom Server keiner angegeben wurde. Andererseits basiert die wichtigste `include`-Regel auf diesem Content-type, und wenn da keiner vorhanden ist, dann wird es schwierig werden, eine entsprechende Regel zum Feuern zu bringen ... Ich persönlich habe genau diese Prüfung aus `mod_gzip` ausgebaut, denn ich bekomme via `mod_proxy` Seiten von einem M$/IIS ohne Content-type (ich weiß aber, daß es `text/html` sein soll), die ich komprimiert weitersenden will ...

## SEND_AS_IS:RESPONSE_CONTENT_TYPE_EXCLUDED

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Die Anforderung wurde während der Analyse der Filter-Regeln (`mod_gzip_validate1 (CONTENT_TYPE)`, Zeile 6307) von der Komprimierung ausgeschlossen.

## SEND_AS_IS:DECHUNK_OPTION_IS_OFF

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Es wurde ein `Transfer-Encoding: chunked` entdeckt, aber in der Konfiguration wurde `mod_gzip` nicht erlaubt, diese Codierung zu entfernen (d. h. alle chunks aufzusammeln und ein einziges Paket daraus zu erstellen, dessen Inhalt dann komprimierbar wäre). Die Direktive `mod_gzip_dechunk Yes` hätte `mod_gzip` erlaubt, diese Anforderung zu komprimieren.

## SEND_AS_IS:FOPEN_FAILED

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Wir wollten gerade mit dem Komprimieren anfangen. Dazu wäre es notwendig gewesen, eine temporäre Datei zu öffnen, deren Namen wir zuvor von `mod_gzip_create_unique_filename` haben berechnen lassen. Aber der Versuch, diese Datei zum Schreiben zu öffnen, ist gescheitert - daher wird der Versuch, die Daten zu komprimieren, abgebrochen. Dieser Fall kann insbesondere auch dann auftreten, falls `mod_gzip` gerade versucht hat, den veralteten Inhalt einer statisch vorkomprimierten Datei zu aktualisieren, aber kein Schreibrecht auf diese Datei besaß.

## SEND_AS_IS:FSEEK_FAILED

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Wir wollten gerade mit dem Komprimieren anfangen. Nachdem die Eingabedatei erfolgreich geöffnet wurde, sollte jetzt in dieser Datei mit `fseek (ifh,0,0)` offenbar an deren Anfang positioniert werden - dies ist aber gescheitert. (Mir ist noch nicht klar, wieso an dieser Stelle bereits entschieden ist, daß die Daten aus einer Datei gelesen werden müssen und nicht aus irgend einem Apache-Puffer ... wir sind noch nicht im de-chunking?)

## SEND_AS_IS:BODY_MISSING

Verursacher | Bedeutung
--- | ---
mod_gzip_sendfile2 | Beim vorherigen Kopieren des Inhalts der zu komprimierenden Datei wurde festgestellt, daß der Inhalt dieser Datei aus 0 Bytes besteht - da macht es keinen Sinn, etwas zu komprimieren.

## SEND_AS_IS:WORK_OPENFAIL

Verursacher | Bedeutung
--- | ---
mod_gzip_open_output_file | Der Versuch, die zuvor während der Komprimierung des Inhalts erzeugte Ausgabedatei wieder zum Lesen zu öffnen (um diese Daten zu senden), ist gescheitert.

## OK / DECHUNK:OK

Verursacher | Bedeutung
--- | ---
mod_gzip_encode_and_transmit | Die Komprimierung wurde erfolgreich durchgeführt. (Dieser Wert wird zu Beginn der Verarbeitung als Default-Wert gesetzt und im Fehlerfall überschrieben.)

## DECLINED:NO_ILEN / DECHUNK:DECLINED:NO_ILEN

Verursacher | Bedeutung
--- | ---
mod_gzip_encode_and_transmit | Die Länge des zu komprimierenden Inhalts ist kleiner als 1 Zeichen - da gibt es nichts zu tun.

## DECLINED:TOO_SMALL / DECHUNK:DECLINED:TOO_SMALL

Verursacher | Bedeutung
--- | ---
mod_gzip_encode_and_transmit | Die Länge des zu komprimierenden Inhalts ist kleiner als der durch die Anweisung `mod_gzip_minimum_file_size` definierte Wert.

## DECLINED:TOO_BIG / DECHUNK:DECLINED:TOO_BIG

Verursacher | Bedeutung
--- | ---
mod_gzip_encode_and_transmit | Die Länge des zu komprimierenden Inhalts ist größer als der durch die Anweisung `mod_gzip_maximum_file_size` definierte Wert.

## DECLINED:NO_OLEN / DECHUNK:DECLINED:NO_OLEN

Verursacher | Bedeutung
--- | ---
mod_gzip_encode_and_transmit | Die Länge des komprimierten Inhalts ist kleiner als 1 Zeichen - da muß während der Komprimierung irgendwas schief gegangen sein.

## DECLINED:ORIGINAL_SMALLER / DECHUNK:DECLINED:ORIGINAL_SMALLER

Verursacher | Bedeutung
--- | ---
mod_gzip_encode_and_transmit | Die Länge des komprimierten Inhalts ist kleiner als die Länge des Original-Inhalts - die Komprimierung hat also nicht zu einer Einsparung geführt. Deshalb wird der unkomprimierte Inhalt ausgeliefert.

## DECLINED:REOPEN_FAILED / DECHUNK:DECLINED:REOPEN_FAILED

Verursacher | Bedeutung
--- | ---
mod_gzip_encode_and_transmit | Der Versuch, die zuvor während der Komprimierung des Inhalts erzeugte Ausgabedatei wieder zum Lesen zu öffnen (um diese Daten zu senden), ist gescheitert.

## TRANSMIT_ERROR:ISMEM:%d:%s / DECHUNK:TRANSMIT_ERROR:ISMEM:%d:%s

Verursacher | Bedeutung
--- | ---
mod_gzip_encode_and_transmit | Fehler bei der Ausgabe komprimierter Daten aus dem Hauptspeicher (Meldung im in DEBUG-Modus)

## TRANSMIT_ERROR:ISMEM:%d / DECHUNK:TRANSMIT_ERROR:ISMEM:%d

Verursacher | Bedeutung
--- | ---
mod_gzip_encode_and_transmit | Fehler bei der Ausgabe komprimierter Daten aus dem Hauptspeicher

## TRANSMIT_ERROR:%d / DECHUNK:TRANSMIT_ERROR:%d:%s

Verursacher | Bedeutung
--- | ---
mod_gzip_encode_and_transmit | Fehler bei der Ausgabe komprimierter Daten aus der temporären Datei

## TRANSMIT_ERROR:%d / DECHUNK:TRANSMIT_ERROR:%d

Verursacher | Bedeutung
--- | ---
mod_gzip_encode_and_transmit | Fehler bei der Ausgabe komprimierter Daten aus der temporären Datei

## SEND_AS_IS:PRECOMPRESSED_VARIANT_OUTDATED

Verursacher | Bedeutung
--- | ---
mod_gzip_handler | (neu in mod_gzip 1.3.19.2a) Der Inhalt einer statisch vorkomprimierten Datei ist älter als derjenige der unkomprimierten Originaldatei. Daher wurde der Inhalt der Originaldatei (in unkomprimierter Form) ausgeliefert - besser korrekte Daten liefern als veraltete.

## DECLINED:METHOD_EXCLUDED

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | (neu in mod_gzip 1.3.19.2a) Die Anforderung dieses URL erfolgte mit einer HTTP-Methode, deren Ergebnisse nicht mit der Direktive `mod_gzip_handle_methods` als zu komprimieren deklariert wurden.

## DECLINED:POST_TOO_BIG

Verursacher | Bedeutung
--- | ---
mod_gzip_type_checker | (neu in mod_gzip 1.3.26.1a) Der Inhalt eines HTTP-POST-Request ist größer als der verfügbare Puffer und kann von `mod_gzip` nicht korrekt verarbeitet werden - dieses Problem tritt nur unter Windows auf. Die Antwort auf diese Anforderung wird in unkomprimierter Form ausgeliefert.

## OK:PRECOMPRESSED_VARIANT_UPDATED

Verursacher | Bedeutung
--- | ---
mod_gzip_compress_file | (neu in mod_gzip 1.3.26.1a) Während der Auslieferung des Inhalts einer statisch vorkomprimierten Datei wurde erkannt, daß deren Inhalt älter war als derjenige der zugehörigen Original-Datei. Der Inhalt der vorkomprimierten Datei wurde durch erneute Komprimierung des Original-Inhalts erfolgreich aktualisiert; der komprimierte Inhalt wurde anschließend ausgeliefert.

(Michael Schröpl, 2002-09-30)