Filterung zu komprimierender Anfragen
Nicht jede Datei, die vom Webserver abgerufen wird, sollte auch komprimiert werden. So macht es beispielsweise wenig Sinn ein in Punkto Platzverbrauch bereits minimal gehaltenes JPG-Bild durch den Packalgorithmus des Webservers zu jagen. Letztlich werden in solch einem Fall nur Zeit und Resourcen verschwendet. Deshalb sollten auch nur bestimmte Dateien der Komprimierung durch mod_gzip zugeführt werden.
Nach den zuvor beschriebenen grundlegenen Angaben folgt nun eine Auswahl der Dateien, die durch den Webserver komprimiert werden sollen. Dabei lassen sich Dateien durch Positiv- und Negativ-Filter gezielt über den Dateinamen, den Mime-Typen oder bestimmte Angaben im Response-Header auswählen. Eine solche Filterung ist wichtig, denn schließlich wirken sich unnötig durchgeführte Packvorgänge negativ auf die Geschwindigkeit einer Website aus. Folgender Block enthält die zugehörigen Einstellungen in der .htaccess-Datei:
AddEncoding gzip .gz
mod_gzip_update_static no
mod_gzip_item_include file \.(html|php|rss)$
mod_gzip_item_exclude file \.(css|js|exe)$
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
mod_gzip_dechunk yes
...
AddEncoding gzip .gz bewirkt eine modulinterne Zuordnung zwischen .gz und dem Content-Encoding gzip, was zu einer internen Weiterleitung, nicht aber zum Setzen entsprechender Informationen zum Content-Encoding für den Response-Header führt. Diese Festlegung der Zuordnungen von Dateien zu ihrem Content-Encoding muss – wie unter FilesMatch beschrieben – zusätzlich per set Header erfolgen.
Über mod_gzip_update_static no wird festgelegt, dass ggf. im Dateisystem des Webservers vorhandene bereits vorkomprimierte Dateien nicht durch eine neuere Version ersetzt werden sollen. Durch Angabe von yes würde die gepackte Dateiversion automatisch überschrieben werden, wenn die ungepackte Datei neueren Datums ist. Zwar würde diese Vorgehensweise dazu führen, dass Dateien nur einmal – nämlich nach einer Änderung der ungepackten Datei – gepackt und im Dateisystem abgelegt wird – bei Folgeaufrufen kann diese Datei vorkomprimiert aus dem Filesystem ausgeliefert werden. Allerdings setzt dies voraus, dass der Webserver Schreibrechte auf die gepackten Dateien haben muss. Zur Sicherheit sollte diese Option ausgeschaltet bleiben – falls dennoch gewünscht, sollte das korrekte Verhalten überprüft werden.
Mit den nun folgenden Anweisungen mod_gzip_item_include und mod_gzip_item_exclude werden die Dateien – über deren Dateiendung gesteuert – angegeben, bei denen eine Komprimierung erwünscht bzw. nicht gewollt ist. Der erste Parameter file gibt dabei an, dass die Dateinamen zur Entscheidung – ob komprimiert werden soll oder nicht – herangezogen werden. Auch hier kommen bei der Angabe von Dateiendungen wieder reguläre Ausdrücke (\.(html|css)$ bedeutet alle auf .html und .css endenden Dateien) zum Einsatz um eine größere Flexibilität bei der Dateiauswahl nutzen zu können. Dateien mit den Endungen .js und .css werden wegen Problemen seitens älterer aber dennoch bislang weit verbreiteter Browseranwendungen (Internet Explorer bis 6.0 haben unter Umständen Probleme mit komprimierten JavaScript-Dateien) ausgespart. Darüber hinaus werden ausführbare .exe-Dateien auch nicht komprimiert.
Die nächste der Item-Exclude-Angaben nimmt den Mime-Type einer Datei zur Entscheidungsfindung. Hier werden alle Dateien, die einen bildbasierten Mime-Type haben (durch image/ werden alle Kombinationen wie image/gif, image/jpg, image/png usw. bezeichnet) ausgeschlossen. Da diese Dateien bereits durch ihr internes Kodierungsverfahren komprimiert sind, würde eine zusätzliche Komprimierung nur Zeit kosten und die Dateien wären am Ende auch nicht kleiner als zuvor.
Der letzte Item-Exclude-Filter nutzt mit rspheader den Response-Header einer Anfrage und entscheidet, dass alle Anfragen deren Response-Header ein Content-Encoding enthalten, der besagt, dass die Ausgabe schon komprimiert ist, nicht zur Komprimierung vorgesehen sind. Damit wird verhindert, dass beispielsweise ein PHP-Script, welches eine bereits durch das Script komprimierte Antwort versendet, nocheinmal einer Kompression zugeführt wird.
Am Ende steht die Einstellung mod_gzip_dechunk yes. Hierdurch wird der Eintrag Transfer-Encoding: chunked aus dem Response-Header getilgt, wodurch Probleme mit per PHP oder Perl-Scripte dynamisch generierten Seiten vermieden werden, wenn diese die angeforderten Daten „häppchenweise” ausliefern. Derarige Probleme treten beispielsweise bei vielen Content-Management-Systemen auf.