mod_gzip - Bereitstellung komprimierter Inhalte durch den Apache-Webserver - Seite 8

Autor: Michael Schröpl

Dieses Dokument beschreibt einige mögliche funktionale Verbesserungen, die hoffentlich in die aktuelle Version 1.3.26.1a von mod_gzip ohne zu großen Aufwand implementiert werden können und die Benutzerfreundlichkeit dieses Moduls erhöhen.

Protokollierungsklasse und Wert der entscheidenden Filterregel

Die Entscheidung, ob der Inhalt eines Dokuments für die Kompression durch mod_gzip qualifiziert ist, erfolgt letztendlich während der Auswertung der Filterregeln, die durch die Direktiven mod_gzip_item_include und mod_gzip_item_exclude definiert sind und die von der Funktion mod_gzip_validate1 überprüft werden.

Diese Funktion wird an nicht weniger als fünf Stellen im Quellcode aufgerufen, jedes Mal mit unterschiedlichen Parametereinstellungen für spezifische Teile der zu überprüfenden Regelklassen. In einigen dieser Fälle ist aus der eingeschränkten Parametereinstellung klar, welche Regelklasse zu dem spezifischen Ergebnis geführt haben muss (aber nicht welcher Regelwert!), in anderen Fällen (wie dem gleichzeitigen Test aller Regeln der Klassen file, uri, mime und handler) ist nicht einmal die Klasse der entscheidenden Regel klar (weil mod_gzip_validate1 einen so unspezifischen Ergebniswert an den Aufrufer zurückgibt, dass dieser nicht einmal versteht, was genau passiert ist - in einigen Fällen sind sogar interne Fehler wie eine Entscheidung aufgrund einer Ausschlussregel kodiert). In diesen Fällen ist nicht einmal eine sinnvolle Auswertung des mod_gzip-Statuscodes möglich.

Aber die Definition eines geeigneten Regelsets ist der wichtigste Schritt während des gesamten (und derzeit noch recht komplizierten) Konfigurationsverfahrens von mod_gzip. Jegliche Informationen darüber, welche der definierten Regeln in welchen Fällen entschieden hat, ob der Inhalt eines Dokuments komprimiert werden sollte, wären in vielen Fällen hilfreich für den Benutzer.

Andererseits unterstützt mod_gzip bereits die Verarbeitungstransparenz nach erfolgreicher Bearbeitung eines Dokuments, indem einige Variablen gesetzt werden, die in Apache-Protokollformaten verwendet werden können (der Verarbeitungsstatus, die Dokumentgrößen vor und nach der Kompression sowie die Volumeneinsparung in Prozent - die letzte wird fälschlicherweise immer aufgerundet). In Übereinstimmung damit könnte mod_gzip (gerade in dem Moment, als die Entscheidung über die Kompression des Dokumentinhalts getroffen wurde) problemlos die Klasse und den Inhalt der entscheidenden Regel in zwei weiteren Protokollvariablen speichern, die dann innerhalb eines Protokollformats über die Namen mod_gzip_rule_class und mod_gzip_rule_content angesprochen werden könnten.

Konfigurierbares gzip-Kompressionsniveau

Derzeit verwendet mod_gzip das gzip-Kompressionsniveau 6. Dies ist hartkodiert durch die Zuweisung gz1->level = 6 innerhalb der Funktion gz1_init.

Je höher das Kompressionsniveau (gzip erlaubt Werte zwischen 1 und 9), desto besser der Kompressionseffekt, aber desto höher auch der CPU-Zeitverbrauch. Durch die Anpassung dieses Kompressionsniveaus könnte ein Benutzer den Kompromiss zwischen CPU-Last und Bandbreiteneinsparung gemäß seinen eigenen Anforderungen lösen. Eigene Experimente haben gezeigt, dass Niveau 3 bereits nahe an den Effekt des Kompressionsniveaus 6 herankommt - zumindest sollte die Wahl zwischen diesen beiden Werten dem Benutzer überlassen werden.

Daher wäre es sinnvoll, dieses Kompressionsniveau konfigurierbar zu machen, indem eine weitere Direktive mod_gzip_compression_level angeboten wird.

Ein genauerer Blick von Christian Kruse führte zu dem Schluss, dass Kevins Kileys Kompressionscode für mod_gzip anscheinend nicht alle 9 Kompressionsniveaus für gzip unterstützt, sondern grundsätzlich nur die für Niveau 6 erforderlichen (obwohl die Programmstruktur für die Implementierung aller 9 Niveaus später entworfen wurde). Daher reicht es nicht aus, die oben genannte Konstante einfach zu ändern; in der Tat ist mod_gzip nach dieser Art von Modifikation nicht einmal mehr verwendbar.

Boolesche Ausdrücke in include / exclude-Direktiven

mod_gzip 1.3.19.1a verwendet - verursacht durch seine Art der Einbettung in die Apache-Anforderungsverarbeitung - ein komplexes, zweistufiges Filterverfahren, um zu entscheiden, ob das Ergebnis einer Anfrage komprimiert werden sollte. (In einer modifizierten Architektur von Apache 2.0 könnte eine einfachere Art der Einbettung möglich sein.)

Eine Anfrage wird derzeit von mod_gzip genau dann akzeptiert, wenn während jeder der beiden Entscheidungsphasen mindestens eine include-Regel ausgelöst wird, aber keine exclude-Regel. Da solche Regeln reguläre Ausdrücke als Parameterwerte zulassen, stehen leistungsstarke Bedingungen zur Verfügung.

Dennoch sind alle Regeln unabhängig voneinander; die derzeit verfügbaren Direktiven erlauben es dem Benutzer nicht, auszudrücken, dass bestimmte MIME-Typen nur in komprimierter Form an bestimmte Browser geliefert werden - die UND-Verbindung zwischen mehreren Regeln fehlt.

Es scheint nur selten Gelegenheiten zu geben, in denen dies wirklich hilfreich wäre - bis jetzt wäre es besonders erforderlich, Filterregeln so fein abzustimmen, dass sie mit all den Bugs von Netscape 4 umgehen können, anstatt diesen Browser vollständig von der Kompression auszuschließen. Mit der Zeit (und verbesserter Standardskonformität der Browser) könnte dieses Feature obsolet werden.

Identische HTTP-Header für GET- und HEAD-Anfragen bereitstellen

Laut RFC 2616 sollte eine HTTP/1.1-konforme Implementierung für eine Anfrage, die die HEAD-Methode verwendet, HTTP-Header bereitstellen, die identisch mit denen sind, die für eine Anfrage nach derselben Ressource unter Verwendung der GET-Methode bereitgestellt worden wären.

Im Falle von mod_gzip würde dies bedeuten, dass selbst für eine HEAD-Anfrage der Inhalt komprimiert werden müsste (bzw. gelesen, im Falle einer statisch vorkomprimierten Datei), nur um einen korrekten Content-Length-HTTP-Header generieren zu können.

Bis jetzt behandelt mod_gzip diesen (extrem seltenen) Anwendungsfall nicht (wahrscheinlich aus Leistungsgründen); dennoch könnte dies gemäß RFC 2119 dazu führen, dass das Verhalten des Moduls nur bedingt mit HTTP/1.1 kompatibel ist, da es einen gültigen Grund geben muss, um eine empfohlene Anforderung nicht zu unterstützen.

Ursprünglicher Standort dieses Dokuments:

http://www.schroepl.net/projekte/mod_gzip/enhancements.htm