Serveur Apache HTTP Version 2.4
Serveur Apache HTTP Version 2.4
| Description: | Chargement de modules ou de code ex�cutable au cours du d�marrage ou du red�marrage du serveur |
|---|---|
| Statut: | Extension |
| Identificateur�de�Module: | so_module |
| Fichier�Source: | mod_so.c |
| Compatibilit�: | Sous Windows, c'est un module de base (toujours inclus) |
Sur les syst�mes d'exploitation s�lectionn�s, ce module peut �tre utilis� pour charger des modules dans le serveur HTTP Apache en cours d'ex�cution gr�ce au m�canisme des Dynamic Shared Object ou Objets Partag�s Dynamiquement (DSO), et �vite ainsi de devoir effectuer une recompilation.
Sous Unix, le code charg� provient en g�n�ral de fichiers objet
partag�s poss�dant en g�n�ral l'extension .so, alors
que sous Windows, l'extension peut �tre soit .so, soit
.dll.
En g�n�ral, les modules compil�s pour une version majeure du serveur HTTP Apache ne fonctionneront pas avec une autre (par exemple de 1.3 � 2.0 ou 2.0 � 2.2). D'une version majeure � l'autre, il y a souvent des modifications d'API qui n�cessitent des modifications du module pour qu'il puisse fonctionner avec la nouvelle version.
Sous Windows, o� les modules chargeables poss�dent en g�n�ral
l'extension de nom de fichier .dll, les modules Apache
httpd se nomment mod_nom-module.so, tout comme sur les
autres plates-formes. Vous trouverez cependant encore des modules
tiers, comme PHP par exemple, qui continuent d'utiliser la
convention de nommage avec extension .dll.
Bien que mod_so puisse encore charger des modules
poss�dant un nom du style ApacheModuleFoo.dll,
il est pr�f�rable d'utiliser la
nouvelle convention de nommage ; si vous modifiez votre module
chargeable pour la version 2.0, veuillez aussi modifier son nom pour
respecter cette nouvelle convention.
Les API des modules Apache httpd sous Unix et Windows sont identiques. Alors que certains modules s'appuient sur certains aspects de l'architecture Unix non pr�sents dans Windows, et ne fonctionneront donc pas sur cette derni�re plate-forme, de nombreux modules fonctionnent sous Windows avec peu ou pas de modification par rapport � leur version Unix.
Lorsqu'un module fonctionne, il peut �tre ajout� au serveur de
deux mani�res. Sous Unix, il peut �tre compil� dans le serveur.
Comme Apache httpd pour Windows ne dispose pas du programme
Configure propre � Apache httpd pour Unix, le fichier source
du module doit �tre ajout� au fichier projet Apache de base, et ses
symboles ajout�s au fichier os\win32\modules.c.
La seconde m�thode consiste � compiler le module en tant que DLL,
� savoir une biblioth�que partag�e qui pourra �tre charg�e dans le
serveur en cours d'ex�cution via la directive
LoadModule
Pour cr�er un module DLL, il est n�cessaire d'apporter une l�g�re
modification � son fichier source : l'enregistrement du module doit
�tre export� depuis la DLL (qui sera elle-m�me cr��e plus tard ;
voir plus loin). Pour ce faire, ajoutez la macro
AP_MODULE_DECLARE_DATA (d�finie dans les fichiers
d'en-t�tes d'Apache httpd) � la d�finition de l'enregistrement de votre
module. Par exemple, si votre module est d�clar� comme suit :
module foo_module;
Remplacez cette ligne par :
module AP_MODULE_DECLARE_DATA foo_module;
Notez que cette macro ne sera prise en compte que sous Windows,
si bien que le module poura �tre utilis� sans changement sous Unix,
si besoin est. Alternativement, si vous �tes familier avec les
fichiers .DEF, vous pouvez les utiliser pour exporter
l'enregistrement du module.
Maintenant, nous sommes pr�ts � cr�er une DLL contenant notre module. Il va falloir pour cela la lier avec la biblioth�que d'export libhttpd.lib qui a �t� cr��e au cours de la compilation de la biblioth�que partag�e libhttpd.dll. Il sera peut-�tre aussi n�cessaire de modifier la configuration du compilateur pour s'assurer que les fichiers d'en-t�tes d'Apache httpd seront correctement localis�s. Vous trouverez cette biblioth�que � la racine du r�pertoire des modules de votre serveur. Il est souhaitable d'utiliser un fichier de module .dsp existant dans l'arborescence afin de s'assurer que l'environnement de compilation est correctement configur�, mais vous pouvez aussi comparer les options de compilation et d'�dition de liens � votre fichier .dsp.
Ceci devrait cr�er une version DLL de votre module. Il vous
suffit maintenant de l'enregistrer dans le r�pertoire
modules � la racine de votre serveur, et d'utiliser la
directive LoadModule pour la charger.
| Description: | Liaison du fichier objet ou de la biblioth�que sp�cifi� |
|---|---|
| Syntaxe: | LoadFile nom-fichier [nom-fichier] ... |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_so |
La directive LoadFile permet de lier le fichier objet ou la biblioth�que sp�cifi� au serveur lors du d�marrage ou du red�marrage de ce dernier ; ceci permet d'ajouter tout code additionnel n�cessaire au fonctionnement d'un module. nom-fichier est soit un chemin absolu, soit un chemin relatif au r�pertoire d�fini par la directive ServerRoot.
Par exemple:
LoadFile libexec/libxmlparse.so
| Description: | Liaison avec le serveur du fichier objet ou de la biblioth�que sp�cifi�, et ajout de ce dernier � la liste des modules actifs |
|---|---|
| Syntaxe: | LoadModule module nom-fichier |
| Contexte: | configuration du serveur, serveur virtuel |
| Statut: | Extension |
| Module: | mod_so |
La directive LoadModule permet de lier le fichier objet ou la
biblioth�que nom-fichier avec le serveur, et d'ajouter la
structure de module nomm�e module � la liste des modules
actifs. module est le nom de la variable externe de type
module dans le fichier, et est r�f�renc� comme Identificateur de
module dans la documentation des modules. Exemple :
LoadModule status_module modules/mod_status.so
charge le module sp�cifi� depuis le sous-r�pertoire des modules situ� � la racine du serveur.
