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.

Eine genauere Untersuchung durch Christian Kruse hat zu der Erkenntnis geführt, daß Kevin Kileys Komprimierungscode für mod_gzip offenbar gar nicht alle 9 Komprimierungsstufen von 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)