Mögliche Erweiterungen in künftigen Versionen von mod_gzip
Dieses Dokument beschreibt einige mögliche Funktionserweiterungen, die sich hoffentlich mit wenig Aufwand in die derzeit aktuelle Version 1.3.26.1a von mod_gzip einbauen lassen sollten und die Verwendung dieses Moduls verbessern würden.
Protokollierung von Klasse und Wert der entscheidenden Filter-Regel
Die Entscheidung darüber, ob sich ein Dokument-Inhalt für eine Komprimierung durch mod_gzip qualifiziert, fällt letzten Endes bei der Auswertung der entsprechenden Filterregeln, welche mit Hilfe der Direktiven mod_gzip_item_include
bzw. mod_gzip_item_exclude
definiert und durch die Funktion mod_gzip_validate1
geprüft wird.
Diese Funktion wird allerdings an nicht weniger als fünf Stellen im Programmquelltext aufgerufen, jeweils mit unterschiedlichen Parameter-Belegungen für bestimmte Teilmengen der zu diesem Zeitpunkt jeweils zu prüfenden Regel-Klassen. In einigen dieser Fälle ist aufgrund der eingeschränkten Parameterbelegung klar, welche Klasse von Regel zu einem bestimmten Ergebnis geführt haben muß (nicht jedoch, welche Regel!), in anderen Fällen (etwa bei der gleichzeitigen Prüfung aller Regeln der Klassen file
, uri
, mime
und handler
) ist nicht einmal die Klasse der entscheidenden Regel klar (denn mod_gzip_validate1
liefert einen so unspezifischen Ergebniswert an den Aufrufer zurück, daß dieser nicht verstehen kann, was genau passiert ist - in einigen Fällen werden sogar interne Verarbeitungsfehler genauso dargestellt wie eine Ablehnung aufgrund einer Regel). In solchen Fällen Daher ist nicht einmal eine vernünftige Auswertung des mod_gzip-Statuscodes möglich.
Das Definieren eines sinnvollen Regelsatzes ist jedoch der wichtigste Schritt bei der gesamten (und momentan noch ziemlich komplizierten) mod_gzip-Konfiguration. Jede Information darüber, welche der definierten Regeln in welchen Fällen über die Komprimierung eines Dokument-Inhalts den Ausschlag gegeben hat, wäre für den Anwender in vielen Fällen hilfreich.
Andererseits unterstützt mod_gzip nach erfolgreicher Verarbeitung eines Dokuments bereits die Transparenz der Verarbeitung durch das Setzen einiger Variablen, welche innerhalb von Apache-Log-Formaten verwendet werden können (den Verarbeitungs-Status, die Dokumentgröße vor bzw. nach der Komprimierung sowie die Volumen-Einsparung in Prozent - letztere leider fälschlicherweise immer aufgerundet). Analog könnte mod_gzip (in dem Moment, in welchem es die Entscheidung über die Komprimierung des Dokument-Inhalts getroffen hat) Klasse und Inhalt der entscheidenden Regel in zwei weiteren Protokoll-Variablen ablegen, welche innerhalb eines Log-Formats über die Namen mod_gzip_rule_class
und mod_gzip_rule_content
angesprochen würden.
Konfigurierbare gzip-Komprimierungsstufe
Aktuell verarbeitet mod_gzip die gzip
-Komprimierungsstufe 6. (Dies ist fest eincodiert durch die Zuweisung gz1->level = 6
in der Funktion gz1_init
.)
Je höher die Komprimierungsstufe (gzip
erlaubt Werte zwischen 1 und 9), desto besser die Komprimierungswirkung, desto höher aber auch der Verbrauch an CPU-Zeit. Durch eine Anpassung dieser Komprimierungsstufe könnte ein Betreiber also den trade-off zwischen CPU-Last und Bandbreiteneinsparung nach seinen eigenen Vorstellungen auflösen. Eigene Experimente haben ergeben, daß auch Stufe 3 bereits sehr nahe an die Komprimierungswirkung von Stufe 6 heran kommt - zumindest die Wahl zwischen diesen beiden Werten sollte dem Anwender überlassen werden.
Insofern wäre es sinnvoll, diese Komprimierungsstufe durch die Einführung einer zusätzlichen Direktive mod_gzip_compression_level
konfigurierbar zu gestalten.
gzip
unterstützt, sondern im Wesentlichen nur das, was Stufe 6 benötigt (obgleich die Programmstruktur darauf ausgelegt war, später einmal alle 9 Stufen zu unterstützen). Eine reine Änderung der genannten Konstante führt also nicht zum Erfolg; mod_gzip ist nach einer solchen Änderung nicht einmal mehr lauffähig.Verknüpfung der include
/exclude
-Direktiven um Boole'sche Ausdrücke
mod_gzip 1.3.19.1a verwendet - aufgrund der Art seiner Einbettung in die Request-Verarbeitung des Apache-Servers - ein komplexes, zweistufiges Filterverfahren für die Entscheidung, ob das Ergebnis eines Requests komprimiert werden soll. (In einer geänderten Architektur von Apache 2.0 könnte diese Einbettung in einfacherer Form möglich sein.)
Ein Request wird derzeit genau dann von mod_gzip akzeptiert, wenn in jeder der beiden Entscheidungsphasen mindestens eine include
-Regel, aber keine exclude
-Regel feuert. Da solche Regeln reguläre Ausdrücke als Parameterwerte erlauben, sind damit mächtige Bedingungen möglich.
Allerdings sind alle Regeln voneinander unabhängig. Die derzeit verfügbaren Direktiven erlauben es dem Anwender beispielsweise nicht, auszudrücken, daß bestimmte MIME-Typen nur an bestimmte Browser in komprimierter Form ausgeliefert werden sollen - es fehlt eine AND
Verknüpfung zwischen mehreren Regeln.
Es scheint nur wenige Einsatzfälle für dieses Feature zu geben - derzeit wäre es vor allem notwendig, um Filterregeln zur Umgebung der diversen bugs in Netscape 4 zu formulieren, ohne diesen Browser komplett von der Komprimierung ausschließen. Mit der Zeit (und besserer Standard-Kompatibilität der Browser) könnte dieses Feature entbehrlich werden.
Identische HTTP-Header für GET
- und HEAD
-Requests ausliefern
Gemäß RFC 2616 sollte eine HTTP/1.1-kompatible Implementierung für Anforderungen mit der Methode HEAD
identische HTTP-Header ausliefern, wie sie für eine Anforderung derselben Ressoruce mit der Methode GET
ausgeliefert werden würden.
Im Fall von mod_gzip würde dies bedeuten, daß auch bei einem HEAD
-Zugriff der Content zunächst einmal komprimiert (bzw. im Fall einer statisch vorkomprimierten Datei eingelesen) werden müßte, allein um einen korrekten HTTP-Header Content-Length
generieren zu können.
mod_gzip hat diesen - extrem seltenen - Anwendungsfall bisher nicht berücksichtigt (wahrscheinlich aus Performance-Überlegungen heraus); gemäß RFC 2119 könnte dies allerdings bedeuten, daß das Verhalten des Moduls deshalb jedoch nur 'bedingt kompatibel' zu HTTP/1.1 ist, da für das Ignorieren einer recommended
-Anforderung ein triftiger Grund vorliegen muß.
(Michael Schröpl, 2004-09-30)