mod_gzip - servir du contenu compressé par le serveur web Apache

Auteur : Michael Schröpl

Effectuer l’installation n’est pas difficile, mais trouver la méthode qui convient le mieux aux besoins de votre installation Apache peut prendre un certain temps.

Il est donc fortement recommandé de lire ce chapitre complètement et de prendre conscience des avantages et des inconvénients des différentes options avant de sélectionner la méthode d’opération et d’effectuer l’installation.

Le document en main couvre particulièrement le modèle de traitement interne de mod_gzip en tant que module Apache et peut donc fournir des informations qui peuvent être utiles pour comprendre la méthode d’évaluation de mod_gzip pour les directives de configuration.

Bases

Introduction

Le serveur web Apache prend en charge deux méthodes différentes d’intégration d’un module dans son code source :

intégration statique et
intégration dynamique.

Selon le concept d’opération utilisé pour votre serveur Apache et les exigences données

l’une de ces deux méthodes d’opération pour mod_gzip doit être sélectionnée et
le jeu de fichiers requis pour cette méthode doit être téléchargé.

Intégration statique d’un module Apache

L’intégration statique signifie que le module devient une partie permanente du binaire de programme lié httpd qui implémente le serveur Apache.

Pour cela, le code source du serveur Apache doit être

étendu par le code source de ce module et ensuite
compilé dans son ensemble en utilisant un compilateur C.

Normalement, chaque administrateur peut vouloir utiliser un ensemble différent de fonctionnalités pour son serveur Apache adapté à ses propres exigences ; il ne semble donc pas faisable de fournir des fichiers de programme prêts à l’emploi pour téléchargement sur une multitude de plateformes.

Intégration dynamique d’un module Apache

L’intégration dynamique signifie que le module peut être chargé à partir d’un fichier de module séparé en tant qu’objet partagé lors du démarrage du processus Apache.

Pour cela

le fichier d’objet partagé de ce module pour la plateforme cible requise doit être - soit procuré soit généré et
installé dans le répertoire Apache correspondant et
le fichier de configuration Apache doit être étendu par une directive pour charger ce module.

La structure du code source du module mod_gzip

La plupart des modules Apache se composent d’un seul fichier de code source. Ce fichier peut être compilé en invoquant le programme apxs (avec les valeurs de paramètres correspondantes) ; pour l’installation de l’objet partagé créé de cette manière, une autre invocation de apxs (avec des valeurs de paramètres différentes) serait requise.

À partir de la version 1.3.26.1a, le code source de mod_gzip est divisé en trois fichiers séparés :

mod_gzip.c (environ 8000 lignes) contient toutes les fonctions nécessaires à l’implémentation de la logique de traitement du module Apache mod_gzip.
Ce fichier dépend beaucoup de l’interface du module de la version 1.3 d’Apache (qui n’a pas changé pendant de nombreuses années).
mod_gzip_debug.c (environ 500 lignes) contient des fonctions qui ne sont nécessaires que pour les tâches de débogage pour le développeur ; une partie de ces fonctions n’est même pas contenue dans un mod_gzip compilé ‘de la manière normale’ (en fonction des valeurs des directives de compilateur données de type -D pour définir des constantes symboliques).
mod_gzip_compress.c (environ 3000 lignes) contient l’implémentation de Kevin Kiley de la fonction de compression gzip, celle qui ‘fait réellement le travail’.
Cette partie n’est pas dépendante d’aucune version spécifique d’Apache et (d’un point de vue purement technique) pourrait également être utilisée par d’autres outils de compression (comme mod_deflate qui utilise actuellement ‘zlib’ pour la compression).

Cette structure du code source rend la maintenance de mod_gzip un peu plus facile - et l’installation un peu plus compliquée (car maintenant plusieurs fichiers source doivent être compilés au lieu d’un seul). Par conséquent, mod_gzip fournit maintenant des Makefile pour simplifier ce processus d’installation.

Télécharger

Selon lequel des concepts d’opération nommés ci-dessus doit être exécuté, différents fichiers (adaptés à l’usage respectif) doivent être utilisés.

Au moment de la rédaction, les fichiers suivants sont disponibles pour chaque version de mod_gzip sur la page de téléchargement du projet mod_gzip :

| mod_gzip- version .tgz: | une archive tar compressée gzip du produit mod_gzip, incluant - le code source du module (en langage de programmation C),

plusieurs Makefile (pour compiler le code source),
un Change-Log (comme documentation courte des changements les plus importants pour toutes les versions du programme) et
la documentation en main. | | ApacheModuleGzip.dll.zip: | une archive ZIP contenant le fichier objet partagé de mod_gzip pour la plateforme Windows. | | mod_gzip- version -FreeBSD-4.6-i386.so.gz: | un fichier compressé gzip contenant le fichier objet partagé de mod_gzip pour la plateforme FreeBSD-UNIX 4.6. | | mod_gzip.so.gz: | un fichier compressé gzip contenant le fichier objet partagé de mod_gzip pour la plateforme Solaris 2.7. |

Si mod_gzip doit être exécuté avec une intégration dynamique sur une autre plateforme, alors le fichier de module partagé pour cette plateforme doit être créé par l’administrateur.

Intégration statique de mod_gzip

La compilation normale du serveur web Apache

La procédure d’installation du serveur web Apache sur une machine UNIX documentée par le groupe Apache se lit comme suit (dans la version courte) :

télécharger l’archive avec le code source d’Apache depuis le WWW
décompresser l’archive
naviguer dans le répertoire créé par l’opération précédente
lire et comprendre le fichier INSTALL
démarrer le script shell ./configure avec les valeurs de paramètres appropriées (cela entraînera la création de fichiers Makefile dans un grand nombre de sous-répertoires)
make install (cela entraînera la compilation et l’installation du serveur Apache y compris sa documentation en ligne)

Si le serveur web Apache a été créé de cette manière, alors les modules fournis deviennent normalement des parties statiques du fichier de programme créé httpd dans le répertoire du programme Apache - à moins que vous n’ayez spécifié quelque chose de différent dans les paramètres de l’appel configure.

(L’appel réel de configure peut devenir très étendu, en fonction du degré de déviation par rapport aux valeurs de paramètres standard. Je recommande de stocker cet appel lui-même dans un petit script shell pour documenter le type d’installation traitée d’ailleurs.)

L’intégration de mod_gzip dans le code source d’Apache

Le code source des modules Apache officiels est contenu dans le sous-répertoire src/modules de l’archive tar décompressée du logiciel Apache.

Pour que mod_gzip soit traité comme un module Apache standard par ce mécanisme, les préparations suivantes sont nécessaires :

Décompresser et déballer le contenu de l’archive de téléchargement contenant le code source de mod_gzip (ce qui créera un répertoire mod_gzip- numéro de version),
Créer un répertoire src/modules/gzip dans l’arborescence du code source d’Apache
Copier tous les fichiers avec les extensions .c*, .h et .tmpl dans ce nouveau répertoire gzip.

Comme prochaine étape, vous étendez l’appel configure par le paramètre –activate-module=src/modules/gzip/mod_gzip.c. Maintenant, le script configure trouvera le code source de mod_gzip et créera un Makefile approprié à partir du fichier fourni Makefile.tmpl - enregistré par les messages

 + module gzip activé (modules/gzip/mod_gzip.c)

Création de Makefile dans src/modules/gzip

ce dernier comme pour les propres modules d’Apache. (Le Makefile fourni avec mod_gzip n’est pas adapté pour ce type d’installation - celui-ci est uniquement pour la création d’un fichier objet partagé.)

Maintenant, l’installation d’Apache fonctionnera comme d’habitude - et mod_gzip sera traité comme un module Apache normal.

Mais configure sait qu’un module intégré via le paramètre –activate-module est un module tiers qui peut probablement avoir des exigences spécifiques, et donc chargera mod_gzip automatiquement au sommet de la pile de modules afin qu’il ait accès à la requête HTTP entrante avant tous les autres modules - ce qui est exactement ce dont mod_gzip a urgemment besoin.

Sur certaines plateformes, il semble que la configuration d’Apache ne définisse pas automatiquement la valeur de la variable d’environnement $(LIBEXT) à la valeur appropriée de .a. Dans ce cas, la compilation de mod_gzip échouera. La raison exacte de ce comportement est inconnue à l’heure actuelle ; comme solution de contournement, vous pouvez remplacer la ligne

LIB=libgzip.$(LIBEXT)

par

LIB=libgzip.a

dans le fichier fourni Makefile.tmpl, c’est-à-dire insérer la valeur appropriée manuellement.

Assurez-vous d’utiliser un éditeur qui n’expanse pas les caractères de tabulation en espaces pour cette tâche !

(À tester : Que se passe-t-il lors de l’intégration de plus d’un module tiers avec –activate-module ? L’ordre des valeurs de paramètres est-il pertinent dans ce cas ?)

Vérifiez que mod_gzip a été intégré correctement

Pour vérifier si mod_gzip a effectivement été intégré dans le code du programme Apache comme demandé, le serveur Apache fournit la commande httpd -l. Cela affichera une liste de tous les modules intégrés (dans l’ordre dans lequel ils seront chargés) ; mod_gzip.c devrait être la dernière entrée affichée là.

Intégration dynamique de mod_gzip

Le concept des modules Apache chargeables

Le serveur web Apache prend en charge le concept de modules chargeables.

Presque chaque module Apache peut être

compilé en tant qu’objet partagé et ensuite
chargé dynamiquement dans l’espace d’adressage d’Apache au démarrage du serveur Apache (en utilisant les directives de configuration correspondantes).

La gestion des modules chargeables nécessite des connaissances supplémentaires sur la configuration d’Apache (car l’ordre dans lequel ces modules sont chargés peut être significatif pour leur fonctionnement) mais permet des modifications de la plage de code du serveur Apache sans avoir à recompiler son code source.

Sur des plateformes comme Windows (où peu d’administrateurs Apache ont un environnement de développement C à disposition pour compiler et lier le code Apache), l’utilisation de modules chargeables peut souvent être la seule possibilité d’élargir le champ fonctionnel du serveur Apache.

La documentation d’Apache 1.3 fournit les articles suivants sur ce sujet :

Support des objets partagés dynamiques (DSO) - la description du concept correspondant pour le serveur web Apache
Module mod_so - la description du module Apache pour charger d’autres modules et les directives de configuration requises

Directive pour charger mod_gzip

Pour ajouter dynamiquement l’objet partagé mod_gzip au code d’Apache, l’une des directives de configuration suivantes est requise :

# ---------------------------------------------------------------------  
# charger un DLL / Windows :  
  LoadModule gzip_module modules/ApacheModuleGzip.dll  
# ---------------------------------------------------------------------  
# charger un DSO / UNIX :  
  LoadModule gzip_module modules/mod_gzip.so**  
# ---------------------------------------------------------------------  
# (aucun des deux si le module est intégré statiquement)  
# ---------------------------------------------------------------------

Le nom de fichier réel peut être choisi librement - il doit seulement correspondre au nom du fichier effectivement utilisé. D’autre part, ce nom peut dépendre de la plateforme du système d’exploitation et même de la méthode de compilation utilisée pour ce module - dans ce cas, soit la directive affichée ci-dessus doit être adaptée, soit le fichier doit être renommé en conséquence.

La gestion des modules par Apache 1.3

Le serveur Apache peut charger dynamiquement n’importe quel nombre de modules. Lors de ce processus, les directives LoadModule correspondantes sont traitées dans l’ordre de leur occurrence dans le fichier de configuration.

Mais les modules sont chargés sur une pile dans la mémoire de travail : Le module qui a été chargé dernier sera le premier à avoir accès au traitement de la requête HTTP correspondante au serveur web Apache - et peut alors décider s’il considère être responsable du traitement de cette requête ou non.

Un seul de tous les modules concernés peut être responsable du traitement d’une requête dans Apache 1.3 - les modules suivants ne seront même pas interrogés.

L’intégration de mod_gzip dans l’évaluation d’une requête par Apache

Par conséquent, pour pouvoir traiter la sortie de modules arbitraires, mod_gzip doit faire quelque chose qui contredit en fait l’architecture d’Apache 1.3 : Il doit ‘traiter’ une requête mais ensuite révoquer la responsabilité de traiter cette requête. Ce n’est qu’en procédant ainsi que le module qui est effectivement responsable du traitement de la requête peut encore être activé par le serveur Apache.

Dans cette première phase, le ‘traitement’ de cette requête par mod_gzip ne signifie pas compresser le contenu de la page à servir - car ce contenu n’existe même pas encore, il doit encore être généré par un autre module ! Au lieu de cela, à ce moment-là, mod_gzip se prépare simplement à être interrogé à nouveau s’il souhaite faire quelque chose après la création du contenu de la page. Ce n’est que dans cette seconde phase de son activation (où le contenu de la réponse HTTP est déjà disponible alors) que mod_gzip peut effectuer sa tâche essentielle, qui est de compresser le contenu d’un paquet de réponse HTTP (et la modification de certains en-têtes HTTP).

Cette ‘inscription’ pour un traitement ultérieur de la réponse HTTP effectuée par mod_gzip n’est nécessaire que si mod_gzip ne peut pas déjà déterminer à ce stade qu’il ne sera définitivement pas intéressé par le traitement du contenu de la réponse de toute façon.

Ainsi, dans cette première phase, mod_gzip effectue déjà une partie de l’évaluation des directives de filtre spécifiées dans la configuration d’Apache : Il vérifie ces règles où il peut le faire sur la base de la description de la requête seule (c’est-à-dire le contenu des en-têtes HTTP correspondants). Cela s’applique aux règles mod_gzip_item_include / mod_gzip_item_exclude de type

reqheader (contenu des en-têtes de requête HTTP de la requête),
url (URL de la ressource HTTP demandée),
file (nom de fichier du fichier concerné par cette requête, après évaluation de toutes les traductions Alias etc.) et
handler (nom du gestionnaire responsable de l’évaluation de cette requête, selon la configuration d’Apache).

Si l’évaluation de ces règles de filtre prouve déjà que le résultat de cette requête ne doit pas être compressé, c’est-à-dire si

au moins une règle exclude est satisfaite ou
aucune des règles include n’est satisfaite ou
si toute autre condition pour effectuer la compression n’est pas satisfaite (par exemple, à ce stade, il peut déjà être vérifié si le client a autorisé le service de données compressées en envoyant l’en-tête HTTP Accept-Encoding: gzip)

alors il n’est pas nécessaire pour mod_gzip de vérifier les règles restantes après la création du contenu de la réponse - donc cela ne se produira pas, car mod_gzip se souvient du résultat de la première phase d’évaluation pour chaque requête et termine immédiatement la seconde phase dans ce cas.

Sinon, dans la seconde phase de son fonctionnement, mod_gzip vérifie les règles de filtre restantes qui ne peuvent être évaluées que sur la base du contenu réel du paquet de réponse généré :

rspheader (contenu des en-têtes de réponse HTTP) ainsi que
mime (type de contenu HTTP du résultat).

De plus, certaines autres conditions sont maintenant testées, telles que la taille du paquet de réponse (directives mod_gzip_minimum_file_size rsp. mod_gzip_maximum_file_size).

Et ce n’est que si tous ces tests ont abouti à un résultat positif que la compression du paquet de réponse sera effectivement effectuée.

La position de mod_gzip dans la séquence de chargement de tous les modules Apache

Pour pouvoir effectuer toutes les tâches décrites ci-dessus, le module mod_gzip doit avoir accès au traitement de la requête HTTP avant chaque autre module Apache dont la sortie est censée être traitée. En raison de l’ordre inversé d’accès au traitement d’une requête pour tous les modules Apache, mod_gzip devrait être chargé en dernier de tous les modules Apache.

Pour l’intégration statique, cet ordre de module est défini par le ‘plan’ du programme httpd lors de la compilation du code source d’Apache. La procédure de compilation du code source fourni par le groupe Apache, activée par le script shell configure, connaît toutes les dépendances entre les modules fournis (et assure un ordre correspondant de ces modules) mais pas les exigences des modules tiers comme mod_gzip qui sont intégrés dans le processus de compilation par le paramètre configure –add-module= fichier. Pour permettre un maximum d’influence à ces modules tiers, ces modules sont chargés en tant que derniers modules sur la pile de modules.

Ainsi, si mod_gzip doit être intégré dans un serveur Apache en tant que seul module tiers, alors configure fait automatiquement ce qu’il faut. Dans le cas de l’utilisation de plus d’un module tiers, l’administrateur est responsable de l’ordre de ces modules (peut-être par l’ordre de ses valeurs –add-module= ? Je n’ai pas encore testé cela).

Compiler mod_gzip en utilisant apxs

La fonction de l’utilitaire de compilation Apache apxs

Si un serveur Apache est exploité pour prendre en charge l’intégration dynamique de modules (c’est-à-dire utilise le module mod_so), alors un programme utilitaire nommé apxs sera généré dans le répertoire bin d’Apache lors de l’installation d’Apache.

Ce programme permet à son utilisateur de compiler le code source d’un module Apache (en utilisant un compilateur C) et de créer un fichier objet partagé correspondant sans nécessiter que le code source complet des serveurs Apache soit disponible : apxs connaît toutes les interfaces de programme Apache requises et fournit au compilateur C les informations nécessaires.

Création d’un objet partagé pour mod_gzip en utilisant make

Pour éviter à l’utilisateur de découvrir comment exactement mod_gzip doit être compilé et installé complètement lors de l’utilisation de apxs, un fichier nommé Makefile est fourni dans l’archive du code source.

L’utilisation de ce Makefile réduit la procédure d’installation aux étapes suivantes :

Extraire les fichiers de l’archive de code source mod_gzip téléchargée dans un répertoire (nouveau, temporaire) de votre choix et changer votre position de répertoire actuel en celui-ci.
Trouver le nom de chemin du programme apxs de votre installation Apache.
Effectuer la compilation en exécutant la commande make APXS=*votre_nom_de_chemin_apxs* Cela créera le fichier objet partagé mod_gzip.so dans le répertoire actuel.
(Cette étape de la séquence d’exploitation peut être omise car elle sera alors couverte par l’étape suivante.)
Effectuer l’installation en exécutant la commande make install APXS=*votre_nom_de_chemin_apxs* Cela copiera non seulement le fichier objet partagé dans le répertoire correspondant de l’installation d’Apache mais étendra automatiquement le fichier de configuration d’Apache httpd.conf par les directives requises LoadModule et AddModule également … si vous n’aimez pas que des programmes étrangers réécrivent vos précieux fichiers de configuration, vous pourriez préférer effectuer cette étape finale manuellement, ou au moins faire une sauvegarde de votre configuration Apache d’abord.

En plus de ces étapes nécessaires, le Makefile prend en charge les commandes suivantes (qui pourraient plutôt intéresser les développeurs) :

make clean supprime tous les fichiers de module objet créés des fichiers source de mod_gzip du répertoire actuel (c’est-à-dire tous les fichiers avec le motif de nom *.o).
make clean supplémentaire supprime également le fichier objet partagé créé mod_gzip.so.

Emplacement original de ce document :

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

mod_gzip - servir du contenu compressé par le serveur web Apache - Page 5