mod_gzip - Bereitstellung komprimierter Inhalte durch den Apache-Webserver

Autor: Michael Schröpl

Die eigentliche Installation ist nicht schwierig, aber die Methode zu finden, die am besten zu den Bedürfnissen Ihrer Apache-Installation passt, kann einige Zeit in Anspruch nehmen.

Daher wird dringend empfohlen, dieses Kapitel vollständig zu lesen und sich der Vor- und Nachteile der verschiedenen Optionen bewusst zu werden, bevor Sie die Betriebsart auswählen und die Installation durchführen.

Das vorliegende Dokument behandelt insbesondere das interne Verarbeitungsmodell von mod_gzip als Apache-Modul und kann somit Informationen bereitstellen, die hilfreich sein können, um die Bewertungsmethode von mod_gzip für Konfigurationsdirektiven zu verstehen.

Grundlagen

Einführung

Der Apache-Webserver unterstützt zwei verschiedene Methoden zur Integration eines Moduls in seinen Programmcode:

statische und
dynamische Integration.

Je nach dem verwendeten Betriebskonzept für Ihren Apache-Server und den gegebenen Anforderungen

muss eine dieser beiden Betriebsarten für mod_gzip ausgewählt werden und
muss der Dateisatz, der für diese Methode erforderlich ist, heruntergeladen werden.

Statische Integration eines Apache-Moduls

Statische Integration bedeutet, dass das Modul ein dauerhafter Bestandteil der verlinkten Programm-Binärdatei httpd wird, die den Apache-Server implementiert.

Dafür muss der Quellcode des Apache-Servers

um den Quellcode dieses Moduls erweitert und dann
als Ganzes mit einem C-Compiler kompiliert werden.

Normalerweise möchte jeder Administrator eine andere Funktionalität für seinen Apache-Server nutzen, die an seine eigenen Anforderungen angepasst ist; daher scheint es nicht machbar, Programmdateien, die auf einer Vielzahl von Plattformen lauffähig sind, zum Download bereitzustellen.

Dynamische Integration eines Apache-Moduls

Dynamische Integration bedeutet, dass das Modul beim Start des Apache-Prozesses aus einer separaten Moduldatei als Shared Object geladen werden kann.

Dafür

muss die Shared Object-Datei dieses Moduls für die erforderliche Zielplattform - entweder beschafft oder generiert werden und
in das entsprechende Apache-Verzeichnis installiert werden und
die Apache-Konfigurationsdatei muss um eine Direktive erweitert werden, um dieses Modul zu laden.

Die Struktur des Quellcodes des mod_gzip-Moduls

Die meisten Apache-Module bestehen nur aus einer einzigen Quellcodedatei. Diese Datei kann durch Aufruf des Programms apxs (mit entsprechenden Parameterwerten) kompiliert werden; für die Installation des auf diese Weise erstellten Shared Object wäre ein weiterer Aufruf von apxs (mit anderen Parameterwerten) erforderlich.

Ab Version 1.3.26.1a ist der Quellcode von mod_gzip in drei separate Dateien unterteilt:

mod_gzip.c (ca. 8000 Zeilen) enthält alle Funktionen, die notwendig sind, um die Verarbeitungslogik des mod_gzip-Apache-Moduls zu implementieren.
Diese Datei ist sehr stark von der Modul-Schnittstelle der Apache-Version 1.3 abhängig (die sich über viele Jahre nicht geändert hat).
mod_gzip_debug.c (ca. 500 Zeilen) enthält Funktionen, die lediglich für Debugging-Aufgaben für den Entwickler erforderlich sind; ein Teil dieser Funktionen ist nicht einmal in einem mod_gzip, das ‘normal’ kompiliert wurde, enthalten (abhängig von den Werten der gegebenen Compiler-Direktiven des -D-Typs zur Definition symbolischer Konstanten).
mod_gzip_compress.c (ca. 3000 Zeilen) enthält die Implementierung der gzip-Komprimierungsfunktion von Kevin Kiley, die ‘tatsächlich die Arbeit macht’.
Dieser Teil ist nicht von einer bestimmten Apache-Version abhängig und könnte (aus rein technischer Sicht) auch von anderen Komprimierungstools verwendet werden (wie mod_deflate, das derzeit ‘zlib’ für die Komprimierung verwendet).

Diese Struktur des Quellcodes erleichtert die Wartung von mod_gzip ein wenig - und macht die Installation etwas komplizierter (da nun mehrere Quellcodedateien anstelle von nur einer kompiliert werden müssen). Daher stellt mod_gzip jetzt Makefiles zur Verfügung, um diesen Installationsprozess zu vereinfachen.

Download

Je nachdem, welches der oben genannten Betriebskonzepte ausgeführt werden soll, sind unterschiedliche Dateien (geeignet für den jeweiligen Verwendungszweck) zu verwenden.

Zum Zeitpunkt dieses Schreibens sind die folgenden Dateien für jede mod_gzip-Version auf der Download-Seite des mod_gzip-Projekts verfügbar:

| mod_gzip- version .tgz: | ein gzip-komprimiertes tar-Archiv des mod_gzip-Produkts, einschließlich - dem Quellcode des Moduls (in der Programmiersprache C),

mehreren Makefiles (zum Kompilieren des Quellcodes),
einem Change-Log (als kurze Dokumentation der wichtigsten Änderungen für alle Programmversionen) und
der vorliegenden Dokumentation. | | ApacheModuleGzip.dll.zip: | ein ZIP-Archiv, das die Shared Object-Datei von mod_gzip für die Windows-Plattform enthält. | | mod_gzip- version -FreeBSD-4.6-i386.so.gz: | eine gzip-komprimierte Datei, die die Shared Object-Datei von mod_gzip für die FreeBSD-UNIX 4.6-Plattform enthält. | | mod_gzip.so.gz: | eine gzip-komprimierte Datei, die die Shared Object-Datei von mod_gzip für die Solaris 2.7-Plattform enthält. |

Wenn mod_gzip mit dynamischer Integration auf einer anderen Plattform ausgeführt werden soll, muss die Shared Module-Datei für diese Plattform vom Administrator erstellt werden.

Statische Integration von mod_gzip

Die normale Kompilierung des Apache-Webservers

Das Verfahren zur Installation des Apache-Webservers auf einer UNIX-Maschine, das von der Apache Group dokumentiert wurde, lautet wie folgt (in der Kurzversion):

Laden Sie das Archiv mit dem Quellcode von Apache aus dem WWW herunter
Entpacken Sie das Archiv
Navigieren Sie in das durch die vorherige Operation erstellte Verzeichnis
Lesen Sie und verstehen Sie die Datei INSTALL
Starten Sie das Shell-Skript ./configure mit den angemessenen Parameterwerten (dies führt zur Erstellung von Makefile-Dateien in einer großen Anzahl von Unterverzeichnissen)
make install (dies führt zur Kompilierung und Installation des Apache-Servers einschließlich seiner Online-Dokumentation)

Wenn der Apache-Webserver auf diese Weise erstellt wurde, werden die mitgelieferten Module normalerweise zu statischen Teilen der erstellten Programmdatei httpd im Apache-Programmierverzeichnis - es sei denn, Sie haben etwas anderes in den Parametern des configure-Aufrufs angegeben.

(Der tatsächliche Aufruf von configure kann sehr umfangreich werden, abhängig vom Grad der Abweichung von den Standardparameterwerten. Ich empfehle, diesen Aufruf selbst in einem kleinen Shell-Skript zu speichern, um die Art der verarbeiteten Installation zu dokumentieren.)

Die Integration von mod_gzip in den Apache-Quellcode

Der Quellcode der offiziellen Apache-Module befindet sich im src/modules-Unterverzeichnis des entpackten tar-Archivs der Apache-Software.

Um mod_gzip von diesem Mechanismus wie ein Standard-Apache-Modul behandeln zu lassen, sind folgende Vorbereitungen erforderlich:

Entpacken und entpacken Sie den Inhalt des Download-Archivs, das den mod_gzip-Quellcode enthält (was ein Verzeichnis mod_gzip- versionsnummer erstellt),
Erstellen Sie ein Verzeichnis src/modules/gzip innerhalb des Verzeichnisbaums des Apache-Quellcodes
Kopieren Sie alle Dateien mit den Erweiterungen .c*, .h und .tmpl in dieses neue gzip-Verzeichnis.

Als nächsten Schritt erweitern Sie den configure-Aufruf um den Parameter –activate-module=src/modules/gzip/mod_gzip.c. Jetzt wird das configure-Skript den mod_gzip-Quellcode finden und ein geeignetes Makefile aus der mitgelieferten Datei Makefile.tmpl erstellen - protokolliert durch die Nachrichten

 + aktiviertes gzip-Modul (modules/gzip/mod_gzip.c)

und

Erstellen von Makefile in src/modules/gzip

letzteres genau wie für die eigenen Module von Apache. (Das Makefile, das mit mod_gzip geliefert wird, ist nicht für diese Art der Installation geeignet - dieses ist nur für die Erstellung einer Shared Object-Datei.)

Jetzt wird die Apache-Installation wie gewohnt funktionieren - und mod_gzip wird wie ein normales Apache-Modul behandelt.

Aber configure weiß, dass ein über den Parameter –activate-module integriertes Modul ein Drittanbieter-Modul ist, das wahrscheinlich spezifische Anforderungen hat, und wird daher mod_gzip automatisch oben auf dem Modulstapel laden, sodass es Zugriff auf die eingehende HTTP-Anfrage vor allen anderen Modulen hat - was genau das ist, was mod_gzip dringend benötigt.

Auf einigen Plattformen scheint das Configure von Apache den Wert der Umgebungsvariablen $(LIBEXT) nicht automatisch auf den richtigen Wert von .a zu setzen. In diesem Fall wird die Kompilierung von mod_gzip fehlschlagen. Der genaue Grund für dieses Verhalten ist derzeit unbekannt; als Workaround können Sie die Zeile

LIB=libgzip.$(LIBEXT)

durch

LIB=libgzip.a

innerhalb der mitgelieferten Datei Makefile.tmpl ersetzen, d. h. den richtigen Wert manuell einfügen.

Stellen Sie sicher, dass Sie für diese Aufgabe einen Editor verwenden, der keine Tabulatorzeichen in Leerzeichen umwandelt!

(Zu testen: Was passiert, wenn mehr als ein Drittanbieter-Modul mit –activate-module integriert wird? Ist die Reihenfolge der Parameterwerte in diesem Fall relevant?)

Überprüfen, ob mod_gzip korrekt integriert wurde

Um zu überprüfen, ob mod_gzip tatsächlich wie gewünscht in den Apache-Programmcode integriert wurde, stellt der Apache-Server den Befehl httpd -l zur Verfügung. Dies zeigt eine Liste aller integrierten Module (in der Reihenfolge, in der sie geladen werden); mod_gzip.c sollte der letzte dort angezeigte Eintrag sein.

Dynamische Integration von mod_gzip

Das Konzept der ladbaren Apache-Module

Der Apache-Webserver unterstützt das Konzept der ladbaren Module.

Fast jedes Apache-Modul kann

als Shared Object kompiliert und dann
beim Start des Apache-Servers dynamisch in den Adressraum von Apache geladen werden (unter Verwendung der entsprechenden Konfigurationsdirektiven).

Der Umgang mit ladbaren Modulen erfordert zusätzliches Wissen über die Apache-Konfiguration (da die Reihenfolge, in der diese Module geladen werden, für deren Funktion von Bedeutung sein kann), ermöglicht jedoch Änderungen am Codebereich des Apache-Servers, ohne den Quellcode neu kompilieren zu müssen.

Auf Plattformen wie Windows (wo nicht viele Apache-Administratoren eine C-Entwicklungsumgebung zur Verfügung haben, um den Apache-Code zu kompilieren und zu verlinken) kann die Verwendung von ladbaren Modulen oft die einzige Möglichkeit sein, den Funktionsumfang des Apache-Servers zu erweitern.

Die Dokumentation von Apache 1.3 bietet die folgenden Artikel zu diesem Thema:

Unterstützung für dynamische Shared Objects (DSO) - die Beschreibung des entsprechenden Konzepts für den Apache-Webserver
Modul mod_so - die Beschreibung des Apache-Moduls zum Laden anderer Module und der erforderlichen Konfigurationsdirektiven

Direktive zum Laden von mod_gzip

Um das mod_gzip Shared Object dynamisch zum Apache-Code hinzuzufügen, ist eine der folgenden Konfigurationsdirektiven erforderlich:

# ---------------------------------------------------------------------  
# lade eine DLL / Windows:  
  LoadModule gzip_module modules/ApacheModuleGzip.dll  
# ---------------------------------------------------------------------  
# lade ein DSO / UNIX:  
  LoadModule gzip_module modules/mod_gzip.so**  
# ---------------------------------------------------------------------  
# (keines von beiden, wenn das Modul statisch integriert ist)  
# ---------------------------------------------------------------------

Der tatsächliche Dateiname kann frei gewählt werden - er muss nur mit dem Namen der tatsächlich verwendeten Datei übereinstimmen. Andererseits kann dieser Name von der Betriebssystemplattform und sogar von der Kompilierungsmethode dieses Moduls abhängen - in diesem Fall muss entweder die oben gezeigte Direktive angepasst oder die Datei entsprechend umbenannt werden.

Der Umgang mit Modulen durch Apache 1.3

Der Apache-Server kann beliebig viele Module dynamisch laden. Dabei werden die entsprechenden LoadModule-Direktiven in der Reihenfolge ihrer Vorkommen innerhalb der Konfigurationsdatei verarbeitet.

Die Module werden jedoch in einem Stapel im Arbeitsspeicher geladen: Das zuletzt geladene Modul erhält als erstes Zugriff auf die Bearbeitung der entsprechenden HTTP-Anfrage an den Apache-Webserver - und kann dann entscheiden, ob es sich für die Bearbeitung dieser Anfrage verantwortlich fühlt oder nicht.

Nur eines der betreffenden Module kann in Apache 1.3 für die Bearbeitung einer Anfrage verantwortlich sein - nachfolgende Module werden nicht einmal gefragt.

Die Integration von mod_gzip in die Bewertung einer Anfrage durch Apache

Um die Ausgabe von beliebigen Modulen verarbeiten zu können, muss mod_gzip etwas tun, das tatsächlich der Architektur von Apache 1.3 widerspricht: Es muss eine Anfrage ‘bearbeiten’, aber anschließend die Verantwortung für die Bearbeitung dieser Anfrage zurückziehen. Nur durch dieses Verfahren kann das Modul, das tatsächlich für die Bearbeitung der Anfrage verantwortlich ist, vom Apache-Server überhaupt aktiviert werden.

In dieser ersten Phase bedeutet die ‘Bearbeitung’ dieser Anfrage durch mod_gzip nicht, den Inhalt der Seite, die bereitgestellt werden soll, zu komprimieren - denn dieser Inhalt existiert noch nicht, er muss noch von einem anderen Modul generiert werden! Stattdessen bereitet mod_gzip zu diesem Zeitpunkt lediglich vor, erneut gefragt zu werden, ob es nach der Erstellung des Seiteninhalts etwas tun möchte. Nur in dieser zweiten Phase seiner Aktivierung (in der der Inhalt des HTTP-Antwortpakets bereits verfügbar ist) kann mod_gzip seine wesentliche Aufgabe erfüllen, nämlich den Inhalt eines HTTP-Antwortpakets zu komprimieren (und die Modifikation bestimmter HTTP-Header).

Diese ‘Registrierung’ für die spätere Nachbearbeitung der HTTP-Antwort, die von mod_gzip durchgeführt wird, ist nur erforderlich, wenn mod_gzip zu diesem Zeitpunkt nicht bereits feststellen kann, dass es sich ohnehin nicht für die Verarbeitung des Antwortinhalts interessieren wird.

So führt mod_gzip in dieser ersten Phase bereits einen Teil der Bewertung der Filterdirektiven durch, die in der Apache-Konfiguration angegeben sind: Es überprüft die Regeln, bei denen es dies allein auf der Grundlage der Anfragebeschreibung tun kann (d. h. den Inhalt der entsprechenden HTTP-Header). Dies gilt für die mod_gzip_item_include / mod_gzip_item_exclude-Regeln des Typs

reqheader (Inhalt der HTTP-Anfrage-Header der Anfrage),
url (URL der angeforderten HTTP-Ressource),
file (Dateiname der von dieser Anfrage betroffenen Datei, nach Auswertung aller Alias-Übersetzungen usw.) und
handler (Name des für die Auswertung dieser Anfrage verantwortlichen Handlers gemäß der Apache-Konfiguration).

Wenn die Bewertung dieser Filterregeln bereits zeigt, dass das Ergebnis dieser Anfrage nicht komprimiert werden darf, d. h. wenn

mindestens eine exclude-Regel erfüllt ist oder
keine der include-Regeln erfüllt ist oder
wenn keine andere Bedingung für die Durchführung der Komprimierung erfüllt ist (z. B. kann zu diesem Zeitpunkt bereits überprüft werden, ob der Client das Bereitstellen komprimierter Daten überhaupt berechtigt hat, indem er den Accept-Encoding: gzip-HTTP-Header sendet)

dann ist es nicht notwendig, dass mod_gzip die verbleibenden Regeln nach der Erstellung des Antwortinhalts überprüft - dies wird dann nicht geschehen, da mod_gzip das Ergebnis der ersten Bewertungsphase für jede Anfrage merkt und die zweite Phase in diesem Fall sofort beendet.

Andernfalls überprüft mod_gzip in der zweiten Phase seines Betriebs die verbleibenden Filterregeln, die nur auf der Grundlage des tatsächlichen Inhalts des generierten Antwortpakets ausgewertet werden können:

rspheader (Inhalt der HTTP-Antwort-Header) sowie
mime (HTTP-Inhaltstyp des Ergebnisses).

Darüber hinaus werden jetzt einige andere Bedingungen getestet, wie die Größe des Antwortpakets (Direktiven mod_gzip_minimum_file_size bzw. mod_gzip_maximum_file_size).

Und nur wenn alle diese Tests zu einem positiven Ergebnis geführt haben, wird die Komprimierung des Antwortpakets tatsächlich durchgeführt.

Die Position von mod_gzip innerhalb der Ladefolge aller Apache-Module

Um alle oben beschriebenen Aufgaben ausführen zu können, muss das mod_gzip-Modul Zugriff auf die Bearbeitung der HTTP-Anfrage vor jedem anderen Apache-Modul haben, dessen Ausgabe es verarbeiten soll. Aufgrund der umgekehrten Reihenfolge des Zugriffs auf die Bearbeitung einer Anfrage für alle Apache-Module sollte mod_gzip als letztes von allen Apache-Modulen geladen werden.

Für die statische Integration wird diese Modulreihenfolge durch den ‘Blaupause’ des httpd-Programms während der Kompilierung des Apache-Quellcodes definiert. Das Verfahren zur Kompilierung des von der Apache Group gelieferten Quellcodes, das durch das configure-Shell-Skript aktiviert wird, kennt alle Abhängigkeiten zwischen den gelieferten Modulen (und sorgt für eine entsprechende Reihenfolge dieser Module), jedoch nicht die Anforderungen von Drittanbieter-Modulen wie mod_gzip, die durch den configure-Parameter –add-module= datei in den Kompilierungsprozess integriert werden. Um diesen Drittanbieter-Modulen maximalen Einfluss zu gewähren, werden solche Module als letzte Module im Modulstapel geladen.

Wenn mod_gzip also als das einzige Drittanbieter-Modul in einen Apache-Server integriert werden soll, dann macht configure automatisch das Richtige. Im Falle der Verwendung von mehr als einem Drittanbieter-Modul ist der Administrator dafür verantwortlich, diese Module zu ordnen (vielleicht nach der Reihenfolge seiner –add-module= Werte? Ich habe das noch nicht getestet).

Kompilierung von mod_gzip mit apxs

Die Funktion des Apache-Kompilierungswerkzeugs apxs

Wenn ein Apache-Server betrieben wird, um die dynamische Integration von Modulen zu unterstützen (d. h. das mod_so-Modul verwendet), wird während der Apache-Installation ein Dienstprogramm namens apxs im bin-Verzeichnis von Apache erstellt.

Dieses Programm ermöglicht es dem Benutzer, den Quellcode eines Apache-Moduls (unter Verwendung eines C-Compilers) zu kompilieren und eine entsprechende Shared Object-Datei zu erstellen, ohne dass der vollständige Quellcode der Apache-Server verfügbar sein muss: apxs kennt alle erforderlichen Apache-Programmierschnittstellen und liefert dem C-Compiler die notwendigen Informationen.

Erstellen eines Shared Object für mod_gzip mit make

Um den Benutzer davon abzuhalten, herauszufinden, wie genau mod_gzip vollständig kompiliert und installiert werden muss, wenn apxs verwendet wird, wird eine Datei namens Makefile innerhalb des Quellcode-Archivs bereitgestellt.

Mit diesem Makefile reduziert sich das Installationsverfahren auf die folgenden Schritte:

Extrahieren Sie die Dateien aus der heruntergeladenen mod_gzip-Quellcode-Archivdatei in ein (neues, temporäres) Verzeichnis Ihrer Wahl und wechseln Sie in dieses Verzeichnis.
Finden Sie den Pfadnamen des Programms apxs aus Ihrer Apache-Installation.
Führen Sie die Kompilierung mit dem Befehl make APXS=*your_apxs_pathname* aus. Dies erstellt die Shared Object-Datei mod_gzip.so im aktuellen Verzeichnis.
(Dieser Schritt der Ablauffolge kann weggelassen werden, da er dann durch den nachfolgenden Schritt abgedeckt wird.)
Führen Sie die Installation mit dem Befehl make install APXS=*your_apxs_pathname* aus. Dies kopiert nicht nur die Shared Object-Datei in das entsprechende Verzeichnis der Apache-Installation, sondern erweitert auch automatisch die Apache-Konfigurationsdatei httpd.conf um die erforderlichen Direktiven LoadModule und AddModule … wenn Sie nicht möchten, dass fremde Programme Ihre wertvollen Konfigurationsdateien überschreiben, ziehen Sie es möglicherweise vor, diesen letzten Schritt manuell durchzuführen oder zumindest eine Sicherung Ihrer Apache-Konfiguration zuerst zu erstellen.

Neben diesen notwendigen Schritten unterstützt das Makefile die folgenden Befehle (die für Entwickler eher von Interesse sein könnten):

make clean entfernt alle erstellten Objektmoduldateien der mod_gzip-Quellcodedateien aus dem aktuellen Verzeichnis (d. h. alle Dateien mit dem Namensmuster *.o).
make clean zusätzlich entfernt die erstellte Shared Object-Datei mod_gzip.so ebenfalls.

Ursprünglicher Standort dieses Dokuments:

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

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