Michael Schröpl: Perl-Modul mit der Funktion von mod_gzip

Beitrag lesen

Hi Erik,

gibt es ein Perl-Modul das die Funktion des Apache-Modules mod_gzip
übernehmen kann, wenn der Hoster dieses nicht installiert hat?

hm ... das ist nicht so einfach.

Also erstens einmal ist ein großer Teil dessen, was mod_gzip tut, gar
nicht mal das Komprimieren selbst. Dieses könntest Du sicherlich als
Modul irgendwo her bekommen. Schlimmstenfalls könntest Du Deinen Content
über eine pipe in ein "/usr/local/bin/gzip" oder so ähnlich jagen.
Wahrscheinlich gibt es aber in den Tiefen des CPAN schon einen gzipper.
Das löst aber einen großen Teil der Probleme nicht.

Diese gehen schon mal damit los, daß man herausfinden muß, ob der Client
überhaupt komprimierte Daten empfangen will. Dazu muß man in seinem
HTTP-Header nachsehen - das könnte ein Modul durchaus tun.

Als nächstes sollte man sich Gedanken darüber machen, ob man dem Client
glauben will. Es ist nämlich mitnichten so, daß der Client in jedem Fall,
in dem er behauptet, komprimierte Daten zu verstehen, das auch tatsächlich
tut. Neben HTML gibt es noch eine Menge anderer Dinge, die man mit HTTP
über die Leitung jagen kann ... mod_gzip muß sich da mit eine Menge Zeug
herumschlagen, die an dieser Stelle wohl zu weit führen würden. Reduzie-
ren wir Deinen Fall mal auf HTML, das vereinfacht die Sache schon sehr.

Tja, und wenn Du Dir sicher bist, daß Du komprimiert kommunizieren
willst, dann mußt Du es auch noch tun. Das ist nicht damit getan, daß
Du einfach komprimierte Daten auf die Leitung kippst - Du mußt sie in
einer Art und Weise verpacken, daß sie der Client auch wieder lesen kann.
Du mußt also den HTTP-Header mit den entsprechenden Informationen versehen.
Insbesondere muß da ganz vorne drin stehen, wie lang der komprimierte
Inhalt ist - Du mußt also zuerst komprimieren, dann den Header basteln
und die komprimierten Daten derweil irgendwo zwischenspeichern.

Und zu allem Überfluß ist das Basteln des Headers eine Aufgabe, die
normalerweise nur zu einem sehr kleinen Teil das CGI-Skript erledigt.
Du wirst gerade mal den Content-type setzen, den Rest macht der Web-
server für Dich. Und zwar nachdem Du Deine Ausgaben auf die "Leitung"
gekippt und die Kontrolle aufgegeben hast! Der Webserver (puffert die
Daten nämlich auch erst mal und tut genau das, was ich gerade beschrie-
ben habe: Er fügt diejenigen HTTP-Header dazu, von denen sinnvoller-
weise nur er die passenden Werte setzen kann (so Sachen wie seinen
Server-Namen, die aktuelle Uhrzeit etc.). Dein Skript ist leider schon
beendet und kann jetzt nicht nachträglich eingreifen - mod_gzip kann
das, weil es sich in einer Weise in die Apache-Ablaufkette hinein hängt,
welche (meistens) sicherstellt, daß sein mod_gzip_handler noch einmal
aufgerufen wird, bevor die Antwort auf die Reise geht. Und erst in
diesem allerletzten Moment fängt mod_gzip an, wirklich zu arbeiten -
wenn es sicher ist, daß ihm danach niemand mehr ins Handwerk pfuscht,
aber auch vorher schon alle Leute ihren Senf dazu gegeben haben.

Eine Lösung über ein Perl-Modul halte ich also aus rein architektonischen
Gründen für ziemlich schwierig. Wenn überhaupt, dann solltest Du Dir
Gedanken über NPH-Skripte machen (non parsed header - da hättest Du die
Kontrolle, sämtliche HTTP-Header zu basteln, Du mußt dann aber auch alles
selbst und vor allem korrekt tun).
Ich verwende selbst ein Programm (ein Binary, vermutlich in C), dessen
Autor sich tatsächlich die Mühe gemacht hat, "Content-Encoding: gzip"
selbst zu implementieren ... es geht also. (Und das Mistding hat nicht
mal einen Schalter, um die Komprimierung abzuwürgen - das versaut mir
meine ganze schöne statistische mod_gzip-Traffic-Analyse ...)

Anders könnte die Sache aussehen, wenn Dein Provider mod_perl verwendet

  • ein solches Apache-Modul hätte zumindest die Möglichkeit, die Funktio-
    nalität von mod_gzip selbst zu realisieren.
    Ich würde aber niemandem dazu raten, das zu implementieren - der
    ob_gzhandler von PHP 4
        (http://www.phpbuilder.com/columns/piergiorgio20010321.php3?page=3)
    versucht das zwar, aber ich bezweifele, daß er die Flexibilität von
    mod_gzip auch nur annähernd erreichen kann.

Wenn ich es recht bedenke, dann <werbung>dürften Webhosting-Angebote wie
die des Self-Portal-Sponsors PrimeKom für solche Extrawürste eine wirt-
schaftlich vertretbare Plattform bieten können ...</werbung>

Viele Grüße
      Michael