Serveur HTTP Apache Version 2.4
+
Serveur HTTP Apache Version 2.4
+
Configuration du serveur HTTP Apache pour l'écoute + sur un port et une adresse IP spécifiques.
+
Vue d'ensemble Changer la configuration de l'écoute au redémarrage Remarques spécifiques à IPv6 Spécification du protocole avec Listen Comment tout ceci fonctionne-t-il avec les hôtes virtuels
| Modules Apparentés | Directives Apparentées |
|---|---|
Au démarrage de httpd, un port et une adresse lui sont associés sur
+ l'hôte local et le serveur se met en attente de l'arrivée d'une requête.
+ Par défaut, le serveur écoute toutes les adresses de l'hôte local.
+ Cependant, on peut lui préciser des ports et des adresses spécifiques à écouter,
+ ou une combinaison des deux.
+ Tout ceci est souvent associé avec la fonctionnalité
+ des hôtes virtuels
+ qui détermine la manière dont httpd répond aux différents ports,
+ noms d'hôtes et adresses IP.
La directive Listen
+ enjoint le serveur de n'accepter des requêtes que sur le(s)
+ port(s) spécifiés ou
+ une combinaison adresse/port. Si seul un numéro de port est spécifié
+ dans la directive Listen,
+ le serveur se met à l'écoute sur ce port, sur toutes les interfaces réseau.
+ Si une adresse IP est spécifiée en plus du port, le serveur va écouter
+ sur ce port, uniquement sur l'interface réseau correspondante. On peut utiliser
+ de multiples directives
+ Listen pour
+ spécifier plusieurs adresses et ports à écouter. Le serveur répondra alors
+ aux requêtes sur ces ports et adresses spécifiés.
Par exemple, pour faire en sorte que le serveur accepte des connexions + sur les ports 80 et 8000, sur toutes les interfaces, utilisez :
+ +Listen 80 +Listen 8000+
Pour faire en sorte que le serveur accepte des connexions sur le port 80 + pour une interface, et sur le port 8000 pour une + autre interface, utilisez :
+ +Listen 192.0.2.1:80 +Listen 192.0.2.5:8000+
Les adresses IPv6 doivent être mises entre crochets, comme dans + l'exemple suivant :
+ +Listen [2001:db8::a00:20ff:fea7:ccea]:80+
Des directives Listen
+ imbriquées provoqueront une erreur fatale qui
+ empêchera le serveur de démarrer.
+ (48)Address already in use: make_sock: could not bind to address [::]:80
+
Voir cette + discussion dans le wiki pour plus de conseils pour résoudre ce + problème.
+ +Lorsque httpd est redémarré, certaines remarques sont à prendre en compte
+ quant aux modifications apportées aux directives Listen. Au cours du redémarrage, httpd
+ conserve la liaison avec les ports de la configuration précédente afin
+ d'éviter l'obtention d'un message d'erreur "Connection refused" lors d'une
+ tentative ultérieure de connexion au serveur. Si les modifications apportées au jeu de
+ directives Listen utilisé entrent
+ en conflit avec ce dernier, le serveur refusera de redémarrer.
Par exemple, modifier la configuration suivante :
+ +Listen 127.0.0.1:80+
pour utiliser la suivante pourra échouer car écouter le port 80 sur + toutes les adresses IP entre en conflit avec une écoute sélective du port 80 + sur la seule adresse IP 127.0.0.1.
+ +Listen 80+
Pour qu'une telle modification de configuration soit prise en compte avec + succès, il est nécessaire d'arrêter, puis de démarrer le serveur.
+ +Un nombre croissant de plateformes implémentent IPv6, et + APR supporte IPv6 sur la plupart d'entre elles, + ce qui permet à httpd d'allouer des points de connexion (sockets) IPv6 + et de traiter des requêtes envoyées sur IPv6.
+ +Les administrateurs de httpd doivent se préoccuper de la possibilité
+ pour un point de connexion IPv6 de traiter à la fois des connexions IPv4
+ et des connexions IPv6.
+ Le traitement de connexions IPv4 avec un point de connexion IPv6 utilise
+ des adresses IPv6 traduites en IPv4, qui sont autorisées par défaut sur la
+ plupart des plateformes, mais sont interdites par défaut sous FreeBSD, NetBSD,
+ et OpenBSD, afin de respecter la politique de sécurité du système sur ces plateformes.
+ Sur les systèmes où ces adresses sont interdites par défaut, un
+ paramètre spécial du script configure permet de modifier
+ ce comportement pour httpd.
En revanche, sur certaines plateformes comme Linux et Tru64, la
+ seule manière de gérer à la fois IPv6 et IPv4 passe
+ par l'utilisation d'adresses traduites. Si vous voulez que httpd gère
+ des connexions IPv4 et IPv6 avec un minimum de points de connexion,
+ ce qui nécessite l'utilisation d'adresses IPv6 traduites en IPv4,
+ utilisez l'option --enable-v4-mapped du script configure.
L'option --enable-v4-mapped est utilisée par défaut sur
+ toutes les plateformes sauf FreeBSD, NetBSD, et OpenBSD;
+ votre httpd a donc probablement été construit avec cette option.
Si vous souhaitez que httpd ne gère que des connexions IPv4, sans se
+ soucier de ce que vos plateforme et APR supportent, spécifiez une adresse
+ IPv4 dans toutes les directives
+ Listen, comme dans l'exemple
+ suivant :
Listen 0.0.0.0:80 +Listen 192.0.2.1:80+
Si votre plateforme le supporte et si vous souhaitez que httpd gère
+ des connexions IPv4 et IPv6 sur des points de connexion séparés
+ (c'est à dire désactiver la traduction des adresses IPv6 au format IPv4),
+ utilisez l'option --disable-v4-mapped du script
+ configure. --disable-v4-mapped est
+ utilisé par défaut sur FreeBSD, NetBSD, et OpenBSD.
Dans la plupart des configurations, le second paramètre optionnel
+ protocol de la directive Listen n'est pas obligatoire. S'il
+ n'est pas spécifié, les protocoles par défaut
+ sont https pour le port 443, et http pour
+ tous les autres ports. Le protocole sert à déterminer quel module
+ doit traiter une requête, et à appliquer les optimisations
+ spécifiques au protocole via la directive AcceptFilter.
Vous ne devez définir le protocole que si vous travaillez avec
+ des ports non standards. Par exemple, pour travailler en
+ https sur le port 8443 :
Listen 192.170.2.1:8443 https+
La directive Listen n'implémente pas les hôtes virtuels.
+ Elle indique simplement au serveur principal sur quels adresses et ports
+ il doit écouter. Si aucune directive
+ <VirtualHost>
+ n'est présente, le serveur se comportera de la même façon pour toutes
+ les requêtes acceptées. En revanche, la directive
+ <VirtualHost>
+ peut être utilisée pour provoquer une réaction différente du serveur
+ pour un ou plusieurs adresses ou ports. Pour implémenter un hôte virtuel,
+ on doit d'abord indiquer au serveur sur quels adresses et ports il doit écouter.
+ Ensuite, une section
+ <VirtualHost>
+ doit être créée pour le couple adresse+port spécifié afin de définir le
+ comportement de cet hôte virtuel. Notez que si la directive
+ <VirtualHost>
+ est définie pour une adresse et un port sur lesquels le serveur n'est pas censé
+ écouter, cet hôte virtuel ne sera pas accessible.
Serveur HTTP Apache Version 2.4
+Ce document complète la documentation de référence des modules
+ mod_cache, mod_cache_disk,
+ mod_file_cache et du programme htcacheclean.
+ Il décrit l'utilisation des fonctionnalités de mise en
+ cache du serveur HTTP Apache
+ pour accélérer les services web et proxy, tout en évitant les problèmes
+ courants et les erreurs de configuration.
Introduction Mise en cache HTTP à trois états RFC2616 Exemples de configuration du cache Mise en cache générale d'objets partagés à deux états de forme
+ clé/valeur Mise en cache à base de fichiers spécialisés Considérations sur la sécuritéLe serveur HTTP Apache offre tout un ensemble de fonctionnalités + de mise en cache qui ont été conçues pour améliorer les performances + du serveur de différentes manières.
+ +mod_cache et son module de fournisseur
+ mod_cache_disk proposent une mise en cache
+ intelligente de niveau HTTP. Le contenu proprement dit est
+ stocké dans le cache, et mod_cache vise à respecter tous les
+ en-têtes HTTP, ainsi que les options qui contrôlent la mise en
+ cache du contenu comme décrit dans la Section
+ 13 de la RFC2616. mod_cache peut gérer des
+ configurations de mise en cache simples, mais aussi complexes
+ comme dans les cas où vous avez à faire à des contenus mandatés,
+ à des contenus locaux dynamiques, ou lorsque vous avez besoin
+ d'accélérer l'accès aux fichiers locaux situés sur disque
+ supposé lent.
+ mod_file_cache offre la possibilité de
+ précharger des fichiers en mémoire au démarrage du serveur,
+ et peut améliorer les temps d'accès et sauvegarder les
+ gestionnaires de fichiers pour les fichiers qui font l'objet
+ d'accès fréquents, évitant ainsi d'avoir à accéder au disque
+ à chaque requête.
+ Pour tirer parti efficacement de ce document, les bases de HTTP doivent + vous être familières, et vous devez avoir lu les sections + Mise en correspondance des + URLs avec le système de fichiers et + Négociation sur le contenu + du guide de l'utilisateur.
+ +| Modules Apparentés | Directives Apparentées |
|---|---|
Le module mod_cache permet de tirer avantage du
+ mécanisme de mise en cache en ligne faisant partie
+ intégrante du protocole HTTP, et décrit dans la section
+ 13 de la RFC2616.
A la différence d'un cache simple clé/valeur à deux états où le + contenu est supprimé lorsqu'il est périmé, un cache HTTP comporte un + mécanisme permettant de conserver temporairement un contenu périmé, + de demander au serveur original si ce contenu périmé a été modifié, + et dans le cas contraire de le rendre à nouveau valide.
+ +Une entrée d'un cache HTTP peut se présenter sous un de ces trois + états :
+ +Si le contenu est trop ancien (plus vieux que sa + durée de fraîcheur), il est considéré comme + périmé. Un cache HTTP doit contacter le serveur + original pour vérifier si le contenu, même s'il est périmé, est + encore à jour avant de le servir au client. Soit le serveur + original va répondre en envoyant un contenu de remplacement si + le contenu périmé n'est plus à jour, soit dans le cas idéal il + renverra un code pour signaler au cache que le contenu est + encore à jour, et qu'il est inutile de le générer ou de + l'envoyer à nouveau. Le contenu repasse à l'état "frais" et le + cycle continue.
+ +Le protocole HTTP permet au cache de servir des données
+ périmées dans certaines circonstances, comme lorsqu'une
+ tentative de rafraîchir une entrée depuis un serveur original
+ se solde par un échec avec un code d'erreur 5xx, ou lorsqu'une
+ autre requête est déjà en train d'essayer de rafraîchir la même
+ entrée. Dans ces cas, un en-tête Warning est ajouté
+ à la réponse.
Le fonctionnement détaillé d'un cache HTTP est décrit dans la Section + 13 de la RFC2616.
+ +Le module mod_cache interagit avec le serveur
+ à deux niveaux possibles en fonction de la directive CacheQuickHandler :
+
Cette phase se déroule très tôt au cours du traitement de + la requête, juste après l'interprétation de cette dernière. Si + le contenu se trouve dans le cache, il est servi immédiatement + et pratiquement tout le reste du traitement de la requête est + court-circuité.
+ +Dans ce scénario, le cache se comporte comme s'il avait + été "boulonné" à l'entrée du serveur.
+ +Ce mode possède les meilleures performances car la + majorité des traitements au niveau du serveur sont + court-circuités. Cependant, il court-circuite aussi les + phases d'authentification et d'autorisation du traitement + au niveau du serveur, et il doit donc être utilisé avec + prudence lorsque que ces phases sont importantes.
+ +Les requêtes comportant un en-tête "Authorization"
+ (comme par exemple l'authentification HTTP basique) ne
+ peuvent être ni mises en cache, ni servies depuis ce
+ dernier lorsque mod_cache s'exécute dans
+ cette phase.
Cette phase se déroule très tard au cours du traitement + de la requête, en fait après toutes les phases de ce + traitement.
+ +Dans ce scénario, le cache se comporte comme s'il avait + été "boulonné" à la sortie du serveur.
+ +Ce mode offre la plus grande souplesse, car il permet + de faire intervenir la mise en cache en un point + précisément spécifié de la chaîne de filtrage, et le + contenu issu du cache peut être filtré ou personnalisé + avant d'être servi au client.
+Si l'URL ne se trouve pas dans le cache,
+ mod_cache ajoutera un filtre à la chaîne de filtrage afin
+ d'enregistrer la réponse dans le cache, puis passera la main
+ pour permettre le déroulement normal de la suite du traitement
+ de la requête. Si la mise en cache du contenu est autorisée, il
+ sera enregistré dans le cache pour pouvoir être servi à nouveau
+ ; dans le cas contraire, le contenu sera ignoré.
Si le contenu trouvé dans le cache est périmé, le module
+ mod_cache convertit la requête en
+ requête conditionnelle. Si le serveur original
+ renvoie une réponse normale, elle est enregistrée dans le cache
+ en lieu et place du contenu périmé. Si le serveur original
+ renvoie une réponse "304 Not Modified", le contenu repasse à
+ l'état "frais" et est servi par le filtre au lieu d'être
+ sauvegardé.
Lorsqu'un serveur virtuel est connu sous la forme d'un des
+ nombreux alias du serveur, la définition de la directive
+ UseCanonicalName à
+ On peut augmenter de manière significative le nombre
+ de correspondances positives dans le cache. Ceci est du au fait
+ que la clé du cache contient le nom d'hôte du serveur virtuel.
+ Avec UseCanonicalName positionnée
+ à On,
+ les hôtes virtuels possédant plusieurs noms de serveur ou alias ne
+ généreront pas d'entités de cache différentes, et le contenu sera mis en
+ cache en faisant référence au nom d'hôte canonique.
Un contenu bien formé destiné à être mis en cache doit déclarer
+ explicitement une durée de fraîcheur via les champs
+ max-age ou s-maxage de l'en-tête
+ Cache-Control, ou en incluant un en-tête
+ Expires.
De plus, un client peut passer outre la durée de fraîcheur
+ définie pour le serveur original en ajoutant son propre en-tête
+ Cache-Control à la requête. Dans ce cas, c'est la
+ durée de fraîcheur la plus basse entre la requête et la réponse
+ qui l'emporte.
Lorsque cette durée de fraîcheur est absente de la requête ou
+ de la réponse, une durée de fraîcheur par défaut s'applique. La
+ durée de fraîcheur par défaut des entrées du cache est d'une heure
+ ; elle peut cependant être facilement modifiée à l'aide de
+ la directive CacheDefaultExpire.
Si une réponse ne contient pas d'en-tête Expires mais
+ inclut un en-tête Last-Modified, mod_cache
+ peut déduire une durée de fraîcheur en se basant sur une
+ heuristique, qui peut être contrôlée via la directive CacheLastModifiedFactor.
Pour les contenus locaux, ou les contenus distants qui ne
+ spécifient pas leur propre en-tête Expires,
+ mod_expires permet de régler finement la durée de
+ fraîcheur via les paramètres max-age et
+ Expires.
On peut aussi contrôler la durée de fraîcheur maximale en utilisant
+ la directive CacheMaxExpire.
Lorsqu'un contenu du cache est périmé, httpd modifie la requête + pour en faire une requête conditionnelle
+ +Lorsque la réponse originale du cache contient un en-tête
+ ETag, mod_cache ajoute un en-tête
+ If-None-Match à la requête envoyée au serveur
+ d'origine. Lorsque la réponse originale du cache contient un en-tête
+ Last-Modified, mod_cache ajoute un en-tête
+ If-Modified-Since à la requête envoyée au serveur
+ d'origine. Dans ces deux cas, la requête devient une requête
+ conditionnelle.
Lorsqu'un serveur d'origine reçoit une requête conditionnelle, + il vérifie si le paramètre Etag ou Last-Modified a été modifié en + fonction des paramètres de la requête. Si ce n'est pas le cas, il + répondra avec le message lapidaire "304 Not Modified". Ceci + informe le cache que le contenu est périmé mais encore à jour, et + peut être utilisé tel quel pour les prochaines requêtes jusqu'à ce + qu'il atteigne à nouveau sa date de péremption.
+ +Si le contenu a été modifié, il est servi comme s'il s'agissait + d'une requête normale et non conditionnelle.
+ +Les requêtes conditionnelles offrent deux avantages. D'une + part, il est facile de déterminer si le contenu du serveur + d'origine correspond à celui situé + dans le cache, et ainsi d'économiser la consommation de ressources + nécessaire au transfert du contenu dans son ensemble.
+ +D'autre part, un serveur d'origine bien conçu sera configuré de
+ telle manière que les requêtes conditionnelles nécessitent pour
+ leur production bien moins de ressources qu'une réponse complète.
+ Dans le cas des fichiers statiques, il suffit en général d'un
+ appel système de type stat() ou similaire pour
+ déterminer si la taille ou la date de modification du fichier a
+ été modifiée. Ainsi, même un contenu local pourra être servi plus
+ rapidement depuis le cache s'il n'a pas été modifié.
Il serait souhaitable que tous les serveurs d'origine + supportent les requêtes conditionnelles, car dans le cas + contraire, ils répondent comme s'il s'agissait d'une requête + normale, et le cache répond comme si le contenu avait été + modifié et enregistre ce dernier. Le cache se comporte alors + comme un simple cache à deux état, où le contenu est servi s'il + est à jour, ou supprimé dans le cas contraire.
+ + +La liste complète des conditions nécessaires pour qu'une + réponse puisse être enregistrée dans un cache HTTP est fournie + dans la section + 13.4 Response Cacheability de la RFC2616, et peut se résumer + ainsi :
+ +CacheEnable et CacheDisable.CacheIgnoreNoLastMod
+ ne précise d'autres contraintes.CacheStorePrivate
+ ne précise d'autres contraintes.CacheStoreNoStore
+ n'ait été utilisée.Le client qui crée la requête ou le serveur d'origine qui
+ génère la réponse doit être à même de déterminer si le contenu
+ doit pouvoir être mis en cache ou non en définissant correctement
+ l'en-tête Cache-Control, et
+ mod_cache sera alors en mesure de satisfaire les
+ souhaits du client ou du serveur de manière appropriée.
+
Les contenus qui varient au cours du temps, ou en fonction de
+ particularités de la requête non prises en compte par la
+ négociation HTTP ne doivent pas être mis en cache. Ce type de
+ contenu doit se déclarer lui-même "à ne pas mettre en cache" via
+ l'en-tête Cache-Control.
Si le contenu change souvent, suite par exemple à une durée de + fraîcheur de l'ordre de la minute ou de la seconde, il peut tout + de même être mis en cache, mais il est alors fortement souhaitable + que le serveur d'origine supporte correctement les + requêtes conditionnelles afin que des réponses + complètes ne soient pas systématiquement générées.
+ +Un contenu qui varie en fonction d'en-têtes de requête fournis
+ par le client peut être mis en cache, sous réserve d'une
+ utilisation appropriée de l'en-tête de réponse Vary.
Lorsque le serveur d'origine est configuré pour servir des + contenus différents en fonction de la valeur de certains en-têtes + de la requête, par exemple pour servir une ressource en plusieurs + langages à partir d'une seule URL, le mécanisme de mise en cache + d'HTTP permet de mettre en cache plusieurs variantes de la même + page à partir d'une seule URL.
+ +Pour y parvenir, le serveur d'origine ajoute un en-tête
+ Vary pour indiquer quels en-têtes doivent être pris
+ en compte par un cache pour déterminer si deux variantes sont
+ différentes l'une de l'autre.
Si par exemple, une réponse est reçue avec l'en-tête Vary suivant,
+ +
+Vary: negotiate,accept-language,accept-charset
+
mod_cache ne servira aux demandeurs que le contenu
+ mis en cache qui correspond au contenu des en-têtes accept-language et
+ accept-charset de la requête originale.
Plusieurs variantes d'un contenu peuvent être mises en cache
+ simultanément ; mod_cache utilise l'en-tête
+ Vary et les valeurs correspondantes des en-têtes de
+ la requête spécifiés dans ce dernier pour
+ déterminer quelle variante doit être servie au client.
| Modules Apparentés | Directives Apparentées |
|---|---|
Le module mod_cache s'appuie sur des
+ implémentations de stockage sous-jacentes spécifiques pour gérer
+ le cache ; à ce titre, mod_cache_disk fournit le
+ support de la mise en cache sur disque.
En général, le module se configure comme suit :
+ +CacheRoot "/var/cache/apache/" +CacheEnable disk / +CacheDirLevels 2 +CacheDirLength 1+ + +
Il est important de savoir que, les fichiers mis en cache étant stockés + localement, la mise en cache par l'intermédiaire du système d'exploitation + sera en général aussi appliquée à leurs accès. Si bien que même si les + fichiers sont stockés sur disque, s'il font l'objet d'accès fréquents, + il est probable que le système d'exploitation s'appliquera à ce qu'ils + soient servis à partir de la mémoire.
+ + + +Pour stocker des entités dans le cache,
+ le module mod_cache_disk crée une empreinte (hash) de 22
+ caractères de l'URL qui a fait l'objet d'une requête. Cette empreinte
+ comprend le nom d'hôte, le protocole, le port, le chemin et tout argument
+ de type CGI associé à l'URL, ainsi que les éléments
+ spécifiés dans l'en-tête Vary afin d'être sur que plusieurs URLs
+ n'interfèrent pas entre elles.
Chaque position de l'empreinte peut contenir un caractère
+ choisi parmi 64 caractères différents, il y a donc
+ 64^22 possibilités pour une empreinte. Par exemple, une URL peut posséder
+ l'empreinte xyTGxSMO2b68mBCykqkp1w. Cette empreinte est
+ utilisée pour préfixer les noms de fichiers spécifiques à cette URL à
+ l'intérieur du cache; cependant, elle est tout d'abord placée dans les
+ répertoires du cache selon les directives
+ CacheDirLevels et
+ CacheDirLength.
La directive
+ CacheDirLevels
+ définit le nombre de niveaux de sous-répertoires, et
+ CacheDirLength
+ le nombre de caractères composant le nom des sous-répertoires. Dans
+ l'exemple donné plus haut, l'empreinte se trouvera à :
+ /var/cache/apache/x/y/TGxSMO2b68mBCykqkp1w.
Cette technique a pour but principal de réduire le nombre de
+ sous-répertoires ou de fichiers contenus dans un répertoire particulier,
+ car le fonctionnement de la plupart des systèmes de fichiers est ralenti
+ quand ce nombre augmente. Avec la valeur "1" pour la directive
+ CacheDirLength,
+ il peut y avoir au plus 64 sous-répertoires à un niveau quelconque.
+ Avec la valeur "2", il peut y en avoir 64 * 64, etc...
+ A moins d'avoir une bonne raison pour ne pas le faire, l'utilisation de
+ la valeur "1" pour la directive
+ CacheDirLength
+ est recommandée.
Le paramétrage de la directive
+ CacheDirLevels
+ dépend du nombre de fichiers que vous pensez stocker dans le cache.
+ Avec une valeur de "2" comme dans l'exemple donné plus haut,
+ 4096 sous-répertoires peuvent être créés au total. Avec 1 million de
+ fichiers dans le cache, cela équivaut à environ 245 URLs mises en cache
+ dans chaque répertoire.
Chaque URL nécessite au moins deux fichiers dans le cache. Ce sont en + général un fichier ".header", qui contient des meta-informations à propos + de l'URL, comme la date de son arrivée à expiration, + et un fichier ".data" qui est la copie exacte du contenu à servir.
+ +Dans le cas d'un contenu négocié via l'en-tête "Vary", un répertoire + ".vary" sera créé pour l'URL en question. Ce répertoire contiendra de + multiples fichiers ".data" correspondant aux différents contenus + négociés.
+ + +Le module mod_cache_disk n'effectue aucune
+ régulation de l'espace disque utilisé par le cache, mais s'il
+ s'arrête en douceur en cas d'erreur disque et se comporte alors
+ comme si le cache n'avait jamais existé.
Par contre l'utilitaire + htcacheclean fourni avec + httpd + vous permet de nettoyer le cache périodiquement. + Déterminer la fréquence à laquelle lancer htcacheclean et la taille souhaitée + pour le cache est une tâche relativement complexe et il vous faudra de + nombreux essais et erreurs pour arriver à sélectionner des valeurs + optimales.
+ +htcacheclean opère selon deux + modes. Il peut s'exécuter comme démon résident, ou être lancé + périodiquement par cron. htcacheclean peut mettre une heure + ou plus pour traiter de très grands caches (plusieurs dizaines de + Gigaoctets) et si vous l'exécutez à partir de cron, il vous est + conseillé de déterminer la durée typique d'un traitement, afin d'éviter + d'exécuter plusieurs instances à la fois.
+ +Il est aussi conseillé d'attribuer un niveau de priorité "nice" + approprié à htcacheclean de façon à ce qu'il n'effectue pas trop + d'accès disque pendant le fonctionnement du serveur.
+ +
+ 
+ Figure 1: Croissance
+ typique du cache / séquence de nettoyage.
Comme mod_cache_disk ne tient pas compte de l'espace
+ utilisé dans le cache, vous devez vous assurer que
+ htcacheclean est configuré de
+ façon à laisser suffisamment d'"espace de croissance"
+ à la suite d'un nettoyage.
En utilisant le module mod_cache_socache,
+ mod_cache peut mettre en cache des données à partir de
+ diverses implémentations aussi nommées "fournisseurs". Par exemple, en
+ utilisant le module mod_socache_memcache, on peut
+ spécifier que c'est memcached qui doit
+ être utilisé comme mécanisme de stockage sous-jacent.
Typiquement, le module sera configuré comme suit :
+ +CacheEnable socache / +CacheSocache memcache:memcd.example.com:11211+ + +
En outre, il est possible de spécifier plusieurs serveurs
+ memcached en les ajoutant à la fin de la ligne
+ CacheSocache memcache: et en les séparant par des virgules :
CacheEnable socache / +CacheSocache memcache:mem1.example.com:11211,mem2.example.com:11212+ + +
Divers autres fournisseurs mod_cache_socache utilisent
+ aussi ce format. Par exemple :
CacheEnable socache / +CacheSocache shmcb:/path/to/datafile(512000)+ + +
CacheEnable socache / +CacheSocache dbm:/path/to/datafile+ + + + +
| Modules Apparentés | Directives Apparentées |
|---|---|
Le serveur HTTP Apache fournit un cache d'objets partagés de bas + niveau pour la mise en cache d'informations comme les sessions SSL + ou les données d'authentification dans l'interface socache.
+ +Pour chaque implémentation un module supplémentaire est fourni + qui offre les services d'arrière-plan suivants :
+ +mod_socache_dbmmod_socache_dcmod_socache_memcachemod_socache_shmcb| Modules Apparentés | Directives Apparentées |
|---|---|
Le module mod_authn_socache permet la mise en
+ cache des données issues d'une authentification, diminuant ainsi
+ la charge des serveurs d'authentification d'arrière-plan.
| Modules Apparentés | Directives Apparentées |
|---|---|
Le module mod_ssl utilise l'interface
+ socache pour fournir un cache de session et un cache
+ de base.
| Modules Apparentés | Directives Apparentées |
|---|---|
Sur les plateformes où le système de fichiers peut être lent, ou + lorsque les descripteurs de fichiers sont gourmands en ressources, + il est possible de précharger des fichiers en mémoire au démarrage + du serveur.
+ +Sur les systèmes où l'ouverture des fichiers est lente, il est + possible d'ouvrir le fichier au démarrage du serveur et de mettre en + cache le descripteur de fichier. Ces options peuvent vous aider sur + les systèmes où l'accès aux fichiers statiques est lent.
+ +Le processus d'ouverture d'un fichier peut être en soi une + source de ralentissement, en particulier sur les systèmes de + fichiers sur le réseau. httpd permet d'éviter ce ralentissement en + maintenant un cache des descripteurs de fichiers ouverts pour les + fichiers souvent servis. Actuellement, httpd fournit une seule + implémentation de mise en cache des descripteurs de fichiers.
+ +La forme la plus basique de mise en cache que propose httpd
+ est la mise en cache des descripteurs de fichiers fournie par le
+ module mod_file_cache. Plutôt que de mettre en
+ cache le contenu des fichiers, ce cache maintient une table des
+ descripteurs de fichiers ouverts. Les fichiers devant faire
+ l'objet d'une mise en cache de ce type sont spécifiés dans le
+ fichier de configuration via la directive CacheFile.
La directive CacheFile informe httpd
+ qu'il doit ouvrir le fichier lors de son démarrage et qu'il doit
+ réutiliser le descripteur de fichier mis en cache pour tous les
+ accès futurs à ce fichier.
CacheFile /usr/local/apache2/htdocs/index.html+ + +
Si vous désirez mettre en cache un grand nombre de fichiers + de cette manière, vous devez vous assurer que le nombre maximal + de fichiers ouverts pour votre système d'exploitation est défini + à une valeur suffisante.
+ +Bien que l'utilisation de la directive CacheFile n'entraîne pas de
+ mise en cache du contenu du fichier proprement dit, elle
+ implique que si le fichier est modifié pendant l'exécution du
+ serveur, ces modifications ne seront pas prises en compte. Le
+ fichier sera toujours servi dans l'état où il se trouvait au
+ moment du démarrage du serveur.
Si le fichier est supprimé pendant l'exécution du serveur, ce + dernier conservera le descripteur de fichier ouvert associé et + servira le fichier dans l'état où il se trouvait au + moment du démarrage du serveur. Cela signifie aussi que même si + le fichier a été supprimé, et n'apparaît donc plus dans le + système de fichiers, l'espace disque libéré ne sera disponible + qu'une fois le serveur httpd arrêté et donc le descripteur de + fichier fermé.
+ + + + +Servir un contenu directement depuis la mémoire système est + universellement reconnu comme la méthode la plus rapide. Lire des fichiers + depuis un contrôleur de disque ou pire, depuis un réseau distant est plus + lent de plusieurs ordres de grandeur. Les contrôleurs de disque réalisent + en général des opérations mécaniques, et l'accès au réseau est limité par la + bande passante dont vous disposez. Par contre, les temps d'accès à la + mémoire sont de l'ordre de la nano-seconde.
+ +Cependant la mémoire système n'est pas bon marché; à capacité égale, + c'est de loin le type de stockage le plus coûteux et il est important de + s'assurer qu'elle est utilisée efficacement. Le fait de mettre en cache + des fichiers en mémoire diminue d'autant la quantité de mémoire système + disponible. Comme nous le verrons plus loin, ce n'est pas un problème en + soi dans le cas de la mise en cache par l'intermédiaire du système + d'exploitation, mais si l'on utilise la mise en cache en mémoire propre à + httpd, il faut prendre garde à ne pas allouer trop de mémoire au cache. + Sinon le système sera contraint d'utiliser le swap, ce qui dégradera + sensiblement les performances.
+ +Dans la plupart des systèmes d'exploitation modernes, c'est le noyau + qui gère directement la mise en cache en mémoire des données relatives + aux fichiers. C'est une fonctionnalité puissante, et les systèmes + d'exploitation s'en acquittent fort bien pour la plus grande partie. + Considérons par exemple, dans le cas de Linux, la différence entre le + temps nécessaire à la première lecture d'un fichier et le temps + nécessaire à sa deuxième lecture;
+ +colm@coroebus:~$ time cat testfile > /dev/null +real 0m0.065s +user 0m0.000s +sys 0m0.001s +colm@coroebus:~$ time cat testfile > /dev/null +real 0m0.003s +user 0m0.003s +sys 0m0.000s
Même pour ce petit fichier, il y a une grande différence entre les + temps nécessaires pour lire le fichier. Ceci est du au fait que le + noyau a mis en cache le contenu du fichier en mémoire.
+ +Du fait de toujours pouvoir disposer de mémoire système, vous pouvez + être assuré qu'il y aura de plus en plus de contenus de fichiers stockés + dans ce cache. Ceci peut s'avérer une méthode de mise en cache en mémoire + très efficace, et ne nécessite aucune configuration supplémentaire + de httpd.
+ +De plus, comme le système d'exploitation sait si des fichiers + ont été + supprimés ou modifiés, il peut effacer automatiquement des contenus de + fichiers du cache lorsque cela s'avère nécessaire. Ceci constitue un gros + avantage par rapport à la mise en cache en mémoire + de httpd qui n'a + aucune possibilité de savoir si un fichier a été modifié.
+ + +En dépit des performances et des avantages de la mise en cache + automatique par le système d'exploitation, la mise en cache en mémoire + peut être effectuée plus efficacement par httpd dans certaines + circonstances.
+ +La directive MMapFile
+ fournie par le module mod_file_cache vous permet de
+ demander à httpd de charger un contenu de fichier statique en mémoire
+ lors de son démarrage (à l'aide de l'appel
+ système mmap). httpd
+ utilisera le contenu chargé en mémoire pour satisfaire ultérieurement
+ toutes les demandes d'accès à ce fichier.
MMapFile /usr/local/apache2/htdocs/index.html+ + +
Comme dans le cas de la directive
+ CacheFile, toute
+ modification du fichier ne sera plus prise en compte par httpd une fois
+ ce dernier démarré.
La directive
+ MMapFile ne gardant
+ pas la trace de la quantité de mémoire qu'elle alloue, vous devez prendre
+ garde de ne pas en abuser. Chaque processus enfant de httpd utilisant
+ sa propre réplique de la mémoire allouée, il est donc d'une importance
+ critique de s'assurer que les fichiers chargés ne sont pas d'une taille
+ trop importante afin d'épargner au système l'utilisation du swap.
Utiliser mod_cache revient sensiblement à la même
+ chose qu'avoir un mandataire inverse intégré (reverse-proxy). Les requêtes
+ seront servies par le module de mise en cache sauf si ce dernier
+ détermine qu'un processus d'arrière-plan doit être appelé. La mise en
+ cache de ressources locales modifie considérablement le modèle de
+ sécurité de httpd.
Comme le parcours de la hiérarchie d'un système de fichiers pour
+ examiner le contenu d'éventuels fichiers
+ .htaccess serait une opération très coûteuse en ressources,
+ annulant partiellement de ce fait l'intérêt de la mise en cache
+ (accélérer le traitement des requêtes),
+ mod_cache ne se préoccupe pas de savoir s'il a
+ l'autorisation de servir une entité mise en cache. En d'autres termes,
+ si mod_cache a mis en cache un certain contenu, ce
+ dernier sera servi à partir du cache tant qu'il ne sera pas arrivé à
+ expiration.
Si par exemple, votre configuration autorise l'accès à une ressource
+ en fonction de l'adresse IP, vous devez vous assurer que ce contenu n'est
+ pas mis en cache. Ceci est possible en utilisant la directive
+ CacheDisable, ou le module
+ mod_expires. Livré à lui-même,
+ mod_cache - pratiquement comme un mandataire inverse -
+ mettrait en cache le contenu lors de son service, et le servirait ensuite
+ à tout client, vers n'importe quelle adresse IP.
Lorsque la directive CacheQuickHandler est définie à
+ Off, toutes les phases du traitement de la requête
+ sont exécutées et le modèle de sécurité reste le même.
Etant donné que les requêtes des utilisateurs finaux peuvent être + servies depuis le cache, ce dernier est une cible potentielle pour ceux + qui veulent défigurer un contenu ou interférer avec lui. Il est important + de garder à l'esprit que l'utilisateur sous lequel tourne + httpd doit + toujours avoir l'accès en écriture dans le cache. Ceci est en contraste + total avec la recommandation usuelle d'interdire à l'utilisateur sous + lequel tourne Apache + l'accès en écriture à tout contenu.
+ +Si l'utilisateur sous lequel tourne Apache est compromis,
+ par exemple à cause d'une
+ faille de sécurité dans un processus CGI, il est possible que le cache
+ fasse l'objet d'une attaque. Il est relativement aisé d'insérer ou de
+ modifier une entité dans le cache en utilisant le module
+ mod_cache_disk.
Cela représente un risque relativement élévé par rapport aux autres
+ types d'attaques qu'il est possible de mener sous l'utilisateur apache.
+ Si vous utilisez mod_cache_disk, vous devez garder ceci
+ à l'esprit : effectuez toujours les mises à jour de
+ httpdquand des
+ correctifs de sécurité sont annoncés et exécutez les processus CGI sous
+ un utilisateur autre qu'apache en utilisant
+ suEXEC dans la mesure du possible.
Si vous utilisez httpd comme serveur mandataire avec mise en cache, + vous vous exposez aussi à un éventuel "Empoisonnement du + cache" (Cache poisoning). L'empoisonnement du cache est un terme général + pour désigner les attaques au cours desquelles l'attaquant fait en sorte + que le serveur mandataire renvoie à un contenu incorrect (et souvent + indésirable) suite à en provenance du serveur d'arrière-plan. +
+ +Par exemple, si les serveur DNS qu'utilise votre système où tourne + httpd sont vulnérables à l'empoisonnement du cache des DNS, un attaquant + pourra contrôler vers où httpd se connecte lorsqu'il demande un contenu + depuis le serveur d'origine. + Un autre exemple est constitué par les attaques ainsi nommées + "Dissimulation de requêtes HTTP" (HTTP request-smuggling).
+ +Ce document n'est pas le bon endroit pour une discussion approfondie + à propos de la Dissimulation de requêtes HTTP (utilisez plutôt votre + moteur de recherche favori); il est cependant important de savoir qu'il + est possible d'élaborer une série de requêtes, et d'exploiter une + vulnérabilité d'un serveur web d'origine de telle façon que l'attaquant + puisse contrôler entièrement le contenu renvoyé par le mandataire.
+ + +Le mécanisme utilisé via l'en-tête Vary permet de mettre en
+ cache simultanément plusieurs variantes d'une ressource avec la
+ même URL. Le cache sélectionne la variante correcte à envoyer au
+ client en fonction des valeurs d'en-tête fournies par ce dernier.
+ Ce mécanisme peut devenir un problème lorsqu'on tente d'appliquer
+ le mécanisme des variantes à un en-tête connu pour pouvoir
+ posséder un grand nombre de valeurs
+ possibles en utilisation normal, comme par exemple l'en-tête
+ User-Agent. En fonction de la popularité du site web,
+ des milliers ou même des millions d'entrées de cache dupliquées
+ peuvent être créées pour la même URL, submergeant les autres
+ entrées du cache.
Dans d'autres cas, il peut être nécessaire de modifier l'URL
+ d'une ressource particulière à chaque requête, en général en lui
+ ajoutant une chaîne "cachebuster". Si ce contenu est déclaré comme
+ pouvant être mis en cache par un serveur avec une durée de
+ fraîcheur significative, ces entrées peuvent submerger les entrées
+ légitimes du cache. Alors que mod_cache fournit
+ une directive CacheIgnoreURLSessionIdentifiers,
+ cette dernière doit être utilisée avec prudence pour s'assurer que
+ les caches du navigateur ou du mandataire le plus proche
+ (downstream proxy) ne sont pas victimes du même problème de Déni de
+ service.
Serveur HTTP Apache Version 2.4
+Ce document décrit les fichiers utilisés pour configurer +le Serveur HTTP Apache.
+ Fichiers de configuration principaux Syntaxe des fichiers de configuration Modules Portée des directives Fichiers .htaccess| Modules Apparentés | Directives Apparentées |
|---|---|
La configuration du serveur HTTP Apache est effectuée en plaçant des directives dans des fichiers de
+ configuration au format texte. Le fichier de configuration principal se nomme
+ en général
+ httpd.conf. La localisation de ce fichier est définie
+ à la compilation, mais peut être redéfinie à l'aide de l'option
+ de ligne de commande -f. En outre, d'autres fichiers de
+ configuration peuvent être ajoutés à l'aide de la directive
+ Include, et des caractères de
+ remplacement
+ peuvent être utilisés pour inclure de nombreux fichiers de configuration.
+ Des directives de tous types peuvent être placées dans chacun de ces fichiers
+ de configuration. Les modifications dans les fichiers de configuration
+ principaux ne sont prises en compte par httpd que lorsque le serveur
+ est démarré ou redémarré.
Le serveur lit aussi un fichier contenant les types de document mime;
+ ce fichier est défini par la directive TypesConfig,
+ et se nomme mime.types par défaut.
Les fichiers de configuration de httpd contiennent une directive + par ligne. + On peut utiliser l'anti-slash "\" comme dernier caractère d'une ligne + pour indiquer que la directive continue à la ligne suivante. + Il ne doit y avoir aucun caractère ni espace entre l'anti-slash et + la fin de la ligne.
+ +Les arguments des directives sont séparés les uns des autres par + des espaces. Si un argument contient des espaces, il doit être + entouré de guillemets.
+ +Les directives dans les fichiers de configuration ne sont pas + sensibles à la casse, mais leurs arguments le sont souvent. Les lignes + qui débutent par le caractère "#" sont interprétées comme des + commentaires, et sont ignorées. Les commentaires ne doivent + pas apparaître sur la même ligne qu'une directive + de configuration. Les espaces précédant une directive + sont ignorés; vous pouvez par conséquent indenter les directives + afin d'améliorer la lisibilité. Les lignes vides sont + aussi ignorées.
+ +Les valeurs des variables d'environnement ou des variables
+ définies via la directive Define peuvent être utilisées dans le
+ fichier de configuration en utilisant la syntaxe
+ ${VAR}. Si "VAR" est le nom d'une variable valide, la
+ valeur de la variable est alors substituée à la chaîne
+ ${VAR}, et le processus de lecture du fichier de
+ configuration continue comme si la chaîne correspondant à la valeur
+ de la variable s'y était trouvée littéralement. Les variables définies
+ via la directive Define
+ l'emportent sur les autres variables d'environnement du shell. Si la
+ variable "VAR" n'est pas trouvée, la chaîne ${VAR}
+ n'est pas modifiée, et un avertissement est enregistré dans le
+ journal. Le caractère ":" est interdit dans les noms de variables
+ afin d'éviter tout conflit avec la syntaxe de la directive RewriteMap.
Seules les variables d'environnement du shell définies avant le démarrage
+ du serveur peuvent être utilisées dans les extensions.
+ Les variables d'environnement
+ définies dans le fichier de configuration lui-même, par exemple avec SetEnv, prennent effet trop tard pour
+ pouvoir être utilisées dans les extensions au sein du fichier de
+ configuration.
La longueur maximale d'une ligne dans un fichier de configuration + normal, après substitution des variables et fusion des lignes + interrompues, est approximativement de 16 Mo. Dans les fichiers .htaccess, la longueur + maximale est de 8190 caractères.
+ +Vous pouvez vérifier l'absence d'erreurs de syntaxe dans vos fichiers
+ de configuration sans démarrer le serveur à l'aide de la commande
+ apachectl configtest ou de l'option de ligne de commande
+ -t.
Vous pouvez utiliser la définition -DDUMP_CONFIG de
+ mod_info pour afficher la configuration avec tous
+ les fichiers inclus et les variables d'environnement évaluées, tous
+ les commentaires et les sections <IfDefine> et <IfModule> non actives ayant
+ été supprimés. Cependant, la sortie ne reflète
+ pas les fusions ou écrasements pouvant intervenir en cas de
+ définitions multiples de directives.
| Modules Apparentés | Directives Apparentées |
|---|---|
httpd est un serveur modulaire. Ceci implique que seules les
+ fonctionnalités les plus courantes sont incluses dans le serveur de base.
+ Les fonctionnalités étendues sont fournies à l'aide de modules qui peuvent être chargés dans httpd.
+ Par défaut, un jeu de modules de base est inclus dans le
+ serveur à la compilation. Si le serveur est compilé de façon à utiliser
+ les modules chargés dynamiquement,
+ alors les modules peuvent être compilés séparément et chargés à
+ n'importe quel moment à l'aide de la directive
+ LoadModule.
+ Dans le cas contraire, httpd doit être recompilé pour ajouter ou
+ supprimer des modules.
+ Les directives de configuration peuvent être incluses de manière
+ conditionnelle selon la présence ou l'absence d'un module particulier
+ en les plaçant dans un bloc <IfModule>.
Pour voir quels modules ont été compilés avec le serveur,
+ vous pouvez utiliser l'option de ligne de commande -l.
| Modules Apparentés | Directives Apparentées |
|---|---|
Les directives placées dans les fichiers de configuration principaux
+ s'appliquent au serveur dans son ensemble. Si vous souhaitez modifier la
+ configuration d'une partie du serveur seulement, vous pouvez limiter la
+ portée de vos directives en les plaçant dans une section
+ <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, ou <LocationMatch>.
+ Ces sections limitent le champ d'application des directives qu'elles
+ contiennent à des URls ou des portions du système de fichiers particulières.
+ Elles peuvent aussi être imbriquées, ce qui permet
+ une configuration très fine.
httpd peut servir simultanément de nombreux sites web au travers des
+ Hôtes Virtuels. La portée des directives peut ainsi
+ être limitée en les plaçant dans des sections
+ <VirtualHost>,
+ afin qu'elles ne s'appliquent qu'aux requêtes
+ pour un site web particulier.
Bien que la plupart des directives puissent être placées dans + chacune de ces sections, certaines d'entre elles n'ont aucun sens + dans certains contextes. + Par exemple, les directives qui contrôlent la création des processus + n'ont de sens que dans le contexte du serveur principal. Pour déterminer + quelles directives peuvent être placées dans quelles sections, consultez + le Contexte de la + directive. Pour plus d'informations, nous fournissons des détails dans + Comment fonctionnent les sections Directory, + Location et Files.
+| Modules Apparentés | Directives Apparentées |
|---|---|
httpd permet la gestion décentralisée de la configuration
+ via des fichiers spéciaux placés dans l'arborescence du site web.
+ Ces fichiers spéciaux se nomment en général .htaccess,
+ mais tout autre nom peut être spécifié à l'aide de la directive
+ AccessFileName.
+ Les directives placées dans les fichiers .htaccess
+ s'appliquent au répertoire dans lequel vous avez placé le fichier,
+ ainsi qu'à tous ses sous-répertoires.
+ La syntaxe des fichiers .htaccess est la même que celle
+ des fichiers de configuration principaux. Comme les fichiers
+ .htaccess sont lus à chaque requête, les modifications de
+ ces fichiers prennent effet immédiatement.
Pour déterminer quelles directives peuvent être placées
+ dans les fichiers .htaccess, consultez le
+ Contexte de la
+ directive. L'administrateur du serveur peut contrôler quelles
+ directives peuvent être placées dans les fichiers
+ .htaccess en définissant la directive
+ AllowOverride
+ dans les fichiers de configuration principaux.
Pour plus d'informations sur les fichiers .htaccess,
+ se référer au tutoriel .htaccess.
Serveur HTTP Apache Version 2.4
+Apache HTTPD supporte la négociation de + contenu telle qu'elle est décrite + dans la spécification HTTP/1.1. Il peut choisir la meilleure représentation + d'une ressource en fonction des préférences du navigateur pour ce qui + concerne le type de media, les langages, le jeu de caractères et son + encodage. Il implémente aussi quelques fonctionnalités pour traiter de + manière plus intelligente les requêtes en provenance de navigateurs qui + envoient des informations de négociation incomplètes.
+ +La négociation de contenu est assurée par le module
+ mod_negotiation qui est compilé par défaut
+ dans le serveur.
À propos de la négociation de contenu La négociation avec httpd Les méthodes de négociation Ajustement des valeurs de qualité Extensions à la négociation de contenu
+transparente Remarques à propos des liens hypertextes et des
+conventions de nommage Remarque sur la mise en cacheUne ressource peut être disponible selon différentes représentations. + Par exemple, elle peut être disponible en différents langages ou pour + différents types de média, ou une combinaison des deux. + Pour faire le meilleur choix, on peut fournir à l'utilisateur une page + d'index, et le laisser choisir. Cependant, le serveur peut souvent faire + ce choix automatiquement. Ceci est possible car les navigateurs peuvent + envoyer des informations sur les + représentations qu'ils préfèrent à l'intérieur de chaque requête. + Par exemple, un navigateur peut indiquer + qu'il préfère voir les informations en français, mais qu'en cas + d'impossibilité l'anglais peut convenir. Les navigateurs indiquent leurs + préférences à l'aide d'en-têtes dans la requête. Pour ne demander que des + représentations en français, le navigateur peut utiliser l'en-tête :
+ +Accept-Language: fr
Notez qu'il ne sera tenu compte de cette préférence que s'il existe un + choix de représentations et que ces dernières varient en fonction + du langage.
+ +À titre d'exemple d'une requête plus complexe, ce navigateur a été + configuré pour accepter le français et l'anglais, avec une préférence pour + le français, et accepter différents types de média, avec une préférence + pour HTML par rapport à au texte plat ("plain text") ou autres types de fichiers texte, et + avec une préférence pour GIF ou JPEG par rapport à tout autre type de + média, mais autorisant tout autre type de média en dernier ressort :
+ +
+ Accept-Language: fr; q=1.0, en; q=0.5
+ Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1
+
httpd supporte la négociation de contenu "server driven" (telle qu'elle
+ est définie dans la spécification HTTP/1.1), où c'est le serveur qui
+ décide quelle est la meilleure représentation à retourner pour la ressource
+ demandée. Il supporte entièrement les en-têtes de requête
+ Accept, Accept-Language,
+ Accept-Charset et Accept-Encoding.
+ httpd supporte aussi la négociation de contenu transparente, qui est un
+ protocole de négociation expérimental défini dans les RFC 2295 et 2296.
+ Il ne supporte pas la négociation de fonctionnalité (feature negotiation)
+ telle qu'elle est définie dans ces RFCs.
Une ressource est une entité conceptuelle identifiée + par une URI (RFC 2396). Un serveur HTTP comme le serveur HTTP Apache + propose l'accès à des + représentations de la ressource à l'intérieur de son + espace de nommage, chaque représentation étant composée d'une séquence + d'octets avec la définition d'un type de media, d'un jeu de caractères, + d'un encodage, etc... A un instant donné, chaque ressource peut être + associée avec zéro, une ou plusieurs représentations. Si plusieurs + représentations sont disponibles, la ressource est qualifiée de + négociable et chacune de ses représentations se nomme + variante. Les différences entre les + variantes disponibles d'une ressource négociable constituent les + dimensions de la négociation.
+Afin de négocier une ressource, on doit fournir au serveur des + informations à propos de chacune des variantes. Il y a deux manières + d'accomplir ceci :
+ +*.var) qui nomme explicitement les fichiers
+ contenant les variantes, ouUne liste de correspondances de types est un document associé au
+ gestionnaire type-map (ou, dans un souci de compatibilité
+ ascendante avec des configurations de httpd plus anciennes, le
+ type MIME
+ application/x-type-map). Notez que pour utiliser cette
+ fonctionnalité, vous devez, dans le fichier de configuration, définir un
+ gestionnaire qui associe un suffixe de fichier à une type-map;
+ ce qui se fait simplement en ajoutant
AddHandler type-map .var+ + +
dans le fichier de configuration du serveur.
+ +Les fichiers de correspondances de types doivent posséder le même nom que
+ la ressource qu'ils décrivent, avec pour extension
+ .var. Dans l'exemple ci-dessous, la ressource a pour
+ nom foo, et le fichier de correspondances se nomme donc
+ foo.var.
Ce fichier doit comporter une entrée pour chaque variante + disponible; chaque entrée consiste en une ligne contiguë d'en-têtes au + format HTTP. les entrées sont séparées par des lignes vides. Les lignes + vides à l'intérieur d'une entrée sont interdites. Par convention, le + fichier de correspondances de types débute par une entrée concernant l'entité + considérée dans son ensemble (bien que ce ne soit pas obligatoire, et + ignoré si présent). Un exemple de fichier de + correspondance de types est fourni + ci-dessous.
+ +Les URIs de ce fichier sont relatifs à la localisation du fichier + de correspondances de types. En général, ces fichiers se trouveront dans le + même répertoire que le fichier de correspondances de types, mais ce + n'est pas obligatoire. Vous pouvez utiliser des URIs absolus ou + relatifs pour tout fichier situé sur le même serveur que le fichier + de correspondances.
+ +
+ URI: foo
+
+ URI: foo.en.html
+ Content-type: text/html
+ Content-language: en
+
+ URI: foo.fr.de.html
+ Content-type: text/html;charset=iso-8859-2
+ Content-language: fr, de
+
Notez aussi qu'un fichier de correspondances de types prend le pas sur + les extensions de noms de fichiers, même si les Multivues sont activées. + Si les variantes sont de qualités différentes, on doit l'indiquer + à l'aide du paramètre "qs" à la suite du type de média, comme pour cette + image + (disponible aux formats JPEG, GIF, ou ASCII-art) :
+ +
+ URI: foo
+
+ URI: foo.jpeg
+ Content-type: image/jpeg; qs=0.8
+
+ URI: foo.gif
+ Content-type: image/gif; qs=0.5
+
+ URI: foo.txt
+ Content-type: text/plain; qs=0.01
+
Les valeurs de qs peuvent varier de 0.000 à 1.000. Notez que toute + variante possédant une valeur de qs de 0.000 ne sera jamais choisie. + Les variantes qui n'ont pas de paramètre qs défini se voient attribuer + une valeur de 1.0. Le paramètre qs indique la qualité relative de la + variante comparée à celle des autres variantes disponibles, sans tenir + compte des capacités du client. Par exemple, un fichier JPEG possède + en général une qualité supérieure à celle d'un fichier ASCII s'il + représente une photographie. Cependant, si la ressource représentée est + à un ASCII art original, la représentation ASCII sera de meilleure qualité + que la représentation JPEG. Ainsi une valeur de qs est associée à une + variante en fonction de la nature de la ressource qu'elle représente.
+ +La liste complète des en-têtes reconnus est disponible dans la + documentation sur les correspondances de types du + module mod_negotiation.
+ + +MultiViews est une option qui s'applique à un répertoire,
+ ce qui signifie qu'elle peut être activée à l'aide d'une directive
+ Options à l'intérieur d'une section
+ <Directory>, <Location> ou <Files> dans
+ httpd.conf, ou (si AllowOverride est correctement positionnée) dans
+ des fichiers
+ .htaccess. Notez que Options All
+ n'active pas MultiViews; vous devez activer cette option en
+ la nommant explicitement.
L'effet de MultiViews est le suivant : si le serveur reçoit
+ une requête pour /tel/répertoire/foo, si
+ MultiViews est activée pour
+ /tel/répertoire, et si
+ /tel/répertoire/foo n'existe pas, le serveur parcourt
+ le répertoire à la recherche de fichiers nommés foo.*, et simule
+ littéralement une correspondance de types (type map) qui liste tous ces
+ fichiers, en leur associant les mêmes types de média et encodages de
+ contenu qu'ils auraient eu si le client avait demandé l'accès à l'un
+ d'entre eux par son nom. Il choisit ensuite ce qui correspond le mieux
+ aux besoins du client.
MultiViews peut aussi s'appliquer à la recherche du fichier
+ nommé par la directive DirectoryIndex, si le serveur tente d'indexer
+ un répertoire. Si les fichiers de configuration spécifient
DirectoryIndex index+ +
le serveur va choisir entre index.html
+ et index.html3 si les deux fichiers sont présents. Si aucun
+ n'est présent, mais index.cgi existe,
+ le serveur l'exécutera.
Si, parcequ'elle n'est pas reconnue par mod_mime,
+ l'extension d'un des fichiers du répertoire ne permet pas de
+ déterminer son jeu de caractères, son type de contenu, son langage, ou son
+ encodage, alors
+ le résultat dépendra de la définition de la directive MultiViewsMatch. Cette directive détermine
+ si les gestionnaires (handlers), les filtres, et autres types d'extensions
+ peuvent participer à la négociation MultiVues.
Une fois obtenue la liste des variantes pour une ressource donnée, + httpd dispose de deux méthodes pour choisir la meilleure variante à + retourner, s'il y a lieu, soit à partir d'un fichier de + correspondances de types, soit en se basant sur les noms de fichiers du + répertoire. Il n'est pas nécessaire de connaître en détails comment la + négociation fonctionne réellement pour pouvoir utiliser les fonctionnalités + de négociation de contenu de httpd. La suite de ce document explique + cependant les méthodes utilisées pour ceux ou celles qui sont + intéressés(ées).
+ +Il existe deux méthodes de négociation :
+ +| Dimension | + +Notes | +
|---|---|
| Type de média | + +Le navigateur affiche ses préférences à l'aide du champ d'en-tête
+ Accept. Chaque type de média peut se voir associé un facteur de
+ qualité. La description de la variante peut aussi avoir un facteur de
+ qualité (le paramètre "qs"). |
+
| Langage | + +Le navigateur affiche ses préférences à l'aide du champ d'en-tête
+ Accept-Language. Chaque langue peut se voir associé un facteur de
+ qualité. Les variantes peuvent être associées avec zéro, un ou
+ plusieurs langages. |
+
| Encoding | + +Le navigateur affiche ses préférences à l'aide du champ d'en-tête
+ Accept-Encoding. Chaque encodage peut se voir associé un facteur de
+ qualité. |
+
| Charset | + +Le navigateur affiche ses préférences à l'aide du champ d'en-tête
+ Accept-Charset. Chaque jeu de caractère peut se voir associé un facteur de
+ qualité. Les variantes peuvent préciser un jeu de caractères comme
+ paramètre du type de média. |
+
httpd peut utiliser l'algorithme suivant pour choisir la "meilleure" + variante (s'il y en a une) à retourner au navigateur. Cet algorithme n'est pas + configurable. Il fonctionne comme suit :
+ +Accept par le facteur de qualité "qs" pour le type de
+ média de ces variantes, et choisir la variante qui possède la valeur
+ la plus importante.Accept-Language (s'il existe), ou de la directive
+ LanguagePriority (si elle existe).Accept-Charset . Le jeu de
+ caractères ISO-8859-1 est acceptable sauf s'il est explicitement
+ exclus. Les variantes avec un type de média text/*
+ mais non explicitement associées avec un jeu de caractères
+ particulier sont supposées être en ISO-8859-1.Vary de la réponse est renseigné de façon à
+ indiquer les dimensions de la négociation (les navigateurs et les caches
+ peuvent utiliser cette information lors de la mise en cache de la
+ ressource). Travail terminé.Vary de façon à indiquer les dimensions de la variante.Parfois httpd modifie les valeurs de qualité par rapport à celles qui
+ découleraient d'une stricte interprétation de l'algorithme de négociation
+ de httpd ci-dessus, ceci pour améliorer les résultats de l'algorithme pour
+ les navigateurs qui envoient des informations incomplètes ou inappropriées.
+ Certains des navigateurs les plus populaires envoient des informations dans
+ l'en-tête Accept qui, sans ce traitement, provoqueraient la
+ sélection d'une variante inappropriée dans de nombreux cas. Quand un
+ navigateur envoie des informations complètes et correctes ces ajustements
+ ne sont pas effectués.
L'en-tête de requête Accept: indique les types de média
+ souhaités. Il peut aussi contenir des types de média avec caractères
+ génériques, comme "image/*" ou "*/*" où * correspond à n'importe quelle
+ chaîne de caractères. Ainsi une requête contenant :
Accept: image/*, */*
indiquerait que tout type de média est acceptable, avec une préférence + pour les types commençant par "image/". + Certains navigateurs ajoutent par défaut des types de média avec caractères + génériques aux types explicitement nommés qu'ils peuvent gérer. + Par exemple :
+ +
+ Accept: text/html, text/plain, image/gif, image/jpeg, */*
+
Ceci indique que les types explicitement listés sont préférés, mais + qu'une représentation avec un type différent de ces derniers conviendra + aussi. Les valeurs de qualités explicites, + afin de préciser ce que veut vraiment le navigateur, s'utilisent + comme suit :
+
+ Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
+
Les types explicites n'ont pas de facteur de qualité, la valeur par + défaut de leur préférence est donc de 1.0 (la plus haute). Le type avec + caractères génériques */* se voit attribuer une préférence basse de 0.01, + si bien que les types autres que ceux explicitement listés ne seront retournés + que s'il n'existe pas de variante correspondant à un type explicitement + listé.
+ +Si l'en-tête Accept: ne contient pas aucun
+ facteur de qualité, httpd positionne la valeur de qualité de
+ "*/*", si present, à 0.01 pour simuler l'effet désiré. Il positionne aussi
+ la valeur de qualité des types avec caractères génériques au format
+ "type/*" à 0.02 (ils sont donc préférés à ceux correspondant à "*/*"). Si
+ un type de média dans l'en-tête Accept: contient un facteur de
+ qualité, ces valeurs spéciales ne seront pas appliquées, de façon
+ à ce que les requêtes de navigateurs qui envoient les informations
+ explicites à prendre en compte fonctionnent comme souhaité.
A partir de la version 2.0 de httpd, certaines exceptions ont été + ajoutées à l'algorithme de négociation afin de ménager une issue de secours + quand la négociation ne trouve aucun langage correspondant.
+ +Quand un client demande une page sur votre serveur, si ce dernier ne
+ parvient pas à trouver une page dont la langue corresponde à l'en-tête
+ Accept-language envoyé par le navigateur, il enverra au client
+ une réponse "Aucune variante acceptable" ou "Plusieurs choix possibles".
+ Pour éviter ces
+ messages d'erreur, il est possible de configurer httpd de façon à ce que,
+ dans ces cas, il ignore l'en-tête Accept-language et fournisse
+ tout de même un document, même s'il ne correspond pas exactement à la
+ demande explicite du client. La directive ForceLanguagePriority
+ peut être utilisée pour éviter ces messages d'erreur et leur substituer une
+ page dont le langage sera déterminé en fonction du contenu de la directive
+ LanguagePriority.
Le serveur va aussi essayer d'étendre sa recherche de correspondance aux
+ sous-ensembles de langages quand aucune correspondance exacte ne peut être
+ trouvée. Par exemple, si un client demande des documents possédant le
+ langage en-GB, c'est à dire anglais britannique, le standard
+ HTTP/1.1 n'autorise normalement pas le serveur à faire correspondre cette
+ demande à un document dont le langage est simplement en.
+ (Notez qu'inclure en-GB et non en dans l'en-tête
+ Accept-Language constitue une quasi-erreur de configuration,
+ car il est très peu probable qu'un lecteur qui comprend l'anglais
+ britannique, ne comprenne pas l'anglais en général. Malheureusement, de
+ nombreux clients ont réellement des configurations par défaut de ce type.)
+ Cependant, si aucune autre correspondance de langage n'est possible, et que le
+ serveur est sur le point de retourner une erreur "Aucune variable
+ acceptable" ou de choisir le langage défini par la directive LanguagePriority, le serveur ignorera
+ la spécification du sous-ensemble de langage et associera la demande en
+ en-GB à des documents en en. Implicitement,
+ httpd ajoute le langage parent à la liste de langues acceptés par le
+ client avec une valeur de qualité très basse. Notez cependant que si le
+ client demande "en-GB; q=0.9, fr; q=0.8", et le serveur dispose de
+ documents estampillés "en" et "fr", alors c'est le document "fr" qui sera
+ retourné, tout ceci dans un souci de compatibilité avec la spécification
+ HTTP/1.1 et afin de fonctionner efficacement avec les clients
+ correctement configurés.
Pour supporter les techniques avancées (comme les cookies ou les chemins
+ d'URL spéciaux) afin de déterminer le langage préféré de l'utilisateur, le
+ module mod_negotiation reconnaît la
+ variable d'environnement
+ prefer-language
+ depuis la version 2.0.47 de httpd. Si elle est définie et contient un
+ symbole de langage approprié, mod_negotiation va essayer
+ de sélectionner une variante correspondante. S'il n'existe pas de telle
+ variante, le processus normal de négociation sera lancé.
SetEnvIf Cookie "language=(.+)" prefer-language=$1 +Header append Vary cookie+
httpd étend le protocole de négociation de contenu transparente (RFC
+2295) comme suit. Un nouvel élément {encodage ..} est utilisé dans
+les listes de variantes pour marquer celles qui ne sont disponibles qu'avec un
+encodage de contenu spécifique. L'implémentation de l'algorithme
+RVSA/1.0 (RFC 2296) est étendue à la reconnaissance de variantes encodées dans
+la liste, et à leur utilisation en tant que variantes candidates à partir du
+moment où leur encodage satisfait au contenu de l'en-tête de requête
+Accept-Encoding. L'implémentation RVSA/1.0 n'arrondit pas les
+facteurs de qualité calculés à 5 décimales avant d'avoir choisi la meilleure
+variante.
Si vous utilisez la négociation de langage, vous avez le choix entre + différentes conventions de nommage, car les fichiers peuvent posséder + plusieurs extensions, et l'ordre dans lequel ces dernières apparaissent + est en général sans rapport (voir la documentation sur le module mod_mime + pour plus de détails).
+ +Un fichier type possède une extension liée au type MIME
+ (par exemple, html), mais parfois aussi une
+ extension liée à l'encodage (par exemple, gz),
+ et bien sûr une extension liée au langage
+ (par exemple, en) quand plusieurs variantes de
+ langage sont disponibles pour ce fichier.
Exemples :
+ +Ci-dessous d'autres exemples de noms de fichiers avec des liens + hypertextes valides et invalides :
+ +| Nom fichier | + +lien valide | + +Lien invalide | +
|---|---|---|
| foo.html.en | + +foo + foo.html |
+
+ - | +
| foo.en.html | + +foo | + +foo.html | +
| foo.html.en.gz | + +foo + foo.html |
+
+ foo.gz + foo.html.gz |
+
| foo.en.html.gz | + +foo | + +foo.html + foo.html.gz + foo.gz |
+
| foo.gz.html.en | + +foo + foo.gz + foo.gz.html |
+
+ foo.html | +
| foo.html.gz.en | + +foo + foo.html + foo.html.gz |
+
+ foo.gz | +
En regardant la table ci-dessus, vous remarquerez qu'il est toujours
+ possible d'utiliser le nom de fichier sans extension dans un lien
+ (par exemple, foo). L'avantage est de pouvoir
+ dissimuler le type réel du fichier associé à un document et de pouvoir
+ le modifier
+ ultérieurement, par exemple, de html à
+ shtml ou cgi sans avoir à
+ mettre à jour aucun lien.
Si vous souhaitez continuer à utiliser un type MIME dans vos liens
+ (par exemple foo.html), l'extension liée au langage
+ (y compris une extension liée à l'encodage s'il en existe une)
+ doit se trouver à droite de l'extension liée au type MIME
+ (par exemple, foo.html.en).
Quand un cache stocke une représentation, il l'associe avec l'URL de la + requête. Lorsque cette URL est à nouveau demandée, le cache peut utiliser + la représentation stockée. Cependant, si la ressource est négociable au + niveau du serveur, il se peut que seule la première variante demandée soit + mise en cache et de ce fait, la correspondance positive du cache peut + entraîner une réponse inappropriée. Pour + éviter ceci, httpd marque par + défaut toutes les réponses qui sont retournées après une négociation de + contenu comme "non-cachables" par les clients HTTP/1.0. httpd supporte + aussi les fonctionnalités du protocole HTTP/1.1 afin de permettre la mise + en cache des réponses négociées.
+ +Pour les requêtes en provenance d'un client compatible HTTP/1.0
+ (un navigateur ou un cache), la directive CacheNegotiatedDocs peut être utilisée
+ pour permettre la mise en cache des réponses qui ont fait l'objet d'une
+ négociation. Cette directive peut intervenir dans la configuration au
+ niveau du serveur ou de l'hôte virtuel, et n'accepte aucun argument. Elle
+ n'a aucun effet sur les requêtes en provenance de clients HTTP/1.1.
Pour les clients HTTP/1.1, httpd envoie un en-tête de réponse HTTP
+ Vary afin d'indiquer les dimensions de la négociation pour
+ cette réponse. Les caches peuvent
+ utiliser cette information afin de déterminer
+ si une requête peut être servie à partir de la copie locale. Pour inciter
+ un cache à utiliser la copie locale sans tenir compte des dimensions de la
+ négociation, définissez la
+ variable d'environnement
+ force-no-vary.
Serveur HTTP Apache Version 2.4
+Le serveur HTTP Apache fournit des messages d'erreur génériques + pour les codes de statut 4xx ou 5xx ; ces messages sont cependant + relativement austères, imprécis, et peuvent s'avérer intimidants + pour les visiteurs du site. Si vous le souhaitez, vous pouvez + afficher des messages d'erreur plus conviviaux, dans un langage + autre que l'anglais, ou même sous une forme plus en adéquation avec + le style de votre site.
+ +Il est possible de définir des messages d'erreur personnalisés + pour chaque code de statut HTTP associé à une condition d'erreur - + c'est à dire tout code de statut 4xx ou 5xx.
+ +De plus, il est possible de + personnaliser le message d'erreur en fonction d'un jeu de valeurs + fourni, en utilisant les Inclusions Côté + Serveur (SSI). Un programme CGI ou un autre gestionnaire + dynamique (PHP, mod_perl, etc...) peut aussi utiliser ces variables + pour gérer les conditions d'erreur.
+ + + Configuration Variables disponibles Personnalisation des messages d'erreur Messages d'erreur personnalisés
+ multilinguesLes messages d'erreur personnalisés sont configurés via la
+ directive ErrorDocument, qui
+ peut être utilisée dans un contexte global, serveur virtuel ou
+ répertoire. On peut utiliser cette directive dans les fichiers
+ .htaccess si AllowOverride est
+ définie à FileInfo.
ErrorDocument 500 "Désolé, notre script s'est +crashé ; comme c'est dommage !" +ErrorDocument 500 /cgi-bin/crash-recover +ErrorDocument 500 http://error.example.com/server_error.html +ErrorDocument 404 /errors/not_found.html +ErrorDocument 401 /subscription/how_to_subscribe.html+ + +
La syntaxe de la directive ErrorDocument est :
ErrorDocument <code_3_chiffres> <action>+ +
où action peut être traitée comme :
+Dans le cas d'une redirection vers une URL locale, des variables + d'environnement supplémentaires sont définies de façon à ce que la + réponse puisse être personnalisée par la suite. Elles ne sont pas + envoyées aux URLs externes.
+ +La redirection vers une autre URL peut être utile, mais + seulement s'il est possible de transmettre certaines informations + qui pourront être utilisées pour expliquer ou journaliser + la condition d'erreur ou le problème plus clairement.
+ +Pour y parvenir, lorsque la redirection d'erreur est envoyée, + des variables d'environnement supplémentaires sont définies à + partir des en-têtes de la requête originale en préfixant le nom + d'origine de l'en-tête par 'REDIRECT_', ce qui permet de fournir au + message d'erreur le contexte de la requête originelle.
+ +Par exemple, en plus des variables d'environnement habituelles, + vous pouvez recevoir ce qui suit :
+ + +
+ REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/jpeg, image/png
+ REDIRECT_HTTP_USER_AGENT=Mozilla/5.0 Fedora/3.5.8-1.fc12 Firefox/3.5.8
+ REDIRECT_PATH=.:/bin:/usr/local/bin:/sbin
+ REDIRECT_QUERY_STRING=
+ REDIRECT_REMOTE_ADDR=121.345.78.123
+ REDIRECT_REMOTE_HOST=client.example.com
+ REDIRECT_SERVER_NAME=www.example.edu
+ REDIRECT_SERVER_PORT=80
+ REDIRECT_SERVER_SOFTWARE=Apache/2.2.15
+ REDIRECT_URL=/cgi-bin/buggy.pl
+
Les variables d'environnement REDIRECT_ sont
+ créées à partir des variables d'environnement préexistantes à la
+ redirection qui sont préfixées par la chaîne REDIRECT_ ;
+ par exemple, HTTP_USER_AGENT devient
+ REDIRECT_HTTP_USER_AGENT.
REDIRECT_URL, REDIRECT_STATUS, et
+ REDIRECT_QUERY_STRING sont systématiquement définies,
+ les autres variables n'étant définies que si l'en-tête
+ correspondant existait avant la condition d'erreur.
Aucune d'entre elles ne sera définie si votre
+ directive ErrorDocument
+ spécifie une redirection externe (toute URL commençant
+ par un protocole du style http:, même si elle fait
+ référence au même hôte que le serveur).
Si vous faites pointer votre directive
+ ErrorDocument vers certains gestionnaires
+ dynamiques comme les inclusions côté serveur, les scripts CGI ou
+ d'autres gestionnaires, vous pouvez utiliser les variables
+ d'environnement supplémentaires disponibles pour personnaliser
+ le message.
Si la directive ErrorDname-basedocument spécifie une redirection locale
+ vers un script CGI, ce dernier doit ajouter un en-tête
+ "Status:" dans sa sortie afin de s'assurer du bon
+ acheminement jusqu'au client de la condition d'erreur qui a
+ provoqué cette redirection. Par exemple, un script Perl spécifié
+ par une directive ErrorDocument pourrait contenir ce qui suit
+ :
...
+print "Content-type: text/html\n";
+printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
+...
+
+
+ Si un script est dédié à la gestion d'une condition d'erreur
+ spécifique, telle que 404 Not Found, il
+ peut utiliser le code et le texte de l'erreur spécifiques à la
+ place.
Notez que si la réponse contient un en-tête
+ Location: (afin d'initier une redirection côté
+ client), le script doit émettre un en-tête approprié
+ (comme 302 Found). Dans le cas contraire,
+ l'en-tête Location: ne produira aucun effet.
Vous trouverez dans la distribution du serveur HTTP Apache un
+ répertoire contenant des messages d'erreur personnalisés traduits en
+ 16 langues différentes. Pour activer cette fonctionnalité, vous
+ pouvez aussi inclure un fichier de configuration qui se trouve dans
+ le répertoire de configuration conf/extra.
Dans le fichier de configuration de votre serveur, vous trouverez + un groupe de lignes du style :
+ +# Multi-language error messages + #Include conf/extra/httpd-multilang-errordoc.conf+ + +
Décommentez la ligne Include pour activer cette
+ fonctionnalité, et présenter des messages d'erreur dont le langage
+ sera négocié en fonction du langage préféré défini au niveau du
+ navigateur du client.
De plus, ces documents contiennent diverses variables
+ REDIRECT_, de façon à ce que l'utilisateur final
+ dispose d'informations supplémentaires à propos de ce qui a pu se
+ produire, et de ce qu'il est susceptible de faire maintenant.
Ces documents peuvent être personnalisés en fournissant autant + d'informations utiles que vous le souhaitez aux utilisateurs à + propos de votre site, et de ce qu'ils sont susceptibles d'y trouver.
+ +Pour pouvoir utiliser cette fonctionnalité, vous devez activer
+ mod_include et mod_negotiation.
Serveur HTTP Apache Version 2.4
+Cette page pourrait se résumer ainsi : configurez le + serveur HTTP Apache de façon + à ce qu'il n'ait pas besoin de résolution DNS pour interpréter les + fichiers de configuration. Si httpd doit effectuer des résolutions + DNS pour interpréter les fichiers de configuration, votre serveur + pourra présenter des problèmes de fiabilité (en d'autres termes, + il est possible qu'il refuse de démarrer), ou d'attaques par déni ou + usurpation de service (y compris l'attribution de requêtes à un + serveur virtuel autre que le serveur virtuel voulu).
+ Un exemple simple Déni de service L'adresse du "serveur principal" Conseils pour éviter ce genre de problème# Ceci est un exemple de mauvaise configuration ; ne l'utilisez pas comme base +# de configuration +<VirtualHost www.example.dom> + ServerAdmin webgirl@example.dom + DocumentRoot "/www/example" +</VirtualHost>+ + +
Pour fonctionner correctement, le serveur a absolument besoin de deux
+ informations à propos de chaque serveur virtuel : le nom du serveur
+ défini par la directive ServerName, et au moins une adresse IP à
+ laquelle le serveur va se rattacher et répondre. L'exemple ci-dessus
+ ne comporte pas d'adresse IP, si bien que httpd devra utiliser le
+ DNS pour trouver l'adresse IP de www.example.dom. Si pour
+ une raison quelconque, le DNS n'est pas disponible au moment où
+ votre serveur interprète son fichier de configuration, ce serveur
+ virtuel ne sera pas pris en compte dans la
+ configuration. Il sera incapable de
+ répondre à toute requête pour ce serveur virtuel.
Supposons que l'adresse de www.example.dom soit
+ 192.0.2.1, et examinons cet extrait de configuration :
# Ceci est un exemple de mauvaise configuration ; ne l'utilisez pas comme base +# de configuration +<VirtualHost 192.0.2.1> + ServerAdmin webgirl@example.dom + DocumentRoot "/www/example" +</VirtualHost>+ + +
Cette fois, httpd doit effectuer une recherche DNS inverse pour
+ trouver le nom ServerName de ce serveur virtuel. Si
+ cette recherche inverse échoue, le serveur virtuel sera
+ partiellement désactivé. Si le serveur
+ virtuel est à base de nom, il sera en fait totalement désactivé,
+ mais s'il est à base d'adresse IP, il fonctionnera probablement.
+ Cependant, httpd échouera s'il doit générer une URL complète pour
+ le serveur qui inclut ce nom de serveur (comme dans le cas d'une
+ redirection).
Voici un extrait de configuration qui permet d'éviter ces deux + types de problèmes :
+ +<VirtualHost 192.0.2.1> + ServerName www.example.dom + ServerAdmin webgirl@example.dom + DocumentRoot "/www/example" +</VirtualHost>+ +
Considérons cet extrait de configuration :
+ +<VirtualHost www.example1.dom> + ServerAdmin webgirl@example1.dom + DocumentRoot "/www/example1" +</VirtualHost> +<VirtualHost www.example2.dom> + ServerAdmin webguy@example2.dom + DocumentRoot "/www/example2" +</VirtualHost>+ + +
Supposons que vous ayez assigné 192.0.2.1 à
+ www.example1.dom et 192.0.2.2 à www.example2.dom. En
+ outre, supposons que example1.dom gère son propre DNS. Avec
+ cette configuration, example1.dom sera en mesure de
+ détourner tout trafic destiné à example2.dom. Pour y
+ parvenir, tout ce qu'ils ont à faire consiste à
+ assigner 192.0.2.2 à
+ www.example1.dom. Comme ils gèrent leur propre DNS, vous ne
+ pouvez pas les empêcher de faire pointer l'enregistrement
+ www.example1.dom vers l'adresse qu'ils veulent.
Les requêtes à destination de 192.0.2.2 (y compris toutes celles
+ où l'utilisateur à tapé une URL de la forme
+ http://www.example2.dom/quelquepart), seront toutes servies
+ par le serveur virtuel example1.dom. Une meilleur
+ compréhension de la raison pour laquelle ceci peut se produire
+ nécessite une discussion plus approfondie à propos de la manière
+ dont httpd associe les requêtes entrantes aux différents serveurs
+ virtuels qui vont les servir. Un document de base décrivant ceci est disponible.
Le support des
+ serveurs virtuels à base de nom oblige httpd à
+ connaître la/les adresse(s) IP de l'hôte sur
+ lequel httpd s'exécute. Pour obtenir cette
+ adresse, soit il utilise la directive ServerName globale (si elle est présente),
+ soit il fait appel à la fonction C gethostname (qui
+ doit renvoyer le même nom que la commande shell "hostname"). Il
+ effectue ensuite une recherche DNS sur cette adresse. Pour le
+ moment, il n'existe aucun moyen d'éviter cette recherche DNS.
Si vous craignez que cette recherche DNS échoue parce que votre
+ serveur DNS est arrêté, vous pouvez insérer le nom d'hôte dans le
+ fichier /etc/hosts (où il est probablement déjà
+ enregistré afin que la machine démarre correctement). Assurez-vous
+ ensuite que la machine est configurée pour utiliser
+ /etc/hosts dans le cas où la recherche DNS échoue.
+ Suivant le système d'exploitation que vous utilisez, vous y
+ parviendrez en éditant /etc/resolv.conf, ou
+ /etc/nsswitch.conf.
Si votre serveur n'a aucune autre raison d'effectuer des
+ recherches DNS, vous pouvez définir la variable d'environnement
+ HOSTRESORDER à "local", et vous serez alors en mesure
+ d'exécuter httpd. Tout dépend du système d'exploitation et des
+ bibliothèques de résolution de noms que vous utilisez. Elle affecte
+ aussi les programmes CGI, à moins que vous n'utilisiez
+ mod_env pour contrôler l'environnement. Il est
+ conseillé de consulter les pages de manuel ou les FAQs de votre
+ système d'exploitation.
VirtualHost
+ Listen
+ ServerName explicite
+ <VirtualHost
+ _default_:*> qui n'a aucune page à servirServeur HTTP Apache Version 2.4
+La conception modulaire du serveur HTTP Apache permet à l'administrateur
+ de choisir les fonctionnalités à inclure dans le serveur en sélectionnant
+ un certain nombre de modules. Les modules seront compilés en tant
+ qu'Objets Dynamiques Partagés (Dynamic Shared Objects ou DSOs)
+ qui mènent une existence séparée du fichier binaire principal
+ httpd. Les modules DSO peuvent être compilés en
+ même temps que le serveur, ou compilés et ajoutés ultérieurement via
+ l'Outil des Extensions à Apache (Apache Extension Tool ou
+ apxs).
Les modules peuvent aussi être intégrés statiquement dans le
+ binaire httpd lors de la compilation de ce
+ dernier.
Ce document décrit l'utilisation des modules DSO ainsi que les dessous + de leur fonctionnement.
+ Implémentation Mode d'emploi succinct Les dessous du fonctionnement des DSO Avantages et inconvénients| Modules Apparentés | Directives Apparentées |
|---|---|
Le support DSO pour le chargement de modules individuels d'Apache
+ httpd est
+ assuré par un module nommé mod_so qui doit être compilé
+ statiquement dans le coeur d'Apache httpd. Il s'agit du seul module avec le
+ module core à ne pas pouvoir être compilé en tant que
+ module DSO lui-même. Pratiquement tous les autres modules d'Apache httpd
+ distribués seront alors compilés en tant que modules DSO. Une fois
+ compilé en tant que module DSO nommé mod_foo.so, un
+ module peut être chargé en mémoire au
+ démarrage ou redémarrage du serveur à l'aide de
+ la directive LoadModule du module
+ mod_so, placée
+ dans votre fichier httpd.conf.
La compilation en mode DSO peut être désactivée pour certains
+ modules via l'option --enable-mods-static du script
+ configure, comme expliqué dans la Documentation sur l'installation.
Un utilitaire permet de simplifier la création de
+ fichiers DSO pour les modules d'Apache httpd
+ (particulièrement pour les modules tiers) ; il s'agit du programme nommé
+ apxs (APache
+ eXtenSion). On peut l'utiliser pour construire des modules de type
+ DSO en dehors de l'arborescence des sources d'Apache httpd. L'idée est
+ simple : à l'installation du serveur HTTP Apache, la procédure make install
+ du script configure installe les fichiers d'en-têtes
+ d'Apache httpd et positionne, pour la plateforme de compilation, les drapeaux du compilateur et de
+ l'éditeur de liens à l'intérieur du programme
+ apxs, qui sera utilisé pour la construction de fichiers DSO.
+ Il est ainsi possible d'utiliser le programme apxs
+ pour compiler ses sources de modules Apache httpd sans avoir besoin de
+ l'arborescence des sources de la distribution d'Apache, et sans avoir à
+ régler les drapeaux du compilateur et de l'éditeur de liens pour le support DSO.
Afin que vous puissiez vous faire une idée des fonctionnalités DSO + du serveur HTTP Apache 2.x, en voici un résumé court et concis :
+ +Construire et installer un module Apache httpd faisant partie de la
+ distribution, par exemple mod_foo.c,
+ en tant que module DSO mod_foo.so :
+$ ./configure --prefix=/chemin/vers/installation --enable-foo
+$ make install
+
Configure le serveur HTTP Apache avec tous les modules
+ activés. Seul un jeu de modules de base sera chargé au
+ démarrage du serveur. Vous pouvez modifier ce jeu de modules
+ chargés au démarrage en activant ou désactivant les directives LoadModule correspondantes dans le
+ fichier httpd.conf.
+$ ./configure --enable-mods-shared=all
+$ make install
+
L'argument most de l'option
+ --enable-modules indique que tous les modules
+ non-expérimentaux ou qui ne sont pas là à titre d'exemple seront
+ compilés.
Certains modules ne sont utilisés que par les développeurs et
+ ne seront pas compilés. Si vous voulez les utiliser, spécifiez
+ l'option all. Pour compiler tous les modules disponibles,
+ y compris les modules de développeurs, spécifiez l'option
+ reallyall. En outre, la directive LoadModule peut être activée pour tous
+ les modules compilés via l'option du script configure
+ --enable-load-all-modules.
+$ ./configure --enable-mods-shared=reallyall --enable-load-all-modules
+$ make install
+
mod_foo.c, en tant que module DSO
+ mod_foo.so en dehors de l'arborescence des sources
+ d'Apache httpd à l'aide du programme apxs :
+
+
+$ cd /chemin/vers/module_tiers
+$ apxs -cia mod_foo.c
+
Dans tous les cas, une fois le module partagé compilé, vous devez
+ ajouter une directive LoadModule
+ dans le fichier httpd.conf pour qu'Apache httpd active le module.
Voir la documentation sur apxs + pour plus de détails.
+Les clônes modernes d'UNIX proposent un mécanisme + appelé édition de liens et chargement dynamiques d' + Objets Dynamiques Partagés (DSO), qui permet de construire un + morceau de programme dans un format spécial pour le rendre chargeable + à l'exécution dans l'espace d'adressage d'un programme exécutable.
+ +Ce chargement peut s'effectuer de deux manières : automatiquement par
+ un programme système appelé ld.so quand un programme
+ exécutable est démarré, ou manuellement à partir du programme en cours
+ d'exécution via sa propre interface système vers le chargeur Unix à l'aide
+ des appels système dlopen()/dlsym().
Dans la première méthode, les DSO sont en général appelés
+ bibliothèques partagées ou encore bibliothèques DSO, et
+ possèdent des noms du style
+ libfoo.so ou libfoo.so.1.2. Ils résident dans un
+ répertoire système (en général /usr/lib)
+ et le lien avec le programme exécutable est établi à la compilation en
+ ajoutant -lfoo à la commande de l'éditeur de liens. Les
+ références à la bibliothèque sont ainsi codées en dur dans le fichier du
+ programme exécutable de façon à ce qu'au démarrage du programme, le
+ chargeur Unix soit capable de localiser libfoo.so dans
+ /usr/lib, dans des chemins codés en dur à l'aide d'options de
+ l'éditeur de liens comme -R ou dans des chemins définis par la
+ variable d'environnement
+ LD_LIBRARY_PATH. Le chargeur peut dès lors résoudre tous les symboles
+ (jusque là non encore résolus) du DSO dans le programme exécutable.
Les symboles du programme exécutable ne sont en général pas
+ référencés par le DSO (car c'est une bibliothèque de code à usage général
+ et réutilisable),
+ et ainsi aucune résolution supplémentaire n'est nécessaire. De son côté,
+ le programme exécutable ne doit accomplir aucune action particulière
+ pour utiliser les
+ symboles du DSO car toutes les résolutions sont effectuées par le chargeur
+ Unix. En fait, le code permettant d'invoquer
+ ld.so fait partie du code de démarrage pour l'exécution qui
+ est lié dans tout programme exécutable non statiquement lié.
+ L'avantage du chargement dynamique du code d'une bibliothèque partagée est
+ évident : le code de la bibliothèque ne doit être stocké qu'une seule fois
+ dans une bibliothèque système telle que libc.so, ce qui permet
+ d'économiser de l'espace disque pour les autres programmes.
Dans la seconde méthode, les DSO sont en général appelés objets
+ partagés ou fichiers DSO, et peuvent être nommés avec
+ l'extension de son choix (bien que le nom conseillé soit du style
+ foo.so). Ces fichiers résident en général dans un répertoire
+ spécifique à un programme, et aucun lien n'est automatiquement établi avec
+ le programme exécutable dans lequel ils sont utilisés.
+ Le programme exécutable charge manuellement le DSO à l'exécution dans son
+ espace d'adressage à l'aide de l'appel système dlopen().
+ A ce moment, aucune résolution de symboles du DSO n'est effectuée pour le
+ programme exécutable. Par contre le chargeur Unix
+ résoud automatiquement tout symbole du DSO (non encore résolu)
+ faisant partie de l'ensemble de symboles exporté par le programme
+ exécutable et ses bibliothèques DSO déjà chargées (et en particulier tous
+ les symboles de la bibliothèque à tout faire libc.so).
+ De cette façon, le DSO prend connaissance de l'ensemble de symboles du
+ programme exécutable comme s'il avait été lié statiquement avec lui
+ auparavant.
Finalement, pour tirer profit de l'API des DSO, le programme exécutable
+ doit résoudre certains symboles du DSO à l'aide de l'appel système
+ dlsym() pour une utilisation ultérieure dans les tables de
+ distribution, etc... En d'autres termes, le programme exécutable doit
+ résoudre manuellement tous les symboles dont il a besoin pour pouvoir les
+ utiliser.
+ Avantage d'un tel mécanisme : les modules optionnels du programme n'ont pas
+ besoin d'être chargés (et ne gaspillent donc pas de ressources mémoire)
+ tant qu'il ne sont pas nécessaires au programme en question. Si nécessaire,
+ ces modules peuvent être chargés dynamiquement afin d'étendre les
+ fonctionnalités de base du programme.
Bien que ce mécanisme DSO paraisse évident, il comporte au moins une + étape difficile : la résolution des symboles depuis le programme exécutable + pour le DSO lorsqu'on utilise un DSO pour étendre les fonctionnalités d'un + programme (la seconde méthode). Pourquoi ? Parce que la "résolution + inverse" des symboles DSO à partir du jeu de symboles du programme + exécutable dépend de la conception de la bibliothèque (la bibliothèque n'a + aucune information sur le programme qui l'utilise) et n'est ni standardisée + ni disponible sur toutes les plateformes. En pratique, les symboles globaux + du programme exécutable ne sont en général pas réexportés et donc + indisponibles pour l'utilisation dans un DSO. Trouver une méthode pour + forcer l'éditeur de liens à exporter tous les symboles globaux est le + principal problème que l'on doit résoudre lorsqu'on utilise un DSO pour + étendre les fonctionnalités d'un programme au moment de son exécution.
+ +L'approche des bibliothèques partagées est la plus courante, parce que + c'est dans cette optique que le mécanisme DSO a été conçu ; c'est cette + approche qui est ainsi + utilisée par pratiquement tous les types de bibliothèques que fournit le + système d'exploitation.
+ +Les fonctionnalités ci-dessus basées sur les DSO présentent les + avantages suivants :
+ +LoadModule du fichier de
+ configuration httpd.conf plutôt que par des options du script
+ configure à la compilation. Par exemple,
+ on peut ainsi exécuter différentes instances du serveur
+ (standard et version SSL, version minimale et version dynamique
+ [mod_perl, mod_php], etc...) à partir d'une seule installation
+ d'Apache httpd.apxs vous permet d'une part de travailler en
+ dehors de l'arborescence des sources d'Apache httpd, et d'autre part de n'avoir
+ besoin que de la commande apxs -i
+ suivie d'un apachectl restart pour introduire une nouvelle
+ version de votre module fraîchement développé dans le serveur HTTP Apache
+ en cours d'exécution.Inconvénients des DSO :
+ +ld -lfoo) sur toutes les
+ plates-formes
+ (par exemple, les plates-formes basées sur a.out ne fournissent en
+ général pas cette fonctionnalité alors que les plates-formes basées sur
+ ELF le font), vous ne pouvez pas utiliser le mécanisme DSO pour tous les
+ types de modules. Ou en d'autres termes, les modules compilés comme
+ fichiers DSO sont contraints de n'utiliser que les symboles du coeur
+ d'Apache httpd, de la bibliothèque C
+ (libc) et toutes autres bibliothèques statiques ou
+ dynamiques utilisées par le coeur d'Apache httpd, ou d'archives statiques
+ (libfoo.a) contenant du code indépendant de la
+ position (PIC).
+ Il y a deux solutions pour utiliser un autre type de code : soit le
+ coeur d'Apache httpd contient déjà lui-même une référence au code, soit vous
+ chargez le code vous-même via dlopen().Serveur HTTP Apache Version 2.4
+Deux types de variables d'environnement affectent le serveur + HTTP Apache.
+ +Le premier type correspond aux variables d'environnement + contrôlées par le système d'exploitation sous-jacent et définies + avant le démarrage du serveur. Leurs valeurs peuvent être utilisées + directement dans les fichiers de configuration, et peuvent + éventuellement être transmises aux scripts CGI et SSI via la + directive PassEnv.
+ +Le second type correspond aux variables nommées appelées aussi + variables d'environnement dans lesquelles le serveur HTTP + Apache stocke des informations via un mécanisme spécial. Ces + informations peuvent servir à contrôler diverses opérations comme + l'enregistrement des traces ou le contrôle d'accès. On utilise aussi ces + variables dans le mécanisme de communication avec les programmes externes + comme les scripts CGI. Ce document présente différentes méthodes pour + manipuler et utiliser ces variables.
+ +Bien que ces variables soient référencées comme variables + d'environnement, il ne faut pas les confondre avec les variables + d'environnement contrôlées par le système d'exploitation sous-jacent. + En fait, ces variables sont stockées et manipulées dans une structure + interne à Apache. Elles ne deviennent de véritables variables + d'environnement du système d'exploitation que lorsqu'elles sont mises à la + disposition de scripts CGI et de scripts inclus côté serveur (SSI). Si vous + souhaitez manipuler l'environnement du système d'exploitation sous lequel + le serveur s'exécute, vous devez utiliser les mécanismes standards de + manipulation de l'environnement fournis par l'interpréteur de commandes + (shell) de votre système d'exploitation.
+ Définition des variables d'environnement Utilisation des variables d'environnement Variables d'environnement à usage spécial Exemples| Modules Apparentés | Directives Apparentées |
|---|---|
La méthode la plus élémentaire pour définir une variable
+ d'environnement au niveau d'Apache consiste à utiliser la directive
+ inconditionnelle SetEnv. Les variables peuvent aussi être transmises depuis
+ l'environnement du shell à partir duquel le serveur a été démarré en
+ utilisant la directive
+ PassEnv.
Pour plus de souplesse, les directives fournies par le module
+ mod_setenvif permettent de définir les
+ variables d'environnement en tenant compte des caractéristiques
+ de chaque requête. Par exemple, une
+ variable pourrait n'être définie que lorsqu'un navigateur spécifique
+ (User-Agent) a généré la requête, ou seulement quand un en-tête
+ Referer particulier est présent. La directive
+ RewriteRule du module
+ mod_rewrite qui utilise l'option
+ [E=...] pour définir
+ les variables d'environnement apporte encore plus de souplesse.
Finalement, le module mod_unique_id définit la variable
+ d'environnement UNIQUE_ID pour chaque requête à une valeur
+ qui est garantie unique parmi "toutes" les requêtes sous des
+ conditions très spécifiques.
En plus de l'ensemble des variables d'environnement internes à la + configuration d'Apache et de celles transmises depuis le shell, + les scripts CGI et les pages SSI + se voient affectés un ensemble de variables + d'environnement contenant des méta-informations à propos de la requête + comme préconisé dans la + spécification + sur les CGIs.
+ + +suexec pour exécuter des
+ scripts CGI, l'environnement est nettoyé et réduit à un ensemble de
+ variables sûres avant l'exécution du script. La liste des
+ variables sûres est définie à la compilation dans
+ suexec.c.SetEnv s'exécute assez tard au
+ cours du traitement de la requête, ce qui signifie que des
+ directives telles que SetEnvIf et RewriteCond ne verront pas
+ les variables qu'elle aura définies.DirectoryIndex), ou lorsqu'il génère un
+ listing du contenu d'un répertoire via le module
+ mod_autoindex, la sous-requête n'hérite pas des
+ variables d'environnement spécifiques à la requête. En outre, à cause
+ des phases de l'API auxquelles mod_setenvif prend
+ part, les directives SetEnvIf ne sont pas évaluées
+ séparément dans la sous-requête.| Modules Apparentés | Directives Apparentées |
|---|---|
La communication d'informations aux scripts CGI constitue une des + principales utilisations des variables d'environnement. Comme indiqué + plus haut, l'environnement transmis aux scripts CGI comprend des + méta-informations standards à propos de la requête, en plus des + variables définies dans la configuration d'Apache. Pour plus de + détails, se référer au + tutoriel CGI.
+ + +Les documents inclus côté serveur (SSI) traités par le filtre
+ INCLUDES du module mod_include,
+ peuvent afficher les
+ variables d'environnement à l'aide de l'élément echo,
+ et peuvent utiliser des variables d'environnement dans les éléments
+ de contrôle de flux pour rendre certaines parties d'une page
+ conditionnelles en fonction des caractéristiques de la requête.
+ Apache fournit aussi les variables d'environnement CGI standards
+ aux pages SSI
+ comme indiqué plus haut. Pour plus de détails, se référer au
+ tutoriel SSI.
L'accès au serveur peut être contrôlé en fonction de la valeur de
+ variables d'environnement à l'aide des directives
+ allow from env= et deny from env=.
+ En association avec la directive
+ SetEnvIf, ceci confère une
+ grande souplesse au contrôle d'accès au serveur en fonction des
+ caractéristiques du client. Par exemple, vous pouvez utiliser ces
+ directives pour interdire l'accès depuis un navigateur particulier
+ (User-Agent).
+
Les variables d'environnement peuvent être enregistrées dans le
+ fichier de log des accès à l'aide de l'option %e de la
+ directive LogFormat.
+ En outre, la décision de tracer ou non les requêtes peut être prise
+ en fonction de l'état de variables d'environnement en utilisant la
+ forme conditionnelle de la directive
+ CustomLog. En
+ association avec la directive SetEnvIf, ceci confère une grande souplesse au contrôle
+ du traçage des requêtes. Par exemple, vous pouvez choisir de ne pas
+ tracer les requêtes pour des noms de fichiers se terminant par
+ gif, ou encore de ne tracer que les requêtes des clients
+ n'appartenant pas à votre sous-réseau.
La directive Header
+ peut se baser sur la présence ou l'absence d'une variable
+ d'environnement pour décider si un certain en-tête HTTP sera placé
+ dans la réponse au client. Ceci permet, par exemple, de n'envoyer un
+ certain en-tête de réponse que si un en-tête correspondant est présent
+ dans la requête du client.
Les filtres externes configurés par le module
+ mod_ext_filter à l'aide de la directive ExtFilterDefine peuvent être
+ activés de manière conditionnelle en fonction d'une variable
+ d'environnement à l'aide des options
+ disableenv= et enableenv=.
La forme %{ENV:variable} de
+ TestString dans la
+ directive RewriteCond
+ permet au moteur de réécriture du module
+ mod_rewrite de prendre des
+ décisions conditionnées par des variables d'environnement.
+ Notez que les variables accessibles dans
+ mod_rewrite sans le préfixe
+ ENV: ne sont pas de véritables variables
+ d'environnement. Ce sont plutôt des variables spécifiques à
+ mod_rewrite
+ qui ne sont pas accessibles pour les autres modules.
Des problèmes d'interopérabilité ont conduit à l'introduction de
+ mécanismes permettant de modifier le comportement d'Apache lorsqu'il
+ dialogue avec certains clients. Afin de rendre ces mécanismes aussi
+ souples que possible, ils sont invoqués en définissant des variables
+ d'environnement, en général à l'aide de la directive
+ BrowserMatch, bien que les
+ directives SetEnv et
+ PassEnv puissent aussi être
+ utilisées, par exemple.
Ceci force le traitement d'une requête comme une requête HTTP/1.0 + même si elle a été rédigée dans un langage plus récent.
+ + +Si le filtre DEFLATE est activé, cette variable
+ d'environnement ignorera les réglages accept-encoding de votre
+ navigateur et enverra une sortie compressée inconditionnellement.
Cette variable entraîne la suppression de tout champ
+ Vary des en-têtes de la réponse avant que cette dernière
+ soit renvoyée au client. Certains clients n'interprètent pas ce champ
+ correctement, et la définition de cette variable permet de contourner
+ ce problème, mais implique aussi la définition de
+ force-response-1.0.
Cette variable force une réponse en langage HTTP/1.0 aux clients + qui envoient des requêtes dans le même langage. Elle fut implémentée à + l'origine suite à des problèmes avec les mandataires d'AOL. Certains + clients en langage HTTP/1.0 ne réagissent pas correctement face à une + réponse en langage HTTP/1.1, et cette variable peut être utilisée pour + assurer l'interopérabilité avec eux.
+ + + +Positionnée à "1", cette variable désactive le filtre en sortie
+ DEFLATE fourni par le module mod_deflate pour les
+ types de contenu autres que text/html. Si vous préférez
+ utiliser des fichiers compressés statiquement,
+ mod_negotiation évalue aussi la variable (non
+ seulement pour gzip, mais aussi pour tous les encodages autres que
+ "identity").
Quand cette variable est définie, le filtre DEFLATE du
+ module mod_deflate est désactivé, et
+ mod_negotiation refusera de délivrer des ressources
+ encodées.
Disponible dans les versions 2.2.12 et ultérieures d'Apache
+ +Lorsque cette variable est définie,
+ mod_cache ne sauvegardera pas de réponse
+ susceptible d'être mise en cache. Cette variable d'environnement
+ n'a aucune incidence sur le fait qu'une réponse déjà enregistrée
+ dans la cache soit utilisée ou non pour la requête courante.
Quand cette variable est définie, la directive
+ KeepAlive est désactivée.
Cette variable modifie le comportement du module
+ mod_negotiation. Si elle contient un symbole de
+ langage (tel que en, ja
+ ou x-klingon), mod_negotiation essaie de
+ délivrer une variante dans ce langage. S'il n'existe pas de telle
+ variante, le processus normal de
+ négociation s'applique.
Cette variable force le serveur à être plus prudent lors de l'envoi + d'une redirection au client. Elle est en général utilisée quand un + client présente un problème connu avec les redirections. Elle fut + implémentée à l'origine suite a un problème rencontré avec le logiciel + WebFolders de Microsoft qui ne gère pas correctement les redirections + vers des ressources de type répertoire via des méthodes DAV.
+ + + +Disponible dans les versions postérieures à 2.0.54
+ +Quand Apache génère une redirection en réponse à une requête client, + la réponse inclut un texte destiné à être affiché au cas où le client ne + suivrait pas, ou ne pourrait pas suivre automatiquement la redirection. + Habituellement, Apache marque ce texte en accord avec le jeu de caractères + qu'il utilise, à savoir ISO-8859-1.
+Cependant, si la redirection fait référence à une page qui utilise un + jeu de caractères différent, certaines versions de navigateurs obsolètes + essaieront d'utiliser le jeu de caractères du texte de la redirection + plutôt que celui de la page réelle. + Ceci peut entraîner, par exemple, un rendu incorrect du Grec.
+Si cette variable d'environnement est définie, Apache omettra le jeu de + caractères pour le texte de la redirection, et les navigateurs obsolètes + précités utiliseront correctement celui de la page de destination.
+ +L'envoi de pages d'erreur sans spécifier un jeu de caractères peut + conduire à des attaques de type "cross-site-scripting" pour les + navigateurs qui ne respectent pas la spécification HTTP/1.1 (MSIE) et + tentent de déduire le jeu de caractères à partir du contenu. De tels + navigateurs peuvent être facilement trompés et utiliser le jeu de + caractères UTF-7 ; les contenus des données en entrée de type UTF-7 + (comme les URI de requête) ne seront alors plus protégés par les + mécanismes d'échappement usuels conçus pour prévenir les attaques + de type "cross-site-scripting".
+Ces directives modifient le comportement protocolaire du module
+ mod_proxy. Voir la documentation sur
+ mod_proxy et mod_proxy_http pour plus de détails.
Avec la version 2.4, Apache est plus strict avec la conversion
+ des en-têtes HTTP en variables d'environnement dans
+ mod_cgi et d'autres modules : dans les versions
+ précédentes, tout caractère invalide dans les noms d'en-têtes
+ était tout simplement remplacé par un caractère '_', ce qui
+ pouvait exposer à des attaques de type cross-site-scripting via
+ injection d'en-têtes (voir Bogues
+ du Web inhabituelles, planche 19/20).
Si vous devez supporter un client qui envoie des en-têtes non
+ conformes et si ceux-ci ne peuvent pas être corrigés, il existe
+ une solution de contournement simple mettant en jeu les modules
+ mod_setenvif et mod_headers,
+ et permettant de prendre en compte ces en-têtes :
# L'exemple suivant montre comment prendre en compte un en-tête+ + + + +
+# Accept_Encoding non conforme envoyé par un client. +# +SetEnvIfNoCase ^Accept.Encoding$ ^(.*)$ fix_accept_encoding=$1 +RequestHeader set Accept-Encoding %{fix_accept_encoding}e env=fix_accept_encoding
Les versions antérieures recommandaient l'ajout de ces lignes dans + httpd.conf pour tenir compte de problèmes connus avec certains clients. + Comme les clients concernés sont maintenant très peu utilisés, cet + ajout n'est pratiquement plus nécessaire.
+# +# The following directives modify normal HTTP response behavior. +# The first directive disables keepalive for Netscape 2.x and browsers that +# spoof it. There are known problems with these browser implementations. +# The second directive is for Microsoft Internet Explorer 4.0b2 +# which has a broken HTTP/1.1 implementation and does not properly +# support keepalive when it is used on 301 or 302 (redirect) responses. +# +BrowserMatch "Mozilla/2" nokeepalive +BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 + +# +# The following directive disables HTTP/1.1 responses to browsers which +# are in violation of the HTTP/1.0 spec by not being able to grok a +# basic 1.1 response. +# +BrowserMatch "RealPlayer 4\.0" force-response-1.0 +BrowserMatch "Java/1\.0" force-response-1.0 +BrowserMatch "JDK/1\.0" force-response-1.0+ + + +
Dans cet exemple, les requêtes pour des images n'apparaissent pas + dans le fichier de trace des accès. Il peut être facilement adapté pour + empêcher le traçage de répertoires particuliers, ou de requêtes + en provenance de certains hôtes.
+SetEnvIf Request_URI \.gif image-request +SetEnvIf Request_URI \.jpg image-request +SetEnvIf Request_URI \.png image-request +CustomLog logs/access_log common env=!image-request+ + + +
Cet exemple montre comment empêcher les utilisateurs ne faisant pas
+ partie de votre serveur d'utiliser des images de votre serveur comme
+ images en ligne dans leurs pages. Cette configuration n'est pas
+ recommandée, mais elle peut fonctionner dans des circonstances bien
+ définies. Nous supposons que toutes vos images sont enregistrées dans
+ un répertoire nommé /web/images.
SetEnvIf Referer "^http://www\.example\.com/" local_referal +# Autorise les navigateurs qui n'envoient aucune information de Referer +SetEnvIf Referer "^$" local_referal +<Directory "/web/images"> + Require env local_referal +</Directory>+ + +
Pour plus d'informations sur cette technique, voir le tutoriel sur + ServerWatch + "Keeping Your Images from Adorning Other Sites".
+ +Serveur HTTP Apache Version 2.4
+Historiquement, il existe de nombreuses variantes dans la syntaxe + des expressions permettant d'exprimer une condition dans les + différents modules du serveur HTTP Apache. À ce titre, des travaux sont + en cours pour n'utiliser qu'une seule variante nommée + ap_expr, pour toutes les directives de configuration. Ce + document décrit l'interpréteur d'expressions ap_expr. +
+Le type d'expression ap_expr est appelé à remplacer la
+ plupart des autres types d'expressions dans HTTPD. Par exemple, la
+ directive obsolète SSLRequire peut être remplacée par la
+ directive Require
+ expr.
+
Syntaxe en Forme de Backus-Naur Variables Opérateurs binaires Opérateurs unaires Fonctions Exemples d'expressions Autres Comparaison avec SSLRequire Historique de versionIf<If><ElseIf><Else>ErrorDocumentAliasScriptAliasRedirectAuthBasicFakeAuthFormLoginRequiredLocationAuthFormLoginSuccessLocationAuthFormLogoutLocationRewriteCondSetEnvIfExprHeaderRequestHeaderFilterProviderSSLRequireLogMessagemod_includeLa Forme de Backus-Naur
+ (souvent abrégée en BNF, de l'anglais Backus-Naur Form) est une notation permettant de décrire
+ les règles syntaxiques des langages de programmation. En
+ général, les expressions représentent des valeurs booléennes. Dans
+ ce cas, le point de départ de la BNF est expr.
+ Cependant, certaines directives comme LogMessage utilisent comme
+ paramètres des expressions qui représentent des chaînes de
+ caractères. Dans ce cas, le point de départ de la BNF est
+ string.
+
+expr ::= "true" | "false"
+ | "!" expr
+ | expr "&&" expr
+ | expr "||" expr
+ | "(" expr ")"
+ | comp
+
+comp ::= stringcomp
+ | integercomp
+ | unaryop word
+ | word binaryop word
+ | word "in" "{" wordlist "}"
+ | word "in" listfunction
+ | word "=~" regex
+ | word "!~" regex
+
+
+stringcomp ::= word "==" word
+ | word "!=" word
+ | word "<" word
+ | word "<=" word
+ | word ">" word
+ | word ">=" word
+
+integercomp ::= word "-eq" word | word "eq" word
+ | word "-ne" word | word "ne" word
+ | word "-lt" word | word "lt" word
+ | word "-le" word | word "le" word
+ | word "-gt" word | word "gt" word
+ | word "-ge" word | word "ge" word
+
+wordlist ::= word
+ | wordlist "," word
+
+word ::= word "." word
+ | digit
+ | "'" string "'"
+ | """ string """
+ | variable
+ | rebackref
+ | function
+
+string ::= stringpart
+ | string stringpart
+
+stringpart ::= cstring
+ | variable
+ | rebackref
+
+cstring ::= ...
+digit ::= [0-9]+
+
+variable ::= "%{" varname "}"
+ | "%{" funcname ":" funcargs "}"
+
+rebackref ::= "$" [0-9]
+
+function ::= funcname "(" word ")"
+
+listfunction ::= listfuncname "(" word ")"
+
+
+L'interpréteur d'expressions fournit plusieurs variables de la
+ forme %{HTTP_HOST}. Notez que la valeur d'une variable
+ peut dépendre de la phase du traitement de la requête au cours de
+ laquelle elle est évaluée. Par exemple, une expression utilisée dans
+ une directive <If > sera évaluée avant
+ la phase d'authentification. Par conséquent, la variable
+ %{REMOTE_USER} ne sera pas encore définie à ce stade.
Les variables suivantes contiennent la valeur de l'en-tête de
+ requête HTTP correspondant. La fonction
+ req permet d'extraire les valeurs des autres
+ en-têtes. L'utilisation de ces variables peut provoquer
+ l'ajout du nom d'en-tête correspondant à l'en-tête Vary de la
+ réponse HTTP, sauf spécification contraire pour la directive
+ qui accepte l'expression comme paramètre. La function req_novary permet de
+ modifier ce comportement.
| Nom |
|---|
HTTP_ACCEPT |
HTTP_COOKIE |
HTTP_FORWARDED |
HTTP_HOST |
HTTP_PROXY_CONNECTION |
HTTP_REFERER |
HTTP_USER_AGENT |
Autres variables liées aux requêtes
+ +| Nom | Description |
|---|---|
REQUEST_METHOD |
+ La méthode HTTP de la requête entrante (par exemple
+ GET) |
REQUEST_SCHEME |
+ Le protocole associé à l'URI de la requête |
REQUEST_URI |
+ La partie chemin de l'URI de la requête |
DOCUMENT_URI |
+ Idem REQUEST_URI |
REQUEST_FILENAME |
+ Le chemin complet dans le système de fichiers local du
+ fichier ou du script correspondant à la requête, si le serveur
+ l'a dèjà déterminé à l'instant où REQUEST_FILENAME
+ est référencée. Dans le cas contraire, comme dans un
+ contexte de serveur virtuel, même valeur que REQUEST_URI |
SCRIPT_FILENAME |
+ Identique à REQUEST_FILENAME |
LAST_MODIFIED |
+ La date et heure de dernière modification du fichier au
+ format 20101231235959, si elle est déjà connue du
+ serveur au moment où LAST_MODIFIED est référencé.
+ |
SCRIPT_USER |
+ Le nom d'utilisateur du propriétaire du script. |
SCRIPT_GROUP |
+ Le nom du groupe auquel appartient le script. |
PATH_INFO |
+ L'information relative au nom de chemin située en fin, voir
+ la directive AcceptPathInfo |
QUERY_STRING |
+ La chaîne de paramètres de la requête courante |
IS_SUBREQ |
+ "true" si la requête courante est une
+ sous-requête, "false" dans le cas contraire |
THE_REQUEST |
+ La requête complète (par exemple "GET /index.html
+ HTTP/1.1") |
REMOTE_ADDR |
+ L'adresse IP de l'hôte distant |
REMOTE_PORT |
+ Le port de l'hôte distant (versions 2.4.26 et supérieures) |
REMOTE_HOST |
+ Le nom d'hôte de l'hôte distant |
REMOTE_USER |
+ Le nom de l'utilisateur authentifié, s'il existe (non
+ disponible à l'intérieur d'un bloc <If>) |
REMOTE_IDENT |
+ Le nom de l'utilisateur défini par mod_ident |
SERVER_NAME |
+ La valeur de la directive ServerName du serveur virtuel courant |
SERVER_PORT |
+ Le port associé au serveur virtuel courant ; voir la
+ directive ServerName |
SERVER_ADMIN |
+ La valeur de la directive ServerAdmin du serveur virtuel courant |
SERVER_PROTOCOL |
+ Le protocole utilisé par la requête |
DOCUMENT_ROOT |
+ La valeur de la directive DocumentRoot du serveur virtuel
+ courant |
AUTH_TYPE |
+ La valeur de la directive AuthType (par exemple
+ "basic") |
CONTENT_TYPE |
+ Le type de contenu de la réponse (non
+ disponible à l'intérieur d'un bloc <If>) |
HANDLER |
+ Le nom du gestionnaire qui a + généré la réponse |
HTTP2 |
+ "on" si la requête utilise http/2,
+ "off" dans le cas contraire |
HTTPS |
+ "on" si la requête utilise https,
+ "off" dans le cas contraire |
IPV6 |
+ "on" si la connexion utilise IPv6,
+ "off" dans le cas contraire |
REQUEST_STATUS |
+ Le code d'erreur HTTP de la requête (non
+ disponible à l'intérieur d'un bloc <If>) |
REQUEST_LOG_ID |
+ L'identifiant du message d'erreur associé à la requête (voir
+ la directive ErrorLogFormat) |
CONN_LOG_ID |
+ L'identifiant du message d'erreur associé à la connexion
+ (voir la directive ErrorLogFormat) |
CONN_REMOTE_ADDR |
+ L'adresse IP du correspondant pour la connexion (voir le module
+ mod_remoteip) |
CONTEXT_PREFIX |
+ |
CONTEXT_DOCUMENT_ROOT |
+
Variables diverses
+ +| Nom | Description |
|---|---|
TIME_YEAR |
+ L'année courante (par exemple 2010) |
TIME_MON |
+ Le mois courant (01, ..., 12) |
TIME_DAY |
+ Le jour courant dans le mois (01, ...) |
TIME_HOUR |
+ Les heures de la date courante (00, ...,
+ 23) |
TIME_MIN |
+ Les minutes de la date courante |
TIME_SEC |
+ Les secondes de la date courante |
TIME_WDAY |
+ Le jour de la semaine (à partir de 0 pour
+ dimanche) |
TIME |
+ La date et heure au format 20101231235959 |
SERVER_SOFTWARE |
+ La chaîne contenant la version du serveur |
API_VERSION |
+ La date de la version de l'API (module magic number) |
Certains modules, comme mod_ssl, définissent des
+ variables supplémentaires.
À l'exception de quelques opérateurs de comparaison internes, les
+ opérateurs binaires sont de la forme
+ "-[a-zA-Z][a-zA-Z0-9_]+", autrement dit un signe moins
+ et au moins deux caractères. Le nom est insensible à la casse. Les
+ modules peuvent fournir des opérateurs binaires supplémentaires.
| Nom | Alternative | Description |
|---|---|---|
== |
+ = |
+ Egalité de chaînes |
!= |
+ + | Inégalité de chaînes |
< |
+ + | Chaîne inférieure à |
<= |
+ + | Chaîne inférieure ou égale à |
> |
+ + | Chaîne supérieure à |
>= |
+ + | Chaîne supérieure ou égale à |
=~ |
+ + | La chaîne correspond à l'expression rationnelle |
!~ |
+ + | La chaîne ne correspond pas à l'expression rationnelle |
-eq |
+ eq |
+ Egalité d'entiers |
-ne |
+ ne |
+ Inégalité d'entiers |
-lt |
+ lt |
+ Entier inférieur à |
-le |
+ le |
+ Entier inférieur ou égal à |
-gt |
+ gt |
+ Entier supérieur à |
-ge |
+ ge |
+ Entier supérieur ou égal à |
| Nom | Description |
|---|---|
-ipmatch |
+ L'adresse IP correspond à adresse/masque |
-strmatch |
+ la chaîne de gauche correspond au modèle constitué par la + chaîne de droite (contenant des caractères génériques *, ?, []) |
-strcmatch |
+ idem -strmatch, mais insensible à la casse |
-fnmatch |
+ idem -strmatch, mais les slashes ne sont pas
+ pris en compte par les caractères génériques |
Les opérateurs unaires acceptent un seul argument et sont
+ de la forme "-[a-zA-Z]",
+ autrement dit le signe moins et un caractère. Le nom est
+ sensible à la casse. Les modules peuvent fournir des opérateurs
+ unaires supplémentaires.
| Nom | Description | Remarques particulières |
|---|---|---|
-d |
+ L'argument est traité comme un nom de fichier. + Vrai si le fichier existe et correspond à un + répertoire | oui |
-e |
+ L'argument est traité comme un nom de fichier. Vrai si le + fichier (ou dir ou special) existe | oui |
-f |
+ L'argument est traité comme un nom de fichier. Vrai si le + fichier existe et correspond à un fichier + régulier | oui |
-s |
+ L'argument est traité comme un nom de fichier. Vrai si le + fichier existe et n'est pas vide | oui |
-L |
+ L'argument est traité comme un nom de fichier. Vrai si le + fichier existe et correspond à un lien + symbolique | oui |
-h |
+ L'argument est traité comme un nom de fichier. Vrai si le
+ fichier existe et correspond à un lien symbolique
+ (identique à -L) | oui |
-F |
+ Vrai si la chaîne correspond a un fichier valide, accessible + avec tous les contrôles d'accès configurés pour ce chemin. A + cette fin, une sous-requête effectue la vérification, et vous + devez utiliser ce drapeau avec soin car il peut impacter les + performances de votre serveur ! | |
-U |
+ Vrai si la chaîne correspond a une URL valide, accessible + avec tous les contrôles d'accès configurés pour ce chemin. A + cette fin, une sous-requête effectue la vérification, et vous + devez utiliser ce drapeau avec soin car il peut impacter les + performances de votre serveur ! | |
-A |
+ Alias pour -U | |
-n |
+ Vrai si la chaîne n'est pas vide | |
-z |
+ Vrai si la chaîne est vide | |
-T |
+ Faux si la chaîne est vide, "0",
+ "off", "false", ou "no"
+ (insensibilité à la casse). Vrai dans le cas contraire. | |
-R |
+ Idem "%{REMOTE_ADDR} -ipmatch ...", en plus
+ efficace
+ |
Les opérateurs marqués comme "restreints" ne sont pas disponibles
+ avec certains modules comme mod_include.
Normalement, les fonctions dont la valeur est une chaîne acceptent une chaîne + comme argument et renvoient une chaîne. Les noms de fonctions sont + insensibles à la casse. Les modules peuvent fournir des fonctions + supplémentaires.
+ +| Nom | Description | Notes particulières |
|---|---|---|
req, http |
+ Lit l'en-tête de requête HTTP ; les noms + d'en-tête correspondants peuvent être ajoutés + à l'en-tête Vary, + voir ci-dessous | |
req_novary |
+ Identique à req, mais aucun nom d'en-tête n'est
+ ajouté à l'en-tête Vary | |
resp |
+ Lit l'en-tête de réponse HTTP (La plupart des en-têtes de la réponse
+ ne seront pas encore définis pendant le traitement de la directive
+ <If>) | |
reqenv |
+ Recherche une variable d'environnement de requête (on
+ peut aussi utiliser le raccourci v).
+ |
+ ordonnancement |
osenv |
+ Recherche une variable d'environnement du système + d'exploitation | |
note |
+ Recherche une note de requête | ordonnancement |
env |
+ Renvoie le premier résultat positif de note,
+ reqenv, osenv | ordonnancement |
tolower |
+ Convertit une chaîne en minuscules | |
toupper |
+ Convertit une chaîne en majuscules | |
escape |
+ Echappe les caractères spéciaux en codage hexadécimal | |
unescape |
+ "Déséchappe" les chaînes codées + en hexadécimal, en ne gardant encodés que les slashes; renvoie la chaîne vide + si la séquence %00 est rencontrée | |
base64 |
+ Encode la chaîne en base64 | |
unbase64 |
+ Décode les chaînes codées en base64, renvoie une chaîne + tronquée si le caractère 0x00 est rencontré | |
md5 |
+ Génère un hash de la chaîne en utilisant MD5, puis code le + hash obtenu en hexadécimal | |
sha1 |
+ Génère un hash de la chaîne en utilisant SHA1, puis encode + le hash obtenu en hexadécimal | |
file |
+ Lit le contenu d'un fichier(fins de lignes incluses, si + elles existent) | limité |
filemod |
+ Renvoie la date de dernière modification d'un fichier (ou 0 si le + fichier n'existe pas ou n'est pas un fichier régulier) | limité |
filesize |
+ Renvoie la taille d'un fichier (ou 0 si le fichier n'existe + pas ou ne correspond pas à un fichier régulier) | limité |
Les fonctions marquées comme "limité" dans la dernière colonne ne sont
+ pas disponibles avec certains modules comme
+ mod_include.
Les fonctions marquées comme "ordonnancement" dans la dernière colonne
+ nécessitent une attention particulière pour l'ordonnancement des différents
+ composants du serveur, spécialement lorsque la fonction est utilisée au sein
+ d'une directive <If> qui est
+ évaluée relativement tôt.
If>, il est important de tenir
+ compte du moment où cette évaluation intervient dans le traitement de la
+ requête. Par exemple, toute directive définie en dehors d'un contexte de
+ serveur virtuel (directory, location, htaccess) aura peu de chance d'être
+ déjà exécutée. Ainsi la directive SetEnvIf est une directive qui s'exécute
+ avant cette évaluation.
+ reqenv est utilisé en dehors de la directive
+ <If>, l'évaluation survient en
+ général plus tard, mais le moment exact dépend de la directive dans laquelle
+ l'expression a été utilisée.
+ Lorsque les fonctions req ou http sont
+ utilisées, le nom d'en-tête sera automatiquement ajouté à l'en-tête
+ Vary de la réponse HTTP, sauf spécification contraire pour la
+ directive qui accepte l'expression comme paramètre. La
+ fonction req_novary permet d'empêcher l'ajout de noms
+ d'en-têtes à l'en-tête Vary.
En plus des fonctions dont la valeur est une chaîne, il existe
+ aussi des fonctions dont la valeur est une liste, qui acceptent une
+ chaîne comme argument, et renvoient une liste de mots, autrement dit
+ une liste de chaînes. La liste de mot peut être utilisée avec
+ l'opérateur spécial -in. Les noms de fonctions sont
+ insensibles à la casse. Les modules peuvent fournir des fonctions
+ supplémentaires.
Il n'existe pas de fonctions internes dont la valeur est une
+ liste. Le module mod_ssl fournit la fonction
+ PeerExtList. Voir la description de la directive
+ SSLRequire pour plus de
+ détails (notez que la fonction PeerExtList peut aussi
+ être utilisée en dehors de la directive SSLRequire).
Les exemples suivants montent comment utiliser les + expressions pour évaluer les requêtes :
+ +# Comparer le nom d'hôte avec example.com et rediriger vers
+# www.example.com si le nom d'hôte correspond
+<If "%{HTTP_HOST} == 'example.com'">
+ Redirect permanent "/" "http://www.example.com/"
+</If>
+
+# Forcer le type text/plain si un fichier fait l'objet d'une
+# requête dont la chaîne de paramètres contient 'forcetext'
+<If "%{QUERY_STRING} =~ /forcetext/">
+ ForceType text/plain
+</If>
+
+# N'autoriser l'accès à ce contenu que pendant les heures de
+# travail
+<Directory "/foo/bar/business">
+ Require expr %{TIME_HOUR} -gt 9 && %{TIME_HOUR} -lt 17
+</Directory>
+
+# Vérifie si un en-tête HTTP correspond à une des valeurs d'une liste
+<If "%{HTTP:X-example-header} in { 'foo', 'bar', 'baz' }">
+ La définition de l'en-tête correspond à une des valeurs recherchées
+</If>
+
+# Recherche la valeur d'une expression rationnelle dans une variable
+# d'environnement, et renvoie la négation du résultat.
+<If "! reqenv('REDIRECT_FOO') =~ /bar/">
+ La condition est vérifiée
+</If>
+
+# Vérifie le résultat de la recherche d'une correspondance d'URI dans un
+# contexte de répertoire avec l'option -f
+<Directory "/var/www">
+ AddEncoding x-gzip gz
+<If "-f '%{REQUEST_FILENAME}.unzipme' && ! %{HTTP:Accept-Encoding} =~ /gzip/">
+ SetOutputFilter INFLATE
+</If>
+</Directory>
+
+# Vérifie l'adresse IP du client
+<If "-R '192.168.1.0/24'">
+ Header set matched true
+</If>
+
+# Exemple de fonction dans un contexte booléen
+<If "md5('foo') == 'acbd18db4cc2f85cedef654fccc4a4d8'">
+ Header set checksum-matched true
+</If>
+
+# Function example in string context
+Header set foo-checksum "expr=%{md5:foo}"
+
+# L'exemple suivant retarde l'évaluation de la clause de condition par rapport à
+# <If>
+Header always set CustomHeader my-value "expr=%{REQUEST_URI} =~ m#^/special_path\.php$#"
+
+# Journalisation conditionnelle
+CustomLog logs/access-errors.log common "expr=%{REQUEST_STATUS} >= 400"
+CustomLog logs/access-errors-specific.log common "expr=%{REQUEST_STATUS} -in {'405','410'}"
+
+| Nom | Alternative | Description |
|---|---|---|
-in |
+ in |
+ chaîne contenue dans une liste de mots |
/regexp/ |
+ m#regexp# |
+ Expression rationnelle (la seconde forme permet de spécifier + des délimiteurs autres que /) |
/regexp/i |
+ m#regexp#i |
+ Expression rationnelle insensible à la casse |
$0 ... $9 |
+ + | Références arrières dans les expressions rationnelles |
Les chaînes $0 ... $9 permettent de
+ référencer les groupes de capture en provenance d'expressions
+ rationnelles précédemment exécutées et mises en correspondance avec
+ succès. Elles ne peuvent normalement être utilisées que dans la
+ même expression que celle mise en correspondance, mais certains
+ modules permettent de les utiliser de manière spéciale.
La syntaxe ap_expr consiste principalement en une
+ surcouche de la syntaxe de la directive obsolète SSLRequire. Vous pouvez consulter la
+ liste de leur différences dans la documentation de la directive
+ SSLRequire.
La fonction req_novary est
+ disponible à partir de la version 2.4.4 du serveur HTTP Apache.
Serveur HTTP Apache Version 2.4
+
Serveur HTTP Apache Version 2.4
+Ce document décrit l'utilisation des filtres avec Apache.
+ Le filtrage avec Apache 2 Filtrage intelligent Présentation des filtres en tant que service HTTP Utilisation des filtres| Modules Apparentés | Directives Apparentées |
|---|---|
La chaîne de filtrage est disponible depuis la version 2.0 d'Apache, +et permet aux applications de traiter les données en entrée et en sortie +d'une manière hautement flexible et configurable, quelle que soit la +provenance de ces données. Il est possible de pré-traiter les données +en entrée, et post-traiter les données en sortie, selon +vos souhaits. +Ces traitements sont tout à fait indépendants des traditionnelles phases +de traitement des requêtes.
+
+
+
Voici quelques exemples de filtrage avec la distribution standard d'Apache:
+mod_include, implémente les inclusions côté serveur.mod_ssl, implémente le cryptage SSL (https).mod_deflate, implémente la compression/décompression
+à la volée.mod_charset_lite, transcodage entre différents
+jeux de caractères.mod_ext_filter, utilisation d'un programme externe
+comme filtre.Apache utilise aussi plusieurs filtres en interne pour accomplir des tâches +comme le découpage des grosses requêtes (chunking) et la gestion des +requêtes portant sur une partie d'un fichier (byte-range).
+ +Un grand choix d'applications sont implémentées par des modules de filtrage +tiers disponibles à modules.apache.org entre autres. +En voici quelques exemples :
+ +
+
+
mod_filter, inclus dans les version 2.1 et supérieures
+d'Apache, permet de configurer la chaîne de filtrage dynamiquement
+à l'exécution.
+Ainsi par exemple, vous pouvez définir un proxy pour réécrire du code HTML
+avec un filtre HTML et traiter des images JPEG avec un filtre totalement
+séparé, bien que le proxy ne possède aucune information préliminaire
+sur ce que le serveur à l'origine des données à filtrer va envoyer.
+Ceci fonctionne grâce à l'utilisation d'un gestionnaire de filtre,
+qui distribue les tâches à différents fournisseurs de filtrage en fonction
+du contenu réel à filtrer à l'exécution. Tout filtre peut se voir soit
+inséré directement dans la chaîne et lancé inconditionnellement, soit
+utilisé comme un fournisseur de filtrage et inséré dynamiquement.
+Par exemple,
Les filtres permettent de traiter les requêtes des clients avant
+traitement par le serveur, ainsi que les contenus issus du serveur avant de les renvoyer
+au client. Le module mod_reflector permet aussi
+d'utiliser les filtres pour traiter les requêtes des clients avant de
+les renvoyer directement à ces derniers.
Le module mod_reflector reçoit les requêtes POST des
+clients, et en répercute le corps dans la requête POST constituant la
+réponse, lors de l'envoi de cette dernière au client en passant à travers la
+pile de filtres en sortie.
Cette technique peut être utilisée comme alternative à un service web
+s'exécutant à l'intérieur de la pile d'un serveur d'applications, où un
+filtre en sortie effectue la transformation requise sur le corps de la
+requête. Par exemple, on peut utiliser le module
+mod_deflate pour fournir un service général de
+compression ; un filtre de transformation d'images peut aussi se voir
+mué en service de transformation d'images.
Il y a deux manières d'utiliser le filtrage : Simple et Dynamique. +En général, vous utiliserez l'une ou l'autre méthode; le mélange des deux +peut avoir des conséquences inattendues (bien que le filtrage simple en entrée +puisse être associé sans problème avec le filtrage simple ou dynamique +en sortie).
+La méthode Simple est la seule permettant de configurer les filtres
+en entrée, et suffit pour les filtres en sortie pour lesquels vous avez besoin
+d'une chaîne de filtres statique.
+Les directives correspondantes sont
+ SetInputFilter,
+ SetOutputFilter,
+ AddInputFilter,
+ AddOutputFilter,
+ RemoveInputFilter, et
+ RemoveOutputFilter.
La méthode Dynamique permet une configuration dynamique des filtres en
+sortie à la fois statique et flexible, comme discuté dans la page
+mod_filter.
+Les directives correspondantes sont
+ FilterChain,
+ FilterDeclare, et
+ FilterProvider.
Une autre directive AddOutputFilterByType est encore supportée,
+mais obsolète. Utilisez la
+configuration dynamique à la place.
Serveur HTTP Apache Version 2.4
+Si vous ne connaissez rien au serveur HTTP Apache, ou même au +fonctionnement d'un site web, vous vous demandez probablement par où +commencer et quelles questions poser. Ce document vous permettra de +parcourir les bases du sujet.
+ Clients, serveurs et URLs Noms d'hôte et DNS Fichiers de configuration et directives Contenu du site web Fichiers journaux et résolution des problèmes Et maintenant, quelle est la suite des opérations ?
+Les adresses des pages web sur la Toile se présentent sous forme d'URLs
+- Uniform Resource Locators - qui comportent un protocole (par
+ exemple http), un nom de serveur (par exemple
+ www.apache.org), un chemin (par exemple
+ /docs/current/getting-started.html), et le cas échéant
+ une chaîne de requête (query string) (par exemple ?arg=value)
+ permettant de transmettre des informations supplémentaires au serveur.
+
Un client (par exemple un navigateur web) se connecte à un serveur +(par exemple votre serveur HTTP Apache) avec un protocole spécifique, et +effectue une requête pour une ressource en spécifiant +son chemin.
+ +Un chemin peut représenter plusieurs types de ressources sur le
+serveur. Ce peut être un fichier (comme
+getting-started.html), un gestionnaire (comme server-status), ou toute sorte de
+programme (comme index.php). Nous décrirons tout ceci plus
+en détails ci-dessous dans la section Contenu d'un
+site web.
+Le serveur envoie alors une réponse comportant un code +d'état, et éventuellement un corps de réponse. Le code d'état indique si +la requête a été traitée avec succès, ou dans la négative quel type +d'erreur a été rencontré. Le client est alors sensé savoir quoi faire de +la réponse. Vous pouvez vous familiariser avec les différents codes +d'état en consultant le Wiki du +serveur HTTP Apache.
+ +Les détails de la transaction, ainsi que les erreurs rencontrées, +sont enregistrés dans des fichiers journaux. Tout ceci est décrit en +détails ci-dessous dans la section Débogage et fichiers +journaux.
+ +Pour se connecter à un serveur, le client doit tout d'abord résoudre +le nom du serveur en adresse IP, cette dernière permettant de localiser +le serveur sur Internet. Ainsi, pour que votre serveur web soit +accessible, son nom doit être enregistré dans le DNS.
+ +Si vous ne savez pas comment effectuer cet enregistrement, vous +devrez contacter votre administrateur réseau ou votre fournisseur +d'accès à Internet afin qu'il effectue cette opération pour vous.
+ +Plusieurs noms d'hôte peuvent pointer vers la même adresse IP, et +plusieurs adresses IP peuvent être attachées au même serveur physique. +Vous pouvez ainsi héberger plusieurs serveurs web sur le même serveur +physique grâce au mécanisme des serveurs virtuels.
+ +Pour tester un serveur non encore accessible sur Internet, vous
+pouvez renseigner son nom d'hôte dans votre fichier hosts afin
+d'effectuer une résolution de nom locale. Par exemple, pour tester le
+serveur web www.example.com depuis le serveur physique qui
+l'héberge, vous pouvez ajouter la ligne suivante au fichier hosts de ce
+dernier :
+127.0.0.1 www.example.com
+
En général, le fichier hosts se trouve dans le répertoire
+/etc sur les systèmes de style Unix, ou
+C:\Windows\system32\drivers\etc sous Windows.
Vous trouverez plus de détails à propos du fichier hosts à Wikipedia.org/wiki/Hosts_(file), +et à propos du DNS à Wikipedia.org/wiki/Domain_Name_System.
+La configuration du serveur HTTP Apache s'effectue via de simples
+fichiers textes. Ces fichiers peuvent se trouver dans de nombreux
+endroits différents en fonction du mode d'installation du serveur. Vous
+trouverez les positions courantes de ces fichiers dans le wiki httpd.
+Si vous installez httpd depuis le code source, le répertoire par défaut
+des fichiers de configuration est /usr/local/apache2/conf.
+Le nom du fichier de configuration par défaut est en général
+httpd.conf, mais peut aussi varier en fonction des
+distributions tierces du serveur.
L'ensemble de la configuration est en général divisé en plusieurs
+fichiers afin d'en faciliter la gestion. Ces fichiers sont inclus dans
+le fichier de configuration principal via la directive Include. Les noms ou positions de ces fichiers
+ne sont pas figés et peuvent varier considérablement d'une distribution
+à l'autre. N'hésitez pas à les arranger et subdiviser selon
+vos goûts et besoins, quitte à en modifier
+l'organisation par défaut.
La configuration du serveur s'effectue via des directives de configuration que l'on +insère dans les fichiers de configuration. Une directive se compose d'un +mot-clé suivi d'un ou plusieurs arguments qui définissent sa valeur.
+ +La réponse à la question "Où dois-je placer cette directive
+?" dépend en général du niveau auquel cette directive doit être
+prise en compte. S'il s'agit du niveau global, elle doit être placée
+dans le fichier de configuration principal, et en dehors de toute
+section <Directory>, <Location>, <VirtualHost>, ou de toute autre section. Si
+par exemple elle ne doit s'appliquer qu'à un répertoire particulier,
+elle doit être placée dans la section <Directory> qui fait référence à ce répertoire.
+Voir la documentation sur les Sections de
+configuration pour plus de détails.
En complément des fichiers de configuration principaux, certaines
+directives peuvent être insérées dans des fichiers
+.htaccess que l'on place directement dans le répertoire
+concerné. Les fichiers .htaccess sont essentiellement
+destinés aux personnes qui n'ont pas accès aux fichiers de configuration
+du serveur. Vous trouverez plus de détails à propos des fichiers
+.htaccess dans ce .htaccesshowto.
Si le contenu du site web peut se présenter sous de nombreuses +formes, il peut en général être scindé en deux formes principales : les +contenus statiques et les contenus dynamiques.
+ +Les contenus statiques sont par exemple les fichiers HTML, les
+images, les fichiers CSS et tout autre fichier résidant dans le système
+de fichiers. La directive DocumentRoot permet de définir la position
+dans l'arborescence du site où vous devez placer ces fichiers. Cette
+directive peut être définie au niveau global, ou au niveau de chaque
+serveur virtuel. Vous pouvez consulter vos fichiers de configuration
+pour vérifier la manière dont cette directive est définie pour votre
+serveur.
En général, et si aucun nom de fichier n'est spécifié dans la
+requête, c'est une page de nom index.html qui sera
+renvoyée. Par exemple, si la directive DocumentRoot est
+définie à /var/www/html, et si une requête est effectuée
+pour l'adresse http://www.example.com/work/, c'est le
+fichier /var/www/html/work/index.html qui sera envoyé au
+client par le serveur.
Un contenu dynamique est un contenu qui est généré au moment du +traitement de la requête, et qui peut différer d'une requête à l'autre. +Ces contenus dynamiques peuvent être générés de nombreuses manières par +l'intermédiaire de gestionnaires de contenu +ou "handlers". Il est aussi possible de créer des programmes CGI pour générer le contenu de +votre site.
+ +Enfin, on peut utiliser des modules tiers comme mod_php pour écrire +du code permettant d'effectuer de nombreuses choses. De nombreuses +applications tierces écrites à partir de divers langages ou outils sont +disponibles en téléchargement et peuvent être installées sur votre +serveur HTTP Apache. Le support de ces applications dépasse le sujet de +ce document, et nous vous invitons à consulter le site de leur éditeur +pour accéder à leur documentation.
+En tant qu'administrateur d'un serveur HTTP Apache, vos sources +d'informations principales sont les fichiers journaux, et en particulier +le journal des erreurs. Toute tentative de résolution d'un problème sans +consulter le journal des erreurs revient à conduire les yeux fermés.
+ +La position dans le système de fichiers du journal des erreurs est
+spécifiée par la directive ErrorLog
+qui peut être définie au niveau global, ou au niveau de chaque serveur
+virtuel. Chaque entrée du journal des erreurs vous informe sur la nature
+des problèmes et le moment de leur survenue. En outre, elle vous indique
+souvent comment résoudre le problème. Chaque message d'erreur contient
+un code d'erreur que vous pouvez utiliser pour effectuer une recherche
+en ligne afin d'obtenir une description plus détaillée de la manière de
+résoudre le problème. Vous pouvez aussi configurer votre journal des
+erreurs de manière à ce qu'il enregistre un identifiant d'erreur que
+vous pourrez ensuite utiliser pour effectuer une corrélation avec le
+journal des accès afin de déterminer quelle requête est à l'origine de
+l'erreur.
Vous trouverez plus de détails à ce sujet dans la Documentation sur la journalisation.
+La question des prérequis étant réglée, il est temps de passer aux +choses sérieuses.
+ +Ce document ne couvre que les notions de base. Nous espérons qu'il +vous permettra de mettre le pied à l'étrier, mais il y a encore de +nombreuses choses que vous devez savoir.
+ + + +Serveur HTTP Apache Version 2.4
+Ce glossaire définit la terminologie courante relative à Apache en + particulier, et aux serveurs web en général. Vous trouverez plus + d'informations sur chaque concept dans les liens fournis.
+tar.
+ Les distributions d'Apache sont stockées dans des Archives Tar compressées
+ ou en utilisant pkzip.
+ DirectoryIndex,
+ les modules mod_autoindex et
+ mod_include utilisent cette API.
+ /images/.*(jpg|gif)$". Lorsque l'on utilise des
+ expressions rationnelles pour la substitution de chaînes, les
+ variables spéciales $1 ... $9 contiennent des références arrières
+ vers les parties regroupées (entre parenthèses) de l'expression
+ qui correspond. La variable spéciale $0 contient une référence
+ arrière vers l'ensemble de l'expression qui correspond. Pour
+ insérer un caractère littéral "dollar" dans la chaîne de
+ remplacement, il faut l'échapper avec un anti-slash. Pour des
+ raisons historiques, la variable & peut être utilisée en tant
+ qu'alias de $0 dans certains cas, mais ceci n'est plus possible
+ depuis la version 2.3.6. Apache utilise les Expressions
+ Rationnelles Compatibles avec Perl fournies par la librairie PCRE. Vous trouverez plus
+ d'information à propos de la syntaxe des expressions rationnelles
+ PCRE sur ce site, ou dans le Wikipedia de la PCRE.
+ INCLUDES
+ traite les documents pour les
+ Server Side Includes (Inclusions côté Serveur)
+ .cgi-script désigne les fichiers qui doivent être traités
+ comme CGIs./usr/local/apache2/conf/httpd.conf, mais ceci peut être
+ changé en utilisant des options de compilation ou d'exécution.http ou
+ https, un nom d'hôte, et un chemin. Une URL pour cette page
+ pourrait être
+ http://httpd.apache.org/docs/2.4/glossary.html.
+ GET, POST,
+ et PUT.
+ httpd sont appelés modules statiques, alors
+ que les modules qui existent séparément et peuvent être chargés
+ optionnellement à l'exécution sont appelés
+ modules dynamiques ou DSOs.
+ Les modules qui sont inclus par défaut sont appelés
+ modules de base. De nombreux modules disponibles pour Apache
+ ne se trouvent pas dans l'archive
+ du Serveur HTTP Apache . Il sont appelés
+ modules tiers.www est un nom d'hôte, example.com est un nom
+ de domaine, et www.example.com est un nom de domaine
+ entièrement qualifié.
+ httpd et qui peuvent être
+ chargés à la demande.apxs
+ text/html,
+ image/gif, et application/octet-stream. Dans
+ HTTP, le type MIME est transmis dans l'
+ en-tête Content-Type.Serveur HTTP Apache Version 2.4
+Ce document décrit l'utilisation des gestionnaires d'Apache (handlers).
+| Modules Apparentés | Directives Apparentées |
|---|---|
Un "gestionnaire" est une représentation interne à Apache de l'action + qui doit être entreprise quand un fichier est appelé. En général, les + fichiers ont des gestionnaires implicites, basés sur le type du fichier. + Normalement, tous les fichiers sont traités simplement par le serveur, + mais certains types de fichiers sont "gérés" séparément.
+ +Les gestionnaires peuvent aussi être configurés explicitement, + soit en fonction des extensions des noms de fichier, soit en fonction + du chemin du fichier, + sans faire référence au type de fichier. Ceci a le double avantage d'être + une solution plus élégante, et aussi d'autoriser à associer à la fois + un type et un gestionnaire avec un fichier. (Voir aussi Fichiers avec extensions + multiples.)
+ +Les gestionnaires peuvent être soit partie intégrante
+ du serveur ou inclus dans un module, soit ajoutés à l'aide de la directive
+ Action. Les gestionnaires
+ intégrés dans la distribution standard se présentent comme suit :
default_handler(), qui est le gestionnaire utilisé par
+ défaut pour traiter les contenus statiques. (core)mod_asis)mod_cgi)mod_imagemap)mod_info)mod_status)mod_negotiation)Les directives suivantes vont faire en sorte que les requêtes pour
+ des fichiers possédant une extension html déclenchent
+ l'exécution du script CGI footer.pl.
Action add-footer /cgi-bin/footer.pl +AddHandler add-footer .html+ + +
À ce moment-là, le script CGI se charge d'envoyer le document
+ initialement demandé (référencé par la variable d'environnement
+ PATH_TRANSLATED) et d'effectuer tous ajout ou modification
+ voulus.
Les directives suivantes vont activer le gestionnaire
+ send-as-is, qui est utilisé pour les fichiers qui possèdent
+ leurs propres en-têtes HTTP. Tous les fichiers situés dans le répertoire
+ /web/htdocs/asis/ seront traités par le gestionnaire
+ send-as-is, sans tenir compte de l'extension
+ de leur nom de fichier.
<Directory "/web/htdocs/asis"> + SetHandler send-as-is +</Directory>+ + + +
Pour implémenter la fonctionnalité des gestionnaires, l'
+ API Apache a fait l'objet d'un ajout
+ que vous pourriez être amené à utiliser.
+
+ Plus précisément, un nouvel enregistrement a été ajouté à la structure
+ request_rec :
char *handler+ + +
Si vous voulez que votre module déclenche l'utilisation d'un
+ gestionnaire, il vous suffit de définir r->handler avec
+ le nom du gestionnaire à n'importe quel moment avant l'étape
+ invoke_handler
+ de la requête. Les gestionnaires sont implémentés comme auparavant,
+ quoique l'on utilise le nom du gestionnaire à la place d'un type
+ de contenu. Bien que ce ne soit pas obligatoire, la convention de nommage
+ des gestionnaires stipule l'utilisation d'un mot composé séparé par des
+ tirets, sans slashes, afin de ne pas interférer avec l'espace de nommage
+ des types de média.
Serveur HTTP Apache Version 2.4
+Le contrôle d'accès fait référence à tout concept de contrôle + d'accès à une ressource quelconque. Il est distinct du processus d'authentification et d'autorisation.
+
Modules et directives concernés Contrôle d'accès en fonction de l'hôte du
+client Contrôle d'accès en fonction de variables
+arbitraires Utilisation de mod_rewrite pour le contrôle
+d'accès Informations complémentaires
Plusieurs modules peuvent intervenir dans le contrôle d'accès.
+ Les plus importants sont mod_authz_core et
+ mod_authz_host. Ce document illustre aussi comment
+ utiliser mod_rewrite pour le contrôle
+ d'accès.
+ Si vous souhaitez restreindre l'accès à certaines parties de votre
+ site web en fonction de l'addresse de l'hôte de vos visiteurs, le
+ plus simple pour y parvenir consiste à utiliser le module
+ mod_authz_host.
+
La directive Require permet d'accorder ou
+ d'interdire l'accès à certaines ressources de différentes manières.
+ Ces critères d'accès, en conjonction avec les directives RequireAll, RequireAny, et RequireNone, peuvent être
+ combinés d'une manière suffisamment complexe pour
+ satisfaire votre politique de contrôle d'accès.
+ Les directives Allow, Deny, et Order fournies par le module
+ mod_access_compat sont obsolètes, et sont appelées à
+ disparaître dans les versions futures. Il est donc déconseillé de
+ les utiliser, et de se fier aux tutoriels qui recommandent leur
+ utilisation.
+
Les directives Require s'utilisent comme suit :
+ +Require host address +Require ip ip.address+ + +
Dans la première forme, nom-hôte est un nom de domaine + pleinement qualifié (fqdn), ou un nom de domaine partiel ; vous + pouvez spécifier plusieurs noms de domaines, si vous le désirez.
+ +Dans la seconde forme, adresse-ip est une adresse IP + complète, une adresse IP partielle, une paire réseau/masque de + sous-réseau ou une spécification CIDR de la forme réseau/nnn. Il est + possible de spécifier des adresses IPv4 ou IPv6.
+ +Voir la + documentation de mod_authz_host pour d'autres exemples de cette + syntaxe.
+ +Vous pouvez insérer le mot-clé not pour inverser un
+ critère particulier. Notez que le mot not étant la
+ négation d'une valeur, il ne peut pas être utilisé pour autoriser
+ ou interdire une requête, car non vrai ne
+ sera pas interpreté par httpd comme faux. Ainsi, pour interdire la
+ visite d'une page à l'aide d'une négation, le bloc doit contenir un
+ élément évalué à vrai ou faux.
+ Par exemple, si quelqu'un est en train d'inonder
+ votre forum de messages indésirables, vous pouvez ajouter cette ligne pour lui refuser
+ l'accès :
<RequireAll> + Require all granted + Require not ip 10.252.46.165 +</RequireAll>+ + +
Les visiteurs possédant cette adresse (10.252.46.165) ne pourront pas voir le
+ contenu concerné par cette directive. Si vous voulez interdire
+ l'accès à une machine en fonction de son nom, vous pouvez ajouter
+ ceci :
Require not host host.example.com ++ + +
Et si vous voulez interdire l'accès à un domaine particulier, + vous pouvez spécifier des adresses IP partielles ou des noms de + domaine, comme ceci :
+ +Require not ip 192.168.205 +Require not host phishers.example.com moreidiots.example +Require not host gov+ + +
Les directives RequireAll, RequireAny, et RequireNone permettent également de préciser des
+ critères d'accès plus complexes.
Vous pouvez accorder ou refuser l'accès en fonction de variables
+ d'environnement arbitraires ou de valeurs d'en-têtes de la requête
+ en utilisant la directive <If>. Par exemple, pour interdire l'accès en
+ fonction du user-agent (le type de navigateur), vous pouvez
+ spécifier ceci :
<If "%{HTTP_USER_AGENT} == 'BadBot'">
+ Require all denied
+</If>
+
+
+ La syntaxe expr de la directive Require permet de réécrire
+ l'exemple précédent de la manière suivante :
Require expr %{HTTP_USER_AGENT} != 'BadBot'
+
+
+ Contrôler l'accès en fonction de l'en-tête
+ User-Agent n'est pas une technique fiable, car cet
+ en-tête peut être défini à une valeur quelconque, selon le bon
+ vouloir de l'utilisateur.
Voir le document à propos des expressions pour une description plus + approfondie des syntaxes d'expressions et des variables disponibles.
+ +Le drapeau [F] de la directive RewriteRule permet d'envoyer une
+ réponse de type 403 Forbidden. Il vous permet donc d'interdire
+ l'accès à une ressource en fonction d'un critère arbitraire.
Par exemple, pour bloquer l'accès à une ressources entre 20h et
+ 7h du matin, vous pouvez utiliser mod_rewrite :
RewriteEngine On
+RewriteCond "%{TIME_HOUR}" ">=20" [OR]
+RewriteCond "%{TIME_HOUR}" "<07"
+RewriteRule "^/fridge" "-" [F]
+
+
+ Toute requête arrivant après 20h ou avant 7h du matin provoquera + l'envoi d'une réponse de type 403 Forbidden. Vous pouvez utiliser + cette technique pour vérifier toutes sortes de critères. En outre, + si vous le préférez, vous pouvez rediriger ou réécrire la requête.
+ +Notez que la directive <If>, introduite à partir de la version 2.4,
+ permet de remplacer le module mod_rewrite dans de
+ nombreuses situations où il était traditionnellement utilisé, et
+ il sera probablement préférable pour vous de tenter de l'utiliser
+ avant de vous tourner vers mod_rewrite.
Le moteur d'expressions vous fournit + une grande puissance d'action en fonction de variables du serveur + arbitraires, et il vous est conseillé de consulter le document + correspondant pour plus de détails.
+ +De même, vous devez lire la documentation du module
+ mod_authz_core pour des exemples de combinaison de
+ critères d'accès multiples, et en particulier la manière dont ces
+ derniers interagissent.
Voir aussi le How-To Authentification and + autorisation.
+Serveur HTTP Apache Version 2.4
+L'authentification est un processus qui vous permet de vérifier + qu'une personne est bien celle qu'elle prétend être. L'autorisation + est un processus qui permet à une personne d'aller là où elle veut + aller, ou d'obtenir les informations qu'elle désire.
+ +Pour le contrôle d'accès en général, voir le How-To Contrôle d'accès.
+ Modules et directives concernés Introduction Les prérequis Mise en oeuvre Autorisation d'accès à
+plusieurs personnes Problèmes possibles Autre méthode de stockage des mots de
+passe Utilisation de plusieurs fournisseurs
+d'authentification Pour aller plus loin qu'une simple
+autorisation Mise en cache de l'authentification Pour aller plus loin . . .Trois groupes de modules sont concernés par le processus +d'authentification et d'autorisation. Vous devrez utiliser au moins un +module de chaque groupe.
+ +AuthType)
+
+ AuthBasicProvider et AuthDigestProvider)
+
+
+ Require)
+
+ On peut aussi ajouter mod_authn_core et
+ mod_authz_core. Ces modules implémentent des
+ directives générales qui opèrent au dessus de tous les modules
+ d'authentification.
Le module mod_authnz_ldap est un fournisseur
+ d'authentification et d'autorisation. Le module
+ mod_authz_host fournit une autorisation et un
+ contrôle d'accès basés sur le nom du serveur, l'adresse IP ou
+ certaines caractéristiques de la requête, mais ne fait pas partie du
+ système fournisseur d'authentification. Le module
+ mod_access_compat a été créé à des fins de
+ compatibilité ascendante avec mod_access.
Vous devriez aussi jeter un coup d'oeil au manuel de recettes de Contrôle d'accès, qui décrit les différentes + méthodes de contrôle d'accès à votre serveur.
+ +Si votre site web contient des informations sensibles ou + destinées seulement à un groupe de personnes restreint, les + techniques exposées dans cet article vont vous aider à vous assurer + que les personnes qui ont accès à ces pages sont bien celles + auxquelles vous avez donné l'autorisation d'accès.
+ +Cet article décrit les méthodes "standards" de protection de + parties de votre site web que la plupart d'entre vous sont appelés à + utiliser.
+ +Si vos données ont un réel besoin de sécurisation, prévoyez
+ l'utilisation de mod_ssl en plus de toute méthode
+ d'authentification.
Les directives décrites dans cet article devront être insérées
+ soit au niveau de la configuration de votre serveur principal (en
+ général dans une section <Directory>), soit au niveau de la
+ configuration des répertoires (fichiers .htaccess)
Si vous envisagez l'utilisation de fichiers
+ .htaccess, la configuration de votre serveur devra
+ permettre l'ajout de directives d'authentification dans ces
+ fichiers. Pour ce faire, on utilise la directive AllowOverride, qui spécifie quelles
+ directives pourront éventuellement contenir les fichiers de
+ configuration de niveau répertoire.
Comme il est ici question d'authentification, vous aurez besoin
+ d'une directive AllowOverride
+ du style :
AllowOverride AuthConfig+ + +
Si vous avez l'intention d'ajouter les directives directement + dans le fichier de configuration principal, vous devrez bien entendu + posséder les droits en écriture sur ce fichier.
+ +Vous devrez aussi connaître un tant soit peu la structure des + répertoires de votre serveur, ne serait-ce que pour savoir où se + trouvent certains fichiers. Cela ne devrait pas présenter de grandes + difficultés, et nous essaierons de clarifier tout ça lorsque le besoin + s'en fera sentir.
+ +Enfin, vous devrez vous assurer que les modules
+ mod_authn_core et mod_authz_core
+ ont été soit compilés avec le binaire httpd, soit chargés par le
+ fichier de configuration httpd.conf. Ces deux modules fournissent
+ des directives générales et des fonctionnalités qui sont critiques
+ quant à la configuration et l'utilisation de l'authentification et
+ de l'autorisation au sein du serveur web.
Nous décrivons ici les bases de la protection par mot de passe + d'un répertoire de votre serveur.
+ +Vous devez en premier lieu créer un fichier de mots de passe. La + méthode exacte selon laquelle vous allez créer ce fichier va varier + en fonction du fournisseur d'authentification choisi. Mais nous + entrerons dans les détails plus loin, et pour le moment, nous nous + contenterons d'un fichier de mots de passe en mode texte.
+ +Ce fichier doit être enregistré à un endroit non accessible
+ depuis le web, de façon à ce que les clients ne puissent pas le
+ télécharger. Par exemple, si vos documents sont servis à partir de
+ /usr/local/apache/htdocs, vous pouvez enregistrer le
+ fichier des mots de passe dans
+ /usr/local/apache/passwd.
L'utilitaire htpasswd fourni avec Apache
+ permet de créer ce fichier. Vous le trouverez dans le répertoire
+ bin de votre installation d'Apache. Si vous avez
+ installé Apache à partir d'un paquetage tiers, il sera probablement
+ dans le chemin par défaut de vos exécutables.
Pour créer le fichier, tapez :
+ +
+ htpasswd -c /usr/local/apache/passwd/passwords rbowen
+
htpasswd vous demandera d'entrer le mot de
+ passe, et de le retaper pour confirmation :
+ # htpasswd -c /usr/local/apache/passwd/passwords rbowen
+ New password: mot-de-passe
+ Re-type new password: mot-de-passe
+ Adding password for user rbowen
+
Si htpasswd n'est pas dans le chemin par
+ défaut de vos exécutables, vous devrez bien entendu entrer le chemin
+ complet du fichier. Dans le cas d'une installation par défaut, il se
+ trouve à /usr/local/apache2/bin/htpasswd.
Ensuite, vous allez devoir configurer le serveur de façon à ce
+ qu'il demande un mot de passe et lui préciser quels utilisateurs ont
+ l'autorisation d'accès. Pour ce faire, vous pouvez soit éditer le
+ fichier httpd.conf, soit utiliser un fichier
+ .htaccess. Par exemple, si vous voulez protéger le
+ répertoire /usr/local/apache/htdocs/secret, vous pouvez
+ utiliser les directives suivantes, soit dans le fichier
+ /usr/local/apache/htdocs/secret/.htaccess, soit dans le
+ fichier httpd.conf à l'intérieur d'une section <Directory
+ "/usr/local/apache/htdocs/secret"> :
AuthType Basic +AuthName "Restricted Files" +# (Following line optional) +AuthBasicProvider file +AuthUserFile "/usr/local/apache/passwd/passwords" +Require user rbowen+ + +
Examinons ces directives une à une. La directive AuthType définit la méthode
+ utilisée pour authentifier l'utilisateur. La méthode la plus
+ courante est Basic, et elle est implémentée par
+ mod_auth_basic. Il faut cependant garder à l'esprit
+ que l'authentification Basic transmet le mot de passe depuis le
+ client vers le serveur en clair. Cette méthode ne devra donc pas
+ être utilisée pour la transmission de données hautement sensibles si
+ elle n'est pas associée au module mod_ssl. Apache
+ supporte une autre méthode d'authentification : AuthType
+ Digest. Cette méthode est implémentée par le module mod_auth_digest et a été conçue pour
+ améliorer la sécurité. Ce but n'a cependant pas été atteint et il est préférable
+ de chiffrer la connexion avec mod_ssl.
La directive AuthName définit
+ l'Identificateur (Realm) à utiliser avec
+ l'authentification. L'identificateur possède deux fonctions. Tout
+ d'abord, le client présente en général cette information à
+ l'utilisateur dans le cadre de la boîte de dialogue de mot de passe.
+ Ensuite, le client l'utilise pour déterminer quel mot de passe
+ envoyer pour une zone authentifiée donnée.
Ainsi par exemple, une fois un client authentifié dans la zone
+ "Fichiers réservés", il soumettra à nouveau
+ automatiquement le même mot de passe pour toute zone du même serveur
+ marquée de l'identificateur "Fichiers réservés". De
+ cette façon, vous pouvez éviter à un utilisateur d'avoir à saisir
+ plusieurs fois le même mot de passe en faisant partager le même
+ identificateur entre plusieurs zones réservées. Bien entendu et pour
+ des raisons de sécurité, le client devra redemander le mot
+ de passe chaque fois que le nom d'hôte du serveur sera modifié.
La directive AuthBasicProvider est, dans ce
+ cas, facultative, car file est la valeur par défaut
+ pour cette directive. Par contre, cette directive sera obligatoire
+ si vous utilisez une autre source d'authentification comme
+ mod_authn_dbm ou
+ mod_authn_dbd.
La directive AuthUserFile définit le chemin
+ du fichier de mots de passe que nous venons de créer avec
+ htpasswd. Si vous possédez un grand nombre
+ d'utilisateurs, la durée de la recherche dans un fichier texte pour
+ authentifier un utilisateur à chaque requête va augmenter
+ rapidement, et pour pallier cet inconvénient, Apache peut aussi
+ stocker les données relatives aux
+ utilisateurs dans des bases de données rapides. Le module
+ mod_authn_dbm fournit la directive AuthDBMUserFile. Les programmes dbmmanage et htdbm permettent de
+ créer et manipuler ces fichiers. Vous
+ trouverez de nombreuses options d'autres types d'authentification
+ fournies par des modules tiers dans la Base de données des modules
+ d'Apache.
Enfin, la directive Require implémente la partie
+ autorisation du processus en définissant l'utilisateur autorisé à
+ accéder à cette zone du serveur. Dans la section suivante, nous
+ décrirons les différentes méthodes d'utilisation de la directive
+ Require.
Les directives ci-dessus n'autorisent qu'une personne (quelqu'un
+ possédant le nom d'utilisateur rbowen) à accéder au
+ répertoire. Dans la plupart des cas, vous devrez autoriser
+ l'accès à plusieurs personnes. C'est ici
+ qu'intervient la directive AuthGroupFile.
Si vous voulez autoriser l'accès à plusieurs personnes, vous + devez créer un fichier de groupes qui associe des noms de groupes + avec une liste d'utilisateurs de ce groupe. Le format de ce fichier + est très simple, et vous pouvez le créer avec votre éditeur favori. + Son contenu se présente comme suit :
+ +
+ Nom-de-groupe: rbowen dpitts sungo rshersey
+
Il s'agit simplement une liste des membres du groupe sous la + forme d'une ligne séparée par des espaces.
+ +Pour ajouter un utilisateur à votre fichier de mots de passe + préexistant, entrez :
+ +
+ htpasswd /usr/local/apache/passwd/passwords dpitts
+
Vous obtiendrez le même effet qu'auparavant, mais le mot de passe
+ sera ajouté au fichier, plutôt que d'en créer un nouveau (C'est le
+ drapeau -c qui permet de créer un nouveau fichier de
+ mots de passe)..
Maintenant, vous devez modifier votre fichier
+ .htaccess ou la section <Directory> comme suit :
AuthType Basic +AuthName "By Invitation Only" +# Optional line: +AuthBasicProvider file +AuthUserFile "/usr/local/apache/passwd/passwords" +AuthGroupFile "/usr/local/apache/passwd/groups" +Require group GroupName+ + +
Maintenant, quiconque appartient au groupe
+ Nom-de-groupe, et possède une entrée dans le fichier
+ password pourra accéder au répertoire s'il tape le bon
+ mot de passe.
Il existe une autre méthode moins contraignante pour autoriser + l'accès à plusieurs personnes. Plutôt que de créer un fichier de + groupes, il vous suffit d'ajouter la directive suivante :
+ +Require valid-user+ + +
Le remplacement de la ligne Require user rbowen par
+ la ligne Require valid-user autorisera l'accès à
+ quiconque possédant une entrée dans le fichier password, et ayant
+ tapé le bon mot de passe.
L'authentification Basic est spécifiée d'une telle manière que + vos nom d'utilisateur et mot de passe doivent être vérifiés chaque + fois que vous demandez un document au serveur, et ceci même si vous + rechargez la même page, et pour chaque image contenue dans la page + (si elles sont situées dans un répertoire protégé). Comme vous + pouvez l'imaginer, ceci ralentit un peu le fonctionnement. La mesure + dans laquelle le fonctionnement est ralenti est proportionnelle à la + taille du fichier des mots de passe, car ce dernier doit être ouvert + et la liste des utilisateurs parcourue jusqu'à ce que votre nom soit + trouvé, et ceci chaque fois qu'une page est chargée.
+ +En conséquence, ce ralentissement impose une limite pratique au + nombre d'utilisateurs que vous pouvez enregistrer dans un fichier de + mots de passe. Cette limite va varier en fonction des performances + de votre serveur, mais vous commencerez à remarquer un + ralentissement lorsque vous atteindrez quelques centaines + d'utilisateurs, et serez alors appelés à utiliser une méthode + d'authentification différente.
+Suite au problème évoqué précédemment et induit par le stockage + des mots de passe dans un fichier texte, vous pouvez être appelé à + stocker vos mots de passe d'une autre manière, par exemple dans une + base de données.
+ +Pour y parvenir, on peut utiliser les modules
+ mod_authn_dbm ou mod_authn_dbd.
+ Vous pouvez choisir comme format de stockage dbm ou
+ dbd à la place de file pour la directive
+ AuthBasicProvider.
Par exemple, pour sélectionner un fichier dbm à la place d'un + fichier texte :
+ +<Directory "/www/docs/private"> + + AuthName "Private" + AuthType Basic + AuthBasicProvider dbm + AuthDBMUserFile "/www/passwords/passwd.dbm" + Require valid-user + +</Directory>+ + +
D'autres options sont disponibles. Consultez la documentation de
+ mod_authn_dbm pour plus de détails.
Depuis l'arrivée des nouvelles architecture d'autorisation et + d'authentification basées sur les fournisseurs, vous n'êtes plus + limité à une méthode d'authentification et d'autorisation + unique. En fait, on peut panacher autant de fournisseurs que l'on + veut, ce qui vous permet d'élaborer l'architecture qui correspond + exactement à vos besoins. Dans l'exemple suivant, on utilise + conjointement les fournisseurs d'authentification + file et LDAP :
+ +<Directory "/www/docs/private"> + + AuthName "Private" + AuthType Basic + AuthBasicProvider file ldap + AuthUserFile "/usr/local/apache/passwd/passwords" + AuthLDAPURL ldap://ldaphost/o=yourorg + Require valid-user + +</Directory>+ + +
Dans cet exemple, le fournisseur file va tenter d'authentifier + l'utilisateur en premier. S'il n'y parvient pas, le fournisseur LDAP + sera sollicité. Ceci permet l'élargissement des possibilités + d'authentification si votre organisation implémente plusieurs types + de bases d'authentification. D'autres scénarios d'authentification + et d'autorisation peuvent associer un type d'authentification avec + un autre type d'autorisation. Par exemple, une authentification + basée sur un fichier de mots de passe peut permettre l'attribution + d'autorisations basée sur un annuaire LDAP.
+ +Tout comme plusieurs fournisseurs d'authentification peuvent être + implémentés, on peut aussi utiliser plusieurs méthodes + d'autorisation. Dans l'exemple suivant, on utilise à la fois une + autorisation à base de fichier de groupes et une autorisation à base + de groupes LDAP.
+ +<Directory "/www/docs/private"> + + AuthName "Private" + AuthType Basic + AuthBasicProvider file + AuthUserFile "/usr/local/apache/passwd/passwords" + AuthLDAPURL ldap://ldaphost/o=yourorg + AuthGroupFile "/usr/local/apache/passwd/groups" + Require group GroupName + Require ldap-group cn=mygroup,o=yourorg + +</Directory>+ + +
Pour un scénario d'autorisation un peu plus avancé, des
+ directives de conteneur d'autorisation comme <RequireAll> et
+ <RequireAny> permettent d'appliquer une
+ logique telle que l'ordre dans lequel les autorisations sont
+ appliquées peut être entièrement contrôlé au niveau de la
+ configuration. Voir Conteneurs
+ d'autorisations pour un exemple de ce contrôle.
La manière dont les autorisations sont accordées est désormais + beaucoup plus souple qu'une simple vérification auprès d'une seule + base de données. Il est maintenant possible de choisir l'ordre, la + logique et la manière selon lesquels une autorisation est + accordée.
+ +Le contrôle de la manière et de l'ordre selon lesquels le
+ processus d'autorisation était appliqué
+ constituait une sorte de mystère par
+ le passé. Dans Apache 2.2, un mécanisme d'authentification basé
+ sur les fournisseurs a été développé afin de séparer le
+ véritable processus d'authentification de l'autorisation et ses
+ différentes fonctionnalités. Un des avantages colatéraux
+ résidait dans le fait que les fournisseurs d'authentification
+ pouvaient être configurés et appelés selon un ordre particulier
+ indépendant de l'ordre de chargement du module auth proprement
+ dit. Ce mécanisme basé sur les fournisseurs a été étendu au
+ processus d'autorisation. Ceci signifie que la directive
+ Require définit
+ non seulement quelles méthodes d'autorisation doivent être
+ utilisées, mais aussi l'ordre dans lequel elles sont appelées.
+ Les méthodes d'autorisation sont appelées selon l'ordre dans
+ lequel les directives Require apparaissent dans la
+ configuration.
Avec l'introduction des directives de conteneur
+ d'autorisations <RequireAll>
+ et <RequireAny>, la
+ configuration contrôle aussi le moment où les méthodes
+ d'autorisation sont appelées, et quels critères déterminent
+ l'autorisation d'accès. Voir Conteneurs
+ d'autorisations pour un exemple de la manière de les
+ utiliser pour exprimer des logiques d'autorisation
+ complexes.
Par défaut, toutes les directives Require sont
+ traitées comme si elles étaient contenues dans une directive
+ <RequireAny>. En d'autres termes, il
+ suffit
+ qu'une méthode d'autorisation s'applique avec succès pour que
+ l'autorisation soit accordée.
La vérification du nom d'utilisateur et du mot de passe ne + constituent qu'un aspect des méthodes d'authentification. + Souvent, le contrôle d'accès à certaines personnes n'est pas + basé sur leur identité ; il peut dépendre, par exemple de leur + provenance.
+ +Les fournisseurs d'autorisation all,
+ env, host et ip vous
+ permettent d'accorder ou refuser l'accès en
+ fonction de critères tels que le nom d'hôte ou l'adresse
+ IP de la machine qui effectue la requête.
L'utilisation de ces fournisseurs est spécifiée à l'aide de
+ la directive Require. Cette directive
+ permet d'enregistrer quels fournisseurs d'autorisation
+ seront appelés dans le processus d'autorisation au cours du
+ traitement de la requête. Par exemple :
Require ip address+ + +
où adresse est une adresse IP (ou une adresse IP + partielle) ou :
+ +Require host domain_name+ + +
où nom_domaine est un nom de domaine entièrement + qualifé (ou un nom de domaine partiel) ; vous pouvez indiquer + plusieurs adresses ou noms de domaines, si vous le désirez.
+ +Par exemple, si vous voulez rejeter les spams dont une + machine vous inonde, vous pouvez utiliser ceci :
+ +<RequireAll> + Require all granted + Require not ip 10.252.46.165 +</RequireAll>+ + +
Ainsi, les visiteurs en provenance de cette adresse ne + pourront pas voir le contenu concerné par cette directive. Si, + par contre, vous connaissez le nom de la machine, vous pouvez + utiliser ceci :
+ +<RequireAll> + Require all granted + Require not host host.example.com +</RequireAll>+ + +
Et si vous voulez interdire l'accès à toutes les machines + d'un domaine, vous pouvez spécifier une partie seulement de + l'adresse ou du nom de domaine :
+ +<RequireAll> + Require all granted + Require not ip 192.168.205 + Require not host phishers.example.com moreidiots.example + Require not host ke +</RequireAll>+ + +
L'utilisation de la directive <RequireAll>
+ avec de multiples directives <Require>, toutes avec la négation
+ not, n'accordera l'accès que si toutes les
+ conditions négatives sont vérifiées. En d'autres termes, l'accès
+ sera refusé si au moins une des conditions négatives n'est pas
+ vérifiée.
L'adoption d'un mécanisme à base de fournisseurs pour
+ l'authentification, a pour effet colatéral de rendre inutiles
+ les directives Order, Allow, Deny et Satisfy. Cependant, et à
+ des fins de compatibilité ascendante vers les anciennes
+ configurations, ces directives ont été déplacées vers le module
+ mod_access_compat.
Les directives fournies par le module
+ mod_access_compat sont devenues obsolètes depuis
+ la refonte du module mod_authz_host. Mélanger d'anciennes
+ directives comme Order, Allow ou Deny avec des nouvelles comme
+ Require est techniquement
+ possible mais déconseillé. En effet, mod_access_compat a
+ été conçu pour supporter des configurations ne contenant que des anciennes
+ directives afin de faciliter le passage à la version 2.4. Voir le document
+ upgrading pour plus de détails.
+
Dans certains cas, l'authentification constitue une charge
+ inacceptable pour un fournisseur d'authentification ou votre réseau.
+ Ceci est susceptible d'affecter les utilisateurs du module
+ mod_authn_dbd (ou les fournisseurs
+ tiers/personnalisés). Pour résoudre ce problème, HTTPD 2.3/2.4
+ propose un nouveau fournisseur de mise en cache,
+ mod_authn_socache, qui permet de mettre en cache
+ les données d'authentification, et ainsi réduire la charge du/des
+ fournisseurs(s) originels.
Cette mise en cache apportera un gain en performance substantiel + à certains utilisateurs.
+Vous pouvez aussi lire la documentation de
+ mod_auth_basic et mod_authz_host
+ qui contient des informations supplémentaires à propos du
+ fonctionnement de tout ceci.
+ Certaines configurations d'authentification peuvent aussi être
+ simplifiées à l'aide de la directive <AuthnProviderAlias>.
Les différents algorithmes de chiffrement supportés par Apache + pour authentifier les données sont expliqués dans PasswordEncryptions.
+ +Enfin vous pouvez consulter la recette Contrôle + d'accès, qui décrit un certain nombre de situations en relation + avec le sujet.
+ +Serveur HTTP Apache Version 2.4
+ Introduction Configurer Apache pour autoriser CGI Ecrire un programme CGI Mais ça ne marche toujours pas ! Que se passe-t-il en coulisse Bibliothèques et modules CGI Pour plus d'informations| Modules Apparentés | Directives Apparentées |
|---|---|
CGI (Common Gateway Interface) définit une méthode d'interaction + entre un serveur web et des programmes générateurs de contenu + externes, plus souvent appelés programmes CGI ou scripts CGI. + Il s'agit d'une méthode simple pour ajouter du contenu dynamique à votre site + web en utilisant votre langage de programmation préféré. + Ce document est une introduction à la configuration de CGI sur votre + serveur web Apache, et une initiation à l'écriture de programmes + CGI.
+Apache doit être configuré pour permettre l'exécution des + programmes CGI, pour que vos programmes CGI puissent fonctionner + correctement. Il existe plusieurs méthodes pour y parvenir.
+ +LoadModule correspondante n'a pas été
+ commentée dans votre httpd.conf. Une directive correcte
+ doit ressembler à ceci :
+
+ LoadModule cgid_module modules/mod_cgid.so+ + + + Sous Windows, ou si l'on utilise un module MPM non-threadé comme prefork, + une directive correctement configurée sera du style : + +
LoadModule cgi_module modules/mod_cgi.so+
La directive ScriptAlias indique à Apache qu'un
+ répertoire particulier est dédié aux programmes CGI. Apache
+ considérera que tout fichier situé dans ce répertoire est un
+ programme CGI, et tentera de l'exécuter lorsque cette ressource
+ fera l'objet d'une requête client.
La directive ScriptAlias se présente comme suit
+ :
ScriptAlias "/cgi-bin/" "/usr/local/apache2/cgi-bin/"+ + +
Cet exemple est tiré de votre fichier de configuration
+ httpd.conf par défaut, si vous avez installé Apache
+ dans son répertoire par défaut. La directive ScriptAlias est similaire à la
+ directive Alias, qui
+ définit à quel répertoire particulier doit correspondre un préfixe
+ d'URL. Alias et
+ ScriptAlias sont généralement utilisés pour
+ accéder à des répertoires situés en dehors du répertoire défini
+ par la directive DocumentRoot. La différence entre
+ Alias et ScriptAlias
+ réside dans le fait que ScriptAlias indique
+ en plus que tout ce qui se trouve sous le préfixe d'URL doit être
+ considéré comme un programme CGI. Ainsi, l'exemple ci-dessus
+ indique à Apache que toute requête pour une ressource commençant
+ par /cgi-bin/ doit être servie depuis le répertoire
+ /usr/local/apache2/cgi-bin/, et doit être traitée en
+ tant que programme CGI.
Par exemple, si une requête pour l'URL
+ http://www.example.com/cgi-bin/test.pl est
+ effectuée, Apache tentera d'exécuter le fichier
+ /usr/local/apache2/cgi-bin/test.pl et en renverra la
+ sortie. Bien entendu, le fichier doit exister, être exécutable, et
+ retourner sa sortie d'une manière particulière, sinon Apache
+ renverra un message d'erreur.
Pour des raisons de sécurité, la localisation des programmes
+ CGI est souvent restreinte aux
+ répertoires définis par ScriptAlias. De cette manière, les administrateurs
+ peuvent contrôler précisément qui est autorisé à utiliser les
+ programmes CGI. Cependant, si les précautions adéquates quant à
+ la sécurité sont prises, il n'y a aucune raison pour que les
+ programmes CGI ne puissent pas être exécutés depuis d'autres
+ répertoires. Par exemple, vous pouvez autoriser les utilisateurs à
+ enregistrer des contenus web dans leurs répertoires home à l'aide
+ de la directive UserDir. S'ils veulent mettre en
+ oeuvre leurs propres programmes CGI, mais n'ont pas l'autorisation
+ d'accès au répertoire cgi-bin principal, ils devront
+ être en mesure d'exécuter ces programmes depuis un autre
+ répertoire.
L'autorisation d'exécution des programmes CGI dans un
+ répertoire arbitraire se fait en deux étapes. En premier lieu, le
+ gestionnaire cgi-script doit être activé à l'aide
+ d'une directive AddHandler ou SetHandler. En second lieu,
+ ExecCGI doit être spécifié dans la directive Options.
Vous pouvez utiliser de manière explicite la directive
+ Options dans le fichier de
+ configuration de votre serveur principal, pour indiquer que
+ l'exécution des programmes CGI est permise depuis un répertoire
+ particulier :
<Directory "/usr/local/apache2/htdocs/somedir"> + Options +ExecCGI +</Directory>+ + +
La directive ci-dessus indique à Apache qu'il doit permettre
+ l'exécution des fichiers CGI. Vous devez aussi indiquer au serveur
+ quels fichiers sont des fichiers CGI. La directive AddHandler suivante indique au
+ serveur qu'il doit traiter tous les fichiers possédant une
+ extension cgi ou pl en tant que
+ programmes CGI :
AddHandler cgi-script .cgi .pl+ + + +
Le tutoriel
+ .htaccess montre comment activer les programmes
+ CGI si vous n'avez pas accès au
+ fichier httpd.conf.
Pour permettre l'exécution en tant que programme CGI de tout
+ fichier possédant l'extension .cgi et situé dans un
+ répertoire utilisateur, vous pouvez utiliser la configuration
+ suivante :
<Directory "/home/*/public_html"> + Options +ExecCGI + AddHandler cgi-script .cgi +</Directory>+ + +
Pour indiquer un sous-répertoire cgi-bin d'un
+ répertoire utilisateur où tout fichier sera traité en tant que
+ programme CGI, vous pouvez utiliser ceci :
<Directory "/home/*/public_html/cgi-bin"> + Options ExecCGI + SetHandler cgi-script +</Directory>+ + + + +
Il y a deux différences principales entre la programmation + "standard" et la programmation CGI.
+ +En premier lieu, toute sortie de votre programme CGI doit être + précédée d'un en-tête MIME-type. Il s'agit d'un + en-tête HTTP qui indique au client quel type de contenu il reçoit. + La plupart du temps, il se présente comme suit :
+ +
+ Content-type: text/html
+
En second lieu, votre sortie doit être en HTML, ou tout autre + format qu'un navigateur est en mesure d'afficher. La plupart du + temps, il s'agira de HTML, mais occasionnellement, vous pouvez être + amené à écrire un programme CGI qui renvoie une image gif, ou un + autre type de contenu non-HTML.
+ +A part ces deux différences, un programme CGI ressemblera à tout + autre programme que vous pourriez être amené à écrire.
+ +L'exemple suivant est un exemple de programme CGI qui permet
+ d'afficher une ligne de caractères dans votre navigateur. Ecrivez
+ ce qui suit, enregistrez le dans un fichier nommé
+ premier.pl, et placez le dans votre répertoire
+ cgi-bin.
#!/usr/bin/perl +print "Content-type: text/html\n\n"; +print "Hello, World.";+ + +
Même si Perl ne vous est pas familier, vous devriez être
+ capable de comprendre le fonctionnement de ce programme. La
+ première ligne indique à Apache (ou à toute interface à partir de
+ laquelle le programme s'exécute) que ce programme peut être
+ exécuté en fournissant son fichier à l'interpréteur
+ /usr/bin/perl. La seconde ligne affiche la
+ déclaration du type de contenu considéré, suivie de deux paires
+ "Retour chariot - Nouvelle ligne". Ceci a pour effet d'insérer une
+ ligne vide après l'en-tête pour marquer la fin des en-têtes HTTP,
+ et le début du corps du document. La troisième ligne affiche la
+ chaîne de caractères "Bonjour tout le monde . . .". Et c'est tout
+ ce dont vous avez besoin.
Si vous ouvrez votre navigateur favori et lui indiquez + l'adresse
+ +
+ http://www.example.com/cgi-bin/premier.pl
+
ou toute autre URL correspondant à votre programme CGI, Vous
+ verrez la ligne Bonjour tout le monde . . .
+ s'afficher dans la fenêtre de votre navigateur. Ce n'est pas
+ extraordinaire, mais si vous y êtes parvenu, vous avez de bonnes
+ chances d'y parvenir pour tout autre programme plus
+ sophistiqué.
Vous devriez voir au moins une des quatre sorties suivantes dans + votre navigateur lorsque vous essayez d'accéder à votre programme + CGI depuis le web :
+ +Content-Type de manière appropriée dans votre
+ programme CGI.Souvenez-vous que le serveur ne s'exécute pas sous votre nom.
+ En d'autres termes, lorsque le serveur a démarré, il s'exécute
+ avec les droits d'un utilisateur non privilégié - en général
+ nobody, ou www - et en conséquence, il
+ aura besoin de droits supplémentaires pour pouvoir exécuter des
+ fichiers dont vous êtes le propriétaire. En général, pour qu'un
+ fichier ait des droits suffisants pour être exécutable par
+ nobody, il suffit de lui attribuer des droits
+ d'exécution pour tout le monde :
+ chmod a+x premier.pl
+
En outre, si votre programme doit pouvoir accéder en lecture + et/ou écriture à d'autres fichiers, ces derniers devront avoir les + droits appropriés.
+ + + +Lorsque vous lancez un programme depuis la ligne de commande,
+ certaines informations sont passées au shell sans que vous vous en
+ doutiez. Par exemple, la variable PATH indique au
+ shell où il doit rechercher les exécutables auxquels vous faites
+ référence.
Lorsqu'un programme s'exécute depuis le serveur web en tant que
+ programme CGI, sa variable PATH n'aura peut-être pas
+ la même valeur. Tout programme que vous invoquez dans votre
+ programme CGI ( comme par exemple sendmail) devra
+ être spécifié par son chemin complet, de façon à ce que le shell
+ puisse le trouver lorsqu'il tentera d'exécuter votre programme
+ CGI.
Un exemple typique de spécification de programme est le chemin
+ vers l'interpréteur de script (souvent perl) que l'on
+ trouve à la première ligne de votre programme CGI et qui va
+ ressembler à ceci :
#!/usr/bin/perl+ + +
Assurez-vous qu'il s'agit bien du chemin correct vers + l'interpréteur.
+ +Si votre programme CGI dépend de variables + d'environnement non standards, vous devrez vous assurez que + ces variables lui sont bien transmises par Apache.
+ +Lorsque des en-têtes HTTP ne sont pas transmis à + l'environnement, assurez-vous qu'ils sont bien formatés selon la + RFC 2616, section + 4.2 : les noms d'en-têtes doivent commencer par une lettre, + elle-même suivie de lettres, chiffres ou traits d'union. Tout + en-tête dont le nom viole cette règle sera ignoré.
+ + + +La plupart des échecs dans l'exécution d'un programme CGI + proviennent du programme lui-même. Ceci est particulièrement vrai + lorsque ce satané programme CGI se bloque, alors que vous avez + appris à ne plus commettre les deux erreurs précédentes. La + première chose à faire est de vous assurer que votre programme + s'exécute depuis la ligne de commande, avant de le tester à partir + du serveur web. Par exemple, essayez :
+ +
+ cd /usr/local/apache2/cgi-bin
+ ./premier.pl
+
(N'invoquez pas l'interpréteur perl. Le shell et
+ Apache doivent être capable de le déterminer à partir de l'information sur le chemin située sur
+ la première ligne du script.)
La première chose que vous devriez voir affichée par votre
+ programme est un ensemble d'en-têtes HTTP, comprenant entre autres
+ le Content-Type, et suivi d'une ligne vide. Si vous
+ voyez quoi que ce soit d'autre, Apache renverra l'erreur
+ Premature end of script headers si vous tentez
+ d'exécuter le programme depuis le serveur. Voir Ecriture d'un programme CGI ci-dessus pour
+ plus de détails.
Les journaux d'erreurs sont vos amis. Toute anomalie de + fonctionnement est consignée dans le journal des erreurs et c'est + ici que vous devez regarder en premier en cas de problème. Si + l'hébergeur de votre site ne vous donne pas accès au journal des + erreurs, vous avez tout intérêt à vous tourner vers quelqu'un + d'autre. Apprenez à déchiffrer les journaux d'erreurs, et vous + vous apercevrez que la plupart des problèmes seront rapidement + identifiés . . . et résolus.
+ + +Le programme suexec permet
+ d'exécuter les programmes CGI avec des droits différents selon le
+ serveur virtuel ou le répertoire utilisateur dans lequel ils
+ se situent. Suexec effectue une vérification des droits très
+ stricte, et toute anomalie détectée au cours de cette vérification
+ entraînera un echec d'exécution de votre programme CGI avec
+ affichage de l'erreur Premature end of script
+ headers.
Pour savoir si vous pouvez utiliser suexec, tapez la commande
+ apachectl -V, et regardez le chemin indiqué par
+ SUEXEC_BIN. Si au démarrage d'Apache, ce dernier
+ trouve un exécutable suexec dans ce chemin,
+ suexec sera activé.
Si vous ne maîtrisez pas le fonctionnement de suexec, il vous
+ est déconseillé de l'utiliser. Pour désactiver suexec, supprimer
+ simplement (ou renommez) l'exécutable suexec
+ pointé par SUEXEC_BIN et redémarrez le serveur. Si
+ après une lecture de suexec, vous
+ décidez quand-même de l'utiliser, tapez la commande suexec
+ -V pour voir où se situe le journal de suexec, et utilisez
+ ce dernier pour déterminer quelles règles vous violez
+ éventuellement.
Lorsque vos compétences en programmation CGI seront plus + poussées, il s'avérera intéressant pour vous de mieux comprendre ce + qui se passe en coulisse, et en particulier la manière dont le + navigateur et le serveur dialoguent entre eux. En effet, bien qu'il + soit tout à fait louable d'écrire un programme qui affiche "Bonjour + tout le monde . . .", cela ne sert pas à grand chose.
+ +Les variables d'environnement sont des valeurs qui gravitent
+ autour de vous lorsque vous utilisez votre ordinateur. Elles sont
+ très utiles, à l'instar de votre chemin par défaut (où votre
+ ordinateur va rechercher le fichier physique correspondant à la
+ commande que vous avez tapée), votre nom d'utilisateur, le type de
+ votre terminal, etc... Pour obtenir une liste complète des
+ variables d'environnement standards que vous utilisez tous les
+ jours, tapez env dans votre interpréteur
+ de commandes.
Au cours de la transaction CGI, le serveur et le navigateur + définissent aussi des variables d'environnement, de façon à ce + qu'ils puissent communiquer entre eux. Ces variables définissent + entre autre le type de navigateur (Netscape, IE, Lynx), le type de + serveur (Apache, IIS, WebSite), le nom du programme CGI en cours + d'exécution, etc...
+ +Ces variables sont à la disposition du programmeur CGI, et + elles constituent 50% de la communication client-serveur. La liste + complète des variables requises se trouve à + Common Gateway + Interface RFC.
+ +Ce programme CGI basique en Perl permet d'afficher toutes les
+ variables d'environnement qui sont échangées. Deux programmes
+ similaires sont fournis avec la distribution d'Apache et situés
+ dans le répertoire cgi-bin.
+ Notez que certaines variables sont
+ obligatoires, alors que d'autres sont optionnelles, si bien que
+ vous verrez s'afficher certaines variables qui ne font pas partie
+ de la liste officielle. De plus, Apache vous propose de nombreuses
+ méthodes pour ajouter vos propres
+ variables d'environnement aux variables de base fournies par
+ défaut.
#!/usr/bin/perl
+use strict;
+use warnings;
+
+print "Content-type: text/html\n\n";
+foreach my $key (keys %ENV) {
+ print "$key --> $ENV{$key}<br>";
+}
+
+
+
+ L'entrée standard (STDIN) et la sortie standard
+ (STDOUT) constituent d'autres voies de communication
+ entre le client et le serveur. Dans un contexte normal,
+ STDIN correspond au clavier, ou à un fichier fourni
+ au programme à des fins de traitement, et STDOUT à la
+ console ou à l'écran.
Lorsque vous transmettez un formulaire web à un programme CGI
+ par la méthode POST, les données de ce formulaire
+ sont transcrites dans un format spécial et transmises à votre
+ programme CGI via STDIN. Le programme peut alors les
+ traiter comme si elles provenaient du clavier ou d'un
+ fichier.
Ce "format spécial" est très simple. Un nom de champ et sa + valeur sont reliés entre eux par un signe "égal" (=), et chacune + de ces paires nom champ/valeur est séparée de la suivante par un + "et" commercial (&). Les caractères + spéciaux comme les espaces, les "et" commerciaux, et les signes + "égal" sont convertis en leur équivalent hexadécimal pour éviter + qu'ils ne gâchent le travail. La chaîne contenant les données doit + ressembler à ceci :
+ +
+ name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey
+
Vous verrez aussi parfois une chaîne de ce type accolée à une
+ URL. Dans ce cas, le serveur enregistre cette chaîne dans la
+ variable d'environnement appelée QUERY_STRING. On a
+ alors affaire à une requête de type GET. Votre
+ formulaire HTML indique laquelle des méthodes GET ou
+ POST est utilisée pour transmettre les données, en
+ définissant l'attribut METHOD au niveau de la balise
+ FORM.
Votre programme est ensuite chargé d'extraire les informations + utiles de cette chaîne. Heureusement, des bibliothèques et des + modules sont à votre disposition pour vous aider à traiter ces + données, et à gérer les différents aspects de votre programme + CGI.
+ +Pour écrire un programme CGI, il vous est conseillé d'utiliser + une bibliothèque de code, ou un module, qui effectueront une grande + partie du travail de base pour vous. Ceci vous permettra de diminuer + le nombre d'erreurs et d'accélérer le développement.
+ +Si vous écrivez des programmes CGI en Perl, des modules sont à
+ votre disposition à CPAN. A ce
+ sujet, le module le plus populaire est CGI.pm. Vous
+ pouvez aussi essayer CGI::Lite, qui implémente les
+ fonctionnalités strictement nécessaires, mais suffisantes pour
+ la majorité des programmes.
Si vous écrivez des programmes CGI en C, vous disposez de
+ nombreuses options. L'une d'elles est la bibliothèque
+ CGIC de http://www.boutell.com/cgic/.
La spécification CGI actuelle est disponible dans la Common Gateway + Interface RFC.
+ +Lorsque vous postez une question à propos d'un problème CGI que + vous rencontrez, que ce soit dans une liste de diffusion ou dans un + newsgroup, faites en sorte de fournir suffisamment d'informations + sur le problème rencontré, ce que vous attendiez exactement, et en + quoi ce qui se produit est réellement différent de ce que vous + attendiez, quel serveur vous utilisez, en quel langage votre + programme CGI a été écrit, et, si possible, son code source. Ceci + permettra une résolution plus aisée de votre problème.
+ +Notez que les questions à propos de problèmes CGI ne doivent + jamais être postées dans la base de données de + bogues d'Apache, à moins que vous ne soyez sûr d'avoir trouvé un + problème dans le code source d'Apache.
+Serveur HTTP Apache Version 2.4
+Les fichiers .htaccess fournissent une méthode pour
+modifier la configuration du serveur au niveau de chaque répertoire.
Fichiers .htaccess Que sont ce fichiers, comment les utiliser ? Quand doit-on (ne doit-on pas) utiliser
+ les fichiers .htaccess ? Comment sont appliquées les directives ? Exemple d'authentification Exemple d'Inclusion Côté Serveur (Server Side
+Includes - SSI) Les règles de réécriture dans les fichiers .htaccess Exemple de CGI Résolution des problèmes| Modules Apparentés | Directives Apparentées |
|---|---|
.htaccess ne doivent être utilisés
+ que si vous n'avez pas accès au fichier de configuration du serveur
+ principal. L'utilisation des fichiers .htaccess
+ ralentit le fonctionnement de votre serveur HTTP Apache. Il est toujours
+ préférable de définir les directives que vous pouvez inclure dans un
+ fichier .htaccess dans une section Directory, car elles produiront le
+ même effet avec de meilleures performances.Les fichiers .htaccess (ou "fichiers de
+ configuration distribués") fournissent une méthode pour modifier la
+ configuration du serveur au niveau d'un répertoire. Un fichier,
+ contenant une ou plusieurs directives de configuration, est placé
+ dans un répertoire de documents particulier, et ses directives
+ s'appliquent à ce répertoire et à tous ses sous-répertoires.
Si vous voulez donner un autre nom à votre fichier
+ .htaccess, vous pouvez le faire en utilisant la
+ directive AccessFileName. Par
+ exemple, si vous préférez nommer votre fichier
+ .config, vous pouvez mettre ceci dans le fichier de
+ configuration de votre serveur :
AccessFileName ".config"+ +
En général, les fichiers .htaccess utilisent la même
+ syntaxe que les fichiers de
+ configuration principaux. Ce que vous pouvez mettre dans ces
+ fichier est déterminé par la directive AllowOverride. Cette directive spécifie,
+ sous forme de catégories, quelles directives seront traitées si
+ elles se trouvent dans un fichier .htaccess. Si une
+ directive est permise dans un fichier .htaccess file,
+ la documentation de cette directive contiendra une section Override,
+ spécifiant quelle valeur doit prendre AllowOverride pour que cette directive
+ soit traitée.
Par exemple, si vous regardez la documentation de la directive
+ AddDefaultCharset, vous verrez
+ que cette dernière est permise dans les fichiers
+ .htaccess (Voir la ligne de contexte dans le résumé de
+ la directive). La ligne Override indique
+ FileInfo. Vous devez donc avoir au moins
+ AllowOverride FileInfo pour que cette directive soit
+ traitée dans les fichiers .htaccess.
| Contexte : | +configuration du serveur, serveur virtuel, directory, .htaccess | +
| Override: | +FileInfo | +
Si vous n'êtes pas sûr qu'une directive particulière soit permise
+ dans un fichier .htaccess, lisez la documentation de
+ cette directive, et consultez la ligne de contexte pour
+ ".htaccess".
En principe, vous ne devriez utiliser les fichiers
+ .htaccess que lorsque vous n'avez pas accès au fichier de
+ configuration du serveur principal. Par exemple, la fausse
+ idée
+ selon laquelle l'authentification de l'utilisateur devrait toujours
+ être faite dans les fichiers .htaccess est très
+ répandue. Il est aussi souvent avancé, ces dernières
+ années, que les directives de mod_rewrite doivent
+ être définies dans les fichiers .htaccess. Ceci est
+ tout simplement faux. Vous pouvez configurer
+ l'authentification des utilisateurs au niveau de la configuration du
+ serveur principal, et c'est en fait cette méthode qui doit être
+ privilégiée. De même, les directives de
+ mod_rewrite fonctionneront mieux, à de nombreux égards,
+ dans le contexte du serveur principal.
Les fichiers .htaccess ne devraient être utilisés
+ que dans le cas où les fournisseurs de contenu ont besoin de
+ modifier la configuration du serveur au niveau d'un répertoire, mais
+ ne possèdent pas l'accès root sur le système du serveur. Si
+ l'administrateur du serveur ne souhaite pas effectuer des
+ modifications de configuration incessantes, il peut être intéressant
+ de permettre aux utilisateurs isolés d'effectuer eux-mêmes ces
+ modifications par le biais de fichiers .htaccess. Ceci
+ est particulièrement vrai dans le cas où le fournisseur d'accès à
+ Internet héberge de nombreux sites d'utilisateurs sur un seul
+ serveur, et souhaite que ces utilisateurs puissent modifier
+ eux-mêmes leurs configurations.
Cependant et d'une manière générale, il vaut mieux éviter
+ d'utiliser les fichiers .htaccess. Tout élément de
+ configuration que vous pourriez vouloir mettre dans un fichier
+ .htaccess, peut aussi être mis, et avec la même
+ efficacité, dans une section <Directory> du fichier de configuration de
+ votre serveur principal.
Il y a deux raisons principales d'éviter l'utilisation des
+ fichiers .htaccess.
La première est liée aux performances. Lorsque la directive
+ AllowOverride est définie de
+ façon à autoriser l'utilisation des fichiers .htaccess,
+ httpd va rechercher leur présence dans chaque répertoire. Ainsi,
+ permettre l'utilisation des fichiers .htaccess est déjà
+ en soi une cause de dégradation des performances, que vous utilisiez
+ effectivement ces fichiers ou non ! De plus, le fichier
+ .htaccess est chargé en mémoire chaque fois qu'un
+ document fait l'objet d'une requête.
Notez aussi que httpd doit rechercher les fichiers
+ .htaccess dans tous les répertoires de niveau
+ supérieur, afin de rassembler toutes les directives qui s'appliquent
+ au répertoire courant (Voir la section comment sont
+ appliquées les directives). Ainsi, si un fichier fait l'objet
+ d'une requête à partir d'un répertoire
+ /www/htdocs/exemple, httpd doit rechercher les
+ fichiers suivants :
+ /.htaccess
+ /www/.htaccess
+ /www/htdocs/.htaccess
+ /www/htdocs/exemple/.htaccess
+
En conséquence, chaque accès à un fichier de ce répertoire
+ nécessite 4 accès au système de fichiers supplémentaires pour
+ rechercher des fichiers .htaccess, même si
+ aucun de ces fichiers n'est présent. Notez que cet exemple ne peut
+ se produire que si les fichiers .htaccess ont été
+ autorisés pour le répertoire /, ce qui est rarement le
+ cas.
La seconde raison d'éviter l'utilisation des fichiers
+ .htaccess est liée à la sécurité. Si vous permettez aux
+ utilisateurs de modifier la configuration du serveur, il peut en
+ résulter des conséquences sur lesquelles vous n'aurez aucun
+ contrôle. Réfléchissez bien avant de donner ce privilège à vos
+ utilisateurs. Notez aussi que ne pas donner aux utilisateurs les
+ privilèges dont ils ont besoin va entraîner une augmentation des
+ demandes de support technique. Assurez-vous d'avoir informé
+ clairement vos utilisateurs du niveau de privilèges que vous leur
+ avez attribué. Indiquer exactement comment vous avez défini la
+ directive AllowOverride et
+ diriger les utilisateurs vers la documentation correspondante vous
+ évitera bien des confusions ultérieures.
Notez que mettre un fichier .htaccess contenant une
+ directive dans un répertoire /www/htdocs/exemple
+ revient exactement au même que mettre la même directive dans une
+ section Directory <Directory "/www/htdocs/exemple">
+ du fichier de configuration de votre serveur principal :
Fichier .htaccess dans
+ /www/htdocs/exemple :
/www/htdocs/exempleAddType text/example ".exm"+
httpd.conf<Directory "/www/htdocs/example"> + AddType text/example .exm +</Directory>+
Cependant, la perte de performances sera moindre si vous
+ définissez cette directive dans la configuration de
+ votre serveur principal, car cette dernière ne sera chargée qu'une
+ seule fois au moment du démarrage du serveur, alors qu'elle le sera
+ à chaque accès dans le cas d'un fichier .htaccess.
L'utilisation des fichiers .htaccess peut être
+ entièrement désactivée en définissant la directive AllowOverride à none :
AllowOverride None+ +
Les directives de configuration situées dans un fichier
+ .htaccess s'appliquent au répertoire dans lequel ce
+ fichier .htaccess se trouve, ainsi qu'à tous ses
+ sous-répertoires. Cependant, il est important de garder à l'esprit
+ qu'il peut y avoir des fichiers .htaccess dans les
+ répertoires de niveau supérieur. Les directives sont appliquées
+ selon l'ordre dans lequel elles sont rencontrées. Ainsi, les
+ directives d'un fichier .htaccess situé dans un
+ répertoire particulier peuvent écraser les directives se trouvant
+ dans des fichiers .htaccess situés à un niveau
+ supérieur dans l'arborescence des répertoires. Et ces dernières
+ peuvent elles-mêmes avoir écrasé des directives d'un fichier
+ .htaccess situé à un niveau encore plus haut, ou dans
+ le fichier de configuration du serveur principal.
Exemple :
+ +Dans le répertoire /www/htdocs/exemple1 se trouve un
+ fichier .htaccess contenant ce qui suit :
Options +ExecCGI+ + +
Note : "AllowOverride Options" doit être présent
+ pour permettre l'utilisation de la directive "Options" dans les fichiers
+ .htaccess.
Dans le répertoire /www/htdocs/exemple1/exemple2 se
+ trouve un fichier .htaccess contenant ce qui suit
+ :
Options Includes+ + +
Ainsi, à cause de ce second fichier .htaccess du
+ répertoire /www/htdocs/exemple1/exemple2, l'exécution
+ des CGI est interdite, car la dernière définition d'options
+ Options Includes écrase toute autre définition
+ d'options d'un fichier .htaccess situé dans un
+ répertoire de niveau supérieur.
Comme indiqué dans la documentation sur les Sections de configuration, les fichiers
+ .htaccess peuvent écraser les directives des sections
+ <Directory> pour
+ le répertoire correspondant, mais peuvent eux-mêmes être écrasés
+ par d'autres types de sections des fichiers de la
+ configuration principale. Cette possibilité peut s'avérer utile pour
+ forcer certaines configurations, même en cas de présence de l'option
+ libérale AllowOverride. Par
+ exemple, pour interdire l'exécution de scripts en autorisant la
+ définition de toute autre option dans les fichiers
+ .htaccess, vous pouvez utiliser :
<Directory "/www/htdocs"> + AllowOverride All +</Directory> + +<Location "/"> + Options +IncludesNoExec -ExecCGI +</Location>+ + +
DocumentRoot est
+ /www/htdocs.Si vous accédez directement à ce point du document pour apprendre
+ à effectuer une authentification, il est important de noter ceci. Il
+ existe une fausse idée selon laquelle il serait nécessaire
+ d'utiliser les fichiers .htaccess pour implémenter
+ l'authentification par mot de passe. Ceci est tout simplement faux.
+ Pour y parvenir, il est préférable de mettre les directives
+ d'authentification dans une section <Directory> du fichier de configuration de
+ votre serveur principal, et les fichiers .htaccess ne
+ devraient être utilisés que dans le cas où vous n'avez pas accès au
+ fichier de configuration du serveur principal. Voir ci-dessus pour savoir dans quels cas vous devez ou
+ ne devez pas utiliser les fichiers .htaccess.
Ceci étant dit, si vous pensez que vous devez quand-même utiliser
+ un fichier .htaccess, vous pouvez utiliser la
+ configuration suivante :
Contenu du fichier .htaccess :
AuthType Basic +AuthName "Password Required" +AuthUserFile "/www/passwords/password.file" +AuthGroupFile "/www/passwords/group.file" +Require group admins+ + +
Notez que AllowOverride AuthConfig doit être présent
+ pour que ces directives produisent leur effet.
Vous pouvez vous référer au tutoriel sur + l'authentification pour une description plus détaillée de + l'authentification et de l'autorisation.
+Les fichiers .htaccess sont aussi couramment
+ utilisés pour activer les SSI pour un répertoire particulier. Pour y
+ parvenir, on utilise les directives de configuration suivantes,
+ placées dans un fichier .htaccess enregistré dans le
+ répertoire considéré :
Options +Includes +AddType text/html shtml +AddHandler server-parsed shtml+ + +
Notez que AllowOverride Options et AllowOverride
+ FileInfo doivent être tous les deux présents pour que ces
+ directives puissent produire leur effet.
Vous pouvez vous référer au tutoriel SSI + pour une description plus détaillée des SSI.
+Sivous utilisez des directives RewriteRule dans un fichier
+.htaccess, gardez à l'esprit que les choses sont légèrement
+différentes dans un contexte de répertoire. En particulier, les règles
+sont relatives au répertoire courant, et non à l'URI original. Considérez
+les exemples suivants :
# Dans httpd.conf +RewriteRule "^/images/(.+)\.jpg" "/images/$1.png" + +# Dans un fichier .htaccess situé dans le répertoire racine de vos +# documents +RewriteRule "^images/(.+)\.jpg" "images/$1.png" + +# Dans un fichier .htaccess situé dans le répertoire images/ +RewriteRule "^(.+)\.jpg" "$1.png"+ + +
On voit que si le fichier .htaccess se situe à la racine
+de vos documents, le slash de tête est supprimé de la valeur de
+remplacement spécifiée pour la règle RewriteRule, et que si le fichier
+.htaccess se situe dans le répertoire images,
+la chaîne /images/ disparaît de cette même valeur de
+remplacement. Il doit donc en être de même dans votre expression
+rationnelle.
Veuillez vous référer à cette documentation
+pour une étude détaillée de l'utilisation du module
+mod_rewrite.
En fin de compte, vous avez décidé d'utiliser un fichier
+ .htaccess pour permettre l'exécution des programmes CGI
+ dans un répertoire particulier. Pour y parvenir, vous pouvez
+ utiliser la configuration suivante :
Options +ExecCGI +AddHandler cgi-script cgi pl+ + +
Alternativement, si vous souhaitez que tous les fichiers d'un + répertoire donné soient considérés comme des programmes CGI, vous + pouvez utiliser la configuration suivante :
+ +Options +ExecCGI +SetHandler cgi-script+ + +
Notez que AllowOverride Options et AllowOverride
+ FileInfo doivent être tous les deux présents pour que ces
+ directives puissent produire leur effet.
Vous pouvez vous référer au tutoriel CGI + pour une description plus détaillée de la configuration et de la + proprammation CGI.
+ +De nombreuses raisons peuvent être à l'origine du fait que
+ les directives que vous avez mises dans un fichier
+ .htaccess ne produisent pas l'effet désiré.
Le plus souvent, le problème vient du fait que la définition de
+ la directive AllowOverride
+ ne permet pas l'activation des directives de votre fichier
+ .htaccess. Vérifiez si une directive
+ AllowOverride None n'affecte pas le répertoire où se
+ trouve votre fichier. Un bon test consiste à mettre des directives
+ dont la syntaxe est erronée dans votre ficher .htaccess
+ et de recharger la page. Si aucune erreur n'est générée par le
+ serveur, il est pratiquement certain qu'une directive
+ AllowOverride None affecte votre répertoire.
Par contre, si vous obtenez des erreurs de serveur lorsque vous
+ tentez d'accéder à des documents, consultez votre journal des
+ erreurs de httpd. Il vous indiquera probablement que la directive
+ utilisée dans votre fichier .htaccess n'est pas
+ permise.
+ [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here
+
Cela signifie soit que vous utilisez une directive qui n'est
+ jamais permise dans les fichiers .htaccess, soit
+ que vous n'avez tout simplement pas défini la directive
+ AllowOverride à un niveau
+ suffisant pour la directive que vous utilisez. Consultez la
+ documentation de cette directive pour déterminer quel cas
+ s'applique.
Le journal des erreurs peut aussi vous signaler une erreur de + syntaxe dans l'usage de la directive elle-même.
+ +
+ [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters
+
Dans ce cas, le message d'erreur sera spécifique à l'erreur + de syntaxe que vous avez commise.
+Serveur HTTP Apache Version 2.4
+Ce document est le guide de l'utilisateur de l'implémentation de HTTP/2 + dans Apache httpd. Cette fonctionnalité en est au stade + de production, et les interfaces et directives devraient donc être + dorénavant relativement stables. +
+ Le protocole HTTP/2 HTTP/2 dans Apache httpd Compilation de httpd avec le support de HTTP/2 Configuration de base Configuration du MPM Clients Outils efficaces pour déboguer HTTP/2 Push serveur Suggestions précocesHTTP/2 est une évolution du protocole de la couche application le plus + utilisé au monde, HTTP. Cette évolution permet en particulier une utilisation + plus efficace des ressources réseau. Il ne modifie pas les aspects + fondamentaux de HTTP (sa sémantique). Entre autres, il y a toujours des + requêtes, des réponses et des en-têtes. Par conséquent, si vous connaissez + HTTP/1, vous connaissez déjà 95% de HTTP/2.
+Beaucoup a déjà été écrit à propos de HTTP/2 et de son fonctionnement. La + documentation la plus officielle est bien entendu sa RFC 7540 (ou cette version au format plus + lisible). Vous trouverez ici une description des rouages de HTTP/2 dans + leurs moindres détails.
+Le premier document à lire lorsqu'on ne connaît pas un mécanisme n'est + cependant pas sa RFC. Il est préférable de comprendre tout d'abord ce + que ce mécanisme est censé faire, et seulement ensuite de lire sa RFC + pour comprendre comment il fonctionne. http2 explained de Daniel Stenberg + (l'auteur de curl) + est un bien meilleur document pour démarrer l'étude de HTTP/2. En outre, de + nouveaux langages s'ajoutent régulièrement à sa liste de traductions + disponibles !
+Si vous n'avez pas envie de le lire parce que vous le trouvez trop long, + voici certains pièges à éviter et nouveaux termes à connaître avant de lire + ce document :
+Le protocole HTTP/2 est implémenté dans Apache httpd via un module
+ propre, pertinemment nommé mod_http2. Ce
+ module implémente toutes les fonctionnalités décrites par la RFC 7540 et
+ supporte les connexions en texte pur (http:), ou sécurisées (https:).
+ La variante texte pur se nomme 'h2c', et la variante sécurisée
+ 'h2'. h2c peut être en mode direct ou
+ Upgrade: via une requête initiale en HTTP/1.
Server Push est une nouvelle fonctionnalité offerte + aux développeurs web par HTTP/2. La section correspondante de ce document + vous indiquera comment votre application peut en tirer parti.
+mod_http2 se base sur la bibliothèque
+ de nghttp2 pour son implémentation. Pour
+ pouvoir compiler mod_http2, libnghttp2 version
+ 1.2.1. ou supérieure doit être installée dans votre système.
Pour déclencher la compilation de mod_http2, vous devez
+ ajouter l'argument '--enable-http2' au script
+ ./configure que vous exécutez à la racine de l'arborescence des
+ sources de httpd. Si libnghttp2 est installée dans un
+ répertoire non connu du chemin de vos bibliothèques, vous devez indiquer ce
+ répertoire au script ./configure via l'argument
+ '--with-nghttp2=<path>'.
Alors que cette méthode de compilation conviendra à la plupart, certains
+ préféreront lier statiquement nghttp2 à ce module. Pour ce
+ faire, utilisez l'argument --enable-nghttp2-staticlib-deps.
+ Cette méthode est pratiquement la même que celle utilisée pour lier
+ statiquement openssl à mod_ssl.
En parlant de SSL, vous devez savoir que la plupart des navigateurs ne
+ communiqueront en HTTP/2 que sur des URLs sécurisées de type
+ https: ; votre serveur doit donc supporter SSL. Mais de plus,
+ votre bibliothèque SSL devra supporter l'extension ALPN. Enfin,
+ si la bibliothèque que vous utilisez est OpenSSL, sa version devra être
+ 1.0.2. ou supérieure.
Maintenant que vous disposez d'un binaire httpd compilé avec le
+ module mod_http2, l'activation de ce dernier nécessite un
+ minimum de configuration supplémentaire. En premier lieu, comme pour tout
+ module Apache, vous devez le charger :
LoadModule http2_module modules/mod_http2.so+ + +
La seconde directive que vous devez ajouter à votre fichier de + configuration est
+Protocols h2 http/1.1+ +
Ceci permet de définir h2, la variante sécurisée, comme le protocole + préféré pour les connexions à votre serveur. Si vous souhaitez que toutes les + variantes soient disponibles, utilisez la directive suivante :
+Protocols h2 h2c http/1.1+ +
Selon l'endroit où vous placez cette directive, elle affectera l'ensemble + de votre serveur, ou seulement un ou plusieurs serveurs virtuels. Vous + pouvez aussi l'imbriquer comme dans l'exemple suivant :
+Protocols http/1.1 +<VirtualHost ...> + ServerName test.example.org + Protocols h2 http/1.1 +</VirtualHost>+ + +
Seules les connexions en HTTP/1 seront alors permises, sauf pour le serveur
+ virtuel test.example.org qui acceptera aussi les connexions SSL
+ en HTTP/2.
La directive SSLCipherSuite doit
+ être définie avec une chaîne d'algorithmes de chiffrement TLS forte. Même si
+ la version actuelle de mod_http2 n'impose pas d'algorithmes de chiffrement
+ particuliers, la plupart des clients le font. Faire pointer un navigateur
+ vers un serveur où h2 est activé avec une chaîne d'algorithmes
+ de chiffrement inappropriée entraînera un rejet et une retrogradation vers
+ HTTP 1.1. C'est une erreur que l'on fait couramment lorsqu'on configure
+ httpd pour HTTP/2 pour la première fois ; donc gardez la à l'esprit si vous
+ voulez éviter de longues sessions de débogage ! Si vous voulez être sûr de
+ définir une chaîne d'algorithmes de chiffrement appropriée, évitez ceux qui
+ sont listés dans la blacklist TLS HTTP/2
+ .
L'ordre des protocoles indiqués est aussi important. Par défaut, le + premier sera le protocole préféré. Lorsqu'un client offre plusieurs choix, + c'est le plus à gauche qui sera sélectionné. Dans
+Protocols http/1.1 h2+ +
le protocole préféré sera HTTP/1 et il sera toujours sélectionné sauf si + un client ne supporte que h2. Comme nous souhaitons communiquer en + HTTP/2 avec les clients qui le supportent, la meilleure définition de la + directive est
+Protocols h2 h2c http/1.1+ + +
Toujours à propos de l'ordre des protocoles, le client a lui aussi ses + propres préférences en la matière. À ce titre, si vous le souhaitez, vous + pouvez configurer votre serveur pour qu'il sélectionne non plus son + protocole préféré, mais au contraire le protocole préféré + du client :
+ProtocolsHonorOrder Off+ +
Avec cette directive, l'ordre des protocoles que vous avez + défini devient caduque et seul l'ordre défini par le client sera pris en + compte.
+Une dernière chose : les protocoles que vous définissez ne sont pas
+ vérifiés quant à leurs validité ou orthographe. Vous pouvez très bien
+ définir des protocoles qui n'existent pas, et il n'est donc pas nécessaire
+ de filtrer le contenu de la directive Protocols avec des vérifications de type
+ <IfModule>.
Pour des conseils plus avancés à propos de la configuration, voir la Documentation de mod_http2, et en particulier + la section à propos de la consommation supplémentaire de + ressources, ainsi que la section expliquant comment gérer les serveurs multiples avec certificat + commun.
+Tous les modules multiprocessus (MPM) fournis avec httpd supportent
+ HTTP/2. Cependant, si vous utilisez le MPM prefork, vous allez
+ faire face à de sévères restrictions.
Avec le MPM prefork, mod_http2 ne traitera
+ qu'une requête à la fois par connexion alors que les clients tels que les
+ navigateurs internet envoient de nombreuses requêtes au même moment. Si
+ l'une d'entre elles est longue à traiter (ou implique une longue
+ interrogation), les autres requêtes seront mises en attente.
Par défaut, mod_http2 ne passe pas outre cette limitation pour
+ la simple et bonne raison que le MPM prefork n'est aujourd'hui
+ choisi que si vous exécutez des moteurs de traitement qui ne sont pas préparés
+ pour le multithreading (par exemple qui se crashent lorsque plusieurs
+ requêtes arrivent).
Si votre plateforme et votre installation de httpd le supportent, la
+ meilleur solution consiste actuellement à utiliser le MPM
+ event.
+
Si vous n'avez pas d'autre choix que d'utiliser le MPM
+ prefork, mais souhaitez tout de même traiter plusieurs requêtes
+ simultanément, vous pouvez jouer avec la directive H2MinWorkers, sans garantie que cela
+ fonctionne.
La plupart des navigateurs modernes supportent HTTP/2, mais seulement sur + des connexions SSL : Firefox v43, Chrome v45, Safari v9, iOS Safari v9, + Opera v35, Chrome pour Android v49 et + Internet Explorer v11 sous Windows10 (selon cette source).
+D'autres clients et serveurs sont listés dans le wiki des + implémentations ; entre autres des implémentations pour c, c++, common + lisp, dart, erlang, haskell, java, nodejs, php, python, perl, ruby, rust, + scala et swift.
+De nombreuses implémentations clientes autres que les navigateurs + supportent HTTP/2 en texte pur, h2c. L'une des plus efficaces d'entre elles + est curl.
+Le premier d'entre eux est bien entendu curl. Assurez-vous au préalable que votre
+ version supporte HTTP/2 en vérifiant ses Fonctionnalités :
$ curl -V + curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4 + Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...] + Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 ++ +
Pour une inspection en profondeur : wireshark.
+Le paquet nghttp2 inclut aussi des + outils comme :
+Chrome fournit des journaux détaillés des connexions HTTP/2 via la page + special net-internals page. Il y + a aussi cette extension intéressante pour Chrome + et Firefox + qui permet d'indiquer que votre navigateur utilise HTTP/2.
+Le protocole HTTP/2 permet au serveur de proposer (PUSH) des réponses + pour lesquelles le client n'a rien demandé. La communication autour de ces + réponses est du style : "voici une requête que vous n'avez jamais + envoyée, et la réponse vous parviendra bientôt tout de même ..."
+Il y a cependant des conditions : le client peut désactiver cette + fonctionnalité et le serveur ne pourra alors lui proposer des réponses que + pour les requêtes qu'il a effectivement envoyées.
+Cette fonctionnalité a pour but de permettre au serveur d'envoyer au + client des ressources dont il va probablement avoir besoin : par exemple une + ressource css ou javascript appartenant à une page html que le client a + demandée, un jeu d'images référencé par un css, etc...
+Cette anticipation a pour avantage de permettre au client d'économiser le + temps qu'il lui aurait fallu pour envoyer une requête, quelques + millisecondes à une demi-seconde en fonction de l'éloignement du serveur. + Elle a cependant pour inconvénient d'imposer au client le téléchargement de + ressources qu'il possède peut-être déjà dans son cache. Bien entendu, HTTP/2 + permet d'annuler prématurément de telles requêtes, mais des ressources sont + tout de même gaspillées.
+En résumé : il n'existe pas encore de stratégie efficace pour faire le + meilleur usage de cette fonctionnalité de HTTP/2 et tout le monde en est + encore au stade de l'expérimentation. À ce titre, voici des conseils pour + procéder vous-même à ces expérimentations :
+mod_http2 inspecte l'en-tête de la réponse et recherche les
+ en-têtes Link sous un certain format :
Link </xxx.css>;rel=preload, </xxx.js>; rel=preload+ +
Si la connexion supporte PUSH, ces deux ressources seront envoyées au + client. En tant que développeur web vous pouvez définir ces en-têtes soit + directement au niveau de la réponse de votre application, soit en + configurant votre serveur via
+<Location /xxx.html> + Header add Link "</xxx.css>;rel=preload" + Header add Link "</xxx.js>;rel=preload" +</Location>+ +
Si vous souhaitez utiliser des liens preload sans déclencher
+ de PUSH, vous pouvez utiliser le paramètre nopush comme suit :
Link </xxx.css>;rel=preload;nopush+ +
Vous pouvez aussi désactiver les PUSHes pour l'ensemble de votre + serveur via la directive
+H2Push Off+ +
À savoir aussi :
+Le module maintient un journal des ressources ayant fait l'objet d'un + PUSH pour chaque connexion (en général des condensés hash des URLs), et + n'effectuera pas deux fois un PUSH pour la même ressource. Cependant, + lorsque la connexion est fermée, le journal de ses PUSHes est supprimé.
+Certains développeurs planchent sur la manière de permettre au client + d'informer le serveur des ressources qu'il possède déjà dans son cache afin + d'éviter les PUSHes pour ces dernières, mais ceci n'en est actuellement qu'à + un stade très expérimental.
+L'
+ en-tête Accept-Push-Policy est un autre dispositif expérimental
+ implémenté dans mod_http2 ; il permet au client de définir pour
+ chaque requête quels genres de PUSHes il accepte.
+ La fonctionnalité PUSH n'apportera pas toujours le gain de performances dans + l'obtention de réponses aux requêtes. Vous trouverez plusieurs études sur ce + sujet sur internet qui en expliquent les avantages et inconvénients et + comment les particularités des clients et du réseau en influencent le + fonctionnement. Par exemple, le seul fait que le serveur PUSHes une + ressource n'implique pas forcément que le navigateur l'utilisera.
+Ce qui influence le plus la réponse PUSHed, c'est la requête qui a été
+ simulée. En effet, l'URL de la requête pour un PUSH est fournie par
+ l'application, mais d'où viennent les en-têtes ? Par exemple, La requête
+ PUSH requiert-elle un en-tête accept-language et si oui, quelle
+ sera sa valeur ?
httpd va consulter la requête originale (celle qui a déclenché le PUSH)
+ et copier les en-têtes suivants vers la requête PUSH :
+ user-agent, accept, accept-encoding,
+ accept-language et cache-control.
Tous les autres en-têtes sont ignorés. Les cookies eux non plus ne seront + pas copiés. PUSHer des ressources qui requièrent la présence d'un cookie ne + fonctionnera pas. Ceci peut être sujet à débat, mais tant que ce ne sera pas + clairement discuté avec les navigateurs, restons prudents et évitons + d'exposer les cookies là où ils ne sont pas censés être visibles.
+A l'instar des ressources PUSHées, une autre méthode consiste à envoyer
+ des en-têtes Link au client avant même que la réponse ne soit
+ prête. Cette méthode utilise la fonctionnalité appelée "Suggestions
+ précoces" (Early Hints) décrite dans la RFC 8297.
Pour utiliser cette fonctionnalité, vous devez l'activer explicitement + sur le serveur via :
+H2EarlyHints on+ +
Elle n'est en effet pas activée par défaut car certains navigateurs + anciens perdent pied avec de telles réponses.
+Une fois cette fonctionnalité activée, vous pouvez utiliser la directive
+ H2PushResource pour déclencher les
+ suggestions précoces et les PUSHes de ressources :
<Location /xxx.html> + H2PushResource /xxx.css + H2PushResource /xxx.js +</Location>+ +
Le serveur enverra alors au client une réponse "103 Early
+ Hints" dès qu'il commencera à traiter la requête. Selon
+ votre application web, cet envoi peut intervenir beaucoup plus tôt que le
+ moment où les premiers en-têtes de réponse auront été déterminés.
Si H2Push est activé, ceci
+ déclenchera aussi le PUSH juste après la réponse 103. Mais si H2Push n'est pas activé, la réponse 103 sera
+ quand-même envoyée au client.
Serveur HTTP Apache Version 2.4
+L'authentification représente tout processus par lequel vous + vérifiez si quelqu'un correspond bien à la personne qu'il + prétend être. L'autorisation représente tout processus + permettant de savoir si une personne est autorisée à aller là où + elle veut aller, ou à obtenir les informations qu'elle demande.
+ + +Le contrôle d'accès se réfère au processus permettant + d'interdire ou d'accorder l'accès à une ressource en fonction de + certains critères, et il existe de nombreuses façons d'y + parvenir.
+ +Voir Contrôle d'accès
+L'interface CGI (Common Gateway Interface) + fournit au serveur web une méthode d'interaction avec des + programmes externes générateurs de contenu, souvent nommés + programmes CGI ou scripts CGI. Il s'agit d'une méthode + simple permettant d'ajouter du contenu + dynamique à votre site web. Ce document se veut une introduction + à la configuration de CGI sur votre serveur web Apache et à + l'écriture de programmes CGI.
+ + +.htaccessLes fichiers .htaccess permettent de modifier la
+ configuration du serveur au niveau de chaque répertoire. À cet
+ effet, un fichier est placé dans un répertoire particulier du site
+ web, et les directives de configuration qu'il contient s'appliquent à ce
+ répertoire et à tous ses sous-répertoires.
Voir Fichiers .htaccess
HTTP/2 est une évolution du protocole de la couche application le plus + connu au monde, HTTP. Les efforts se sont concentrés sur une amélioration + de l'efficacité de l'utilisation des ressources réseau sans modifier la + sémantique de HTTP. Ce guide explique la manière dont HTTP/2 est + implémenté dans httpd, donne des conseils pour une configuration de base + ainsi qu'une liste de recommandations. +
+ +Voir le guide HTTP/2
+Les SSI sont des directives que l'on place dans des pages + HTML, et qui sont évaluées par le serveur lorsque ces pages sont + servies. Elles vous permettent d'ajouter du contenu généré + dynamiquement à une page HTML existante, sans avoir à servir + l'intégralité de la page via un programme CGI, ou toute autre + technologie dynamique.
+ + +Sur les systèmes multi-utilisateurs, vous pouvez permettre à
+ chaque utilisateur d'avoir un site web dans son répertoire home
+ via la directive UserDir. Les visiteurs de l'URL
+ http://example.com/~nom-utilisateur/ vont recevoir
+ du contenu situé dans le répertoire home de l'utilisateur
+ "nom-utilisateur", et dans le sous-répertoire
+ spécifié par la directive UserDir.
Apache httpd possède des fonctionnalités évoluées de serveur
+ mandataire inverse via ses directives ProxyPass et BalancerMember qui permettent
+ d'implémenter un système de mandataire inverse sophistiqué garantissant
+ une haute disponibilité, une répartition et une réattribution de charge,
+ un regroupement de serveurs en grappe (clustering) basé sur le cloud et
+ une reconfiguration dynamique à la volée.
La réécriture d'URLs avec (ou sans) mod_rewrite devient
+ l'une des questions les plus fréquentes posées dans nos listes de
+ diffusion et nos canaux IRC. C'est pourquoi nous avons dédié une section entière de notre documentation à des
+ howtos et recettes sur ce sujet.
Serveur HTTP Apache Version 2.4
+Sur les systèmes multi-utilisateurs, on peut permettre à chaque
+utilisateur d'avoir un site web dans son répertoire home à l'aide de la
+directive UserDir. Les
+visiteurs de l'URL http://example.com/~nom_utilisateur/
+recevront un contenu situé dans le répertoire home de l'utilisateur
+"nom_utilisateur", et dans le sous-répertoire spécifié par
+la directive UserDir.
Notez que par défaut, l'accès à ces répertoires n'est
+pas permis. Vous pouvez en permettre l'accès à l'aide
+de la directive UserDir en
+décommentant la ligne :
#Include conf/extra/httpd-userdir.conf+ +
dans le fichier de configuration par défaut
+ conf/httpd.conf, et en adaptant le
+ fichier httpd-userdir.conf selon vos besoins, ou en
+ incluant les directives appropriées dans une section
+ <Directory> du fichier de
+ configuration principal.
Répertoires web utilisateurs Définition du chemin des fichiers avec UserDir Redirection vers des URLs externes Définition de la liste des utilisateurs autorisés à utiliser
+ cette fonctionnalité Définition d'un répertoire CGI pour chaque utilisateur Permettre aux utilisateurs de modifier la
+ configuration| Modules Apparentés | Directives Apparentées |
|---|---|
La directive UserDir
+ permet de spécifier un répertoire à partir duquel le contenu de
+ l'utilisateur pourra être chargé. Elle peut revêtir plusieurs
+ formes.
Si le chemin spécifié ne commence pas par un slash, il sera + interprété comme chemin relatif au répertoire home de l'utilisateur + considéré. Par exemple, avec cette configuration :
+ +UserDir public_html+ + +
l'URL http://example.com/~rbowen/fichier.html
+ correspondra au chemin fichier
+ /home/rbowen/public_html/fichier.html
Si le chemin spécifié commence par un slash, le chemin du fichier + sera construit en utilisant ce chemin, suivi du nom de l'utilisateur + considéré. Par exemple, avec cette configuration :
+ +UserDir /var/html+ + +
l'URL http://example.com/~rbowen/fichier.html
+ correspondra au chemin fichier
+ /var/html/rbowen/fichier.html
Si le chemin spécifié contient un astérisque (*), ce dernier sera + remplacé par le nom de l'utilisateur dans le chemin du fichier + correspondant. Par exemple, avec cette configuration :
+ +UserDir /var/www/*/docs+ + +
l'URL http://example.com/~rbowen/fichier.html
+ correspondra au chemin fichier
+ /var/www/rbowen/docs/fichier.html
On peut aussi définir plusieurs répertoires ou chemins de + répertoires.
+ +UserDir public_html /var/html+ + +
Avec l'URL http://example.com/~rbowen/fichier.html,
+ Apache va rechercher ~rbowen. S'il ne le trouve pas,
+ Apache va rechercher rbowen dans
+ /var/html. S'il le trouve, l'URL ci-dessus correspondra
+ au chemin fichier /var/html/rbowen/file.html
On peut utiliser la directive UserDir pour rediriger les requêtes
+ relatives aux répertoires utilisateurs vers des URLs externes.
UserDir http://example.org/users/*/+ + +
L'exemple ci-dessus va rediriger une requête pour
+ http://example.com/~bob/abc.html vers
+ http://exemple.org/users/bob/abc.html.
En suivant la syntaxe décrite dans la documentation de UserDir, + vous pouvez définir quels utilisateurs sont autorisés à utiliser + cette fonctionnalité :
+ +UserDir disabled root jro fish+ + +
La configuration ci-dessus va autoriser l'utilisation de la
+ fonctionnalité pour tous les utilisateurs, à l'exception de ceux
+ listés à la suite de l'argument disabled. De même, vous
+ pouvez interdire l'utilisation de la fonctionnalité à tous les
+ utilisateurs sauf certains d'entre eux en utilisant une
+ configuration du style :
UserDir disabled +UserDir enabled rbowen krietz+ + +
Vous trouverez d'autres exemples dans la documentation de
+ UserDir.
Afin de réserver un répertoire cgi-bin pour chaque utilisateur,
+ vous pouvez utiliser une section <Directory> pour activer CGI dans un
+ sous-répertoire particulier d'un répertoire home utilisateur.
<Directory "/home/*/public_html/cgi-bin/"> + Options ExecCGI + SetHandler cgi-script +</Directory>+ + +
Avec la configuration ci-dessus, et en supposant que
+ UserDir est défini à public_html, un
+ programme CGI exemple.cgi pourra être chargé depuis ce
+ répertoire en passant par l'URL :
+ http://example.com/~rbowen/cgi-bin/exemple.cgi
+
Si vous voulez que vos utilisateurs puissent modifier la
+ configuration du serveur pour ce qui concerne leur espace web, ils
+ devront utiliser des fichiers .htaccess pour effectuer
+ ces modifications. Assurez-vous d'avoir défini la directive
+ AllowOverride à une valeur
+ appropriée pour les directives dont vous voulez permettre la
+ modification aux utilisateurs. Voir le tutoriel .htaccess pour plus de détails sur
+ la manière dont tout ceci fonctionne.
Serveur HTTP Apache Version 2.4
+En plus de ses fonctions de serveur web "basique", à savoir fournir du + contenu statique et dynamique à l'utilisateur, Apache httpd (comme la + plupart des autres serveurs web) peut aussi assurer les fonctions de serveur + mandataire inverse, connu aussi sous le nom de serveur "passerelle".
+ +Dans un tel scénario, httpd ne génère et n'héberge pas lui-même les + données, le contenu étant en général obtenu à partir d'un ou plusieurs serveurs + d'arrière-plan qui n'ont normalement aucune connexion directe avec le réseau + externe. Lorsque httpd reçoit une requête en provenance d'un client, la + requête proprement dite est mandatée vers un de ces serveurs + d'arrière-plan qui traite la requête, génère le contenu et l'envoie à httpd, + ce dernier générant la véritable réponse HTTP à destination du client.
+ +De nombreuses raisons peuvent vous motiver à utiliser cette + fonctionnalité, mais elles sont souvent du domaine de la sécurité, de + la haute disponibilité, de la répartition de charge et de + l'authentification/autorisation centralisée. Il est alors indispensable que + l'organisation, la conception et l'architecture de l'infrastructure + d'arrière-plan (les serveurs qui traitent au sens propre les requêtes) soient + isolées et protégées de l'extérieur ; vu du client, le serveur mandataire + inverse est le seul serveur accessible pouvant lui fournir du + contenu.
+ +Voici un exemple typique d'implémentation de cette fonctionnalité :
+
Mandataire inverse Mandatement inverse simple Clusters et Balancers Configuration du Balancer et des BalancerMembers Gestion des indisponibilités (Failover) Gestion du répartiteur de charge Vérification dynamique du bon fonctionnement d'un serveur
+ d'arrière-plan Drapeaux d'état d'un membre du groupe de répartition de charge| Modules Apparentés | Directives Apparentées |
|---|---|
+ La directive ProxyPass permet de
+ rediriger les requêtes entrantes vers un serveur d'arrière-plan (ou un
+ cluster de serveurs plus connu sous le nom de groupe
+ Balancer). Dans cet exemple le plus simple, toutes les
+ requêtes ("/") sont redirigées vers un serveur d'arrière-plan
+ unique :
+
ProxyPass "/" "http://www.example.com/"+ + +
+ Pour être sur que cette redirection soit effectuée et que les en-têtes
+ Location: générés par le serveur d'arrière-plan soient
+ modifiés pour pointer vers le mandataire inverse, et non vers le serveur
+ d'arrière-plan, la directive ProxyPassReverse est souvent requise :
+
ProxyPass "/" "http://www.example.com/" +ProxyPassReverse "/" "http://www.example.com/"+ + +
Seules des URIs spécifiques peuvent être mandatées, comme le montre + l'exemple suivant :
+ +ProxyPass "/images" "http://www.example.com/" +ProxyPassReverse "/images" "http://www.example.com/"+ + +
Dans l'exemple précédent, si le chemin d'une requête commence par
+ /images, elle sera redirigée vers le serveur d'arrière-plan
+ spécifié ; dans le cas contraire, elle sera traitée localement.
+
+ Utiliser un serveur d'arrière-plan unique n'est cependant pas une solution
+ idéale car ce dernier peut devenir indisponible ou surchargé, et le
+ mandatement inverse vers ce serveur ne présente alors plus aucun avantage.
+ La solution réside dans la définition d'un groupe de serveurs
+ d'arrière-plan qui vont se partager le traitement des requêtes via un
+ mécanisme de répartition de charge et de gestion des indisponibilités pris
+ en charge par le mandataire. Ce groupe de répartition est plus connu sous le nom de
+ cluster, mais dans la terminologie d'Apache httpd, on utilise
+ plutôt le terme de balancer. Un balancer se définit en
+ utilisant les directives <Proxy> et BalancerMember comme suit :
+
<Proxy balancer://myset> + BalancerMember http://www2.example.com:8080 + BalancerMember http://www3.example.com:8080 + ProxySet lbmethod=bytraffic +</Proxy> + +ProxyPass "/images/" "balancer://myset/" +ProxyPassReverse "/images/" "balancer://myset/"+ + +
+ Le protocole balancer:// indique à httpd que l'on souhaite
+ créer un balancer nommé myset. Ce balancer comporte deux serveurs
+ d'arrière-plan référencés dans la terminologie httpd sous le nom de
+ BalancerMembers. Avec cet exemple, toute requête dont le chemin
+ commence par /images sera mandatée vers un des deux
+ serveurs d'arrière-plan. La directive ProxySet définit ici pour le balancer
+ myset un algorithme de
+ répartition de charge basé sur le trafic entrées/sorties.
+
+ Les BalancerMembers sont aussi souvent référencés sous le terme + workers. +
+
+ Vous pouvez configurer de manière détaillée les balancers et
+ workers via les nombreux paramètres de la directive ProxyPass. Par exemple, si vous souhaitez
+ que http://www3.example.com:8080 traite avec un facteur 3 le
+ trafic avec un timeout d'une seconde, utilisez la configuration suivante :
+
<Proxy balancer://myset> + BalancerMember http://www2.example.com:8080 + BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1 + ProxySet lbmethod=bytraffic +</Proxy> + +ProxyPass "/images" "balancer://myset/" +ProxyPassReverse "/images" "balancer://myset/"+ + +
+ Vous pouvez aussi définir finement des scénarios pour les cas + d'indisponibilité d'un ou plusieurs serveurs d'arrière-plan en spécifiant + quels serveurs doivent alors prendre le relai. Dans l'exemple suivant, + trois scénarios sont envisagés : +
+http://spare1.example.com:8080 et
+ http://spare2.example.com:8080 ne sont sollicités que si
+ http://www2.example.com:8080 ou
+ http://www3.example.com:8080 est indisponible (un serveur
+ de remplacement sera utilisé à la place d'un membre indisponible du même
+ jeu de serveurs cibles).
+ http://hstandby.example.com:8080 n'est sollicité que si
+ tous les autres serveurs cibles du jeu de serveurs 0 sont
+ indisponibles.
+ http://bkup1.example.com:8080 et
+ http://bkup2.example.com:8080 du jeu 1 ne seront sollicités que si
+ tous les serveurs du jeu 0, tous les serveurs de
+ remplacement et tous les serveurs de standby sont indisponibles.
+ + Il est ainsi possible de définir un ou plusieurs serveurs de remplacement + ou de standby pour chaque jeu de serveurs du répartiteur de charge. +
+ +<Proxy balancer://myset> + BalancerMember http://www2.example.com:8080 + BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1 + BalancerMember http://spare1.example.com:8080 status=+R + BalancerMember http://spare2.example.com:8080 status=+R + BalancerMember http://hstandby.example.com:8080 status=+H + BalancerMember http://bkup1.example.com:8080 lbset=1 + BalancerMember http://bkup2.example.com:8080 lbset=1 + ProxySet lbmethod=byrequests +</Proxy> + +ProxyPass "/images/" "balancer://myset/" +ProxyPassReverse "/images/" "balancer://myset/"+ + +
+ Les serveurs de remplacement à chaud remplacent les serveurs indisponibles + du même jeu de serveurs du répartiteur de charge. Un serveur est + considéré comme indisponible s'il est en maintenance, arrêté ou en erreur. + Les serveurs de standby à chaud sont utilisés si tous les serveurs et + serveurs de remplacement du jeu de serveurs du répartiteur de charge sont + indisponibles. Les jeux de serveurs du répartiteur de charge (avec leurs + serveurs de standby et de remplacement à chaud respectifs) sont toujours + sollicités dans l'ordre du plus bas lbset vers le plus haut. +
+ +
+ L'application balancer-manager fournie avec le mandataire inverse
+ d'Apache httpd en est un des outils les plus utiles. Comme
+ mod_status, balancer-manager affiche la
+ configuration et l'activité actuelles des balancers actifs. L'affichage de
+ ces informations n'est cependant pas sa seule fonction ; il permet aussi de
+ modifier la plupart d'entre elles et même d'ajouter des membres au groupe
+ de répartition de charge en temps réel. Pour activer ces fonctionnalités,
+ vous devez ajouter les lignes suivantes à votre fichier de configuration :
+
<Location "/balancer-manager"> + SetHandler balancer-manager + Require host localhost +</Location>+ + +
N'activez le balancer-manager que si vous avez déjà sécurisé votre serveur. + Assurez-vous en particulier que l'accès à l'URL soit fortement restreint.
+
+ Lorsque vous accédez au serveur mandataire avec une adresse du style
+ http://rproxy.example.com/balancer-manager/, la page suivante
+ s'affiche :
+
+ Ce formulaire permet à l'administrateur de modifier certains paramètres, + de désactiver ou d'ajouter certains serveurs d'arrière-plan, et de + modifier les règles de répartition de charge. Par exemple, si on clique + sur le répartiteur, la page suivante s'affiche : +
+
+ Si on clique sur un membre du groupe de répartition de charge, la page + suivante s'affiche : +
+
+ Si vous souhaitez que ces modifications soient conservées après un
+ redémarrage du serveur, assurez-vous que la directive BalancerPersist soit définie à On.
+
+ Avant que le mandataire httpd ne fasse appel à un serveur d'arrière-plan, il
+ peut "tester" si ce dernier est disponible en définissant le
+ paramètre ping de ce serveur via la directive ProxyPass. Cependant, il est souvent plus
+ judicieux de vérifier le bon fonctionnement d'un serveur hors
+ bande et de manière dynamique via le module
+ mod_proxy_hcheck d'Apache httpd.
+
+ balancer-manager permet d'afficher et de modifier l'état d'un + membre du groupe de répartition de charge. Les différents états et leurs + significations sont les suivants : +
+| Drapeau | Sigle | Description |
|---|---|---|
| Ok | Le serveur est disponible | |
| Init | Le serveur a été initialisé | |
D | Dis | Le serveur est + désactivé et n'accepte aucune requête ; il sera retesté automatiquement. |
S | Stop | Le serveur a été + arrêté par l'administrateur ; il n'accepte aucune requête et il ne sera + pas retesté automatiquement. |
I | Ign | Les erreurs + concernant ce serveur sont ignorées et il sera donc toujours considéré + comme disponible. |
R | Spar | Le serveur cible sert de remplaçant à + chaud. Lorsqu'un serveur cible avec un lbset donné est inutilisable + (maintenance, arrêt, en erreur, etc...), un serveur de remplacement à + chaud libre de même lbset sera utilisé à sa place. Les remplaçants à + chaud permettent de s'assurer qu'un nombre déterminé de serveurs cibles + sera toujours disponible pour un répartiteur de charge. |
H | Stby | Le serveur est en + mode hot-standby et ne sera donc utilisé que si aucun autre serveur ou + serveur de remplacement n'est disponible dans le jeu de serveurs du + répartiteur de charge. |
E | Err | Le serveur est en
+ erreur, en général suite à un test préalable à une requête ; aucune
+ requête ne lui sera soumise, mais il sera retesté en fonction de la
+ valeur de son paramètre retry. |
N | Drn | Le serveur est en + mode drain ; il n'acceptera de requêtes que dans le cadre des sessions + persistantes qui lui sont réservées et ignorera toutes les autres. |
C | HcFl | Le serveur a échoué + au test dynamique de bon fonctionnement et ne sera utilisé que lorsqu'il + aura réussi un test ultérieur. |
Serveur HTTP Apache Version 2.4
+Les SSI permettent d'ajouter du contenu dynamique à des documents +HTML préexistants.
+ Introduction Qu'est-ce que SSI ? Configurer votre serveur pour permettre les SSI Directives SSI de base Exemples additionnels Que puis-je configurer d'autre ? Exécution de commandes Techniques SSI avancées Conclusion| Modules Apparentés | Directives Apparentées |
|---|---|
Cet article traite des Inclusions Côté Serveur (Server Side + Includes), plus communément appelés SSI. Vous trouverez ici la + manière de configurer votre serveur pour permettre les SSI, ainsi + qu'une introduction à quelques techniques SSI de base permettant + d'ajouter du contenu dynamique à vos pages HTML préexistantes.
+ +La dernière partie de cet article sera consacrée aux + configurations SSI plus avancées, telles que les expressions + conditionnelles dans les directives SSI.
+ +SSI (Server Side Includes) est constitué de directives placées dans + des pages HTML, et évaluées par le serveur au moment où les pages + sont servies. Elles vous permettent d'ajouter du contenu généré + dynamiquement à une page HTML préexistante, sans avoir à servir la + page entière via un programme CGI, ou toute autre technologie de + contenu dynamique.
+ +Par exemple, vous pouvez insérer la directive suivante dans une + page HTML existante :
+ +
+ <!--#echo var="DATE_LOCAL" -->
+
Ainsi, lorsque la page sera servie, la directive sera évaluée et + remplacée par sa valeur :
+ +
+ Tuesday, 15-Jan-2013 19:28:54 EST
+
Le choix entre l'utilisation des SSI et la génération entière de + la page par un programme quelconque, est en général dicté par la + proportion de contenu statique et de contenu devant être généré + chaque fois que la page est servie. SSI est idéal pour ajouter de + petites quantités d'information, comme l'heure courante dans + l'exemple précédent. Mais si la + plus grande partie de votre page est générée au moment où elle est + servie, vous devez vous tourner vers une autre solution.
+Pour permettre l'utilisation des SSI sur votre serveur, vous
+ devez ajouter la directive suivante dans votre fichier
+ httpd.conf, ou dans un fichier .htaccess
+ :
Options +Includes+ + +
Cette directive indique à Apache que vous désirez permettre la
+ recherche de directives SSI lors de l'interprétation des fichiers.
+ Notez cependant que la plupart des configurations contiennent de
+ nombreuses directives Options
+ qui peuvent s'écraser les unes les autres. Vous devrez probablement
+ appliquer ces directives Options au répertoire
+ spécifique pour lequel vous voulez activer les SSI, afin d'être sûr
+ qu'elles y seront bien activées.
Tout fichier ne fera cependant pas l'objet de recherche de
+ directives SSI. Vous devez indiquer à Apache quels fichiers seront
+ concernés. Vous pouvez y parvenir en indiquant une extension, comme
+ .shtml, à l'aide des directives suivantes :
AddType text/html .shtml +AddOutputFilter INCLUDES .shtml+ + +
Un des désavantages de cette approche réside dans le fait que si
+ vous voulez ajouter des directives SSI à une page préexistante, vous
+ devrez changer le nom de cette page, et donc tout lien qui la
+ contient, de façon à ce qu'elle possède l'extension
+ .shtml, condition nécessaire pour que les directives
+ SSI qu'elle contient soient traitées.
Une autre méthode consiste à utiliser la directive XBitHack :
XBitHack on+ + +
La directive XBitHack
+ indique à Apache qu'il doit rechercher des directivves SSI dans les
+ fichiers si leur bit d'exécution est positionné. Il n'est ainsi plus
+ nécessaire de changer le nom du fichier pour ajouter des directives
+ SSI à une page préexistante ; vous devez simplement attribuer les
+ droits d'exécution au fichier à l'aide de chmod.
+ chmod +x pagename.html
+
Un bref commentaire sur ce qu'il ne faut pas faire. Certaines
+ personnes peuvent vous conseiller de tout simplement indiquer à
+ Apache de rechercher des directives SSI dans tous les fichiers
+ .html, ce qui vous évite d'avoir à gérer les noms de
+ fichiers avec extension .shtml. Ils n'ont probablement
+ pas entendu parler de la directive XBitHack. En effet, vous devez
+ garder à l'esprit qu'en faisant ceci, Apache va devoir rechercher
+ des directives SSI dans chaque fichier qu'il sert, même s'il n'en
+ contient aucune. Ce n'est donc pas une bonne idée car les
+ performances peuvent en être sensiblement affectées.
Bien entendu, sous Windows, il n'y a pas de bit d'exécution à + positionner, ce qui limite un peu vos choix.
+ +Dans sa configuration par défaut, Apache n'envoie pas la date de + dernière modification ou les en-têtes HTTP relatifs à la taille des + contenus dans les pages SSI, car ses valeurs sont difficiles à + calculer pour les contenus dynamiques. Ceci peut induire une + impression de diminution des performances côté client, en empêchant + la mise en cache de votre document. Il existe deux méthodes pour + résoudre ce problème :
+ +XBitHack Full. Elle
+ indique à Apache de déterminer la date de dernière modification en
+ ne regardant que la date du fichier à l'origine de la requête,
+ tout en ignorant la date de modification de tout fichier inclus.mod_expires pour définir de manière explicite la
+ date d'expiration de vos fichiers, laissant par la-même
+ aux navigateurs et aux mandataires le soin de déterminer s'il est
+ opportun ou non de les mettre en cache.Les directives SSI adoptent la syntaxe suivante :
+
+ <!--#fonction attribut=valeur attribut=valeur ... -->
+
Le format d'une directive SSI étant similaire à celui d'un + commentaire HTML, si vous n'avez pas activé correctement SSI, le + navigateur l'ignorera, mais elle sera encore visible dans le source + HTML. Si SSI est correctement configuré, la directive sera remplacée + par ses résultats.
+ +"fonction" peut prendre de nombreuses formes, et nous décrirons + plus précisément la plupart d'entre eux dans la prochaine version de + ce document. Pour le moment, voici quelques exemples de ce que vous + pouvez faire avec SSI.
+ +
+ <!--#echo var="DATE_LOCAL" -->
+
La fonction echo permet d'afficher la valeur d'une
+ variable. Il existe un grand nombre de variables standards, y
+ compris l'ensemble des variables d'environnement disponibles pour
+ les programmes CGI. De plus, vous pouvez définir vos propres
+ variables à l'aide de la fonction set.
Si vous n'aimez pas le format sous lequel la date s'affiche, vous
+ pouvez utiliser la fonction config avec un attribut
+ timefmt, pour le modifier.
+ <!--#config timefmt="%A %B %d, %Y" -->
+ Today is <!--#echo var="DATE_LOCAL" -->
+
+ Dernière modification du document <!--#flastmod file="index.html" -->
+
Le format peut là aussi être modifié à l'aide de l'attribut
+ timefmt.
C'est le cas le plus courant d'utilisation des SSI - afficher les + résultats d'un programme CGI, comme l'universellement adoré + "compteur d'accès".
+ +
+ <!--#include virtual="/cgi-bin/counter.pl" -->
+
Vous trouverez dans ce qui suit quelques exemples spécifiques de + ce que vous pouvez faire de vos documents HTML avec SSI.
+ +Nous avons mentionné plus haut que vous pouviez utiliser SSI pour + informer l'utilisateur de la date de dernière modification du + document. Cependant, la méthode pour y parvenir n'a pas été vraiment + abordée. Placé dans votre document HTML, le code suivant va insérer + un repère de temps dans votre page. Bien entendu, SSI devra avoir + été correctement activé, comme décrit plus haut.
+
+ <!--#config timefmt="%A %B %d, %Y" -->
+ Dernière modification du fichier <!--#flastmod file="ssi.shtml" -->
+
Bien entendu, vous devez remplacer ssi.shtml par le
+ nom du fichier auquel vous faites référence. Ceci ne conviendra pas
+ si vous recherchez un morceau de code générique que vous pourrez
+ insérer dans tout fichier ; dans ce cas, il est préférable
+ d'utiliser la variable LAST_MODIFIED :
+ <!--#config timefmt="%D" -->
+ This file last modified <!--#echo var="LAST_MODIFIED" -->
+
Pour plus de détails sur le format timefmt, tapez
+ strftime dans votre moteur de recherche préferé. La
+ syntaxe est identique.
Si le site que vous gérez comporte plus que quelques pages, vous + allez vite vous apercevoir qu'effectuer des modifications sur toutes + ces pages peut devenir très contraignant, en particulier si vous + voulez qu'elles conservent un aspect homogène.
+ +Inclure un fichier pour un en-tête et/ou un pied de page peut
+ simplifier cette corvée de mises à jour. Il vous suffit de
+ confectionner un fichier de pied de page, et de l'inclure dans
+ chaque page à l'aide de l'élément SSI include. Pour
+ définir le fichier à inclure, la fonction include peut
+ utiliser soit l'attribut file, soit l'attribut
+ virtual. L'attribut file est un chemin de
+ fichier relatif au répertoire courant. C'est à dire qu'il
+ ne peut ni avoir pour valeur un chemin absolu (commençant par /), ni
+ comporter "../" dans son chemin. L'attribut virtual est
+ probablement plus commode, et peut spécifier une URL relative au
+ document servi. Elle peut commencer par un /, mais le fichier inclus
+ et le fichier servi doivent résider sur le même serveur.
+ <!--#include virtual="/footer.html" -->
+
Je combinerai souvent ces deux derniers points, en ajoutant une
+ directive LAST_MODIFIED dans un fichier de pied de page
+ destiné à être inclus. Le fichier inclus peut contenir des
+ directives SSI, et les inclusions peuvent être imbriquées - à
+ savoir, le fichier inclus peut inclure un autre fichier, etc...
En plus du format de date, vous pouvez utiliser l'élément
+ config pour configurer deux autres choses.
En général, lorsque quelque chose se passe mal avec votre + directive SSI, vous recevez le message :
+
+ [an error occurred while processing this directive]
+
Pour modifier ce message, vous pouvez utiliser l'attribut
+ errmsg avec la fonction config :
+ <!--#config errmsg="[Il semblerait que vous ne sachiez pas
+ utiliser les SSI]" -->
+
Il est cependant probable que les utilisateurs finaux ne voient + jamais ce message, car vous aurez résolu tous les problèmes issus de + vos directives SSI avant que votre site ne soit mis en production. + (N'est-ce pas ?)
+ +Vous pouvez aussi modifier le format sous lequel les tailles de
+ fichiers sont affichées à l'aide de l'attribut sizefmt.
+ Vous pouvez spécifier bytes pour un affichage en
+ octets, ou abbrev pour un affichage plus concis en Ko
+ ou Mo, selon le cas.
Voici autre chose que vous pouvez faire avec la fonction
+ exec. Vous pouvez vraiment faire exécuter une commande
+ par SSI en utilisant le shell (/bin/sh, pour être plus
+ précis - ou le shell DOS, si vous êtes sous Win32). Par exemple, ce
+ qui suit vous permet d'afficher le contenu d'un répertoire.
+ <pre>
+ <!--#exec cmd="ls" -->
+ </pre>
+
ou, sous Windows
+
+ <pre>
+ <!--#exec cmd="dir" -->
+ </pre>
+
Vous noterez probablement l'étrange formatage provoqué par cette
+ directive sous Windows, car la sortie de dir contient
+ la chaîne de caractères "<dir>", ce qui trompe le
+ navigateur.
Notez que cette fonctionnalité est très dangereuse, car elle va
+ permettre d'exécuter tout code associé à l'élément
+ exec. Si vous êtes dans la situation où les
+ utilisateurs peuvent éditer le contenu de vos pages web, dans le cas
+ d'un "livre d'or" par exemple, assurez-vous de désactiver cette
+ fonctionnalité. Vous pouvez, tout en permettant les SSI, désactiver
+ la fonctionnalité exec à l'aide de l'argument
+ IncludesNOEXEC de la directive
+ Options.
Outre l'affichage de contenu, les SSI d'Apache vous permettent de + définir des variables, et de les utiliser dans des comparaisons et + des conditions.
+ +Avec l'élément set, vous pouvez définir des
+ variables pour un usage ultérieur. Comme nous en aurons besoin plus
+ loin, nous allons en parler tout de suite. La syntaxe se présente
+ comme suit :
+ <!--#set var="name" value="Rich" -->
+
Pour affecter une valeur à vos variables, en plus de la
+ définition littérale de l'exemple ci-dessus, vous pouvez utiliser
+ une autre variable, y compris les variables d'environnement, ou les variables
+ décrites plus haut (comme LAST_MODIFIED par exemple).
+ Pour indiquer qu'il s'agit d'une variable et non d'une chaîne, vous
+ devez utiliser le symbole dollar ($) devant le nom de la
+ variable.
<!--#set var="modified" value="$LAST_MODIFIED" -->
+
Pour insérer un caractère $ dans la valeur de votre variable, + vous devez l'échapper à l'aide d'un backslash.
+
+ <!--#set var="cost" value="\$100" -->
+
Enfin, si vous voulez insérer une variable dans une chaîne, et + s'il y a une chance pour que le nom de la variable se confonde avec + le reste de la chaîne, vous pouvez l'entourer d'accolades pour + eviter toute confusion (Il est difficile de trouver un bon exemple + pour illustrer ceci, mais j'espère que vous comprendrez).
+
+ <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->
+
Maintenent que nous avons des variables, et que nous pouvons
+ définir et comparer leurs valeurs, nous sommes à même de les
+ utiliser dans des expressions conditionnelles. Ceci confère à SSI le
+ statut de petit langage de programmation.
+ mod_include fournit une structure if,
+ elif, else, endif pour la
+ construction d'expressions conditionnelles, ce qui vous permet de
+ générer plusieurs pages logiques à partir d'une seule vraie
+ page.
La structure de l'expression conditionnelle est :
+
+ <!--#if expr="condition" -->
+ <!--#elif expr="condition" -->
+ <!--#else -->
+ <!--#endif -->
+
Une condition peut revêtir la forme de toute comparaison
+ logique - soit une comparaison de valeurs avec une autre, soit une
+ vérification de la "vérité" d'une valeur particulière (Une chaîne
+ donnée est vraie si elle n'est pas vide). Pour une liste exhaustive
+ des opérateurs de comparaison disponibles, voir la documentation du
+ module mod_include.
Par exemple, spour insérer l'heure du jour dans votre page web, + vous pouvez ajouter ces lignes dans la page HTML :
+ +
+ Good
+ <!--#if expr="%{TIME_HOUR} <12" -->
+ morning!
+ <!--#else -->
+ afternoon!
+ <!--#endif -->
+
Toute autre variable (que vous avez définie, ou une variable + d'environnement normale) peut être utilisée dans les expressions + conditionnelles. Voir le document Expressions + rationnelles dans le serveur HTTP Apache pour plus de détails à + propos du fonctionnement du moteur d'évaluation des expressions + rationnelles.
+ +Associée à la possibilité avec Apache de définir
+ des variables d'environnement à l'aide de directives
+ SetEnvIf, ainsi que d'autres directives en rapport,
+ cette fonctionnalité vous permet d'ajouter une grande variété
+ de contenus dynamiques côté serveur sans avoir à concevoir une
+ application web de A à Z.
SSI ne remplace certainement pas CGI, ou d'autres technologies + utilisées pour la génération de pages web dynamiques. Mais c'est une + bonne méthode pour ajouter des petits contenus dynamiques à vos + pages, sans devoir fournir un gros effort supplémentaire.
+Serveur HTTP Apache Version 2.4
+Serveur HTTP Apache Version 2.4
+Ce document couvre l'installation et la compilation du serveur + HTTP Apache + sur les systèmes Unix et similaires seulement. Pour la compilation et + l'installation sous Windows, voir Utiliser le serveur HTTP Apache avec Microsoft + Windows et Compilation + d'Apache sous Microsoft Windows. Pour les autres plateformes, se + référer à la documentation par + plateforme.
+ +Apache httpd utilise libtool et autoconf
+ afin de créer un environnement de construction similaire à la plupart
+ des projets Open Source .
Si vous effectuez une mise à jour depuis une version mineure vers + la suivante (par exemple, 2.4.9 à 2.4.10), veuillez passer à la section + mise à jour.
+ + Aperçu pour les plus pressés Prérequis Téléchargement Extraction Configuration de l'arborescence des sources Construction Installation Personnalisation Test Mise à jour Paquets tierssudo yum install httpd +sudo service httpd start+ + +
dnf à yum. Voir la documentation du
+ projet Fedora pour des informations spécifiques à cette plateforme.sudo apt install apache2 +sudo service apache2 start+ + +
| Téléchargement | + +Téléchargez la dernière version depuis http://httpd.apache.org/download.cgi + | +
| Extraction | + +$ gzip -d httpd-NN.tar.gz |
+
| Configuration | + +$ ./configure --prefix=PREFIX
+ |
+
| Compilation | + +$ make |
+
| Installation | + +$ make install |
+
| Personnalisation | + +$ vi PREFIX/conf/httpd.conf |
+
| Test | + +$ PREFIX/bin/apachectl -k start
+ |
+
NN doit être remplacé par le numéro de version courant,
+ et PREFIX par le
+ chemin du répertoire d'installation. Si
+ PREFIX n'est pas spécifié, le chemin du répertoire
+ d'installation prendra sa valeur par défaut, à savoir
+ /usr/local/apache2.
Chaque étape du processus de compilation et d'installation est + décrite plus en détails ci-dessous, à commencer par les prérequis + pour compiler et installer Apache httpd.
+ +Les prérequis pour la construction d'Apache httpd sont les suivants:
+ +/racine_sources_httpd/srclib/apr et
+ /racine_sources_httpd/srclib/apr-util (les noms des répertoires ne
+ doivent pas comporter de numéros de versions ; par exemple, la
+ distribution d'APR doit se trouver dans /racine_sources_httpd/srclib/apr/), et
+ utilisez l'option --with-included-apr du script
+ ./configure. Sur certaines plateformes, vous devrez
+ peut-être installer les paquets -dev correspondants
+ pour permettre la compilation de httpd avec les versions
+ installées d'APR et APR-Util.--with-pcre du script ./configure. Sur
+ certaines plateformes, vous devrez
+ peut-être installer les paquets -dev correspondants
+ pour permettre la compilation de httpd avec la version
+ installée de PCRE.PATH doit contenir
+ les outils de construction de base tels que make.ntpdate ou xntpd, basés sur le protocole NTP,
+ sont couramment utilisés à cet effet.
+ Voir la page d'accueil de NTP
+ pour plus de détails à propos du logiciel NTP et des serveurs
+ de temps publics.apxs ou dbmmanage
+ (qui sont écrits en Perl).
+ Si le script configure ne trouve pas d'interpréteur
+ Perl 5, vous ne pourrez pas utiliser les scripts qui en ont besoin.
+ Bien entendu, vous pourrez tout de même construire et utiliser
+ Apache httpd.Le serveur HTTP Apache peut être téléchargé à partir du
+ site de téléchargement
+ du serveur HTTP Apache, qui fournit la liste de nombreux miroirs.
+ Il sera plus commode à la plupart des utilisateurs d'Apache sur les
+ systèmes UNIX ou similaires de télécharger et de compiler
+ la version sources. Le processus de construction (décrit ci-dessous) est
+ simple, et vous permet de personnaliser votre serveur selon vos besoins.
+ En outre, les versions binaires sont souvent plus anciennes que les
+ dernières versions sources. Si vous téléchargez une version binaire,
+ suivez les instructions décrites dans le fichier
+ INSTALL.bindist inclus dans la distribution.
Après le téléchargement, il est important de vérifier que vous + disposez d'une version complète et non modifiée du serveur HTTP Apache. + Vous pouvez le faire en testant l'archive téléchargée à l'aide de + la signature PGP. Vous trouverez les détails de cette opération sur la page de téléchargement ainsi qu'un exemple précis décrivant l'utilisation de + PGP.
+ +L'extraction des sources depuis l'archive du serveur HTTP Apache consiste + simplement à décompresser et à désarchiver cette dernière :
+ +
+$ gzip -d httpd-NN.tar.gz
+$ tar xvf httpd-NN.tar
+
Ceci créera, dans le répertoire courant, un nouveau répertoire + contenant le code source de la distribution. Vous devrez vous positionner + dans ce répertoire avant de procéder à la compilation du serveur.
+L'étape suivante consiste à configurer l'arborescence des sources
+ d'Apache en fonction de votre plateforme et de vos besoins personnels.
+ Le script configure, situé à la racine du
+ répertoire de la distribution, a été conçu à cet effet
+ (Les développeurs qui téléchargent
+ une version non officielle de l'arborescence des sources d'Apache
+ devront disposer de
+ autoconf et libtool et
+ exécuter buildconf avant de passer à l'étape suivante,
+ ce qui n'est pas nécessaire pour les versions officielles).
Pour configurer l'arborescence des sources avec les valeurs par défaut
+ pour toutes les options, entrez simplement ./configure.
+ Pour modifier les valeurs des options, configure
+ accepte toute une variété de variables et
+ d'options de ligne de commande.
L'option la plus importante --prefix est le chemin
+ du répertoire d'installation d'Apache, car Apache doit être configuré
+ en fonction de ce chemin pour pouvoir fonctionner correctement.
+ Il est possible de définir plus finement le chemin d'installation des fichiers
+ à l'aide d'options
+ supplémentaires de configure.
À ce niveau, vous pouvez aussi spécifier de quelles fonctionnalités vous
+ voulez disposer dans Apache en activant ou désactivant des modules. Apache est fourni avec un grand nombre de
+ modules inclus par défaut. Ils seront compilés en tant qu'objets partagés (DSOs) qui pourront être chargés
+ ou déchargés à l'exécution. Vous pouvez aussi choisir de compiler
+ les modules statiquement via l'option
+ --enable-module=static.
Des modules supplémentaires peuvent être activés à l'aide de l'option
+ --enable-module, où
+ module est le nom du module sans la chaîne
+ mod_ et où tout caractère de soulignement est converti
+ en tiret. D'une manière similaire,
+ vous pouvez désactiver des modules à l'aide de l'option
+ --disable-module. Faites très attention
+ en utilisant ces options, car configure n'est pas en
+ mesure de vous avertir si le module que vous avez spécifié n'existe pas;
+ il ignorera tout simplement l'option.
En outre, vous devrez peut-être fournir au script
+ configure des informations supplémentaires sur
+ le chemin de votre compilateur, de vos bibliothèques, ou de vos fichiers
+ d'en-têtes. A cet effet, vous pouvez passer des options de ligne de
+ commande ou des variables d'environnement au script
+ configure. Pour plus d'informations, voir la
+ page de manuel de configure, ou lancez le script
+ configure avec l'option --help.
+
Pour vous faire une idée des possibilités qui s'offrent à vous, voici
+ un exemple typique de compilation d'Apache avec le répertoire
+ d'installation /sw/pkg/apache, un compilateur et des drapeaux
+ particuliers et les deux modules additionnels mod_ldap
+ et mod_lua :
+ $ CC="pgcc" CFLAGS="-O2" \
+ ./configure --prefix=/sw/pkg/apache \
+ --enable-ldap=shared \
+ --enable-lua=shared
+
Plusieurs minutes peuvent être nécessaires à
+ configure pour tester la disponibilité des
+ fonctionnalités
+ au sein de votre système, et construire les Makefiles qui seront utilisés
+ par la suite pour compiler le serveur.
Vous trouverez une description détaillée des options de
+ configure dans sa page de manuel.
Vous pouvez maintenant construire les différents éléments qui + composent le paquet Apache en lançant tout simplement la commande :
+ +$ make
Vous devez être patient, car il faut plusieurs minutes pour compiler + une configuration de base, et cette durée peut varier considérablement + en fonction de votre matériel et du nombre de modules que vous avez activés.
+Il est temps maintenant d'installer le paquet dans le répertoire
+ d'installation défini par PREFIX (voir plus haut l'option
+ --prefix) en lançant:
$ make install
Cette étape nécessite habituellement les privilèges + de root, car PREFIX est en général un + répertoire possèdant des droits en écriture + restreints.
+ +Si vous effectuez une mise à jour, l'installation n'écrasera pas + vos fichiers de configuration ou autres documents.
+Ensuite, vous pourrez personnaliser votre Serveur HTTP Apache en
+ éditant les fichiers de configuration
+ situés dans PREFIX/conf/.
$ vi PREFIX/conf/httpd.conf
Consultez le manuel d'Apache situé dans
+ PREFIX/docs/manual/ ou
+ http://httpd.apache.org/docs/2.4/ pour la version la plus
+ récente de ce manuel et la liste complète des directives de configuration disponibles.
Vous pouvez maintenant démarrer votre + serveur HTTP Apache en lançant:
+ +$ PREFIX/bin/apachectl -k start
Vous devriez alors pouvoir requérir votre premier document
+ à l'aide de l'URL http://localhost/. La page web que vous
+ voyez est située dans le répertoire défini par la directive
+ DocumentRoot,
+ qui est généralement PREFIX/htdocs/.
+ Pour arrêter le serveur, lancez:
$ PREFIX/bin/apachectl -k stop
La première étape d'une mise à jour consiste à lire l'annonce de la
+ sortie de la nouvelle version et le fichier CHANGES
+ dans la distribution des sources afin de déceler toutes les modifications
+ qui pourraient affecter votre site. Lors d'un changement majeur de version
+ (par exemple de 2.0 à 2.2 ou de 2.2 à 2.4),
+ il y aura certainement des différences importantes quant à la
+ configuration de la compilation et de l'exécution qui nécessiteront des
+ ajustements manuels. Tous les
+ modules devront aussi être mis à jour pour qu'ils s'adaptent aux
+ changements de l'API des modules.
La mise à jour d'une version mineure à la suivante (par exemple, de
+ 2.2.55 à 2.2.57) est plus aisée. Le processus make install
+ n'écrasera aucun de vos documents existants, fichiers de log,
+ ou fichiers de configuration. De plus, les développeurs font tout
+ leur possible pour éviter les changements entraînant une
+ incompatibilité dans les options de
+ configure, la configuration de l'exécution, ou l'API
+ des modules d'une version mineure à l'autre. Dans la plupart des cas,
+ vous pourrez utiliser une ligne de commande
+ configure identique, le même fichier de configuration,
+ et tous vos modules continueront de fonctionner.
Pour effectuer une mise à jour entre deux versions mineures,
+ commencez par trouver le fichier
+ config.nice dans le répertoire de construction
+ de votre serveur installé ou à la racine de l'arborescence des sources
+ de votre ancienne installation. Il contient la reproduction exacte de la
+ ligne de commande configure que vous avez utilisée pour
+ configurer l'arborescence des sources. Ensuite, pour mettre à jour
+ l'ancienne version vers la nouvelle,
+ il vous suffit de copier le fichier config.nice dans
+ l'arborescence des sources de la nouvelle version, de l'éditer pour
+ effectuer toute modification souhaitée, et de lancer :
+ $ ./config.nice
+ $ make
+ $ make install
+ $ PREFIX/bin/apachectl -k graceful-stop
+ $ PREFIX/bin/apachectl -k start
+
--prefix et un port différents (en ajustant la directive
+ Listen) afin de déceler toute
+ incompatibilité avant d'effectuer la mise à jour définitive.Vous pouvez ajouter des arguments supplémentaires à
+ config.nice ; ils seront alors ajoutés aux options de
+ votre script configure original :
+ $ ./config.nice --prefix=/home/test/apache --with-port=90
+
De nombreux tiers fournissent leur propre distribution du + serveur HTTP Apache à installer sur une plate-forme particulière. On + peut citer les différentes distributions Linux, divers + paquets tiers Windows, Mac OS X, Solaris et de nombreux autres.
+ +Notre license logicielle non seulement permet, mais aussi + encourage ce genre de redistribution. Cependant, ceci conduit à une + situation ou l'organisation de la configuration et les valeurs par + défaut de votre installation du serveur peuvent ne pas correspondre + à ce qui est écrit dans la documentation. Bien que fâcheuse, cette + situation n'est pas appelée à évoluer de sitôt.
+ +Une description + de ces distributions tierces est maintenue dans le wiki du + serveur HTTP, et doit en refléter l'état actuel. Vous devrez + cependant vous familiariser par vous-même avec la gestion du paquet + de votre plate-forme particulière et les procédures d'installation.
+ +Serveur HTTP Apache Version 2.4
+Sous Windows, Apache est habituellement lancé en tant que + service. Pour plus de détails, voir Démarrer Apache en tant + que service.
+ +Sous Unix, le programme httpd
+ est lancé en mode démon et s'exécute de manière permanente en
+ arrière-plan pour gérer les requêtes. Ce document décrit comment invoquer
+ httpd.
Comment Apache démarre Erreurs en cours de démarrage Lancement au démarrage du système Informations supplémentairesSi la directive Listen
+ spécifiée dans le fichier de configuration est à sa valeur par défaut
+ de 80 (ou tout autre port inférieur à 1024), il est nécessaire de
+ posséder les privilèges root pour pouvoir démarrer apache, et lui
+ permettre d'être associé à ce port privilégié. Lorsque le serveur est
+ démarré, il effectue quelques opérations préliminaires
+ comme ouvrir ses fichiers de log, puis il lance plusieurs processus
+ enfants qui ont pour rôle d'écouter et de répondre aux
+ requêtes des clients. Le processus httpd principal
+ continue à s'exécuter sous l'utilisateur root, tandis que les processus
+ enfants s'exécutent sous un utilisateur aux privilèges restreints.
+ Ceci s'effectue par la voie du
+ Module Multi-Processus (MPM).
Il est recommandé d'utiliser le script de contrôle
+ apachectl pour invoquer l'exécutable
+ httpd. A cet effet, ce script définit certaines variables
+ d'environnement nécessaires pour permettre à
+ httpd de fonctionner correctement sous certains systèmes
+ d'exploitation.
+ apachectl accepte des arguments de ligne de
+ commande ;
+ ainsi toute option de httpd peut aussi être utilisée avec
+ apachectl. Vous pouvez aussi éditer directement le
+ script apachectl en modifiant la variable
+ HTTPD située en début de script pour spécifier la
+ localisation du binaire httpd et tout argument de ligne
+ de commande que vous souhaitez voir systématiquement présent.
La première chose qu'effectue httpd quand il est
+ invoqué est de localiser et lire le fichier de configuration
+ httpd.conf. La localisation de ce fichier est définie à la
+ compilation, mais il est possible d'en spécifier une autre à
+ l'exécution en utilisant l'option de ligne de commande -f comme suit:
/usr/local/apache2/bin/apachectl -f
+ /usr/local/apache2/conf/httpd.conf
Si tout se passe bien pendant le démarrage, le serveur va se dissocier
+ du terminal et l'invite de commande réapparaîtra presque immédiatement.
+ Ceci indique que le serveur a démarré et est en cours d'exécution.
+ À partir de ce moment, vous pouvez utiliser votre navigateur pour vous connecter
+ au serveur et afficher la page de test située dans le répertoire défini
+ par la directive DocumentRoot
Si un problème fatal survient pendant le démarrage
+ d'Apache, ce dernier va
+ afficher un message décrivant le problème sur la console ou
+ enregistrer ces informations dans le fichier défini par la directive
+ ErrorLog avant de quitter.
+ Un des messages d'erreur les plus courants est "Unable
+ to bind to Port ...". Ce message d'erreur est habituellement
+ provoqué par :
Pour plus d'instructions de dépannage, consultez la + FAQ Apache.
+Si vous souhaitez que votre serveur web soit automatiquement
+ disponible après
+ un redémarrage du système, vous devez ajouter un appel à
+ apachectl à vos
+ fichiers de démarrage système (en général rc.local ou un
+ fichier dans un répertoire rc.N), ce qui démarrera Apache sous
+ l'utilisateur root. Avant de faire ceci, assurez-vous que votre serveur
+ soit correctement configuré en ce qui concerne la sécurité et les
+ restrictions d'accès.
Le script apachectl est conçu pour fonctionner
+ comme un script d'initialisation SysV standard ; il accepte les arguments
+ start, restart, et stop
+ et les traduit en signaux appropriés pour
+ httpd, et il suffit en général d'installer
+ un lien vers
+ apachectl dans le répertoire d'initialisation approprié.
+ Mais prenez soin de vérifier les besoins exacts de votre système
+ en la matière.
Des informations supplémentaires à propos des options en ligne de
+ commande de httpd et apachectl
+ ainsi que d'autres programmes support inclus dans la distribution
+ sont disponibles sur la page
+ Le serveur et ses programmes support.
+ Il existe aussi une documentation sur tous les modules inclus dans la distribution Apache
+ et les directives
+ qu'ils supportent.
Serveur HTTP Apache Version 2.4
+Pour véritablement gérer un serveur web, + il est nécessaire de disposer d'un + retour d'informations à propos de l'activité et des performances du + serveur, ainsi que de tout problème qui pourrait survenir. Le serveur HTTP + Apache propose des fonctionnalités de journalisation souples et très + complètes. Ce document décrit comment configurer ces fonctionnalités de + journalisation et interpréter le contenu des journaux.
+ Vue d'ensemble Avertissement à propos de la sécurité Journal des erreurs Journalisation par module Journal des accès Rotation des journaux Journaux redirigés Hôtes virtuels Autres fichiers journaux| Modules Apparentés | Directives Apparentées |
|---|---|
+ Le serveur HTTP Apache fournit toute une variété de mécanismes + différents pour la journalisation de tout ce qui peut se passer au + sein de votre serveur, depuis la requête initiale, en passant par le + processus de mise en correspondance des URLs, et jusqu'à la fermeture + de la connexion, y compris toute erreur pouvant survenir au cours du + traitement. De plus, certains modules tiers fournissent des + fonctionnalités de journalisation ou insèrent des entrées dans les + fichiers journaux existants, et les applications comme les programmes + CGI, les scripts PHP ou autres gestionnaires peuvent envoyer des + messages vers le journal des erreurs du serveur. +
+ ++ Ce document décrit le fonctionnement des modules de journalisation + fournis en standard avec le serveur httpd. +
+ +Tout utilisateur qui a les droits en écriture sur le répertoire dans + lequel Apache httpd écrit ses journaux pourra quasi + certainement avoir accès à l'uid sous lequel le serveur est démarré, en + l'occurrence habituellement root. N'accordez PAS aux utilisateurs + l'accès en écriture au répertoire dans lequel les journaux sont stockés + sans savoir exactement quelles en seraient les conséquences ; voir le + document conseils sur la sécurité + pour plus de détails.
+ +En outre, les journaux peuvent contenir des informations fournies + directement par un client, sans caractères d'échappement. Des clients mal + intentionnés peuvent donc insérer des caractères de contrôle dans les + journaux, et il convient par conséquent d'être très prudent lors de la + manipulation des journaux bruts.
+| Modules Apparentés | Directives Apparentées |
|---|---|
Le journal des erreurs du serveur, dont le nom et la localisation sont
+ définis par la directive ErrorLog,
+ est le journal le plus important. C'est dans celui-ci
+ que le démon Apache httpd va envoyer les informations de diagnostic et
+ enregistrer toutes les erreurs qui surviennent lors du traitement des
+ requêtes. Lorsqu'un problème survient au démarrage du serveur ou pendant
+ son fonctionnement, la première chose à faire est de regarder dans ce
+ journal, car il vous renseignera souvent sur le problème rencontré et
+ la manière d'y remédier.
Le journal des erreurs est habituellement enregistré dans un fichier
+ (en général error_log sur les systèmes de type Unix et
+ error.log sur Windows et OS/2). Sur les systèmes de type Unix,
+ le serveur peut aussi enregistrer ses erreurs dans
+ syslog ou les
+ rediriger vers un programme par l'intermédiaire d'un
+ tube de communication (pipe).
Le format par défaut du journal des erreurs est descriptif et de forme + relativement libre. Certaines informations apparaissent cependant dans la + plupart des entrées du journal. Voici un message typique + à titre d'exemple :
+ +
+ [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
+ client denied by server configuration:
+ /export/home/live/ap/htdocs/test
+
Le premier champ de l'entrée du journal est la date et l'heure du
+ message. Le second champ indique la sévérité de l'erreur rapportée. La
+ directive LogLevel permet de
+ restreindre le type des erreurs qui doivent être enregistrées
+ dans le journal des erreurs en définissant leur niveau de sévérité. Le
+ troisième champ contient l'adresse IP du client qui a généré l'erreur.
+ Vient ensuite le message proprement dit, qui indique dans ce cas que le
+ serveur a été configuré pour interdire l'accès au client. Le serveur
+ indique le chemin système du document requis (et non
+ son chemin web).
Une grande variété de messages différents peuvent apparaître dans le
+ journal des erreurs. La plupart d'entre eux sont similaires à l'exemple
+ ci-dessus. Le journal des erreurs peut aussi contenir des informations de
+ débogage en provenance de scripts CGI. Toute information qu'un script CGI
+ écrit sur la sortie d'erreurs standard stderr sera recopiée
+ telle quelle dans le journal des erreurs.
La directive ErrorLogFormat
+ vous permet de personnaliser le format du journal des erreurs, et de
+ définir les informations à journaliser. Si
+ mod_unique_id est présent, vous pouvez utiliser le
+ drapeau %L à la fois dans le journal des erreurs et
+ dans le
+ journal des accès, ce qui aura pour effet de générer un identifiant
+ d'entrée qui vous permettra de corréler les entrées du journal des
+ erreurs avec celles du journal des accès.
Pendant la phase de test, il est souvent utile de visualiser en continu + le journal des erreurs afin de détecter tout problème éventuel. Sur les + systèmes de type Unix, ceci s'effectue à l'aide de la commande :
+ +
+ tail -f error_log
+
La directive LogLevel permet
+ de spécifier un niveau de sévérité de journalisation pour chaque
+ module. Vous pouvez ainsi résoudre un problème propre à un module particulier
+ en augmentant son volume de journalisation sans augmenter ce volume
+ pour les autres modules. Ceci est particulièrement utile lorsque
+ vous voulez obtenir des détails sur le fonctionnement de modules
+ comme mod_proxy ou mod_rewrite.
Pour ce faire, vous devez spécifier le nom du module dans votre
+ directive LogLevel :
LogLevel info rewrite:trace5+ + +
Dans cet exemple, le niveau de journalisation général est défini
+ à info, et à trace5 pour mod_rewrite.
RewriteLog.| Modules Apparentés | Directives Apparentées |
|---|---|
Le journal des accès au serveur
+ enregistre toutes les requêtes que traite
+ ce dernier. La localisation et le contenu du journal des accès sont définis
+ par la directive CustomLog.
+ La directive LogFormat
+ permet de simplifier la sélection du contenu du journal. Cette section
+ décrit comment configurer le serveur pour l'enregistrement des informations
+ dans le journal des accès.
Bien évidemment, le stockage d'informations dans le journal des accès + n'est que le point de départ de la gestion de la journalisation. L'étape + suivante consiste à analyser ces informations de façon à pouvoir en + extraire des statistiques utiles. L'analyse de journaux en général est en + dehors du sujet de ce document et ne fait pas vraiment partie intégrante + du travail du serveur web lui-même. Pour plus d'informations à propos de ce + sujet et des applications dédiées à l'analyse de journaux, vous pouvez vous + référer à Open Directory.
+ +Différentes versions du démon Apache httpd utilisaient d'autres modules
+ et directives pour contrôler la journalisation des accès, à l'instar de
+ mod_log_referer, mod_log_agent, et de la directive
+ TransferLog. La directive
+ CustomLog rassemble
+ désormais les fonctionnalités de toutes les anciennes directives.
Le format du journal des accès est hautement configurable. Il est
+ défini à l'aide d'une chaîne de format qui ressemble sensiblement à la
+ chaîne de format de style langage C de printf(1). Vous trouverez quelques
+ exemples dans les sections suivantes. Pour une liste exhaustive de ce que
+ peut contenir une chaîne de format, vous pouvez vous référer au chapitre
+ chaînes de format de la
+ documentation du module mod_log_config.
Voici une configuration typique pour le journal des accès :
+ +LogFormat "%h %l %u %t \"%r\" %>s %b" common +CustomLog logs/access_log common+ + +
Ici est définie l'identité common qui est
+ ensuite associée à une chaîne de format de journalisation particulière.
+ La chaîne de format est constituée de directives débutant par le
+ caractère %, chacune d'entre elles indiquant au serveur d'enregistrer
+ un élément particulier d'information. Des caractères littéraux peuvent
+ aussi être insérés dans la chaîne de format ; il seront copiés tels
+ quels dans le flux de sortie destiné à la journalisation.
+ Les guillemets (") doivent être échappées en les faisant
+ précéder d'un anti-slash (\) afin qu'elles ne soient pas
+ interprétées comme la fin de la chaîne de format. La chaîne de format
+ peut aussi contenir les caractères de contrôle spéciaux
+ "\n" et "\t" pour insérer respectivement
+ un passage à la ligne et une tabulation.
La directive CustomLog
+ définit un nouveau fichier journal en l'associant à l'identité
+ précédemment définie. Le chemin du nom de fichier associé au journal
+ des accès est relatif au chemin défini par la directive
+ ServerRoot, sauf s'il
+ débute par un slash.
La configuration ci-dessus va enregistrer les entrées de + journalisation selon un format connu sous le nom de + Common Log Format (CLF) pour "Format de journalisation standard". + Ce format standard peut être produit par de nombreux serveurs web + différents et lu par de nombreux programmes d'analyse de journaux. + Les entrées de fichier journal générées selon le format CLF + ressemblent à ceci :
+ +
+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
+ /apache_pb.gif HTTP/1.0" 200 2326
+
Chaque partie de cette entrée de journal est décrite + dans ce qui suit.
+ +127.0.0.1 (%h)HostnameLookups est positionnée à
+ On, le serveur va essayer de déterminer le nom de l'hôte
+ et de l'enregistrer à la place de l'adresse IP. Cette configuration
+ n'est cependant pas recommandée car elle peut ralentir le serveur de
+ manière significative. Il est par conséquent préférable d'utiliser un
+ processeur d'analyse de journaux a posteriori
+ tel que logresolve
+ pour déterminer les noms d'hôte. L'adresse IP indiquée ici n'est pas
+ nécessairement l'adresse IP de la machine devant laquelle se trouve
+ l'utilisateur. Si un serveur mandataire s'intercale entre le serveur
+ et l'utilisateur, l'adresse indiquée sera celle du mandataire et non
+ celle de la machine à l'origine de la requête.- (%l)identd sur la machine cliente. Cette information est
+ très peu fiable et ne devrait jamais être utilisée, sauf dans le cas
+ de réseaux internes étroitement contrôlés. Le démon httpd ne cherchera
+ d'ailleurs à obtenir cette information que si la directive
+ IdentityCheck est positionnée
+ à On.frank (%u)REMOTE_USER. Si le statut de la requête (voir plus loin)
+ est 401, cette identifiant n'est pas fiable car l'utilisateur n'est
+ pas encore authentifié. Si le document n'est pas protégé par
+ mot de passe, cette partie d'information sera représentée par
+ "-", comme la partie précédente.[10/Oct/2000:13:55:36 -0700]
+ (%t)
+ [jour/mois/année:heure:minutes:secondes zone]
+
+ jour = 2*chiffre
+ mois = 3*lettre
+ année = 4*chiffre
+ heure = 2*chiffre
+ minutes = 2*chiffre
+ secondes = 2*chiffre
+ zone = (`+' | `-') 4*chiffre
%{format}t dans la chaîne de format du
+ journal, où format est une chaîne de format
+ de la forme de celle de la fonction strftime(3)
+ de la bibliothèque C standard, ou choisie parmi les
+ formats spéciaux supportés. Pour plus de détails,
+ reportez-vous aux. chaînes de format
+ de mod_log_config.
+ "GET /apache_pb.gif HTTP/1.0"
+ (\"%r\")GET. Ensuite, le
+ client a demandé la ressource /apache_pb.gif, et enfin,
+ le client a utilisé le protocole HTTP/1.0. Il est aussi
+ possible d'enregistrer séparément une ou plusieurs parties de la
+ requête. Par exemple, la chaîne de format "%m %U %q %H"
+ va enregistrer la méthode, le chemin, la chaîne de la requête et le
+ protocole, ce qui donnera le même résultat que
+ "%r".200 (%>s)2326 (%b)-". Pour indiquer l'absence de contenu
+ par "0", utilisez %B au lieu de
+ %b.Une autre chaîne de format couramment utilisée est le + "Combined Log Format" (Format de journalisation combiné). Il s'utilise + comme suit :
+ +LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
+CustomLog log/access_log combined
+
+
+ Ce format est identique au Common Log Format, avec deux champs
+ supplémentaires. Chacun de ces deux champs utilise la directive
+ commençant par le caractère "%" %{header}i,
+ où header peut être n'importe quel en-tête de requête HTTP.
+ Avec ce format, le journal des accès se présentera comme suit :
+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
+ /apache_pb.gif HTTP/1.0" 200 2326
+ "http://www.example.com/start.html" "Mozilla/4.08 [en]
+ (Win98; I ;Nav)"
+
Les champs supplémentaires sont :
+ +"http://www.example.com/start.html"
+ (\"%{Referer}i\")/apache_pb.gif ou
+ inclut ce dernier fichier)."Mozilla/4.08 [en] (Win98; I ;Nav)"
+ (\"%{User-agent}i\")Plusieurs journaux d'accès peuvent être créés en spécifiant tout
+ simplement plusieurs directives
+ CustomLog dans le
+ fichier de configuration. Par exemple, les directives suivantes vont
+ créer trois journaux d'accès. Le premier contiendra les informations
+ de base CLF, le second les informations du Referer, et le troisième
+ les informations sur le navigateur. Les deux dernières directives
+ CustomLog montrent
+ comment simuler les effets des directives ReferLog et
+ AgentLog.
LogFormat "%h %l %u %t \"%r\" %>s %b" common
+CustomLog logs/access_log common
+CustomLog logs/referer_log "%{Referer}i -> %U"
+CustomLog logs/agent_log "%{User-agent}i"
+
+
+ Cet exemple montre aussi qu'il n'est pas obligatoire d'associer
+ une chaîne de format à un alias au moyen de la directive
+ LogFormat. Elle peut
+ être définie directement dans la ligne de la directive
+ CustomLog.
Il est parfois souhaitable d'exclure certaines entrées des journaux
+ d'accès en fonction des caractéristiques de la requête du client. On
+ peut aisément accomplir ceci à l'aide des
+ variables d'environnement. Tout d'abord, une
+ variable d'environnement doit être définie pour indiquer que la
+ requête remplit certaines conditions. Pour ceci, on utilise en général
+ la directive SetEnvIf,
+ puis la clause env= de la directive
+ CustomLog pour inclure
+ ou exclure les requêtes pour lesquelles
+ la variable d'environnement est définie.
+ Quelques exemples :
# Marque les requêtes en provenance de l'interface loop-back +SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog +# Marque les requêtes pour le fichier robots.txt +SetEnvIf Request_URI "^/robots\.txt$" dontlog +# Journalise toutes les autres requêtes +CustomLog logs/access_log common env=!dontlog+ + +
Autre exemple, imaginons l'enregistrement des requêtes en provenance + d'utilisateurs de langue anglaise dans un journal, et celles des autres + utilisateurs dans un autre journal.
+ +SetEnvIf Accept-Language "en" english + CustomLog logs/english_log common env=english + CustomLog logs/non_english_log common env=!english+ + +
Dans le contexte d'une mise en cache, il peut être + intéressant de connaître l'efficacité du cache. Pour y parvenir, + on pourrait utiliser cette méthode simple :
+ +SetEnv CACHE_MISS 1
+LogFormat "%h %l %u %t "%r " %>s %b %{CACHE_MISS}e" common-cache
+CustomLog logs/access_log common-cache
+
+
+ mod_cache va s'exécuter avant
+ mod_env, et si son action est couronnée de
+ succès, il délivrera le contenu sans faire appel à ce dernier. Si
+ l'URL se trouve dans le cache, la valeur journalisée sera alors
+ -, tandis que dans le cas contraire elle sera
+ 1.
En plus de la syntaxe env=, la directive LogFormat supporte les
+ valeurs de journalisation conditionnelles basées sur le code de la
+ réponse HTTP :
LogFormat "%400,501{User-agent}i" browserlog
+LogFormat "%!200,304,302{Referer}i" refererlog
+
+
+ Dans le premier exemple, le User-agent sera
+ enregistré si le code d'état HTTP est 400 ou 501. Dans le cas
+ contraire, c'est un caractère "-" qui sera enregistré à la place.
+ Dans le second exemple, le Referer sera enregistré si
+ le code d'état HTTP n'est pas 200, 204, ou 302
+ (remarquez le caractère "!" avant les codes d'état).
Bien que nous venions de montrer que la journalisation conditionnelle + est souple et très puissante, cette méthode de contrôle du contenu des + journaux n'est pas la seule. Les fichiers journaux sont plus utiles + quand ils contiennent un enregistrement complet de l'activité du serveur, + et il est souvent plus aisé de simplement traiter à posteriori les fichiers + journaux pour supprimer les requêtes que vous ne voulez pas y voir + apparaître.
+ +Même dans le cas d'un serveur modérément sollicité, la quantité + d'informations stockées dans les fichiers journaux est très importante. + Le fichier journal des accès grossit en général d'1 Mo ou plus toutes + les 10000 requêtes. Il est par conséquent nécessaire d'effectuer + périodiquement la rotation des journaux en déplaçant ou supprimant les + fichiers correspondants. On ne peut pas le faire pendant que le serveur + est en cours d'exécution, car Apache httpd va continuer à écrire dans l'ancien + fichier journal aussi longtemps qu'il le maintiendra ouvert. + C'est pourquoi le serveur doit être + redémarré après le déplacement ou la + suppression des fichiers journaux de façon à ce qu'il en ouvre + de nouveaux.
+ +Avec un redémarrage graceful, on peut faire en sorte que le + serveur ouvre de nouveaux fichiers journaux sans perdre de connexions + existantes ou en cours avec les clients. Cependant, pour que ceci soit + possible, le serveur doit continuer à écrire dans les anciens fichiers + journaux pendant qu'il termine le traitement des requêtes en cours. + Il est donc nécessaire d'attendre un certain temps après le rédémarrage + avant d'effectuer tout traitement sur les fichiers journaux. Voici un + scénario typique dans lequel on effectue une simple rotation des + journaux en compressant les anciens fichiers correspondants afin + de gagner de l'espace disque :
+ +
+ mv access_log access_log.old
+ mv error_log error_log.old
+ apachectl graceful
+ sleep 600
+ gzip access_log.old error_log.old
+
La section suivante présente une autre méthode de rotation des journaux + qui consiste à utiliser les + journaux redirigés.
+Nous avons vu que le démon httpd écrivait les informations de
+ journalisation des erreurs et des accès dans un fichier journal ;
+ il peut aussi
+ rediriger ces informations vers un autre processus par l'intermédiaire d'un
+ tube de communication (pipe). Cette fonctionnalité améliore
+ considérablement la souplesse de la journalisation, sans ajouter de code
+ au serveur principal. Pour rediriger les informations de journalisation
+ vers un tube de communication, remplacez simplement le nom de fichier
+ journal par
+ le caractère pipe "|", suivi du nom de l'exécutable qui va
+ recueillir les entrées de journal sur son entrée
+ standard. Le serveur va
+ lancer le processus de redirection des journaux au moment du démarrage du
+ serveur, et le relancera s'il cesse de fonctionner
+ pendant l'exécution du serveur.
+ (Nous dénommons cette technique "journalisation
+ redirigée fiable" grâce à cette dernière fonctionnalité.)
Les processus de journalisation redirigée sont lancés par le processus + httpd parent, et héritent de l'UID de ce dernier. Cela signifie que les + programmes de journalisation dirigée s'exécutent généralement en tant que + root. Il est donc très important que ces programmes soient simples et + sécurisés.
+ +Un des grands avantages de la journalisation redirigée est la possibilité
+ d'effectuer la rotation des journaux sans avoir à redémarrer le serveur. Pour
+ accomplir cette tâche, le serveur HTTP Apache fournit un programme simple
+ appelé rotatelogs. Par exemple, pour une rotation des
+ journaux toutes les 24 heures, ajoutez ces lignes :
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common+ + +
Notez que l'ensemble de la commande qui sera appelée par le tube de + communication a été placée entre guillemets. Bien que cet exemple + concerne le journal des accès, la même technique peut être utilisée + pour le journal des erreurs.
+ +Comme la journalisation conditionnelle, la journalisation redirigée est + un outil très puissant, mais si elle existe, il est préférable d'utiliser + une solution plus simple comme le traitement à posteriori hors ligne.
+ + +Par défaut, le processus de redirection du journal est lancé sans
+ invoquer un shell. Pour invoquer un shell, utilisez "|$"
+ au lieu de "|" (en général avec /bin/sh -c)
+ :
# Invocation de "rotatelogs" en utilisant un shell +CustomLog "|$/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common+ + + +
Il s'agissait du comportement par défaut sous Apache 2.2. Selon
+ les spécificités du shell, ceci peut générer un processus shell
+ supplémentaire pour toute la durée du programme de redirection du
+ journal, et induire des problèmes de gestion de signaux au cours du
+ redémarrage. La notation "||" est aussi supportée pour
+ des raisons de compatibilité avec Apache 2.2 et est équivalente à
+ "|".
Notez que sous Windows, la mémoire allouée au bureau (desktop
+ heap) peut devenir insuffisante si vous utilisez de nombreux
+ processus vers lesquels sont redirigés des journaux via un pipe, et
+ ceci particulièrement si httpd s'exécute en tant que service. La
+ quantité de mémoire du bureau allouée à chaque service est spécifiée
+ dans le troisième argument du paramètre SharedSection
+ de la clé de registre
+ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\SubSystems\Windows.
+ Modifiez cette valeur avec prudence ; les
+ précautions d'usage s'imposent lorsqu'on modifie la base de registre,
+ mais vous pouvez aussi saturer la mémoire du bureau si vous
+ spécifiez une valeur trop élevée.
Lorsqu'un serveur possède plusieurs hôtes virtuels, il existe de nombreuses solutions pour gérer
+ les fichiers journaux. Par exemple, on peut utiliser les journaux comme
+ s'il s'agissait d'un serveur avec un seul hôte. Il suffit pour cela de
+ placer les directives de journalisation en dehors des sections
+ <VirtualHost> au niveau
+ du serveur principal, ce qui a pour effet de journaliser toutes les
+ requêtes dans le même journal des accès et des erreurs. Cette technique
+ est cependant inappropriée pour recueillir des statistiques sur chaque
+ hôte virtuel individuellement.
Si des directives CustomLog ou
+ ErrorLog sont placées dans une section
+ <VirtualHost>, toutes les
+ requêtes ou erreurs pour cet hôte virtuel ne seront enregistrées que dans
+ le fichier spécifié. Tout hôte virtuel qui ne possède pas de directives de
+ journalisation verra ses requêtes enregistrées dans le journal du serveur
+ principal. Cette technique est appropriée pour un petit nombre d'hôtes
+ virtuels, mais si ce nombre est important, elle peut devenir compliquée à
+ gérer. En outre, des problèmes de nombre de descripteurs
+ de fichiers insuffisant peuvent rapidement apparaître.
Il existe un très bon compromis pour le journal des accès. En intégrant + les informations à propos de l'hôte virtuel à la chaîne de format du + journal, il est possible de journaliser tous les hôtes dans le même + journal, puis de séparer ultérieurement le journal en plusieurs journaux + individuels. Considérons par exemple les directives suivantes :
+ +LogFormat "%v %l %u %t \"%r\" %>s %b" comonvhost +CustomLog logs/access_log comonvhost+ + +
Le champ %v sert à enregistrer le nom de l'hôte virtuel qui
+ traite la requête. Un programme tel que split-logfile peut ensuite être utilisé
+ pour générer "à froid" autant de journaux que d'hôtes virtuels.
| Modules Apparentés | Directives Apparentées |
|---|---|
Le module mod_logio fournit deux champs
+ LogFormat supplémentaires
+ (%I et %O) qui permettent d'enregistrer le nombre réel d'octets reçus et
+ envoyés sur le réseau.
Le module mod_log_forensic permet la journalisation
+ à des fins d'investigation judiciaire des requêtes des clients. La
+ journalisation est effectuée avant et après le traitement de la requête,
+ qui fait donc l'objet de deux entrées dans le journal. Le générateur de
+ journaux d'investigation est très strict et ne permet aucune
+ personnalisation. C'est un inestimable outil de débogage et de sécurité.
Au démarrage, le démon httpd Apache enregistre l'identifiant du
+ processus httpd parent dans le fichier logs/httpd.pid.
+ Le nom de ce fichier peut être modifié à l'aide de la directive
+ PidFile. Cet identifiant
+ permet à l'administrateur de redémarrer et arrêter le démon en
+ envoyant des signaux au processus parent ; sous Windows, vous devez
+ utiliser l'option de ligne de commande -k. Pour plus de détails,
+ consulter la page Arrêt et redémarrage.
Afin de faciliter le débogage, la directive
+ ScriptLog vous permet
+ d'enregistrer les entrées et sorties des scripts CGI. Elle ne doit être
+ utilisée que pendant la phase de test, et en aucun cas sur un
+ serveur en production. Vous trouverez plus d'informations dans la
+ documentation du module mod_cgi.
Serveur HTTP Apache Version 2.4
+Vous trouverez plus loin une liste de pages de documentation + additionnelles concernant le projet de développement du serveur web + Apache.
+ +La mise à jour des documents ci-dessous permettant de prendre en + compte les modifications apportées par la version 2.1 du serveur + HTTP Apache n'a pas été entièrement menée à bien. Certaines + informations sont probablement encore pertinentes, mais utilisez-les tout de même avec + précautions.
+Notes à propos de la configuration d'Apache pour de plus + hautes performances (à l'exécution et à la compilation). Notes + expliquant pourquoi Apache accomplit certaines choses et + n'en accomplit pas certaines autres (les premières l'accélérant + et les deuxièmes le ralentissant).
+Quelques conseils de type "faites" ou "ne faites pas" pour + que votre site web Apache reste sécurisé.
+Ce document constitue une page de référence pour la plupart + des standards concernés par Apache.
+Discussion à propos des divers algorithmes de chiffrement + supportés par Apache à des fins d'authentification.
+Serveur HTTP Apache Version 2.4
+Notes à propos des formats de chiffrement des mots de passe + générés et compris par Apache.
+Voici les cinq formats de mots de passe qu'Apache reconnaît + pour l'authentification de base. Notez que tous les formats ne sont + pas supportés par toutes les plates-formes :
+ +crypt(3) avec une source d'entropie sur 32 bits
+ (seuls 12 bits sont utilisés), et seulement les 8 premiers
+ caractères du mot de passe. Non sûr.
+ $ htpasswd -nbB monNom monMot-de-passe
+ monNom:$2y$05$c4WoMPo3SXsafkva.HHa6uXQZWr7oboPiC2bT/r7q1BB8I2s0BRqC
+
+ $ htpasswd -nbm monNom monMot-de-passe
+ monNom:$apr1$r31.....$HqJZimcKQFAMYayBlzkrA/
+
+ $ htpasswd -nbs monNom monMot-de-passe
+ monNom:{SHA}VBPuJHI7uixaa6LQGWx4s+5GKNE=
+
+ $ htpasswd -nbd monNom monMot-de-passe
+ monNom:rqXexS6ZhobKA
+
OpenSSL connaît l'algorithme MD5 spécifique à Apache.
+ +
+ $ openssl passwd -apr1 monMot-de-passe
+ $apr1$qHDFfhPC$nITSVHgYbDAK1Y0acGRnY0
+
+ openssl passwd -crypt monMot-de-passe
+ qQ5vTYO3c8dsU
+
La source d'entropie pour un mot de passe CRYPT est constituée
+ des deux premiers caractères (convertis en valeur binaire). Pour
+ valider monMot-de-passe par rapport à
+ rqXexS6ZhobKA
+ $ openssl passwd -crypt -salt rq monMot-de-passe
+ Warning: truncating password to 8 characters
+ rqXexS6ZhobKA
+
Notez que spécifier monMot-d au lieu de
+ monMot-de-passe produira le même résultat car seuls
+ les 8 premiers caractères des mots de passe CRYPT sont pris en
+ compte.
La source d'entropie pour un mot de passe MD5 se situe entre
+ $apr1$ et le caractère $ suivant (sous
+ la forme d'une valeur binaire codée en Base64 - au maximum 8
+ caractères). Pour valider monMot-de-passe par rapport
+ à $apr1$r31.....$HqJZimcKQFAMYayBlzkrA/
+ $ openssl passwd -apr1 -salt r31..... monMot-de-passe
+ $apr1$r31.....$HqJZimcKQFAMYayBlzkrA/
+
La variante SHA1 constitue probablement le format le mieux + approprié pour l'authentification DBD. Comme les fonctions SHA1 et + Base64 sont en général disponibles, d'autres logiciels peuvent + renseigner une base de données avec des mots de passe chiffrés + utilisables par l'authentification basique d'Apache.
+ +Pour créer des mots de passe au format SHA1 pour + l'authentification de base d'Apache dans divers langages :
+ +
+ '{SHA}' . base64_encode(sha1($password, TRUE))
+
+ "{SHA}" + new sun.misc.BASE64Encoder().encode(java.security.MessageDigest.getInstance("SHA1").digest(password.getBytes()))
+
+ "{SHA}" & ToBase64(BinaryDecode(Hash(password, "SHA1"), "Hex"))
+
+ require 'digest/sha1'
+ require 'base64'
+ '{SHA}' + Base64.encode64(Digest::SHA1.digest(password))
+
+ Utilisez la fonction APR : apr_sha1_base64
+
+ import base64
+ import hashlib
+ "{SHA}" + format(base64.b64encode(hashlib.sha1(password).digest()))
+
+
+ '{SHA}'||encode(digest(password,'sha1'),'base64')
+
Apache ne reconnaît qu'un format pour les mots de passe
+ d'authentification à base de condensés - le condensé MD5 de la
+ chaîne utilisateur:domaine-de-protection:mot-de-passe
+ sous la forme d'une chaîne de 32 caractères au format hexadécimal.
+ domaine-de-protection est l'identifiant du domaine de
+ protection de l'autorisation passé en argument à la directive
+ AuthName dans
+ httpd.conf.
Comme la fonction MD5 est en général disponible, d'autres + logiciels peuvent renseigner une base de données avec des mots de + passe chiffrés utilisables par l'authentification à base de + condensés d'Apache.
+ +Pour créer des mots de passe pour l'authentification à base de + condensés d'Apache dans divers langages :
+ +
+ md5($user . ':' . $realm . ':' .$password)
+
+ byte b[] = java.security.MessageDigest.getInstance("MD5").digest( (user + ":" + realm + ":" + password ).getBytes());
+ java.math.BigInteger bi = new java.math.BigInteger(1, b);
+ String s = bi.toString(16);
+ while (s.length() < 32)
+
+ s = "0" + s;
+
+ // La chaîne s contient le mot de passe chiffré
+
+ LCase(Hash( (user & ":" & realm & ":" & password) , "MD5"))
+
+ require 'digest/md5'
+ Digest::MD5.hexdigest(user + ':' + realm + ':' + password)
+
+
+ encode(digest( user || ':' || realm || ':' || password , 'md5'), 'hex')
+
Serveur HTTP Apache Version 2.4
+Apache 2.x est un serveur web à usage général, conçu dans un but + d'équilibre entre souplesse, portabilité et performances. Bien que non + conçu dans le seul but d'établir une référence en la matière, + Apache 2.x est capable de hautes performances dans de nombreuses situations + du monde réel.
+ +Comparée à Apache 1.3, la version 2.x comporte de nombreuses + optimisations supplémentaires permettant d'améliorer le débit du serveur + et sa personnalisation. La plupart de ces améliorations sont activées par + défaut. Cependant, certains choix de configuration à la compilation et à + l'exécution peuvent affecter les performances de manière significative. Ce + document décrit les options qu'un administrateur de serveur peut configurer + pour améliorer les performances d'une installation d'Apache 2.x. Certaines + de ces options de configuration permettent au démon httpd de mieux tirer + parti des possibilités du matériel et du système d'exploitation, tandis + que d'autres permettent à l'administrateur de privilégier la vitesse + par rapport aux fonctionnalités.
+ + Problèmes matériels et relatifs au système d'exploitation Optimisation de la configuration à l'exécution Optimisation de la configuration à la compilation Appendice : Analyse détaillée d'une traceLe principal problème matériel qui affecte les performances du serveur
+ web est la mémoire vive (RAM). Un serveur web ne devrait jamais avoir à
+ utiliser le swap, car le swapping augmente le temps de réponse de chaque
+ requête au delà du point que les utilisateurs considèrent comme
+ "trop lent". Ceci incite les utilisateurs à cliquer sur "Stop", puis
+ "Charger à nouveau", ce qui a pour effet d'augmenter encore la charge
+ du serveur. Vous pouvez, et même devez définir la valeur de la directive
+ MaxRequestWorkers de façon à ce que
+ votre serveur ne lance pas un nombre de processus enfants tel qu'il
+ commence à faire du swapping. La méthode pour y parvenir est
+ simple : déterminez la taille de votre processus Apache standard en
+ consultant votre liste de processus à l'aide d'un outil tel que
+ top, et divisez votre quantité totale de mémoire disponible
+ par cette taille, tout en gardant un espace suffisant
+ pour les autres processus.
Hormis ce réglage relatif à la mémoire, le reste est trivial : le + processeur, la carte réseau et les disques doivent être suffisamment + rapides, où "suffisamment rapide" doit être déterminé par + l'expérience.
+ +Le choix du système d'exploitation dépend principalement du + contexte local. Voici cependant quelques conseils qui se sont + généralement avérés utiles :
+ +Exécutez la dernière version stable et le niveau de patches le + plus haut du système d'exploitation que vous avez choisi. De nombreux + éditeurs de systèmes d'exploitation ont amélioré de manière + significative les performances de leurs piles TCP et de leurs + bibliothèques de thread ces dernières années.
+Si votre système d'exploitation possède un appel système
+ sendfile(2), assurez-vous d'avoir installé la version
+ et/ou les patches nécessaires à son activation. (Pour Linux, par
+ exemple, cela se traduit par Linux 2.4 ou plus. Pour les versions
+ anciennes de Solaris 8, vous pouvez être amené à appliquer un patch.)
+ Sur les systèmes où il est disponible, sendfile permet
+ à Apache 2 de servir les contenus statiques plus rapidement, tout en
+ induisant une charge CPU inférieure.
| Modules Apparentés | Directives Apparentées |
|---|---|
Avant Apache 1.3, la directive
+ HostnameLookups était positionnée
+ par défaut à On. Ce réglage augmente le temps de réponse de
+ chaque requête car il entraîne une recherche DNS et le traitement de la
+ requête ne pourra pas être achevé tant que cette recherche ne sera
+ pas terminée. Avec Apache 1.3, ce réglage est défini par défaut à
+ Off. Si vous souhaitez que les adresses dans vos fichiers
+ journaux soient résolues en noms d'hôtes, utilisez le programme
+ logresolve fourni avec Apache, ou un des nombreux
+ paquets générateurs de rapports sur les journaux disponibles.
Il est recommandé d'effectuer ce genre de traitement a posteriori + de vos fichiers journaux sur une autre machine que celle qui héberge le + serveur web en production, afin que cette activité n'affecte pas les + performances du serveur.
+ +Si vous utilisez une directive
+ Allowfrom domainDeny from domain
Notez qu'il est possible de modifier la portée des directives, en les
+ plaçant par exemple à l'intérieur d'une section
+ <Location "/server-status">. Les recherches DNS ne
+ seront alors effectuées que pour les requêtes qui satisfont aux critères.
+ Voici un exemple qui désactive les recherches DNS sauf pour les fichiers
+ .html et .cgi :
HostnameLookups off +<Files ~ "\.(html|cgi)$"> + HostnameLookups on +</Files>+ + +
Mais même dans ce cas, si vous n'avez besoin de noms DNS que dans
+ certains CGIs, vous pouvez effectuer l'appel à gethostbyname
+ dans les CGIs spécifiques qui en ont besoin.
Chaque fois que la ligne Options FollowSymLinks sera
+ absente, ou que la ligne Options SymLinksIfOwnerMatch sera
+ présente dans votre espace d'adressage, Apache devra effectuer des
+ appels système supplémentaires pour vérifier la présence de liens
+ symboliques. Un appel supplémentaire par élément du chemin du fichier.
+ Par exemple, si vous avez :
DocumentRoot "/www/htdocs" +<Directory "/"> + Options SymLinksIfOwnerMatch +</Directory>+ + +
et si une requête demande l'URI /index.html, Apache
+ effectuera un appel à lstat(2) pour
+ /www, /www/htdocs, et
+ /www/htdocs/index.html. Les résultats de ces appels à
+ lstat ne sont jamais mis en cache, ils devront donc être
+ générés à nouveau pour chaque nouvelle requête. Si vous voulez absolument
+ vérifier la sécurité des liens symboliques, vous pouvez utiliser une
+ configuration du style :
DocumentRoot "/www/htdocs" +<Directory "/"> + Options FollowSymLinks +</Directory> + +<Directory "/www/htdocs"> + Options -FollowSymLinks +SymLinksIfOwnerMatch +</Directory>+ + +
Ceci évite au moins les vérifications supplémentaires pour le chemin
+ défini par DocumentRoot. Notez que
+ vous devrez ajouter des sections similaires si vous avez des chemins
+ définis par les directives
+ Alias ou
+ RewriteRule en dehors de
+ la racine de vos documents. Pour améliorer les performances, et supprimer
+ toute protection des liens symboliques, ajoutez l'option
+ FollowSymLinks partout, et n'utilisez jamais l'option
+ SymLinksIfOwnerMatch.
Dans toute partie de votre espace d'adressage où vous autoriserez
+ la surcharge de la configuration (en général à l'aide de fichiers
+ .htaccess), Apache va tenter d'ouvrir .htaccess
+ pour chaque élément du chemin du fichier demandé. Par exemple, si vous
+ avez :
DocumentRoot "/www/htdocs" +<Directory "/"> + AllowOverride all +</Directory>+ + +
et qu'une requête demande l'URI /index.html, Apache
+ tentera d'ouvrir /.htaccess, /www/.htaccess,
+ et /www/htdocs/.htaccess. Les solutions sont similaires à
+ celles évoquées précédemment pour Options FollowSymLinks.
+ Pour améliorer les performances, utilisez AllowOverride None
+ pour tous les niveaux de votre espace d'adressage.
Dans la mesure du possible, évitez toute négociation de contenu si + vous tenez au moindre gain en performances. En pratique toutefois, + les bénéfices de la négociation l'emportent souvent sur la diminution + des performances. + Il y a cependant un cas dans lequel vous pouvez accélérer le serveur. + Au lieu d'utiliser une directive générique comme :
+ +DirectoryIndex index+ + +
utilisez une liste explicite d'options :
+ +DirectoryIndex index.cgi index.pl index.shtml index.html+ + +
où vous placez le choix courant en première position.
+ +Notez aussi que créer explicitement un fichier de
+ correspondances de type fournit de meilleures performances
+ que l'utilisation des MultiViews, car les informations
+ nécessaires peuvent être simplement obtenues en lisant ce fichier, sans
+ avoir à parcourir le répertoire à la recherche de types de fichiers.
Par conséquent, si la négociation de contenu est nécessaire pour votre
+ site, préférez les fichiers de correspondances de type aux
+ directives Options MultiViews pour mener à bien cette
+ négociation. Se référer au document sur la
+ Négociation de contenu pour une
+ description complète des méthodes de négociation, et les instructions
+ permettant de créer des fichiers de correspondances de type.
Dans les situations où Apache 2.x doit consulter le contenu d'un
+ fichier en train d'être servi - par exemple à l'occasion du traitement
+ d'une inclusion côté serveur - il transfère en général le fichier en
+ mémoire si le système d'exploitation supporte une forme quelconque
+ de mmap(2).
Sur certains systèmes, ce transfert en mémoire améliore les + performances. Dans certains cas, ce transfert peut toutefois les dégrader + et même diminuer la stabilité du démon httpd :
+ +Dans certains systèmes d'exploitation, mmap devient
+ moins efficace que read(2) quand le nombre de
+ processeurs augmente. Sur les serveurs multiprocesseurs sous Solaris,
+ par exemple, Apache 2.x sert parfois les fichiers consultés par le
+ serveur plus rapidement quand mmap est désactivé.
Si vous transférez en mémoire un fichier localisé dans un système + de fichiers monté par NFS, et si un processus sur + une autre machine cliente NFS supprime ou tronque le fichier, votre + processus peut rencontrer une erreur de bus la prochaine fois qu'il + essaiera d'accéder au contenu du fichier en mémoire.
+Pour les installations où une de ces situations peut se produire,
+ vous devez utiliser EnableMMAP off afin de désactiver le
+ transfert en mémoire des fichiers servis. (Note : il est possible de
+ passer outre cette directive au niveau de chaque répertoire.)
Dans les cas où Apache peut se permettre d'ignorer le contenu du
+ fichier à servir - par exemple, lorsqu'il sert un contenu de fichier
+ statique - il utilise en général le support sendfile du noyau si le
+ système d'exploitation supporte l'opération sendfile(2).
Sur la plupart des plateformes, l'utilisation de sendfile améliore + les performances en éliminant les mécanismes de lecture et envoi séparés. + Dans certains cas cependant, l'utilisation de sendfile peut nuire à la + stabilité du démon httpd :
+ +Certaines plateformes peuvent présenter un support de sendfile + défaillant que la construction du système n'a pas détecté, en + particulier si les binaires ont été construits sur une autre machine + et transférés sur la machine où le support de sendfile est + défaillant.
+Dans le cas d'un système de fichiers monté + sous NFS, le noyau peut s'avérer incapable de servir + les fichiers réseau de manière fiable depuis + son propre cache.
+Pour les installations où une de ces situations peut se produire,
+ vous devez utiliser EnableSendfile off afin de désactiver
+ la mise à disposition de contenus de fichiers par sendfile. (Note : il
+ est possible de passer outre cette directive au niveau de chaque
+ répertoire.)
Avant Apache 1.3, les directives
+ MinSpareServers,
+ MaxSpareServers, et
+ StartServers avaient des
+ effets drastiques sur les performances de référence. En particulier,
+ Apache avait besoin d'un délai de "montée en puissance" afin d'atteindre
+ un nombre de processus enfants suffisant pour supporter la charge qui lui
+ était appliquée. Après le lancement initial des processus enfants par
+ StartServers, seulement un
+ processus enfant par seconde était créé afin d'atteindre la valeur de la
+ directive MinSpareServers. Ainsi,
+ un serveur accédé par 100 clients simultanés et utilisant la valeur par
+ défaut de 5 pour la directive
+ StartServers, nécessitait
+ environ 95 secondes pour lancer suffisamment de processus enfants
+ permettant de faire face à la charge. Ceci fonctionne en pratique pour
+ les serveurs en production, car ils sont rarement redémarrés. Ce n'est
+ cependant pas le cas pour les tests de référence (benchmarks) où le
+ serveur ne fonctionne que 10 minutes.
La règle "un processus par seconde" avait été implémentée afin
+ d'éviter l'enlisement de la machine dans le démarrage de nouveaux
+ processus enfants. Pendant que la machine est occupée à lancer des
+ processus enfants, elle ne peut pas traiter les requêtes. Mais cette
+ règle impactait tellement la perception des performances d'Apache qu'elle
+ a dû être remplacée. A partir d'Apache 1.3, le code a assoupli la règle
+ "un processus par seconde". Il va en lancer un, attendre une seconde,
+ puis en lancer deux, attendre une seconde, puis en lancer quatre et
+ ainsi de suite jusqu'à lancer 32 processus. Il s'arrêtera lorsque le
+ nombre de processus aura atteint la valeur définie par la directive
+ MinSpareServers.
Ceci s'avère suffisamment réactif pour pouvoir en général se passer
+ de manipuler les valeurs des directives
+ MinSpareServers,
+ MaxSpareServers et
+ StartServers. Lorsque plus de
+ 4 processus enfants sont lancés par seconde, un message est émis vers
+ le journal des erreurs. Si vous voyez apparaître souvent ce genre de
+ message, vous devez vous pencher sur ces réglages. Pour vous guider,
+ utilisez les informations délivrées par le module
+ mod_status.
À mettre en relation avec la création de processus, leur destruction
+ est définie par la valeur de la directive
+ MaxConnectionsPerChild. Sa valeur
+ par défaut est 0, ce qui signifie qu'il n'y a pas de limite
+ au nombre de connexions qu'un processus enfant peut traiter. Si votre
+ configuration actuelle a cette directive réglée à une valeur très basse,
+ de l'ordre de 30, il est conseillé de l'augmenter de manière
+ significative. Si vous utilisez SunOs ou une ancienne version de Solaris,
+ utilisez une valeur de l'ordre de 10000 à cause des fuites
+ de mémoire.
Lorsqu'ils sont en mode "keep-alive", les processus enfants sont
+ maintenus et ne font rien sinon attendre la prochaine requête sur la
+ connexion déjà ouverte. La valeur par défaut de 5 de la
+ directive KeepAliveTimeout tend à
+ minimiser cet effet. Il faut trouver le bon compromis entre la bande
+ passante réseau et les ressources du serveur. En aucun cas vous ne devez
+ choisir une valeur supérieure à 60 seconds, car
+
+ la plupart des bénéfices sont alors perdus.
Apache 2.x supporte les modèles simultanés enfichables, appelés
+ Modules Multi-Processus (MPMs). Vous devez
+ choisir un MPM au moment de la construction d'Apache. Certaines
+ plateformes ont des modules MPM spécifiques :
+ mpm_netware, mpmt_os2 et
+ mpm_winnt. Sur les systèmes de type Unix, vous avez le
+ choix entre un grand nombre de modules MPM. Le choix du MPM peut affecter
+ la vitesse et l'évolutivité du démon httpd :
worker utilise plusieurs processus
+ enfants possédant chacun de nombreux threads. Chaque thread gère une
+ seule connexion à la fois. Worker est en général un bon choix pour les
+ serveurs présentant un traffic important car il possède une empreinte
+ mémoire plus petite que le MPM prefork.event utilise
+ les threads, mais il a été conçu pour traiter davantage de
+ requêtes simultanément en confiant une partie du travail à des
+ threads de support, ce qui permet aux threads principaux de
+ traiter de nouvelles requêtes.prefork utilise plusieurs processus enfants
+ possédant chacun un seul thread. Chaque processus gère une seule
+ connexion à la fois. Sur de nombreux systèmes, prefork est comparable
+ en matière de vitesse à worker, mais il utilise plus de mémoire. De par
+ sa conception sans thread, prefork présente des avantages par rapport à
+ worker dans certaines situations : il peut être utilisé avec les
+ modules tiers qui ne supportent pas le threading, et son débogage est plus
+ aisé sur les platesformes présentant un support du débogage des threads
+ rudimentaire.Pour plus d'informations sur ces deux MPMs et les autres, veuillez + vous référer à la documentation sur les + MPM.
+ + + +Comme le contrôle de l'utilisation de la mémoire est très important
+ en matière de performance, il est conseillé d'éliminer les modules que
+ vous n'utilisez pas vraiment. Si vous avez construit ces modules en
+ tant que DSOs, leur élimination consiste
+ simplement à commenter la directive
+ LoadModule associée à ce
+ module. Ceci vous permet de vérifier si votre site fonctionne toujours
+ après la suppression de tel ou tel module.
Par contre, si les modules que vous voulez supprimer sont liés + statiquement à votre binaire Apache, vous devrez recompiler ce dernier + afin de pouvoir les éliminer.
+ +La question qui découle de ce qui précède est évidemment de
+ savoir de quels modules vous avez besoin et desquels vous pouvez vous
+ passer. La réponse sera bien entendu différente d'un site web à
+ l'autre. Cependant, la liste minimale de modules nécessaire à
+ la survie de votre site contiendra certainement
+ mod_mime, mod_dir et
+ mod_log_config. mod_log_config est bien
+ entendu optionnel puisque vous pouvez faire fonctionner un site web
+ en se passant de fichiers journaux ; ceci est cependant
+ déconseillé.
Certains modules, à l'instar de mod_cache et des
+ versions de développement récentes du MPM worker, utilisent l'API
+ atomique d'APR. Cette API propose des opérations atomiques que l'on
+ peut utiliser pour alléger la synchronisation des threads.
Par défaut, APR implémente ces opérations en utilisant les
+ mécanismes les plus efficaces disponibles sur chaque plateforme cible
+ (Système d'exploitation et processeur). De nombreux processeurs modernes,
+ par exemple, possèdent une instruction qui effectue une opération
+ atomique de type comparaison et échange ou compare-and-swap (CAS) au
+ niveau matériel. Sur certaines platesformes cependant, APR utilise par
+ défaut une implémentation de l'API atomique plus lente, basée sur les
+ mutex, afin d'assurer la compatibilité avec les anciens modèles de
+ processeurs qui ne possèdent pas ce genre d'instruction. Si vous
+ construisez Apache pour une de ces platesformes, et ne prévoyez de
+ l'exécuter que sur des processeurs récents, vous pouvez sélectionner une
+ implémentation atomique plus rapide à la compilation en utilisant
+ l'option --enable-nonportable-atomics du
+ script configure :
+ ./buildconf
+ ./configure --with-mpm=worker --enable-nonportable-atomics=yes
+
L'option --enable-nonportable-atomics concerne les
+ platesformes suivantes :
--enable-nonportable-atomics au script configure, APR
+ génère un code qui utilise le code opération SPARC v8plus pour des
+ opérations de compare-and-swap matériel plus rapides. Si vous
+ utilisez cette option de configure avec Apache, les opérations
+ atomiques seront plus efficaces (permettant d'alléger la charge du
+ processeur et un plus haut niveau de simultanéité), mais
+ l'exécutable produit ne fonctionnera que sur les processeurs
+ UltraSPARC.
+ --enable-nonportable-atomics au script configure,
+ APR générera un code qui utilise un code d'opération du 486
+ pour des opérations de compare-and-swap matériel plus rapides. Le
+ code résultant est plus efficace en matière d'opérations atomiques,
+ mais l'exécutable produit ne fonctionnera que sur des processeurs
+ 486 et supérieurs (et non sur des 386).
+ Si vous incluez le module mod_status à la
+ construction d'Apache et ajoutez ExtendedStatus On à sa
+ configuration, Apache va effectuer pour chaque requête deux appels à
+ gettimeofday(2) (ou times(2) selon votre
+ système d'exploitation), et (pour les versions antérieures à 1.3) de
+ nombreux appels supplémentaires à time(2). Tous ces
+ appels sont effectués afin que le rapport de statut puisse contenir
+ des indications temporelles. Pour améliorer les performances, utilisez
+ ExtendedStatus off (qui est le réglage par défaut).
Cette section n'a pas été totalement mise à jour car elle ne tient pas + compte des changements intervenus dans la version 2.x du Serveur HTTP + Apache. Certaines informations sont encore pertinentes, il vous est + cependant conseillé de les utiliser avec prudence.
+Ce qui suit est une brève discussion à propos de l'API des sockets
+ Unix. Supposons que votre serveur web utilise plusieurs directives
+ Listen afin d'écouter
+ plusieurs ports ou de multiples adresses. Afin de tester chaque socket
+ pour voir s'il a une connexion en attente, Apache utilise
+ select(2). select(2) indique si un socket a
+ zéro ou au moins une connexion en attente. Le modèle
+ d'Apache comporte plusieurs processus enfants, et tous ceux qui sont
+ inactifs testent la présence de nouvelles connexions au même moment.
+ Une implémentation rudimentaire de ceci pourrait ressembler à
+ l'exemple suivant
+ (ces exemples ne sont pas extraits du code d'Apache, ils ne sont
+ proposés qu'à des fins pédagogiques) :
for (;;) {
+ for (;;) {
+ fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+ FD_SET (i, &accept_fds);
+ }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+ if (FD_ISSET (i, &accept_fds)) {
+ new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+ }
+ }
+ if (new_connection != -1) break;
+ }
+ process_the(new_connection);
+ }
+
+
+ Mais cette implémentation rudimentaire présente une sérieuse lacune.
+ Rappelez-vous que les processus enfants exécutent cette boucle au même
+ moment ; ils vont ainsi bloquer sur select s'ils se trouvent
+ entre deux requêtes. Tous ces processus bloqués vont se réactiver et
+ sortir de select quand une requête va apparaître sur un des
+ sockets (le nombre de processus enfants qui se réactivent varie en
+ fonction du système d'exploitation et des réglages de synchronisation).
+ Ils vont alors tous entrer dans la boucle et tenter un
+ "accept" de la connexion. Mais seulement un d'entre eux y
+ parviendra (en supposant qu'il ne reste q'une seule connexion en
+ attente), les autres vont se bloquer au niveau de accept.
+ Ceci verrouille vraiment ces processus de telle sorte qu'ils ne peuvent
+ plus servir de requêtes que par cet unique socket, et il en sera ainsi
+ jusqu'à ce que suffisamment de nouvelles requêtes apparaissent sur ce
+ socket pour les réactiver tous. Cette lacune a été documentée pour la
+ première fois dans
+ PR#467. Il existe
+ au moins deux solutions.
La première consiste à rendre les sockets non blocants. Dans ce cas,
+ accept ne bloquera pas les processus enfants, et ils
+ pourront continuer à s'exécuter immédiatement. Mais ceci consomme des
+ ressources processeur. Supposons que vous ayez dix processus enfants
+ inactifs dans select, et qu'une connexion arrive.
+ Neuf des dix processus vont se réactiver, tenter un accept
+ de la connexion, échouer, et boucler dans select, tout en
+ n'ayant finalement rien accompli. Pendant ce temps, aucun de ces processus
+ ne traite les requêtes qui arrivent sur d'autres sockets jusqu'à ce
+ qu'ils retournent dans select. Finalement, cette solution
+ ne semble pas très efficace, à moins que vous ne disposiez d'autant de
+ processeurs inactifs (dans un serveur multiprocesseur) que de processus
+ enfants inactifs, ce qui n'est pas une situation très courante.
Une autre solution, celle qu'utilise Apache, consiste à sérialiser les + entrées dans la boucle interne. La boucle ressemble à ceci (les + différences sont mises en surbrillance) :
+ + for (;;) {
+ accept_mutex_on ();
+ for (;;) {
+ fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+ FD_SET (i, &accept_fds);
+ }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+ if (FD_ISSET (i, &accept_fds)) {
+ new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+ }
+ }
+ if (new_connection != -1) break;
+ }
+ accept_mutex_off ();
+ process the new_connection;
+ }
+
+
+ Les fonctions
+ accept_mutex_on et accept_mutex_off
+ implémentent un sémaphore permettant une exclusion mutuelle. Un seul
+ processus enfant à la fois peut posséder le mutex. Plusieurs choix se
+ présentent pour implémenter ces mutex. Ce choix est défini dans
+ src/conf.h (versions antérieures à 1.3) ou
+ src/include/ap_config.h (versions 1.3 ou supérieures).
+ Certaines architectures ne font pas ce choix du mode de verrouillage ;
+ l'utilisation de directives
+ Listen multiples sur ces
+ architectures est donc peu sûr.
La directive Mutex permet
+ de modifier l'implémentation du mutex mpm-accept à
+ l'exécution. Des considérations spécifiques aux différentes
+ implémentations de mutex sont documentées avec cette directive.
Une autre solution qui a été imaginée mais jamais implémentée, consiste + à sérialiser partiellement la boucle -- c'est à dire y faire entrer un + certain nombre de processus. Ceci ne présenterait un intérêt que sur les + machines multiprocesseurs où plusieurs processus enfants peuvent + s'exécuter simultanément, et encore, la sérialisation ne tire pas + vraiment parti de toute la bande passante. C'est une possibilité + d'investigation future, mais demeure de priorité basse car les serveurs + web à architecture hautement parallèle ne sont pas la norme.
+ +Pour bien faire, vous devriez faire fonctionner votre serveur sans
+ directives Listen multiples
+ si vous visez les performances les plus élevées.
+ Mais lisez ce qui suit.
Ce qui précède convient pour les serveurs à sockets multiples, mais
+ qu'en est-il des serveurs à socket unique ? En théorie, ils ne
+ devraient pas rencontrer les mêmes problèmes car tous les processus
+ enfants peuvent se bloquer dans accept(2) jusqu'à ce qu'une
+ connexion arrive, et ils ne sont pas utilisés à ne rien faire. En
+ pratique, ceci dissimule un même comportement de bouclage
+ discuté plus haut dans la solution non-blocante. De la manière dont
+ sont implémentées les piles TCP, le noyau réactive véritablement tous les
+ processus bloqués dans accept quand une seule connexion
+ arrive. Un de ces processus prend la connexion en compte et retourne
+ dans l'espace utilisateur, les autres bouclant dans l'espace du
+ noyau et se désactivant quand ils s'aperçoivent qu'il n'y a pas de
+ connexion pour eux. Ce bouclage est invisible depuis le code de l'espace
+ utilisateur, mais il est quand-même présent. Ceci peut conduire à la
+ même augmentation de charge à perte que la solution non blocante au cas
+ des sockets multiples peut induire.
Pour cette raison, il apparaît que de nombreuses architectures se
+ comportent plus "proprement" si on sérialise même dans le cas d'une socket
+ unique. Il s'agit en fait du comportement par défaut dans la plupart des
+ cas. Des expériences poussées sous Linux (noyau 2.0.30 sur un
+ biprocesseur Pentium pro 166 avec 128 Mo de RAM) ont montré que la
+ sérialisation d'une socket unique provoque une diminution inférieure à 3%
+ du nombre de requêtes par secondes par rapport au traitement non
+ sérialisé. Mais le traitement non sérialisé des sockets uniques induit
+ un temps de réponse supplémentaire de 100 ms pour chaque requête. Ce
+ temps de réponse est probablement provoqué par une limitation sur les
+ lignes à haute charge, et ne constitue un problème que sur les réseaux
+ locaux. Si vous voulez vous passer de la sérialisation des sockets
+ uniques, vous pouvez définir
+ SINGLE_LISTEN_UNSERIALIZED_ACCEPT et les
+ serveurs à socket unique ne pratiqueront plus du tout la
+ sérialisation.
Comme discuté dans + draft-ietf-http-connection-00.txt section 8, pour implémenter de + manière fiable le protocole, un serveur HTTP doit fermer + les deux directions d'une communication indépendamment (rappelez-vous + qu'une connexion TCP est bidirectionnelle, chaque direction étant + indépendante de l'autre).
+ +Quand cette fonctionnalité fut ajoutée à Apache, elle causa une
+ avalanche de problèmes sur plusieurs versions d'Unix à cause d'une
+ implémentation à courte vue. La spécification TCP ne précise pas que
+ l'état FIN_WAIT_2 possède un temps de réponse mais elle ne
+ l'exclut pas. Sur les systèmes qui n'introduisent pas ce temps de
+ réponse, Apache 1.2 induit de nombreux blocages définitifs de socket
+ dans l'état FIN_WAIT_2. On peut eviter ceci dans de nombreux
+ cas tout simplement en mettant à jour TCP/IP avec le dernier patch mis à
+ disposition par le fournisseur. Dans les cas où le fournisseur n'a
+ jamais fourni de patch (par exemple, SunOS4 -- bien que les utilisateurs
+ possédant une license source puissent le patcher eux-mêmes), nous avons
+ décidé de désactiver cette fonctionnalité.
Il y a deux méthodes pour arriver à ce résultat. La première est
+ l'option de socket SO_LINGER. Mais le sort a voulu que cette
+ solution ne soit jamais implémentée correctement dans la plupart des
+ piles TCP/IP. Et même dans les rares cas où cette solution a été
+ implémentée correctement (par exemple Linux 2.0.31), elle se
+ montre beaucoup plus gourmande (en temps processeur) que la solution
+ suivante.
Pour la plus grande partie, Apache implémente cette solution à l'aide
+ d'une fonction appelée lingering_close (définie dans
+ http_main.c). La fonction ressemble approximativement à
+ ceci :
void lingering_close (int s)
+ {
+ char junk_buffer[2048];
+
+ /* shutdown the sending side */
+ shutdown (s, 1);
+
+ signal (SIGALRM, lingering_death);
+ alarm (30);
+
+ for (;;) {
+ select (s for reading, 2 second timeout);
+ if (error) break;
+ if (s is ready for reading) {
+ if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
+ break;
+ }
+ /* just toss away whatever is here */
+ }
+ }
+
+ close (s);
+ }
+
+
+ Ceci ajoute naturellement un peu de charge à la fin d'une connexion,
+ mais s'avère nécessaire pour une implémentation fiable. Comme HTTP/1.1
+ est de plus en plus présent et que toutes les connexions sont
+ persistentes, la charge sera amortie par la multiplicité des requêtes.
+ Si vous voulez jouer avec le feu en désactivant cette fonctionnalité,
+ vous pouvez définir NO_LINGCLOSE, mais c'est fortement
+ déconseillé. En particulier, comme les connexions persistantes en
+ pipeline de HTTP/1.1 commencent à être utilisées,
+ lingering_close devient une absolue nécessité (et les
+
+ connexions en pipeline sont plus rapides ; vous avez donc tout
+ intérêt à les supporter).
Les processus parent et enfants d'Apache communiquent entre eux à
+ l'aide d'un objet appelé "Tableau de bord" (Scoreboard). Idéalement, cet
+ échange devrait s'effectuer en mémoire partagée. Pour les systèmes
+ d'exploitation auxquels nous avons eu accès, ou pour lesquels nous avons
+ obtenu des informations suffisamment détaillées pour effectuer un
+ portage, cet échange est en général implémenté en utilisant la mémoire
+ partagée. Pour les autres, on utilise par défaut un fichier d'échange sur
+ disque. Le fichier d'échange sur disque est non seulement lent, mais
+ aussi peu fiable (et propose moins de fonctionnalités). Recherchez dans
+ le fichier src/main/conf.h correspondant à votre
+ architecture soit USE_MMAP_SCOREBOARD, soit
+ USE_SHMGET_SCOREBOARD. La définition de l'un des deux
+ (ainsi que leurs compagnons respectifs HAVE_MMAP et
+ HAVE_SHMGET), active le code fourni pour la mémoire
+ partagée. Si votre système propose une autre solution pour la gestion de
+ la mémoire partagée, éditez le fichier src/main/http_main.c
+ et ajoutez la portion de code nécessaire pour pouvoir l'utiliser dans
+ Apache (Merci de nous envoyer aussi le patch correspondant).
Si vous n'avez pas l'intention d'utiliser les modules chargés
+ dynamiquement (ce qui est probablement le cas si vous êtes en train de
+ lire ce document afin de personnaliser votre serveur en recherchant le
+ moindre des gains en performances), vous pouvez ajouter la définition
+ -DDYNAMIC_MODULE_LIMIT=0 à la construction de votre serveur.
+ Ceci aura pour effet de libérer la mémoire RAM allouée pour le
+ chargement dynamique des modules.
Voici la trace d'un appel système d'Apache 2.0.38 avec le MPM worker + sous Solaris 8. Cette trace a été collectée à l'aide de la commande :
+ +
+ truss -l -p httpd_child_pid.
+
L'option -l demande à truss de tracer l'ID du LWP
+ (lightweight process--la version de Solaris des threads niveau noyau) qui
+ invoque chaque appel système.
Les autres systèmes peuvent proposer des utilitaires de traçage
+ des appels système différents comme strace,
+ ktrace, ou par. Ils produisent cependant tous une
+ trace similaire.
Dans cette trace, un client a demandé un fichier statique de 10 ko au + démon httpd. Le traçage des requêtes pour des contenus non statiques + ou comportant une négociation de contenu a une présentation + différente (et même assez laide dans certains cas).
+ +/67: accept(3, 0x00200BEC, 0x00200C0C, 1) (sleeping...) +/67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9
Dans cette trace, le thread à l'écoute s'exécute à l'intérieur de + LWP #67.
+ +accept(2). Sur
+ cette plateforme spécifique, le MPM worker utilise un accept non sérialisé
+ par défaut sauf s'il est en écoute sur des ports multiples./65: lwp_park(0x00000000, 0) = 0 +/67: lwp_unpark(65, 1) = 0
Après avoir accepté la connexion, le thread à l'écoute réactive un + thread du worker pour effectuer le traitement de la requête. Dans cette + trace, le thread du worker qui traite la requête est associé à + LWP #65.
+ +/65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0
Afin de pouvoir implémenter les hôtes virtuels, Apache doit connaître
+ l'adresse du socket local utilisé pour accepter la connexion. On pourrait
+ supprimer cet appel dans de nombreuses situations (par exemple dans le cas
+ où il n'y a pas d'hôte virtuel ou dans le cas où les directives
+ Listen contiennent des adresses
+ sans caractères de substitution). Mais aucun effort n'a été accompli à ce
+ jour pour effectuer ces optimisations.
/65: brk(0x002170E8) = 0 +/65: brk(0x002190E8) = 0
L'appel brk(2) alloue de la mémoire dans le tas. Ceci est
+ rarement visible dans une trace d'appel système, car le démon httpd
+ utilise des allocateurs mémoire de son cru (apr_pool et
+ apr_bucket_alloc) pour la plupart des traitements de requêtes.
+ Dans cette trace, le démon httpd vient juste de démarrer, et il doit
+ appeler malloc(3) pour réserver les blocs de mémoire
+ nécessaires à la création de ses propres allocateurs de mémoire.
/65: fcntl(9, F_GETFL, 0x00000000) = 2 +/65: fstat64(9, 0xFAF7B818) = 0 +/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0 +/65: fstat64(9, 0xFAF7B818) = 0 +/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0 +/65: setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0 +/65: fcntl(9, F_SETFL, 0x00000082) = 0
Ensuite, le thread de worker passe la connexion du client (descripteur
+ de fichier 9) en mode non blocant. Les appels setsockopt(2)
+ et getsockopt(2) constituent un effet de bord de la manière
+ dont la libc de Solaris utilise fcntl(2) pour les sockets.
/65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97
Le thread de worker lit la requête du client.
+ +/65: stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0
+/65: open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10Ce démon httpd a été configuré avec les options
+ Options FollowSymLinks et AllowOverride None. Il
+ n'a donc ni besoin d'appeler lstat(2) pour chaque répertoire
+ du chemin du fichier demandé, ni besoin de vérifier la présence de fichiers
+ .htaccess. Il appelle simplement stat(2) pour
+ vérifier d'une part que le fichier existe, et d'autre part que c'est un
+ fichier régulier, et non un répertoire.
/65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269
Dans cet exemple, le démon httpd peut envoyer l'en-tête de la réponse
+ HTTP et le fichier demandé à l'aide d'un seul appel système
+ sendfilev(2). La sémantique de sendfile varie en fonction des
+ systèmes d'exploitation. Sur certains autres systèmes, il faut faire un
+ appel à write(2) ou writev(2) pour envoyer les
+ en-têtes avant d'appeler sendfile(2).
/65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78
Cet appel à write(2) enregistre la requête dans le journal
+ des accès. Notez qu'une des choses manquant à cette trace est un appel à
+ time(2). A la différence d'Apache 1.3, Apache 2.x utilise
+ gettimeofday(3) pour consulter l'heure. Sur certains systèmes
+ d'exploitation, comme Linux ou Solaris, gettimeofday est
+ implémenté de manière optimisée de telle sorte qu'il consomme moins de
+ ressources qu'un appel système habituel.
/65: shutdown(9, 1, 1) = 0 +/65: poll(0xFAF7B980, 1, 2000) = 1 +/65: read(9, 0xFAF7BC20, 512) = 0 +/65: close(9) = 0
Le thread de worker effectue une fermeture "en prenant son temps" + (lingering close) de la connexion.
+ +/65: close(10) = 0 +/65: lwp_park(0x00000000, 0) (sleeping...)
Enfin, le thread de worker ferme le fichier qu'il vient de délivrer et + se bloque jusqu'à ce que le thread en écoute lui assigne une autre + connexion.
+ +/67: accept(3, 0x001FEB74, 0x001FEB94, 1) (sleeping...)
Pendant ce temps, le thread à l'écoute peut accepter une autre connexion
+ à partir du moment où il a assigné la connexion présente à un thread de
+ worker (selon une certaine logique de contrôle de flux dans le MPM worker
+ qui impose des limites au thread à l'écoute si tous les threads de worker
+ sont occupés). Bien que cela n'apparaisse pas dans cette trace,
+ l'accept(2) suivant peut (et le fait en général, en situation
+ de charge élevée) s'exécuter en parallèle avec le traitement de la
+ connexion qui vient d'être acceptée par le thread de worker.
Serveur HTTP Apache Version 2.4
+Cette page documente tous les standards applicables que suit le + serveur HTTP Apache, accompagnés d'une brève description.
+ +Pour compléter les informations fournies ci-dessous, vous pouvez + consulter les ressources suivantes :
+ +Ce document n'est pas encore finalisé.
+Indépendamment des modules compilés et utilisés, Apache en + tant que serveur web de base respecte les recommandations IETF + suivantes :
+ +En ce qui concerne le langage HTML, Apache respecte les + recommandations IETF et W3C suivantes :
+ +En ce qui concerne les différentes méthodes d'authentification, + Apache respecte les recommandations IETF suivantes :
+ +Les liens suivants fournissent des informations à propos des + codes de langues et de pays aux normes ISO ou autres :
+ +Serveur HTTP Apache Version 2.4
+Ce document propose quelques conseils et astuces concernant les + problèmes de sécurité liés + à l'installation d'un serveur web. Certaines suggestions seront à caractère + général, tandis que d'autres seront spécifiques à Apache.
+ Maintenez votre serveur à jour Attaques de type "Déni de service"
+ (Denial of Service - DoS) Permissions sur les répertoires de la racine du serveur Inclusions côté serveur Les CGI en général CGI sans alias de script CGI avec alias de script Autres sources de contenu dynamique Protection de la configuration du système Protection par défaut des fichiers du serveur Surveillez vos journaux Fusion des sections de configurationLe serveur HTTP Apache a une bonne réputation en matière de sécurité + et possède une communauté de développeurs très sensibilisés aux problèmes + de sécurité. Mais il est inévitable de trouver certains problèmes + -- petits ou grands -- une fois le logiciel mis à disposition. C'est pour + cette raison qu'il est crucial de se tenir informé des mises à jour. Si + vous avez obtenu votre version du serveur HTTP directement depuis Apache, + nous vous conseillons grandement de vous abonner à la Liste de diffusion + des annonces du serveur HTTP qui vous informera de + la parution des nouvelles versions et des mises à jour de sécurité. La + plupart des distributeurs tiers d'Apache fournissent des services + similaires.
+ +Gardez cependant à l'esprit que lorsqu'un serveur web est compromis, le + code du serveur HTTP n'est la plupart du temps pas en cause. Les problèmes + proviennent plutôt de code ajouté, de scripts CGI, ou du système + d'exploitation sous-jacent. Vous devez donc vous tenir informé des + problèmes et mises à jour concernant tous les logiciels présents sur + votre système.
+ +Tous les services réseau peuvent faire l'objet d'attaques de type + "Déni de service" qui tentent de les empêcher de répondre aux clients en + saturant leurs ressources. Il est impossible de se prémunir totalement + contre ce type d'attaques, mais vous pouvez accomplir certaines actions + afin de minimiser les problèmes qu'elles créent.
+ +Souvent, l'outil anti-DoS le plus efficace sera constitué par le + pare-feu ou certaines configurations du système d'exploitation. Par + exemple, la plupart des pare-feu peuvent être configurés de façon à + limiter le nombre de connexions simultanées depuis une adresse IP ou un + réseau, ce qui permet de prévenir toute une gamme d'attaques simples. + Bien sûr, ceci n'est d'aucun secours contre les attaques de type + "Déni de service" distribuées (DDoS).
+ +Certains réglages de la configuration d'Apache peuvent aussi + minimiser les problèmes :
+ +RequestReadTimeout permet de
+ limiter le temps que met le client pour envoyer sa requête.TimeOut doit être diminuée sur les
+ sites sujets aux attaques DoS. Une valeur de quelques secondes devrait
+ convenir. Cependant, comme TimeOut
+ est actuellement concerné par de nombreuses opérations différentes, lui
+ attribuer une valeur trop faible peut provoquer des problèmes avec les
+ scripts CGI qui présentent un long temps de réponse.KeepAliveTimeout doit aussi être
+ diminuée sur les sites sujets aux attaques DoS. Certains sites
+ désactivent même complètement le "maintien en vie" (keepalives)
+ à l'aide de la directive
+ KeepAlive, ce qui bien sûr
+ présente des inconvénients en matière de performances.LimitRequestBody,
+ LimitRequestFields,
+ LimitRequestFieldSize,
+ LimitRequestLine, et
+ LimitXMLRequestBody doivent être
+ configurées avec prudence afin de limiter la consommation de ressources
+ induite par les demandes des clients.
+ AcceptFilter est
+ activée afin de déléguer une partie du traitement des requêtes au
+ système d'exploitation. Elle est activée par défaut dans le démon httpd
+ d'Apache, mais peut nécessiter une reconfiguration de votre noyau.MaxRequestWorkers de façon à définir le nombre
+ maximum de connexions simultanées au dessus duquel les ressources
+ s'épuisent. Voir aussi la documentation sur l'optimisation des
+ performances.event utilisera un traitement asynchrone afin de ne pas
+ dédier un thread à chaque connexion. De par la
+ nature de la bibliothèque OpenSSL, le module mpm event est actuellement incompatible
+ avec le module mod_ssl ainsi que d'autres filtres
+ en entrée. Dans ces cas, son comportement se ramène à celui
+ du module mpm worker.Typiquement, Apache est démarré par l'utilisateur root, puis il devient
+ la propriété de l'utilisateur défini par la directive User afin de répondre aux demandes. Comme
+ pour toutes les commandes exécutées par root, vous devez vous assurer
+ qu'elle n'est pas modifiable par les utilisateurs autres que root. Les
+ fichiers eux-mêmes, mais aussi les répertoires ainsi que leurs parents ne
+ doivent être modifiables que par root. Par exemple, si vous avez choisi de
+ placer la racine du serveur dans /usr/local/apache, il est conseillé de
+ créer le répertoire en tant que root, avec des commandes du style :
+ mkdir /usr/local/apache
+ cd /usr/local/apache
+ mkdir bin conf logs
+ chown 0 . bin conf logs
+ chgrp 0 . bin conf logs
+ chmod 755 . bin conf logs
+
Nous supposerons que /, /usr et
+ /usr/local ne sont modifiables que par
+ root. Quand vous installez l'exécutable httpd, vous
+ devez vous assurer qu'il possède des protections similaires :
+ cp httpd /usr/local/apache/bin
+ chown 0 /usr/local/apache/bin/httpd
+ chgrp 0 /usr/local/apache/bin/httpd
+ chmod 511 /usr/local/apache/bin/httpd
+
Vous pouvez créer un sous-répertoire htdocs modifiable par d'autres + utilisateurs -- car root ne crée ni exécute aucun fichier dans ce + sous-répertoire.
+ +Si vous permettez à des utilisateurs non root de modifier des fichiers
+ que root écrit ou exécute, vous exposez votre système à une compromission
+ de l'utilisateur root. Par exemple, quelqu'un pourrait remplacer le binaire
+ httpd de façon à ce que la prochaine fois que vous le
+ redémarrerez, il exécutera un code arbitraire. Si le répertoire des
+ journaux a les droits en écriture (pour un utilisateur non root), quelqu'un
+ pourrait remplacer un fichier journal par un lien symbolique vers un autre
+ fichier système, et root pourrait alors écraser ce fichier avec des données
+ arbitraires. Si les fichiers journaux eux-mêmes ont des droits en
+ écriture (pour un utilisateur non root), quelqu'un pourrait
+ modifier les journaux eux-mêmes avec des données fausses.
Les inclusions côté serveur (Server Side Includes - SSI) exposent + l'administrateur du serveur à de nombreux risques potentiels en matière de + sécurité.
+ +Le premier risque est l'augmentation de la charge du serveur. Tous les + fichiers où SSI est activé doivent être analysés par Apache, qu'ils + contiennent des directives SSI ou non. L'augmentation de la charge induite + est minime, mais peut devenir significative dans le contexte d'un + serveur partagé.
+ +Les fichiers SSI présentent les mêmes risques que les scripts CGI en
+ général. Les fichiers où SSI est activé peuvent exécuter tout script CGI
+ ou autre programme à l'aide de la commande "exec cmd" avec les permissions
+ des utilisateur et groupe sous lesquels Apache s'exécute, comme défini
+ dans httpd.conf.
Des méthodes existent pour améliorer la sécurité des fichiers SSI, tout + en tirant parti des bénéfices qu'ils apportent.
+ +Pour limiter les dommages qu'un fichier SSI agressif pourrait causer, + l'administrateur du serveur peut activersuexec + comme décrit dans la section Les CGI en général.
+ +L'activation des SSI pour des fichiers possédant des extensions
+ .html ou
+ .htm peut s'avérer dangereux. Ceci est particulièrement vrai dans un
+ environnement de serveur partagé ou étant le siège d'un traffic élevé. Les
+ fichiers où SSI est activé doivent posséder une extension spécifique, telle
+ que la conventionnelle .shtml. Ceci permet de limiter la charge du serveur
+ à un niveau minimum et de simplifier la gestion des risques.
Une autre solution consiste à interdire l'exécution de scripts et
+ programmes à partir de pages SSI. Pour ce faire, remplacez
+ Includes par IncludesNOEXEC dans la directive
+ Options. Notez que les utilisateurs
+ pourront encore utiliser <--#include virtual="..." --> pour exécuter
+ des scripts CGI si ces scripts sont situés dans des répertoires spécifiés
+ par une directive
+ ScriptAlias.
Tout d'abord, vous devez toujours garder à l'esprit que vous devez + faire confiance aux développeurs de scripts ou programmes CGI ainsi qu'à + vos compétences pour déceler les trous de sécurité potentiels dans les + CGI, que ceux-ci soient délibérés ou accidentels. Les scripts CGI peuvent + essentiellement exécuter des commandes arbitraires sur votre système avec + les droits de l'utilisateur du serveur web, et peuvent par conséquent être + extrèmement dangereux s'ils ne sont pas vérifiés avec soin.
+ +Tous les scripts CGI s'exécutent sous le même utilisateur, il peuvent + donc entrer en conflit (accidentellement ou délibérément) avec d'autres + scripts. Par exemple, l'utilisateur A hait l'utilisateur B, il écrit donc + un script qui efface la base de données CGI de l'utilisateur B. Vous pouvez + utiliser le programme suEXEC pour faire en + sorte que les scripts s'exécutent sous des utilisateurs différents. Ce + programme est inclus dans la distribution d'Apache depuis la version 1.2 + et est appelé à partir de certaines portions de code du serveur Apache. Une + autre méthode plus connue est l'utilisation de + CGIWrap.
+ +Vous ne devez permettre aux utilisateurs d'exécuter des scripts CGI + depuis n'importe quel répertoire que dans l'éventualité où :
+ +Le confinement des CGI dans des répertoires spécifiques permet à + l'administrateur de contrôler ce que l'on met dans ces répertoires. Ceci + est bien entendu mieux sécurisé que les CGI sans alias de script, mais + seulement à condition que les utilisateurs avec les droits en écriture sur + les répertoires soient dignes de confiance, et que l'administrateur ait la + volonté de tester chaque programme ou script CGI à la recherche d'éventuels + trous de sécurité.
+ +La plupart des sites choisissent cette approche au détriment des CGI + sans alias de script.
+ +
+ Les options de scripting intégrées qui s'exécutent en tant que partie du
+ serveur lui-même, comme mod_php, mod_perl,
+ mod_tcl, et mod_python,
+ s'exécutent sous le même utilisateur que le serveur (voir la directive
+ User), et par conséquent,
+ les scripts que ces moteurs exécutent peuvent accéder aux mêmes ressources
+ que le serveur. Certains moteurs de scripting peuvent proposer des
+ restrictions, mais pour plus de sûreté, il vaut mieux partir du principe
+ que ce n'est pas le cas.
Pour contrôler étroitement votre serveur, vous pouvez interdire
+ l'utilisation des fichiers .htaccess qui permettent de
+ passer outre les fonctionnalités de sécurité que vous avez configurées.
+ Voici un moyen pour y parvenir :
Ajoutez dans le fichier de configuration du serveur
+ +<Directory "/"> + AllowOverride None +</Directory>+ + +
Ceci interdit l'utilisation des fichiers .htaccess dans
+ tous les répertoires, sauf ceux pour lesquels c'est explicitement
+ autorisé.
Notez que c'est la configuration par défaut depuis Apache 2.3.9.
+ +Le concept d'accès par défaut est un aspect d'Apache qui est parfois mal + compris. C'est à dire que, à moins que vous ne changiez explicitement ce + comportement, si le serveur trouve son chemin vers un fichier en suivant + les règles normales de correspondance URL - fichier, il peut le retourner + aux clients.
+ +Considérons l'exemple suivant :
+ +
+ # cd /; ln -s / public_html
+ puis accès à http://localhost/~root/
+
Ceci permettrait aux clients de parcourir l'ensemble du système de + fichiers. Pour l'éviter, ajoutez le bloc suivant à la configuration + de votre serveur :
+ +<Directory "/"> + Require all denied +</Directory>+ + +
ceci va interdire l'accès par défaut à tous les fichiers du système de
+ fichiers. Vous devrez ensuite ajouter les blocs
+ Directory appropriés correspondant
+ aux répertoires auxquels vous voulez autorisez l'accès. Par exemple,
<Directory "/usr/users/*/public_html"> + Require all granted +</Directory> +<Directory "/usr/local/httpd"> + Require all granted +</Directory>+ + +
Portez une attention particulière aux interactions entre les directives
+ Location et
+ Directory ; par exemple, si une
+ directive <Directory ""/> interdit un accès, une
+ directive <Location "/"> pourra passer outre.
De même, soyez méfiant en jouant avec la directive
+ UserDir ; la positionner à
+ "./" aurait le même effet, pour root, que le premier exemple plus haut.
+ Nous vous conseillons
+ fortement d'inclure la ligne suivante dans le fichier de configuration de
+ votre serveur :
UserDir disabled root+ + +
Pour vous tenir informé de ce qui se passe réellement dans votre + serveur, vous devez consulter vos + fichiers journaux. Même si les fichiers journaux + ne consignent que des évènements qui se sont déjà produits, ils vous + informeront sur la nature des attaques qui sont lancées contre le serveur + et vous permettront de vérifier si le niveau de sécurité nécessaire est + atteint.
+ +Quelques exemples :
+ +
+ grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
+ grep "client denied" error_log | tail -n 10
+
Le premier exemple listera les attaques essayant d'exploiter la + vulnérabilité + d'Apache Tomcat pouvant provoquer la divulgation d'informations par des + requêtes Source.JSP mal formées, le second donnera la liste des dix + dernières interdictions client ; par exemple :
+ +
+ [Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied
+ by server configuration: /usr/local/apache/htdocs/.htpasswd
+
Comme vous le voyez, les fichiers journaux ne consignent que ce qui
+ s'est déjà produit ; ainsi, si le client a pu accéder au fichier
+ .htpasswd, vous devriez avoir quelque chose du style :
+ foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
+
dans votre journal des accès ; ce + qui signifie que vous avez probablement mis en commentaire ce qui suit dans + le fichier de configuration de votre serveur :
+ +<Files ".ht*"> + Require all denied +</Files>+ + +
La fusion des sections de configuration est complexe et dépend + souvent des directives utilisées. Vous devez systématiquement tester + vos modifications pour vérifier la manière dont les directives sont + fusionnées.
+ +Concernant les modules qui n'implémentent aucune logique de
+ fusion, comme mod_access_compat, le
+ comportement des sections suivantes est tributaire de la présence
+ dans ces dernières de directives appartenant à ces modules. La
+ configuration est héritée jusqu'à ce qu'une modification soit
+ effectuée ; à ce moment, la configuration est remplacée et
+ non fusionnée.
Serveur HTTP Apache Version 2.4
+| Description: | Fonctionnalités de base du serveur HTTP Apache toujours +disponibles |
|---|---|
| Statut: | Noyau httpd |
AcceptFilter AcceptPathInfo AccessFileName AddDefaultCharset AllowEncodedSlashes AllowOverride AllowOverrideList CGIMapExtension CGIPassAuth CGIVar ContentDigest DefaultRuntimeDir DefaultType Define <Directory> <DirectoryMatch> DocumentRoot <Else> <ElseIf> EnableMMAP EnableSendfile Error ErrorDocument ErrorLog ErrorLogFormat ExtendedStatus FileETag <Files> <FilesMatch> ForceType GprofDir HostnameLookups HttpProtocolOptions <If> <IfDefine> <IfDirective> <IfFile> <IfModule> <IfSection> Include IncludeOptional KeepAlive KeepAliveTimeout <Limit> <LimitExcept> LimitInternalRecursion LimitRequestBody LimitRequestFields LimitRequestFieldSize LimitRequestLine LimitXMLRequestBody <Location> <LocationMatch> LogLevel MaxKeepAliveRequests MaxRangeOverlaps MaxRangeReversals MaxRanges MergeTrailers Mutex NameVirtualHost Options Protocol Protocols ProtocolsHonorOrder QualifyRedirectURL RegexDefaultOptions RegisterHttpMethod RLimitCPU RLimitMEM RLimitNPROC ScriptInterpreterSource SeeRequestTail ServerAdmin ServerAlias ServerName ServerPath ServerRoot ServerSignature ServerTokens SetHandler SetInputFilter SetOutputFilter TimeOut TraceEnable UnDefine UseCanonicalName UseCanonicalPhysicalPort <VirtualHost>| Description: | Permet d'optimiser la configuration d'une socket pour +l'écoute d'un protocole |
|---|---|
| Syntaxe: | AcceptFilter protocole filtre
+d'acceptation |
| Contexte: | configuration globale |
| Statut: | Noyau httpd |
| Module: | core |
Cette directive permet d'effectuer une optimisation de la socket
+ d'écoute d'un type de protocole en fonction du système
+ d'exploitation. Le but premier est de faire en sorte que le noyau
+ n'envoie pas de socket au processus du serveur jusqu'à ce que
+ des données soient reçues, ou qu'une requête HTTP complète soit mise
+ en tampon. Seuls les Filtres d'acceptation de FreeBSD, le filtre plus
+ primitif TCP_DEFER_ACCEPT sous Linux, et la version
+ optimisée d'AcceptEx() de Windows sont actuellement supportés.
L'utilisation de l'argument none va désactiver tout
+ filtre d'acceptation pour ce protocole. Ceci s'avère utile pour les
+ protocoles qui nécessitent l'envoi de données par le serveur en
+ premier, comme ftp: ou nntp:
AcceptFilter nntp none+ + +
Les noms de protocoles par défaut sont https pour le
+ port 443 et http pour tous les autres ports. Pour
+ spécifier un autre protocole à utiliser avec un port en écoute,
+ ajoutez l'argument protocol à la directive Listen.
Sous FreeBSD, les valeurs par défaut sont :
+AcceptFilter http httpready +AcceptFilter https dataready+ + +
Le filtre d'acceptation httpready met en tampon des
+ requêtes HTTP entières au niveau du noyau. Quand une requête
+ entière a été reçue, le noyau l'envoie au serveur. Voir la page de
+ manuel de accf_http(9) pour plus de détails. Comme les requêtes
+ HTTPS sont chiffrées, celles-ci n'autorisent que le filtre accf_data(9).
Sous Linux, les valeurs par défaut sont :
+AcceptFilter http data +AcceptFilter https data+ + +
Le filtre TCP_DEFER_ACCEPT de Linux ne supporte pas
+ la mise en tampon des requêtes http. Toute valeur autre que
+ none active le filtre TCP_DEFER_ACCEPT
+ pour ce protocole. Pour plus de détails, voir la page de
+ manuel Linux de tcp(7).
Sous Windows, les valeurs par défaut sont :
+AcceptFilter http connect +AcceptFilter https connect+ + +
Le module MPM pour Windows mpm_winnt utilise la directive
+ AcceptFilter comme commutateur de l'API AcceptEx(), et ne supporte
+ pas la mise en tampon du protocole http. connect
+ utilise l'API AcceptEx(), extrait aussi les adresses réseau finales,
+ mais à l'instar de none, la valeur connect
+ n'attend pas la transmission des données initiales.
Sous Windows, none utilise accept() au lieu
+ d'AcceptEx(), et ne recycle pas les sockets entre les connexions.
+ Ceci s'avère utile pour les interfaces réseau dont le pilote est
+ défectueux, ainsi que pour certains fournisseurs de réseau comme les
+ pilotes vpn, ou les filtres anti-spam, anti-virus ou
+ anti-spyware.
data (Windows)Jusqu'à la version 2.4.23, le filtre d'acceptation data
+ attendait que des données aient été transmises et que le tampon de données
+ initial et l'adresse réseau finale aient été déterminés par l'invocation
+ AcceptEx(). Cette implémentation étant vulnérable à une attaque de type
+ denial of service, elle a été désactivée.
La version actuelle de httpd prend par défaut le filtre
+ connect sous Windows, et reprendra la valeur
+ data si data est spécifié. Il est fortement
+ conseillé aux utilisateurs des versions plus anciennes de définir
+ explicitement le filtre connect pour leurs AcceptFilter
+ comme indiqué plus haut.
Protocol| Description: | Les ressources acceptent des informations sous forme d'un +nom de chemin en fin de requête. |
|---|---|
| Syntaxe: | AcceptPathInfo On|Off|Default |
| Défaut: | AcceptPathInfo Default |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
Cette directive permet de définir si les requêtes contenant des
+ informations sous forme d'un nom de chemin suivant le nom d'un
+ fichier réel (ou un fichier qui n'existe pas dans un répertoire qui
+ existe) doivent être acceptées ou rejetées. Les scripts peuvent
+ accéder à cette information via la variable d'environnement
+ PATH_INFO.
Supposons par exemple que /test/ pointe vers un
+ répertoire qui ne contient que le fichier here.html.
+ Les requêtes pour /test/here.html/more et
+ /test/nothere.html/more vont affecter la valeur
+ /more à la variable d'environnement
+ PATH_INFO.
L'argument de la directive AcceptPathInfo
+ possède trois valeurs possibles :
Off/test/here.html/more dans l'exemple ci-dessus
+ renverra une erreur "404 NOT FOUND".On/test/here.html/more, la requête
+ sera acceptée si /test/here.html correspond à un nom de
+ fichier valide.DefaultPATH_INFO. Les gestionnaires qui
+ servent des scripts, commecgi-script et isapi-handler, acceptent en général par
+ défaut les requêtes avec PATH_INFO.Le but premier de la directive AcceptPathInfo est de
+ vous permettre de remplacer le choix du gestionnaire d'accepter ou
+ de rejeter PATH_INFO. Ce remplacement est nécessaire
+ par exemple, lorsque vous utilisez un filtre, comme INCLUDES, pour générer un contenu basé
+ sur PATH_INFO. Le gestionnaire de base va en général
+ rejeter la requête, et vous pouvez utiliser la configuration
+ suivante pour utiliser un tel script :
<Files "mypaths.shtml"> + Options +Includes + SetOutputFilter INCLUDES + AcceptPathInfo On +</Files>+ + + + +
| Description: | Nom du fichier de configuration distribué |
|---|---|
| Syntaxe: | AccessFileName nom-du-fichier
+[nom-du-fichier] ... |
| Défaut: | AccessFileName .htaccess |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
Au cours du traitement d'une requête, le serveur recherche le + premier fichier de configuration existant à partir de la liste + de noms dans chaque répertoire composant le chemin du document, à + partir du moment où les fichiers de configuration distribués sont activés pour ce répertoire. Par exemple + :
+ +AccessFileName .acl+ + +
avant de renvoyer le document
+ /usr/local/web/index.html, le serveur va rechercher les
+ fichiers /.acl, /usr/.acl,
+ /usr/local/.acl et /usr/local/web/.acl
+ pour y lire d'éventuelles directives, à moins quelles n'aient été
+ désactivées avec
<Directory "/"> + AllowOverride None +</Directory>+ + +
| Description: | Paramètre jeu de caractères par défaut à ajouter quand le
+type de contenu d'une réponse est text/plain ou
+text/html |
|---|---|
| Syntaxe: | AddDefaultCharset On|Off|jeu de caractères |
| Défaut: | AddDefaultCharset Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
Cette directive spécifie une valeur par défaut pour le paramètre
+ jeu de caractères du type de média (le nom d'un codage de
+ caractères) à ajouter à une réponse, si et seulement si le type de
+ contenu de la réponse est soit text/plain, soit
+ text/html. Ceci va remplacer
+ tout jeu de caractères spécifié dans le corps de la réponse via un
+ élément META, bien que cet effet dépende en fait
+ souvent de la configuration du client de l'utilisateur. La
+ définition de AddDefaultCharset Off désactive cette
+ fonctionnalité. AddDefaultCharset On ajoute un jeu de
+ caractères par défaut de iso-8859-1. Toute autre valeur
+ peut être définie via le paramètre jeu de caractères, qui
+ doit appartenir à la liste des valeurs de
+ jeux de caractères enregistrés par l'IANA à utiliser dans les
+ types de média Internet (types MIME).
+ Par exemple :
AddDefaultCharset utf-8+ + +
La directive AddDefaultCharset ne doit
+ être utilisée que lorsque toutes les ressources textes auxquelles
+ elle s'applique possèdent le jeu de caractère spécifié, et qu'il est
+ trop contraignant de définir leur jeu de caractères
+ individuellement. Un exemple de ce type est l'ajout du paramètre jeu
+ de caractères aux ressources comportant un contenu généré, comme les
+ scripts CGI hérités qui peuvent être vulnérables à des attaques de
+ type cross-site scripting à cause des données utilisateurs incluses
+ dans leur sortie. Notez cependant qu'une meilleur solution consiste
+ à corriger (ou supprimer) ces scripts, car la définition d'un jeu de
+ caractères par défaut ne protège pas les utilisateurs qui ont activé
+ la fonctionnalité "Détection automatique de l'encodage des
+ caractères" dans leur navigateur.
AddCharset| Description: | Détermine si les séparateurs de chemin encodés sont +autorisés à transiter dans les URLs tels quels |
|---|---|
| Syntaxe: | AllowEncodedSlashes On|Off|NoDecode |
| Défaut: | AllowEncodedSlashes Off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | L'option NoDecode est disponible depuis la version +2.3.12. |
La directive AllowEncodedSlashes permet
+ l'utilisation des URLs contenant des séparateurs de chemin
+ encodés dans la partie chemin
+ (%2F pour / et même %5C pour
+ \ sur les systèmes concernés).
Avec la valeur par défaut, Off, de telles URLs sont
+ refusées et provoquent le renvoi d'une erreur 404 (Not found).
Avec la valeur On, ces URLs sont acceptées, et les
+ slashes encodés sont décodés comme tout autre caractère codé.
Avec la valeur NoDecode, ces URLs sont acceptées,
+ mais les slashes codés ne sont pas décodés et laissés dans leur état
+ codé.
Définir AllowEncodedSlashes à
+ On est surtout utile en association avec
+ PATH_INFO.
Si le codage des slashes dans la partie chemin est nécessaire,
+ l'utilisation de l'option NoDecode est fortement
+ recommandée par mesure de sécurité. Permettre le décodage des
+ slashes pourrait éventuellement induire l'autorisation de chemins
+ non sûrs.
| Description: | Types de directives autorisées dans les fichiers
+.htaccess |
|---|---|
| Syntaxe: | AllowOverride All|None|type directive
+[type directive] ... |
| Défaut: | AllowOverride None à partir de la version 2.3.9, AllowOverride
+All pour les versions antérieures |
| Contexte: | répertoire |
| Statut: | Noyau httpd |
| Module: | core |
Lorsque le serveur trouve un fichier .htaccess (dont
+ le nom est défini par la directive AccessFileName), il doit savoir lesquelles
+ des directives placées dans ce fichier sont autorisées à modifier la
+ configuration préexistante.
AllowOverride ne peut être
+ utilisée que dans les sections <Directory> définies sans expressions
+ rationnelles, et non dans les sections <Location>, <DirectoryMatch> ou
+ <Files>.
+ Lorsque cette directive et la directive AllowOverrideList sont définies à None, les
+ fichiers .htaccess sont totalement
+ ignorés. Dans ce cas, le serveur n'essaiera même pas de lire les
+ fichiers .htaccess du système de fichiers.
Lorsque cette directive est définie à All, toute
+ directive valable dans le Contexte .htaccess sera
+ autorisée dans les fichiers .htaccess.
L'argument type directive peut contenir les + groupements de directives suivants (voir ce + document pour obtenir la liste à jour des directives activées pour + chaque type de directive) :
+ +AuthDBMGroupFile,
+ AuthDBMUserFile,
+ AuthGroupFile,
+ AuthName,
+ AuthType, AuthUserFile, Require, etc...).ErrorDocument, ForceType, LanguagePriority,
+ SetHandler, SetInputFilter, SetOutputFilter, et directives du
+ module mod_mime Add* et Remove*), des metadonnées
+ des documents (Header, RequestHeader, SetEnvIf, SetEnvIfNoCase, BrowserMatch, CookieExpires, CookieDomain, CookieStyle, CookieTracking, CookieName), des directives du
+ module mod_rewrite directives (RewriteEngine, RewriteOptions, RewriteBase, RewriteCond, RewriteRule), des directives du
+ module mod_alias directives (Redirect, RedirectTemp, RedirectPermanent, RedirectMatch), et de la directive
+ Action du module
+ mod_actions.
+ AddDescription,
+ AddIcon, AddIconByEncoding,
+ AddIconByType,
+ DefaultIcon, DirectoryIndex, FancyIndexing,
+ HeaderName, IndexIgnore, IndexOptions, ReadmeName,
+ etc...).Allow, Deny et Order).Notez qu'une erreur de syntaxe dans une directive valide + causera toujours une internal server error.
+Options et XBitHack). "Options" doit être
+ suivi d'un signe "égal", puis d'une liste d'options séparées par des
+ virgules (pas d'espaces) ; ces options doivent être définies à
+ l'aide de la commande Options.
+
+ Bien que la liste des options disponibles dans les fichiers
+ .htaccess puisse être limitée par cette directive, tant qu'un
+ directive Options est
+ autorisée, toute autre option héritée peut être désactivée en
+ utilisant la syntaxe non-relative. En d'autres termes, ce
+ mécanisme ne peut pas forcer une option spécifique à rester
+ activée tout en permettant à toute autre option d'être
+ activée.
+
+ AllowOverride Options=Indexes,MultiViews
+
Exemple :
+ +AllowOverride AuthConfig Indexes+ + +
Dans l'exemple ci-dessus, toutes les directives qui ne font
+ partie ni du groupe AuthConfig, ni du groupe
+ Indexes, provoquent une erreur "internal
+ server error".
Pour des raisons de sécurité et de performance, ne
+ définissez pas AllowOverride à autre chose que
+ None dans votre bloc <Directory "/">.
+ Recherchez plutôt (ou créez) le bloc <Directory>
+ qui se réfère au répertoire où vous allez précisément placer un
+ fichier .htaccess.
| Description: | Directives autorisées dans les fichiers .htaccess |
|---|---|
| Syntaxe: | AllowOverrideList None|directive
+[directive-type] ... |
| Défaut: | AllowOverrideList None |
| Contexte: | répertoire |
| Statut: | Noyau httpd |
| Module: | core |
Lorsque le serveur trouve un fichier .htaccess
+ (comme spécifié par la directive AccessFileName), il doit savoir lesquelles
+ des directives déclarées dans ce fichier peuvent remplacer des
+ directives des fichiers de configuration du serveur.
AllowOverrideList n'est
+ disponible que dans les sections <Directory> spécifiées sans expressions
+ rationnelles.
+ Lorsque cette directive et la directive AllowOverride sont définies à
+ None, les fichiers .htaccess sont totalement ignorés. Dans
+ ce cas, le serveur ne cherchera même pas à lire des fichiers
+ .htaccess dans le système de fichiers.
Example:
+ +AllowOverride None +AllowOverrideList Redirect RedirectMatch+ + +
Dans l'exemple ci-dessus, seules les directives
+ Redirect et RedirectMatch sont autorisées.
+ Toutes les autres provoqueront une erreur interne du serveur.
Example:
+ +AllowOverride AuthConfig +AllowOverrideList CookieTracking CookieName+ + +
Dans l'exemple ci-dessus, la directive AllowOverride autorise les directives du
+ groupement AuthConfig, et
+ AllowOverrideList n'autorise que deux
+ directives du groupement FileInfo. Toutes les autres
+ provoqueront une erreur interne du serveur.
| Description: | Technique permettant de localiser l'interpréteur des +scripts CGI |
|---|---|
| Syntaxe: | CGIMapExtension chemin CGI .extension |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | NetWare uniquement |
Cette directive permet de contrôler la manière dont Apache httpd trouve
+ l'interpréteur servant à exécuter les scripts CGI. Par exemple, avec
+ la définition CGIMapExtension sys:\foo.nlm .foo, tous
+ les fichiers scripts CGI possédant une extension .foo
+ seront passés à l'interpréteur FOO.
| Description: | Active la transmission d'en-têtes d'autorisation HTTP aux scripts en +tant que variables CGI |
|---|---|
| Syntaxe: | CGIPassAuth On|Off |
| Défaut: | CGIPassAuth Off |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible à partir de la version 2.4.13 du serveur HTTP +Apache |
La directive CGIPassAuth permet aux
+ scripts d'accéder aux en-têtes d'autorisation HTTP tels que
+ Authorization, en-tête nécessaire aux scripts qui
+ implémente une authentification HTTP de base. Normalement, ces
+ en-têtes HTTP sont invisibles pour les scripts car ils leurs
+ permettraient de voir les identifiants et mots de passe
+ utilisés pour accéder au serveur lorsque l'authentification HTTP de
+ base est activée au niveau du serveur web. Cette directive doit être
+ définie à "On" lorsque des scripts sont autorisés à implémenter une
+ authentification HTTP de base.
Cette directive constitue une alternative à l'option de
+ compilation SECURITY_HOLE_PASS_AUTHORIZATION qui était
+ déjà disponible dans les versions précédentes du serveur HTTP
+ Apache.
Cette option est prise en compte par tout module qui utilise
+ ap_add_common_vars(), comme mod_cgi,
+ mod_cgid, mod_proxy_fcgi,
+ mod_proxy_scgi, etc... En particulier, elle affecte
+ les modules qui ne traitent pas à proprement parler les requêtes,
+ mais utilisent quand-même cette API, comme
+ mod_include ou mod_ext_filter. Les
+ modules tiers qui n'utilisent pas ap_add_common_vars()
+ peuvent aussi choisir de prendre en compte cette option.
| Description: | Contrôle la manière dont certaines variables CGI sont définies |
|---|---|
| Syntaxe: | CGIVar variable rule |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible à partir de la version 2.4.21 du serveur HTTP Apache |
Cette directive permet de contrôler la manière dont certaines variables CGI + sont définies.
+ +règles REQUEST_URI :
+original-uri (valeur par défaut)current-uri| Description: | Active la génération d'un en-tête Content-MD5
+dans la réponse HTTP |
|---|---|
| Syntaxe: | ContentDigest On|Off |
| Défaut: | ContentDigest Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Options |
| Statut: | Noyau httpd |
| Module: | core |
Cette directive active la génération d'un en-tête
+ Content-MD5 selon les définitions des RFC 1864 et
+ 2616.
MD5 est un algorithme permettant de générer un condensé (parfois + appelé "empreinte") à partir de données d'une taille aléatoire ; le + degré de précision est tel que la moindre altération des données + d'origine entraîne une altération de l'empreinte.
+ +L'en-tête Content-MD5 permet de vérifier
+ l'intégrité de la réponse HTTP dans son ensemble. Un serveur mandataire
+ ou un client peut utiliser cet en-tête pour rechercher une
+ éventuelle modification accidentelle de la réponse au cours de sa
+ transmission. Exemple d'en-tête :
+ Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
+
Notez que des problèmes de performances peuvent affecter votre + serveur, car l'empreinte est générée pour chaque requête (il n'y a + pas de mise en cache).
+ +L'en-tête Content-MD5 n'est envoyé qu'avec les
+ documents servis par le module core, à l'exclusion
+ de tout autre module. Ainsi, les documents SSI, les sorties de
+ scripts CGI, et les réponses à des requêtes partielles (byte range)
+ ne comportent pas cet en-tête.
| Description: | Répertoire de base des fichiers créés au cours de l'exécution du serveur |
|---|---|
| Syntaxe: | DefaultRuntimeDir chemin-répertoire |
| Défaut: | DefaultRuntimeDir DEFAULT_REL_RUNTIMEDIR (logs/) |
| Contexte: | configuration globale |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible depuis la version 2.4.2 du serveur HTTP Apache |
La directive DefaultRuntimeDir permet de
+ définir le répertoire dans lequel le serveur va créer les différents
+ fichiers relatifs à son exécution (mémoire partagée, verrous,
+ etc...). Si le chemin spécifié est relatif, le chemin absolu sera
+ généré relativement à la valeur de la directive
+ ServerRoot
Example
+DefaultRuntimeDir scratch/+ + +
La valeur par défaut de la directive
+ DefaultRuntimeDir peut être modifiée en
+ changeant la valeur de la macro DEFAULT_REL_RUNTIMEDIR
+ définie à la compilation.
Note: si la valeur de ServerRoot n'a pas
+ été spécifiée avant d'utiliser cette directive, c'est la valeur par
+ défaut de ServerRoot qui sera utilisée pour
+ définir la base du répertoire.
ServerRoot| Description: | Les seuls effets de cette directive sont des émissions
+d'avertissements si sa valeur est différente de none. Dans
+les versions précédentes, DefaultType permettait de spécifier un type de
+média à assigner par défaut au contenu d'une réponse pour lequel aucun
+autre type de média n'avait été trouvé.
+ |
|---|---|
| Syntaxe: | DefaultType type média|none |
| Défaut: | DefaultType none |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | L'argument none est disponible dans les
+versions d'Apache httpd 2.2.7 et supérieures. Tous les autres choix sont
+DESACTIVÉS à partir des version 2.3.x. |
Cette directive a été désactivée. Pour la compatibilité
+ ascendante avec les anciens fichiers de configuration, elle peut
+ être spécifiée avec la valeur none, c'est à dire sans
+ type de médium par défaut. Par exemple :
DefaultType None+ + +
DefaultType None n'est disponible que dans les
+ versions d'Apache 2.2.7 et supérieures.
Utilisez le fichier de configuration mime.types et la directive
+ AddType pour configurer
+ l'assignement d'un type de médium via les extensions de fichiers, ou
+ la directive ForceType pour
+ attribuer un type de médium à des ressources spécifiques. Dans le
+ cas contraire, le serveur enverra sa réponse sans champ d'en-tête
+ Content-Type, et le destinataire devra déterminer lui-même le type
+ de médium.
| Description: | Permet de définir une variable |
|---|---|
| Syntaxe: | Define nom-paramètre [valeur-paramètre] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Noyau httpd |
| Module: | core |
Avec un seul paramètre, l'effet de la directive
+ Define est identique à celui de l'argument
+ -D du programme httpd. Il permet de
+ modifier le comportement des sections <IfDefine> sans avoir à ajouter d'argument
+ -D au sein des scripts de démarrage.
De plus, le second paramètre permet d'affecter une valeur à la
+ variable définie par le premier. Cette variable peut être référencée
+ dans le fichier de configuration via la syntaxe ${VAR}.
+ La portée de la variable est toujours globale, et n'est jamais
+ limitée à la section de configuration courante.
<IfDefine TEST>
+ Define servername test.example.com
+</IfDefine>
+<IfDefine !TEST>
+ Define servername www.example.com
+ Define SSL
+</IfDefine>
+
+DocumentRoot "/var/www/${servername}/htdocs"
+
+
+ Le caractère ":" est interdit dans les noms de variables afin
+ d'éviter les conflits avec la syntaxe de la directive RewriteMap.
Si cette directive est définie au sein d'un bloc VirtualHost, les + changements qu'elle induit sont visibles de toute directive + ultérieure, au delà de tout bloc VirtualHost.
+| Description: | Regroupe un ensemble de directives qui ne s'appliquent +qu'au répertoire concerné du système de fichiers, à ses +sous-répertoires, et à leur contenu. |
|---|---|
| Syntaxe: | <Directory chemin répertoire>
+... </Directory> |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
Les balises <Directory> et
+ </Directory> permettent de regrouper un ensemble
+ de directives qui ne s'appliquent qu'au répertoire précisé,
+ à ses sous-répertoires, et aux fichiers situés dans ces
+ sous-répertoires. Toute directive
+ autorisée dans un contexte de répertoire peut être utilisée.
+ chemin répertoire est soit le chemin absolu d'un
+ répertoire, soit une chaîne de caractères avec caractères génériques
+ utilisant la comparaison Unix de style shell. Dans une chaîne de
+ caractères avec caractères génériques, ? correspond à
+ un caractère quelconque, et * à toute chaîne de
+ caractères. Les intervalles de caractères [] sont aussi
+ autorisés. Aucun caractère générique ne peut remplacer le caractère
+ `/', si bien que l'expression <Directory
+ "/*/public_html"> ne conviendra pas pour le chemin
+ * /home/user/public_html, alors que <Directory
+ "/home/*/public_html"> conviendra. Exemple :
<Directory "/usr/local/httpd/htdocs"> + Options Indexes FollowSymLinks +</Directory>+ + +
Les chemins de répertoires contenant des espaces doivent être + entourés de guillemets afin d'empêcher l'interprétation de ces + espaces comme fins d'arguments.
+ +Soyez prudent avec l'argument chemin répertoire : il
+ doit correspondre exactement au chemin du système de fichier
+ qu'Apache httpd utilise pour accéder aux fichiers. Les directives
+ comprises dans une section <Directory> ne
+ s'appliqueront pas aux fichiers du même répertoire auxquels on
+ aura accédé via un chemin différent, per exemple via un lien
+ symbolique.
Les Expressions rationnelles
+ peuvent aussi être utilisées en ajoutant le caractère
+ ~. Par exemple :
<Directory ~ "^/www/[0-9]{3}">
+
+</Directory>
+
+
+ pourra correspondre à tout répertoire situé dans /www/ et dont le + nom se compose de trois chiffres.
+ +Si plusieurs sections <Directory> (sans expression rationnelle)
+ correspondent au répertoire (ou à un de ses parents) qui contient le
+ document, les directives de la section <Directory> dont le chemin est le plus
+ court sont appliquées en premier, en s'intercalant avec les
+ directives des fichiers .htaccess. Par
+ exemple, avec
<Directory "/"> + AllowOverride None +</Directory> + +<Directory "/home"> + AllowOverride FileInfo +</Directory>+ + +
l'accès au document /home/web/dir/doc.html emprunte
+ le chemin suivant :
AllowOverride None
+ (qui désactive les fichiers .htaccess).AllowOverride
+ FileInfo (pour le répertoire /home).FileInfo qui se
+ trouverait dans d'éventuels fichiers /home/.htaccess,
+ /home/web/.htaccess ou
+ /home/web/dir/.htaccess, dans cet ordre.Les directives associées aux répertoires sous forme d'expressions + rationnelles ne sont prises en compte qu'une fois toutes les + directives des sections sans expressions rationnelles appliquées. + Alors, tous les répertoires avec expressions rationnelles sont + testés selon l'ordre dans lequel ils apparaissent dans le fichier de + configuration. Par exemple, avec
+ +<Directory ~ "abc$"> + # ... directives ici ... +</Directory>+ + +
la section avec expression rationnelle ne sera prise en compte
+ qu'après les sections <Directory> sans expression rationnelle
+ et les fichiers .htaccess. Alors, l'expression
+ rationnelle conviendra pour /home/abc/public_html/abc
+ et la section <Directory>
+ correspondante s'appliquera.
Notez que la politique d'accès par défaut
+ dans les sections <Directory "/"> consiste à
+ autoriser tout accès sans restriction. Ceci signifie qu'Apache httpd va servir tout fichier
+ correspondant à une URL. Il est recommandé de modifier cette
+ situation à l'aide d'un bloc du style
<Directory "/"> + Require all denied +</Directory>+ + +
puis d'affiner la configuration pour les répertoires que vous + voulez rendre accessibles. Voir la page Conseils à propos de sécurité + pour plus de détails.
+ +Les sections <Directory> se situent
+ dans le fichier httpd.conf. Les directives <Directory> ne peuvent pas être imbriquées
+ et ne sont pas autorisées dans les sections <Limit> ou <LimitExcept>.
| Description: | Regroupe des directives qui s'appliquent au contenu de répertoires +du système de fichiers correspondant à une expression rationnelle |
|---|---|
| Syntaxe: | <DirectoryMatch regex>
+... </DirectoryMatch> |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
Les balises <DirectoryMatch>
+ et </DirectoryMatch> permettent de regrouper un
+ ensemble de directives qui ne s'appliqueront qu'au répertoire
+ précisé (et aux fichiers qu'il contient), comme pour la section <Directory>. Cependant, le
+ répertoire est précisé sous la forme d'une expression rationnelle. Par exemple :
<DirectoryMatch "^/www/(.+/)?[0-9]{3}/">
+ # ...
+</DirectoryMatch>
+
+
+ convient pour les sous-répertoires de /www/ dont
+ le nom se compose de trois chiffres.
<Directory>), et ne tenait pas compte du
+ symbole de fin de ligne ($). Depuis la version 2.3.9, seuls les
+ répertoires qui correspondent à l'expression sont affectés par les
+ directives contenues dans la section.
+ A partir de la version 2.4.8, les groupes nommés et les
+ références arrières sont extraits et enregistrés dans
+ l'environnement avec leur nom en majuscules et préfixé
+ par "MATCH_". Ceci permet
+ de référencer des URLs dans des expressions
+ ou au sein de modules comme mod_rewrite. Pour
+ éviter toute confusion, les références arrières numérotées (non
+ nommées) sont ignorées. Vous devez utiliser à la place des groupes
+ nommés.
<DirectoryMatch "^/var/www/combined/(?<sitename>[^/]+)">
+ Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
+</DirectoryMatch>
+
+
+
+<Directory>
+pour une description de la manière dont les expressions rationnelles
+sont traitées en présence d'autres sections <Directory> sans expressions rationnelles| Description: | Racine principale de l'arborescence des documents visible +depuis Internet |
|---|---|
| Syntaxe: | DocumentRoot chemin répertoire |
| Défaut: | DocumentRoot "/usr/local/apache/htdocs" |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
Cette directive permet de définir le répertoire à partir duquel
+ httpd va servir les fichiers. S'il ne correspond
+ pas à un Alias, le chemin
+ de l'URL sera ajouté par le serveur à la racine des documents afin
+ de construire le chemin du document recherché. Exemple :
DocumentRoot "/usr/web"+ + +
un accès à http://my.example.com/index.html se
+ réfère alors à /usr/web/index.html. Si chemin
+ répertoire n'est pas un chemin absolu, il est considéré comme
+ relatif au chemin défini par la directive ServerRoot.
Le répertoire défini par la directive
+ DocumentRoot ne doit pas comporter de slash
+ final.
| Description: | Contient des directives qui ne s'appliquent que si la
+condition correspondant à la section <If> ou <ElseIf> précédente n'est pas satisfaite par la
+requête à l'exécution |
|---|---|
| Syntaxe: | <Else> ... </Else> |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Les conditions imbriquées sont supportées à partir de la version +2.4.26 du serveur HTTP Apache |
La section <Else> applique
+ les directives qu'elle contient si et seulement si les conditions
+ correspondant à la section <If>
+ ou <ElseIf> immédiatement
+ supérieure et dans la même portée n'ont pas été satisfaites. Par
+ exemple, dans :
<If "-z req('Host')">
+ # ...
+</If>
+<Else>
+ # ...
+</Else>
+
+
+ La condition de la section <If> serait satisfaite pour les requêtes
+ HTTP/1.0 sans en-tête Host:, alors que celle de la section
+ <Else> le serait pour les
+ requêtes comportant un en-tête Host:.
<If><ElseIf><If>,
+ <ElseIf>, et <Else> s'appliquent en dernier.| Description: | Contient des directives qui ne s'appliquent que si la
+condition correspondante est satisfaite par une requête à l'exécution,
+alors que la condition correspondant à la section <If> ou <ElseIf> précédente ne l'était pas. |
|---|---|
| Syntaxe: | <ElseIf expression> ... </ElseIf> |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Les conditions imbriquées sont supportées à partir de la version +2.4.26 du serveur HTTP Apache |
La section <ElseIf> applique
+ les directives qu'elle contient si et seulement si d'une part la
+ condition correspondante est satisfaite, et d'autre part la condition
+ correspondant à la section <If>
+ ou <ElseIf> de la même portée ne
+ l'est pas. Par exemple, dans :
<If "-R '10.1.0.0/16'"> + #... +</If> +<ElseIf "-R '10.0.0.0/8'"> + #... +</ElseIf> +<Else> + #... +</Else>+ + +
La condition correspondant à la section <ElseIf> est satisfaite si l'adresse
+ distante de la requête appartient au sous-réseau 10.0.0.0/8, mais
+ pas si elle appartient au sous-réseau 10.1.0.0/16.
<If><Else><If>,
+ <ElseIf>, et <Else> s'appliquent en dernier.| Description: | Utilise la projection en mémoire (Memory-Mapping) pour +lire les fichiers pendant qu'ils sont servis |
|---|---|
| Syntaxe: | EnableMMAP On|Off |
| Défaut: | EnableMMAP On |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
Cette directive définit si httpd peut utiliser
+ la projection en mémoire (Memory-Mapping) quand il doit lire le contenu
+ d'un fichier pendant qu'il est servi. Par défaut, lorsque le
+ traitement d'une requête requiert l'accès aux données contenues dans
+ un fichier -- par exemple, pour servir un fichier interprété par le
+ serveur à l'aide de mod_include -- Apache httpd projette
+ le fichier en mémoire si le système d'exploitation le permet.
Cette projection en mémoire induit parfois une amélioration des + performances. Sur certains systèmes cependant, il est préférable de + désactiver la projection en mémoire afin d'éviter certains problèmes + opérationnels :
+ +httpd.httpd, la suppression ou la troncature d'un
+ fichier peut provoquer un crash de httpd avec une
+ erreur de segmentation.Pour les configurations de serveur sujettes à ce genre de + problème, il est préférable de désactiver la projection en mémoire + des fichiers servis en spécifiant :
+ +EnableMMAP Off+ + +
Pour les montages NFS, cette fonctionnalité peut être + explicitement désactivée pour les fichiers concernés en spécifiant + :
+ +<Directory "/path-to-nfs-files"> + EnableMMAP Off +</Directory>+ + +
| Description: | Utilise le support sendfile du noyau pour servir les +fichiers aux clients |
|---|---|
| Syntaxe: | EnableSendfile On|Off |
| Défaut: | EnableSendfile Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Par défaut à Off depuis la version 2.3.9. |
Cette directive définit si le programme httpd
+ peut utiliser le support sendfile du noyau pour transmettre le
+ contenu des fichiers aux clients. Par défaut, lorsque le traitement
+ d'une requête ne requiert pas l'accès aux données contenues dans un
+ fichier -- par exemple, pour la transmission d'un fichier statique
+ -- Apache httpd utilise sendfile pour transmettre le contenu du fichier
+ sans même lire ce dernier, si le système d'exploitation le
+ permet.
Ce mécanisme sendfile évite la séparation des opérations de + lecture et d'envoi, ainsi que les réservations de tampons. sur + certains systèmes cependant, ou sous certains systèmes de fichiers, + il est préférable de désactiver cette fonctionnalité afin d'éviter + certains problèmes opérationnels :
+ +sendfile peut s'avérer incapable de
+ traiter les fichiers de plus de 2 Go.DocumentRoot (par exemple NFS, SMB, CIFS,
+ FUSE), le
+ noyau peut s'avérer incapable de servir un fichier de ce montage
+ réseau en passant par son propre cache.Pour les configurations de serveur non sujettes à ce genre de + problème, vous pouvez activer cette fonctionnalité en + spécifiant :
+ +EnableSendfile On+ + +
Pour les montages réseau, cette fonctionnalité peut être + explicitement désactivée pour les fichiers concernés en spécifiant + :
+ +<Directory "/path-to-nfs-files"> + EnableSendfile Off +</Directory>+ +
Veuillez noter que la configuration de la directive
+ EnableSendfile dans un contexte de répertoire
+ ou de fichier .htaccess n'est pas supportée par
+ mod_cache_disk. Le module ne prend en compte la
+ définition de EnableSendfile que dans un
+ contexte global.
+
| Description: | Interrompt la lecture de la configuration avec un message +d'erreur personnalisé |
|---|---|
| Syntaxe: | Error message |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | à partir de la version 2.3.9 |
Si une erreur peut être détectée dans la configuration, souvent + un module manquant, cette + directive peut être utilisée pour générer un message d'erreur + personnalisé, et interrompre la lecture de la configuration.
+ +# Exemple +# vérification du chargement de mod_include +<IfModule !include_module> + Error "mod_include is required by mod_foo. Load it with LoadModule." +</IfModule> + +# vérification de la définition de SSL ou (exclusif) NOSSL +<IfDefine SSL> +<IfDefine NOSSL> + Error "Both SSL and NOSSL are defined. Define only one of them." +</IfDefine> +</IfDefine> +<IfDefine !SSL> +<IfDefine !NOSSL> + Error "Either SSL or NOSSL must be defined." +</IfDefine> +</IfDefine>+ + + +
| Description: | Document que le serveur renvoie au client en cas +d'erreur |
|---|---|
| Syntaxe: | ErrorDocument code erreur document |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
Apache httpd peut traiter les problèmes et les erreurs de quatre + manières,
+ +La première option constitue le comportement par défaut; pour
+ choisir une des trois autres options, il faut configurer Apache à
+ l'aide de la directive ErrorDocument, suivie
+ du code de la réponse HTTP et d'une URL ou d'un message. Apache
+ httpd fournit parfois des informations supplémentaires à propos du
+ problème ou de l'erreur.
A partir de la version 2.4.13, il est possible d'utiliser la syntaxe des expressions dans cette directive + afin de générer des chaînes et URLs dynamiques.
+ +Les URLs peuvent commencer par un slash (/) pour les chemins web
+ locaux (relatifs au répertoire défini par la directive DocumentRoot), ou se présenter sous la
+ forme d'une URL complète que le client pourra résoudre.
+ Alternativement, un message à afficher par le navigateur pourra être
+ fourni. Notez que la décision de considérer le paramètre comme URL,
+ chemin ou message intervient avant toute interprètation
+ d'expression. Exemples :
ErrorDocument 500 http://example.com/cgi-bin/server-error.cgi
+ErrorDocument 404 /errors/bad_urls.php
+ErrorDocument 401 /subscription_info.html
+ErrorDocument 403 "Sorry can't allow you access today"
+ErrorDocument 403 Forbidden!
+ErrorDocument 403 /errors/forbidden.py?referrer=%{escape:%{HTTP_REFERER}}
+
+
+ De plus, on peut spécifier la valeur spéciale default
+ pour indiquer l'utilisation d'un simple message d'Apache httpd codé en
+ dur. Bien que non nécessaire dans des circonstances normales, la
+ spécification de la valeur default va permettre de
+ rétablir l'utilisation du simple message d'Apache httpd codé en dur pour
+ les configurations qui sans cela, hériteraient d'une directive
+ ErrorDocument existante.
ErrorDocument 404 /cgi-bin/bad_urls.pl + +<Directory "/web/docs"> + ErrorDocument 404 default +</Directory>+ + +
Notez que lorsque vous spécifiez une directive
+ ErrorDocument pointant vers une URL distante
+ (c'est à dire tout ce qui commence par le préfixe http), le serveur
+ HTTP Apache va
+ envoyer une redirection au client afin de lui indiquer où trouver le
+ document, même dans le cas où ce document se trouve sur le serveur
+ local. Ceci a de nombreuses conséquences dont la plus importante
+ réside dans le fait que le client ne recevra pas le code d'erreur
+ original, mais au contraire un code de statut de redirection. Ceci
+ peut en retour semer la confusion chez les robots web et divers
+ clients qui tentent de déterminer la validité d'une URL en examinant
+ le code de statut. De plus, si vous utilisez une URL distante avec
+ ErrorDocument 401, le client ne saura pas qu'il doit
+ demander un mot de passe à l'utilisateur car il ne recevra pas le
+ code de statut 401. C'est pourquoi, si vous utilisez une
+ directive ErrorDocument 401, elle devra faire référence
+ à un document par le biais d'un chemin local.
Microsoft Internet Explorer (MSIE) ignore par défaut les messages + d'erreur générés par le serveur lorsqu'ils sont trop courts et + remplacent ses propres messages d'erreur "amicaux". Le seuil de + taille varie en fonction du type d'erreur, mais en général, si la + taille de votre message d'erreur est supérieure à 512 octets, il y a + peu de chances pour que MSIE l'occulte, et il sera affiché par ce + dernier. Vous trouverez d'avantage d'informations dans l'article de + la base de connaissances Microsoft Q294807.
+ +Bien que la plupart des messages d'erreur internes originaux
+ puissent être remplacés, ceux-ci sont cependant conservés dans
+ certaines circonstances sans tenir compte de la définition de la
+ directive ErrorDocument. En
+ particulier, en cas de détection d'une requête mal formée, le
+ processus de traitement normal des requêtes est immédiatement
+ interrompu, et un message d'erreur interne est renvoyé, ceci afin de
+ se prémunir contre les problèmes de sécurité liés aux requêtes mal
+ formées.
Si vous utilisez mod_proxy, il est en général préférable
+ d'activer ProxyErrorOverride afin d'être en
+ mesure de produire des messages d'erreur personnalisés pour le
+ compte de votre serveur d'origine. Si vous n'activez pas
+ ProxyErrorOverride, Apache httpd ne générera pas de messages d'erreur
+ personnalisés pour le contenu mandaté.
| Description: | Définition du chemin du journal des erreurs |
|---|---|
| Syntaxe: | ErrorLog file-path|syslog[:[facility][:tag]] |
| Défaut: | ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2) |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
La directive ErrorLog permet de définir le
+ nom du fichier dans lequel le serveur va journaliser toutes les
+ erreurs qu'il rencontre. Si le file-path n'est pas
+ absolu, il est considéré comme relatif au chemin défini par la
+ directive ServerRoot.
ErrorLog "/var/log/httpd/error_log"+ + +
Si le file-path commence par une barre verticale
+ "(|)", il est considéré comme une commande à lancer pour traiter la
+ journalisation de l'erreur.
ErrorLog "|/usr/local/bin/httpd_errors"+ + +
Voir les notes à propos des journaux + redirigés pour plus d'informations.
+ +L'utilisation de syslog à la place d'un nom de
+ fichier active la journalisation via syslogd(8) si le système le
+ supporte. Le dispositif syslog par défaut est local7,
+ mais vous pouvez le modifier à l'aide de la syntaxe
+ syslog:facility, où facility peut
+ être remplacé par un des noms habituellement documentés dans la page
+ de man syslog(1). Le dispositif syslog local7 est
+ global, et si il est modifié dans un serveur virtuel, le dispositif
+ final spécifié affecte l'ensemble du serveur. La même règle s'applique au
+ tag syslog qui utilise par défaut le nom du binaire du serveur HTTP Apache
+ httpd dans la plupart des cas. Vous pouvez aussi modifier cette
+ valeur en utilisant la syntaxe syslog::tag.
ErrorLog syslog:user +ErrorLog syslog:user:httpd.srv1 +ErrorLog syslog::httpd.srv2+ + +
Des modules supplémentaires peuvent fournir leurs propres
+ fournisseurs ErrorLog. La syntaxe est similaire à celle de
+ l'exemple syslog ci-dessus.
SECURITE : Voir le document conseils à propos de + sécurité pour des détails sur les raisons pour lesquelles votre + sécurité peut être compromise si le répertoire contenant les + fichiers journaux présente des droits en écriture pour tout autre + utilisateur que celui sous lequel le serveur est démarré.
+Lors de la spécification d'un chemin de fichier sur les + plates-formes non-Unix, on doit veiller à n'utiliser que des + slashes (/), même si la plate-forme autorise l'utilisation des + anti-slashes (\). Et d'une manière générale, il est recommandé de + n'utiliser que des slashes (/) dans les fichiers de + configuration.
+| Description: | Spécification du format des entrées du journal des erreurs |
|---|---|
| Syntaxe: | ErrorLogFormat [connection|request] format |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
La directive ErrorLogFormat permet de
+ spécifier quelles informations supplémentaires vont être enregistrées
+ dans le journal des erreurs en plus du message habituel.
# Exemple simple +ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"+ + +
La spécification de connection ou
+ request comme premier paramètre permet de définir des
+ formats supplémentaires, ce qui a pour effet de journaliser des
+ informations additionnelles lorsque le premier message est
+ enregistré respectivement pour une connexion ou une requête
+ spécifique. Ces informations additionnelles ne sont enregistrées
+ qu'une seule fois par connexion/requête. Si le traitement d'une
+ connexion ou d'une requête ne génère aucun message dans le journal,
+ alors aucune information additionnelle n'est enregistrée.
Il peut arriver que certains items de la chaîne de format ne
+ produisent aucune sortie. Par exemple, l'en-tête Referer n'est
+ présent que si le message du journal est associé à une requête et s'il
+ est généré à un moment où l'en-tête Referer a déjà été lu par le
+ client. Si aucune sortie n'est générée, le comportement par défaut
+ consiste à supprimer tout ce qui se trouve entre l'espace précédent
+ et le suivant. Ceci implique que la ligne de journalisation est
+ divisée en champs ne contenant pas d'espace séparés par des espaces.
+ Si un item de la chaîne de format ne génère aucune sortie,
+ l'ensemble du champ est omis. Par exemple, si l'adresse distante
+ %a du format [%t] [%l] [%a] %M n'est
+ pas disponible, les crochets qui l'entourent ne seront eux-mêmes pas
+ enregistrés. Il est possible d'échapper les espaces par un anti-slash
+ afin qu'ils ne soient pas considérés comme séparateurs de champs.
+ La combinaison '% ' (pourcentage espace) est un délimiteur de
+ champ de taille nulle qui ne génère aucune sortie.
Ce comportement peut être changé en ajoutant des modificateurs à
+ l'item de la chaîne de format. Le modificateur -
+ (moins) provoque l'enregistrement d'un signe moins si l'item
+ considéré ne génère aucune sortie. Pour les formats à enregistrement
+ unique par connexion/requête, il est aussi possible d'utiliser le
+ modificateur + (plus). Si un item ne générant aucune
+ sortie possède le modificateur plus, la ligne dans son ensemble est
+ omise.
Un modificateur de type entier permet d'assigner un niveau de + sévérité à un item de format. L'item considéré ne + sera journalisé que si la sévérité du message n'est pas + plus haute que le niveau de sévérité spécifié. Les + valeurs possibles vont de 1 (alert) à 15 (trace8), en passant par 4 + (warn) ou 7 (debug).
+ +Par exemple, voici ce qui arriverait si vous ajoutiez des
+ modificateurs à l'item %{Referer}i qui enregistre le
+ contenu de l'en-tête Referer.
| Item modifié | Signification |
|---|---|
%-{Referer}i |
+ Enregistre le caractère - si l'en-tête
+ Referer n'est pas défini. |
+
%+{Referer}i |
+ N'enregistre rien si l'en-tête
+ Referer n'est pas défini. |
+
%4{Referer}i |
+ N'enregistre le contenu de l'en-tête Referer que si
+ la sévérité du message de journalisation est supérieure à 4. |
+
Certains items de format acceptent des paramètres supplémentaires + entre accolades.
+ +| Chaîne de format | Description |
|---|---|
%% |
+ Le signe pourcentage |
%a |
+ Adresse IP et port clients |
%{c}a |
+ Port et adresse IP sous-jacents du correspondant pour la
+ connexion (voir le module
+ mod_remoteip) |
%A |
+ Adresse IP et port locaux |
%{name}e |
+ Variable d'environnement de requête name |
%E |
+ Etat d'erreur APR/OS et chaîne |
%F |
+ Nom du fichier source et numéro de ligne de l'appel du + journal |
%{name}i |
+ En-tête de requête name |
%k |
+ Nombre de requêtes persistantes pour cette connexion |
%l |
+ Sévérité du message |
%L |
+ Identifiant journal de la requête |
%{c}L |
+ Identifiant journal de la connexion |
%{C}L |
+ Identifiant journal de la connexion si utilisé dans la + portée de la connexion, vide sinon |
%m |
+ Nom du module qui effectue la journalisation du message |
%M |
+ Le message effectif |
%{name}n |
+ Note de requête name |
%P |
+ Identifiant du processus courant |
%T |
+ Identifiant du thread courant |
%{g}T |
+ Identifiant unique de thread système du thread courant
+ (l'identifiant affiché par la commande top par
+ exemple ; seulement sous Linux pour l'instant) |
%t |
+ L'heure courante |
%{u}t |
+ L'heure courante avec les microsecondes |
%{cu}t |
+ L'heure courante au format compact ISO 8601, avec les + microsecondes |
%v |
+ Le nom de serveur canonique ServerName du serveur courant. |
%V |
+ Le nom de serveur du serveur qui sert la requête en accord
+ avec la définition de la directive UseCanonicalName. |
\ (anti-slash espace) |
+ Espace non délimiteur |
% (pourcentage espace) |
+ Délimiteur de champ (aucune sortie) |
L'item de format identifiant journal %L génère un
+ identifiant unique pour une connexion ou une requête. Il peut servir
+ à déterminer quelles lignes correspondent à la même connexion ou
+ requête ou quelle requête est associée à tel connexion. Un item de
+ format %L est aussi disponible dans le module
+ mod_log_config, mais il permet dans ce contexte de
+ corréler les entrées du journal des accès avec celles du journal des
+ erreurs. Si le module mod_unique_id est chargé,
+ c'est son identifiant unique qui sera utilisé comme identifiant de
+ journal pour les requêtes.
# Exemple (format par défaut pour les MPMs threadés)
+ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"
+
+
+ Cet exemple renverrait un message d'erreur du style :
+ +
+ [Thu May 12 08:28:57.652118 2011] [core:error] [pid 8777:tid 4326490112] [client ::1:58619] File does not exist: /usr/local/apache2/htdocs/favicon.ico
+
Notez que, comme indiqué plus haut, certains champs sont + totalement supprimés s'ils n'ont pas été définis.
+ +# Exemple (similaire au format 2.2.x)
+ErrorLogFormat "[%t] [%l] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"
+
+
+ # Exemple avancé avec identifiants journal de requête/connexion
+ErrorLogFormat "[%{uc}t] [%-m:%-l] [R:%L] [C:%{C}L] %7F: %E: %M"
+ErrorLogFormat request "[%{uc}t] [R:%L] Request %k on C:%{c}L pid:%P tid:%T"
+ErrorLogFormat request "[%{uc}t] [R:%L] UA:'%+{User-Agent}i'"
+ErrorLogFormat request "[%{uc}t] [R:%L] Referer:'%+{Referer}i'"
+ErrorLogFormat connection "[%{uc}t] [C:%{c}L] local\ %a remote\ %A"
+
+
+
+| Description: | Extrait des informations d'état étendues pour chaque +requête |
|---|---|
| Syntaxe: | ExtendedStatus On|Off |
| Défaut: | ExtendedStatus Off |
| Contexte: | configuration globale |
| Statut: | Noyau httpd |
| Module: | core |
Cette option permet d'extraire des données supplémentaires
+ concernant la requête en cours de traitement pour un processus
+ donné, et crée un résumé d'utilisation ; vous pouvez accéder à
+ ces variables pendant l'exécution en configurant
+ mod_status. Notez que d'autres modules sont
+ susceptibles de s'appuyer sur ce tableau de bord.
Cette directive s'applique au serveur dans son ensemble, et ne + peut pas être activée/désactivée pour un serveur virtuel + particulier. Notez que l'extraction des informations d'état étendues + peut ralentir le serveur. Notez aussi que cette définition ne peut + pas être modifiée au cours d'un redémarrage graceful.
+ +Notez que le chargement de mod_status définit
+ automatiquement ExtendedStatus à On, et que d'autres modules tiers
+ sont susceptibles d'en faire de même. De tels modules ont besoin
+ d'informations détaillées à propos de l'état de tous les processus.
+ Depuis la version 2.3.6, mod_status a définit la
+ valeur par défaut à On, alors qu'elle était à Off dans les versions
+ antérieures.
| Description: | Caractéristiques de fichier utilisées lors de la génération +de l'en-tête de réponse HTTP ETag pour les fichiers statiques |
|---|---|
| Syntaxe: | FileETag composant ... |
| Défaut: | FileETag MTime Size |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | La valeur par défaut était "INode MTime Size" +dans les versions 2.3.14 et antérieures. |
+ La directive FileETag définit les
+ caractéristiques de fichier utilisées lors de la génération de
+ l'en-tête de réponse HTTP ETag (entity tag) quand le
+ document est contenu dans un fichier statique(la valeur de
+ ETag
+ est utilisée dans le cadre de la gestion du cache pour préserver la
+ bande passante réseau). La directive
+ FileETag vous permet maintenant de choisir
+ quelles caractéristiques du fichier vont être utilisées, le cas
+ échéant. Les mots-clés reconnus sont :
+
FileETag INode MTime Size+
ETag ne sera inclus dans la réponseLes mots-clés INode, MTime, et
+ Size peuvent être préfixés par + ou
+ -, ce qui permet de modifier les valeurs par défaut
+ héritées d'un niveau de configuration plus général. Tout mot-clé
+ apparaissant sans aucun préfixe annule entièrement et immédiatement
+ les configurations héritées.
Si la configuration d'un répertoire contient
+ FileETag INode MTime Size, et si un de
+ ses sous-répertoires contient FileETag -INode, la
+ configuration de ce sous-répertoire (qui sera propagée vers tout
+ sous-répertoire qui ne la supplante pas), sera équivalente à
+ FileETag MTime Size.
mod_dav_fs comme fournisseur de stockage.
+ mod_dav_fs utilise
+ MTime Size comme format fixe pour les
+ comparaisons de champs ETag dans les requêtes
+ conditionnelles. Ces requêtes conditionnelles échoueront si le
+ format ETag est modifié via la directive
+ FileETag.
+ mod_include, car l'entité de la réponse peut
+ changer sans modification de l'INode, du MTime, ou de la taille du
+ fichier statique contenant les directives SSI.
+ | Description: | Contient des directives qui s'appliquent aux fichiers +précisés |
|---|---|
| Syntaxe: | <Files nom fichier> ... </Files> |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
La directive <Files> limite
+ la portée des directives qu'elle contient aux fichiers précisés.
+ Elle est comparable aux directives <Directory> et <Location>. Elle doit se terminer par une
+ balise </Files>. Les directives contenues dans
+ cette section s'appliqueront à tout objet dont le nom de base (la
+ dernière partie du nom de fichier) correspond au fichier spécifié.
+ Les sections <Files> sont
+ traitées selon l'ordre dans lequel elles apparaissent dans le
+ fichier de configuration, après les sections <Directory> et la lecture des fichiers
+ .htaccess, mais avant les sections <Location>. Notez que les
+ sections <Files> peuvent être
+ imbriquées dans les sections <Directory> afin de restreindre la portion
+ du système de fichiers à laquelle ces dernières vont
+ s'appliquer.
L'argument filename peut contenir un nom de fichier
+ ou une chaîne de caractères avec caractères génériques, où
+ ? remplace un caractère, et * toute chaîne
+ de caractères.
<Files "cat.html"> + # Insérer ici des directives qui s'appliquent au fichier cat.html +</Files> + +<Files "?at.*"> + # Les directives insérées ici s'appliqueront aux fichiers + # cat.html, bat.html, hat.php, et ainsi de suite. +</Files>+ + +
On peut aussi utiliser les Expressions rationnelles en ajoutant la
+ caractère ~. Par exemple :
<Files ~ "\.(gif|jpe?g|png)$"> + #... +</Files>+ + +
correspondrait à la plupart des formats graphiques de l'Internet.
+ Il est cependant préférable d'utiliser la directive <FilesMatch>.
Notez qu'à la différence des sections <Directory> et <Location>, les sections <Files> peuvent être utilisées dans les
+ fichiers .htaccess. Ceci permet aux utilisateurs de
+ contrôler l'accès à leurs propres ressources, fichier par
+ fichier.
| Description: | Contient des directives qui s'appliquent à des fichiers +spécifiés sous la forme d'expressions rationnelles |
|---|---|
| Syntaxe: | <FilesMatch expression rationnelle> ...
+</FilesMatch> |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
La section <FilesMatch>
+ limite la portée des directives qu'elle contient aux fichiers
+ spécifiés, tout comme le ferait une section <Files>. Mais elle accepte aussi les
+ expressions rationnelles. Par
+ exemple :
<FilesMatch ".+\.(gif|jpe?g|png)$"> + # ... +</FilesMatch>+ + +
correspondrait à la plupart des formats graphiques de + l'Internet.
+ +.+ au début de l'expression
+ rationnelle permettent de s'assurer que les fichiers de nom
+ .png, ou .gif, par exemple, ne seront pas
+ pris en compte.A partir de la version 2.4.8, les groupes nommés et les
+ références arrières sont extraits et enregistrés dans
+ l'environnement avec leur nom en majuscules et préfixé
+ par "MATCH_". Ceci permet
+ de référencer des URLs dans des expressions
+ ou au sein de modules comme mod_rewrite. Pour
+ éviter toute confusion, les références arrières numérotées (non
+ nommées) sont ignorées. Vous devez utiliser à la place des groupes
+ nommés.
<FilesMatch "^(?<sitename>[^/]+)">
+ Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
+</FilesMatch>
+
+
+
+| Description: | Force le type de médium spécifié dans le champ d'en-tête +HTTP Content-Type pour les fichiers correspondants |
|---|---|
| Syntaxe: | ForceType type médium|None |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
Lorsqu'elle est placée dans un fichier .htaccess ou
+ une section <Directory>, <Location>, ou <Files>, cette directive force
+ l'identification du type MIME des fichiers spécifiés à la valeur de
+ l'argument type médium. Par exemple, si vous possédez un
+ répertoire ne contenant que des fichiers GIF, et si vous ne voulez
+ pas leur ajouter l'extension .gif, vous pouvez utiliser
+ :
ForceType image/gif+ + +
Notez que cette directive l'emporte sur d'autres associations de
+ type de médium indirectes définies dans mime.types ou via la
+ directive AddType.
Vous pouvez aussi annuler toute définition plus générale de
+ ForceType en affectant la valeur
+ None à l'argument type médium :
# force le type MIME de tous les fichiers à image/gif: +<Location "/images"> + ForceType image/gif +</Location> + +# mais utilise les méthodes classiques d'attribution du type MIME +# dans le sous-répertoire suivant : +<Location "/images/mixed"> + ForceType None +</Location>+ + +
A la base, cette directive écrase le type de contenu généré pour + les fichiers statiques servis à partir du sytème de fichiers. Pour + les ressources autres que les fichiers statiques pour lesquels le + générateur de réponse spécifie en général un type de contenu, cette + directive est ignorée.
+ +Lorsque des directives explicites comme SetHandler ou
+ module="mod_mime">AddHandler ne s'appliquent
+ pas à la requête courante, le nom du gestionnaire interne
+ normalement défini par ces directives correspondra alors au type de
+ contenu spécifié par cette directive. Il s'agit d'un
+ comportement historique que certains modules
+ tiers, comme mod_php, peuvent interpréter comme un type de contenu
+ artificiel ne servant qu'à indiquer le module qui doit prendre en
+ compte la requête considérée. Dans la mesure du
+ possible, il est conseillé d'éviter les
+ configurations qui comportent de tels types artificiels en utilisant
+ les directives SetHandler ou
+ AddHandler.
| Description: | Répertoire dans lequel écrire les données de profiling +gmon.out. |
|---|---|
| Syntaxe: | GprofDir /tmp/gprof/|/tmp/gprof/% |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
Lorsque le serveur a été compilé avec le support du profiling
+ gprof, la directive GprofDir permet de
+ spécifier dans quel répertoire les fichiers gmon.out
+ doivent être écrits lorsque le processus s'arrête. Si l'argument se
+ termine par un caractère pourcentage ('%'), des sous-répertoires
+ sont créés pour chaque identifiant de processus.
Cette directive ne fonctionne actuellement qu'avec le MPM
+ prefork.
| Description: | Active la recherche DNS sur les adresses IP des +clients |
|---|---|
| Syntaxe: | HostnameLookups On|Off|Double |
| Défaut: | HostnameLookups Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Noyau httpd |
| Module: | core |
Cette directive active la recherche DNS afin de pouvoir
+ journaliser les nom d'hôtes (et les passer aux programmes CGI et aux
+ inclusions SSI via la variable REMOTE_HOST). La valeur
+ Double déclenche une double recherche DNS inverse. En
+ d'autres termes, une fois la recherche inverse effectuée, on lance
+ une recherche directe sur le résultat de cette dernière. Au moins
+ une des adresses IP fournies par la recherche directe doit
+ correspondre à l'adresse originale (ce que l'on nomme
+ PARANOID dans la terminologie "tcpwrappers").
Quelle que soit la configuration, lorsqu'on utilise
+ mod_authz_host pour contrôler l'accès en fonction
+ du nom d'hôte, une double recherche DNS inverse est effectuée,
+ sécurité oblige. Notez cependant que le résultat de cette double
+ recherche n'est en général pas accessible, à moins que vous n'ayez
+ spécifié HostnameLookups Double. Par exemple, si vous
+ n'avez spécifié que HostnameLookups On, et si une
+ requête concerne un objet protégé par des restrictions en fonction
+ du nom d'hôte, quel que soit le résultat de la double recherche
+ inverse, les programmes CGI ne recevront que le résultat de la
+ recherche inverse simple dans la variable
+ REMOTE_HOST.
La valeur par défaut est Off afin de préserver le
+ traffic réseau des sites pour lesquels la recherche inverse n'est
+ pas vraiment nécessaire. Cette valeur par défaut est aussi bénéfique
+ pour les utilisateurs finaux car il n'ont ainsi pas à subir de temps
+ d'attente supplémentaires dus aux recherches DNS. Les sites
+ fortement chargés devraient laisser cette directive à
+ Off, car les recherches DNS peuvent prendre des temps
+ très longs. Vous pouvez éventuellement utiliser hors ligne
+ l'utilitaire logresolve, compilé par défaut dans
+ le sous-répertoire bin de votre répertoire
+ d'installation, afin de déterminer les noms d'hôtes associés aux
+ adresses IP journalisées.
Enfin, si vous avez des directives Require à base de
+ nom, une recherche de nom d'hôte sera effectuée quelle que soit
+ la définition de la directive HostnameLookups.
| Description: | Modifie les contraintes sur les messages des requêtes HTTP |
|---|---|
| Syntaxe: | HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods]
+ [Allow0.9|Require1.0] |
| Défaut: | HttpProtocolOptions Strict LenientMethods Allow0.9 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible à partir des versions 2.2.32 et 2.4.24 du serveur HTTP +Apache |
Cette directive permet de modifier les règles qui s'appliquent à la ligne
+ de requête HTTP (RFC 7230
+ §3.1.1) et aux champs des en-têtes des requêtes HTTP (RFC 7230
+ §3.2), qui s'appliquent maintenant par défaut ou en utilisant
+ l'option Strict. L'option Unsafe
+ a été ajoutée pour pouvoir restaurer les anciens
+ comportements nécessaires aux anciens modules et applications et aux agents
+ utilisateurs personnalisés considérés comme obsolètes.
Ces règles + s'appliquant avant le traitement de la requête, elles doivent, pour être prises en + compte, être définies + au niveau global ou dans la première section par défaut du serveur virtuel + qui correspond à la requête considérée, par interface IP/port et non par + nom.
+ +Cette directive accepte trois paramètres issus de la liste suivante, ceux + qui ne sont pas spécifiés prenant leur valeur par défaut :
+ +Avant l'introduction de cette directive, les interpréteurs de requêtes du
+ serveur HTTP Apache toléraient un grand nombre de formats en entrée qui
+ n'étaient pas forcément conformes au protocole. RFC 7230 §9.4
+ Request Splitting et §9.5 Response
+ Smuggling ne rappellent que deux des risques potentiels induits par des
+ requêtes non conformes, alors que RFC 7230
+ §3.5 signale les risques encourus par l'acceptation de blancs non
+ conformes dans les lignes de requête. Avec l'introduction de cette
+ directive, toutes les règles de grammaire de la spécification doivent être
+ respectées dans le mode d'opérations par défaut Strict.
Il est fortement déconseillé aux utilisateurs d'utiliser le mode
+ d'opération Unsafe, ou
+ UnsafeWhitespace, en particulier pour les déploiements de
+ serveurs ouverts sur l'extérieur et/ou accessibles au public. Si un moniteur
+ défectueux ou autre logiciel spécialisé ne s'exécutant que sur un intranet
+ nécessite une interface, les utilisateurs ne doivent utiliser les options de
+ type UnSafe qu'en cas de nécessité et uniquement au sein d'un serveur
+ virtuel bien spécifique et sur un réseau privé.
+
+ # Missing CRLF
+ GET / HTTP/1.0\n\n
+
Il peut s'avérer nécessaire de forcer certains utilitaires à utiliser + CRLF ; si ce n'est pas le cas, httpd reverra une réponse HTTP 400 comme + dans le cas précédent. Par exemple, le client OpenSSL s_client + doit utiliser le paramètre -crlf pour fonctionner correctement.
+Pour détecter des problèmes tels que l'absence de CRLF, vous pouvez
+ utiliser la directive DumpIOInput qui permet de décortiquer
+ les requêtes HTTP.
La section de la RFC 7231
+ §4.1 "Request Methods" "Overview" indique que les serveurs doivent
+ renvoyer un message d'erreur lorsque la ligne de requête comporte une
+ méthode non supportée. C'est déjà le cas lorsque l'option
+ LenientMethods est utilisée, mais les administrateurs ont la
+ possibilité de limiter les méthodes utilisées via l'option
+ RegisteredMethods en enregistrant toute méthode non standard
+ via la directive RegisterHttpMethod, en particulier
+ si l'option Unsafe est utilisée.
L'option
+ RegisteredMethods ne doit pas être utilisée
+ pour les serveurs mandataires car ces derniers ne connaissent pas les
+ méthodes supportées par les serveurs originaux.
+
+ # Méthode HTTP inconnue
+ WOW / HTTP/1.0\r\n\r\n
+ # Méthode HTTP spécifiée en minuscules
+ get / HTTP/1.0\r\n\r\n
+
La section de la RFC 2616
+ §19.6 "Compatibility With Previous Versions" encouragait les
+ serveurs HTTP à supporter les anciennes requêtes HTTP/0.9. La RFC 7230 va
+ cependant à son encontre via sa préconisation "Le souhait de supporter les
+ requêtes HTTP/0.9 a été supprimé" et y adjoint des commentaires dans RFC 7230 Appendix
+ A. A ce titre, l'option Require1.0 permet à l'utilisateur
+ d'inhiber le comportement induit par l'option par défaut
+ Allow0.9.
+
+ # Version HTTP non supportée
+ GET /\r\n\r\n
+
La consultation des messages enregistrés dans le journal
+ ErrorLog, configuré via la directive
+ LogLevel avec un niveau info, pourra
+ vous aider à identifier de telles requêtes non conformes ainsi que leur
+ provenance. Les utilisateurs devront accorder une attention particulière aux
+ messages d'erreur de type 400 dans le journal access pour détecter les
+ requêtes apparemment valides mais rejetées.
| Description: | Contient des directives qui ne s'appliquent que si une +condition est satisfaite au cours du traitement d'une +requête |
|---|---|
| Syntaxe: | <If expression> ... </If> |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Les conditions imbriquées sont supportées à partir de la version +2.4.26 du serveur HTTP Apache |
La directive <If> évalue une
+ expression à la volée, et applique les directives qu'elle contient
+ si et seulement si l'expression renvoie la valeur "vrai". Par
+ exemple :
<If "-z req('Host')">
+
+
+ serait satisfaite pour les requêtes HTTP/1.0 sans en-tête
+ Host:. Les expressions peuvent contenir différents
+ opérateurs de type shell pour la comparaison de chaînes
+ (==, !=, <, ...), la
+ comparaison d'entiers (-eq, -ne, ...), ou
+ à usages divers (-n, -z, -f,
+ ...). Les expressions rationnelles sont aussi supportées,
<If "%{QUERY_STRING} =~ /(delete|commit)=.*?elem/">
+
+
+ ainsi que les comparaison de modèles de type shell et de
+ nombreuses autres opérations. Ces opérations peuvent être effectuées
+ sur les en-têtes de requêtes (req), les variables
+ d'environnement (env), et un grand nombre d'autres
+ propriétés. La documentation complète est disponible dans Les expressions dans le serveur HTTP Apache.
Cette section de configuration ne peut contenir que des + directives qui supportent le contexte de répertoire.
+ +CONTENT_TYPE and other
+ response headers, are set after <If> conditions have already
+ been evaluated, and so will not be available to use in this
+ directive.
+ <ElseIf><Else><If>, <ElseIf>, et <Else> s'appliquent en dernier.| Description: | Contient des directives qui ne s'appliqueront que si un +test retourne "vrai" au démarrage du serveur |
|---|---|
| Syntaxe: | <IfDefine [!]paramètre> ...
+ </IfDefine> |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
La section <IfDefine
+ test>...</IfDefine> permet de
+ conférer un caractère conditionnel à un ensemble de directives. Les
+ directives situées à l'intérieur d'une section <IfDefine> ne s'appliquent que si
+ test est vrai. Si test est faux, tout ce qui
+ se trouve entre les balises de début et de fin est ignoré.
test peut se présenter sous deux formes :
+ +!nom paramètreDans le premier cas, les directives situées entre les balises de + début et de fin ne s'appliqueront que si le paramètre nommé nom + paramètre est défini. Le second format inverse le test, et + dans ce cas, les directives ne s'appliqueront que si nom + paramètre n'est pas défini.
+ +L'argument nom paramètre est une définition qui peut
+ être effectuée par la ligne de commande
+ httpd via le paramètre
+ -Dparamètre au démarrage du serveur, ou via la
+ directive Define.
Les sections <IfDefine>
+ peuvent être imbriquées, ce qui permet d'implémenter un test
+ multi-paramètres simple. Exemple :
httpd -DReverseProxy -DUseCache -DMemCache ...
<IfDefine ReverseProxy> + LoadModule proxy_module modules/mod_proxy.so + LoadModule proxy_http_module modules/mod_proxy_http.so + <IfDefine UseCache> + LoadModule cache_module modules/mod_cache.so + <IfDefine MemCache> + LoadModule mem_cache_module modules/mod_mem_cache.so + </IfDefine> + <IfDefine !MemCache> + LoadModule cache_disk_module modules/mod_cache_disk.so + </IfDefine> + </IfDefine> +</IfDefine>+ + +
| Description: | Regroupe des directives dont le traitement est conditionné par la +présence ou l'absence d'une directive particulière |
|---|---|
| Syntaxe: | <IfDirective [!]directive-name> ...
+ </IfDirective> |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible à partir de la version 2.4.34 du serveur HTTP Apache |
La section <IfDirective
+ test>...</IfDirective> permet de regrouper des
+ directives dont le traitement n'est effectué que si une directive
+ particulière est présente, autrement dit si l'expression test est
+ évaluée à true. Si l'expression test est évaluée à false, toutes
+ les lignes qui se trouvent entre les balises de début et de fin de la
+ section sont ignorées.
L'expression test de la section <IfDirective> peut prendre les deux formes
+ suivantes :
Dans le premier cas, les directives qui se situent entre les balises de + début et de fin de la section ne sont traitées que si une directive de nom + directive-name est disponible à cet instant. Dans le second cas, la condition est + inversée, et les directives ne sont traitées que si + directive-name n'est pas disponible.
+ +httpd, sans tenir compte de la disponibilité de telle ou
+ telle directive. Dans une configuration standard, il est inutile de placer
+ les directives dans des sections <IfDirective>.<IfSection>| Description: | Regroupe des directives qui ne seront traitées que si un fichier +existe au démarrage |
|---|---|
| Syntaxe: | <IfFile [!]filename> ...
+ </IfFile> |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible à partir de la version 2.4.34 du serveur HTTP Apache |
La section <IfFile filename>...</IfFile>
+ permet de conditionner le traitement de directives à
+ l'existence d'un fichier sur disque. Ainsi, les directives définies au sein
+ d'une section <IfFile> ne seront
+ traitées que si le fichier filename existe. Si le fichier
+ filename n'existe pas, tout ce qui se trouve entre les marqueurs
+ start et end sera ignoré. filename peut être un chemin absolu ou
+ relatif au chemin défini par la directive ServerRoot.
Le paramètre filename de l'en-tête d'une section <IfFile> peut prendre la même forme que la variable
+ test de la section <IfDefine> ; à ce titre, le résultat du test peut
+ être inversé en plaçant le caractère ! juste avant
+ filename.
+
Si filename est un chemin relatif, il sera généré par rapport
+ au chemin défini par la directive ServerRoot. Lorsque la directive <IfFile> intervient avant la définition de la
+ directive ServerRoot,
+ filename sera relatif au répertoire racine par défaut du serveur
+ ou au répertoire racine passé dans la ligne de commande via l'option
+ -d.
| Description: | Contient des directives qui ne s'appliquent qu'en fonction +de la présence ou de l'absence d'un module spécifique |
|---|---|
| Syntaxe: | <IfModule [!]fichier module|identificateur
+module> ... </IfModule> |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Les identificateurs de modules sont disponibles dans les +versions 2.1 et supérieures. |
La section <IfModule
+ test>...</IfModule> permet de conférer à
+ des directives un caractère conditionnel basé sur la présence d'un
+ module spécifique. Les directives situées dans une section
+ <IfModule> ne s'appliquent que
+ si test est vrai. Si test est faux, tout ce
+ qui se trouve entre les balises de début et de fin est ignoré.
test peut se présenter sous deux formes :
+ +Dans le premier cas, les directives situées entre les balises de
+ début et de fin ne s'appliquent que si le module module
+ est présent -- soit compilé avec le binaire Apache httpd, soit chargé
+ dynamiquement via la directive LoadModule. Le second format inverse le test, et dans
+ ce cas, les directives ne s'appliquent que si module
+ n'est pas présent.
L'argument module peut contenir soit l'identificateur
+ du module, soit le nom du fichier source du module. Par exemple,
+ rewrite_module est un identificateur et
+ mod_rewrite.c le nom du fichier source
+ correspondant. Si un module comporte plusieurs fichiers sources,
+ utilisez le nom du fichier qui contient la chaîne de caractères
+ STANDARD20_MODULE_STUFF.
Les sections <IfModule>
+ peuvent être imbriquées, ce qui permet d'implémenter des tests
+ multi-modules simples.
<IfModule>.| Description: | Regroupe des directives dont le traitement est conditionné par la +présence ou l'absence d'une section particulière |
|---|---|
| Syntaxe: | <IfSection [!]section-name> ...
+ </IfSection> |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible à partir de la version 2.4.34 du serveur HTTP Apache |
La section <IfSection
+ test>...</IfSection> permet de regrouper des
+ directives dont le traitement n'est effectué que si une section de
+ configuration particulière est présente. Une section, par exemple <VirtualHost>, permet de regrouper des directives
+ et possède un nom précédé du caractère "<".
Les directives situées à l'intérieur d'une section <IfSection> ne sont traitées que si l'expression
+ test est évaluée à true. Si l'expression test est
+ évaluée à false, toutes les lignes situées entre les balises de début et de
+ fin de la section sont ignorées.
section-name doit être spécifié sans les caractères de début
+ "<" ou fin ">". L'expression test de la section <IfSection> peut prendre deux formes :
Dans le premier cas, les directives qui se situent entre les balises de + début et de fin de la section ne sont traitées que si une section de nom + section-name est disponible à cet instant. Dans le second cas, la condition est + inversée, et les directives ne sont traitées que si + section-name n'est pas disponible.
+ +Par exemple :
+ +<IfSection VirtualHost> + ... +</IfSection>+ + +
httpd, sans tenir compte de la disponibilité de telle ou
+ telle section. Dans une configuration standard, il est inutile de placer
+ les directives dans des sections <IfSection>.| Description: | Inclut d'autres fichiers de configuration dans un des +fichiers de configuration du serveur |
|---|---|
| Syntaxe: | Include chemin-fichier|chemin-répertoire|wildcard |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Utilisation des caractères génériques dans la partie chemin depuis la +version 2.3.6 |
Cette directive permet l'inclusion d'autres fichiers de + configuration dans un des fichiers de configuration du serveur.
+ +On peut utiliser des caractères génériques de style Shell
+ (fnmatch()) aussi bien dans la partie nom de fichier du
+ chemin que dans la partie répertoires pour inclure plusieurs
+ fichiers en une
+ seule fois, selon leur ordre alphabétique. De plus, si la directive
+ Include pointe vers un répertoire, Apache
+ httpd inclura tous les fichiers de ce répertoire et de tous ces
+ sous-répertoires. L'inclusion de répertoires entiers est cependant
+ déconseillée, car il est fréquent d'oublier des fichiers
+ temporaires dans un répertoire, ce qui causerait une erreur
+ httpd en cas d'inclusion. Pour inclure des
+ fichiers qui correspondent à un certain modèle, comme *.conf par
+ exemple, nous vous recommandons d'utiliser plutôt la syntaxe avec
+ caractères génériques comme ci-dessous.
La directive Include
+ échouera avec un code d'erreur si une expression
+ contenant des caractères génériques ne correspond à aucun fichier.
+ Pour ignorer les expressions contenant des caractères génériques ne
+ correspondant à aucun fichier, utilisez la directive IncludeOptional.
Le chemin fichier spécifié peut être soit un chemin absolu, soit
+ un chemin relatif au répertoire défini par la directive ServerRoot.
Exemples :
+ +Include /usr/local/apache2/conf/ssl.conf +Include /usr/local/apache2/conf/vhosts/*.conf+ + +
ou encore, avec des chemins relatifs au répertoire défini par la
+ directive ServerRoot :
Include conf/ssl.conf +Include conf/vhosts/*.conf+ + +
On peut aussi insérer des caractères génériques dans la partie + répertoires du chemin. Dans l'exemple suivant, la directive + échouera si aucun sous-répertoire de conf/vhosts ne contient au + moins un fichier *.conf :
+ +Include conf/vhosts/*/*.conf+ + +
Par contre, dans l'exemple suivant, la directive sera simplement + ignorée si aucun sous-répertoire de conf/vhosts ne contient au + moins un fichier *.conf :
+ +IncludeOptional conf/vhosts/*/*.conf+ + + +
| Description: | Inclusion de fichiers dans le fichier de configuration |
|---|---|
| Syntaxe: | IncludeOptional
+file-path|directory-path|wildcard |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible à partir de la version 2.3.6 du serveur HTTP +Apache. Après la version 2.4.30, les chemins de fichiers non existants et +ne comportant pas de caractères génériques ne génèrent plus d'erreurs de syntaxe |
Cette directive permet d'inclure des fichiers dans les fichiers
+ de configuration du serveur. Elle fonctionne de manière identique à
+ la directive Include, mais au lieu de
+ générer une erreur, elle sera ignorée silensieusement si malgré
+ l'utilisation de caractères génériques, le chemin de fichier ou de
+ répertoire spécifié n'existe pas dans le système de fichiers.
| Description: | Active les connexions HTTP persistantes |
|---|---|
| Syntaxe: | KeepAlive On|Off |
| Défaut: | KeepAlive On |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
L'extension Keep-Alive de HTTP/1.0 et l'implémentation des
+ connexions persistantes dans HTTP/1.1 ont rendu possibles des
+ sessions HTTP de longue durée, ce qui permet de transmettre
+ plusieurs requêtes via la même connexion TCP. Dans certains cas, le
+ gain en rapidité pour des documents comportant de nombreuses images
+ peut atteindre 50%. Pour activer les connexions persistantes,
+ définissez KeepAlive On.
Pour les clients HTTP/1.0, les connexions persistantes ne seront + mises en oeuvre que si elles ont été spécialement demandées par un + client. De plus, une connexion persistante avec un client HTTP/1.0 + ne peut être utilisée que si la taille du contenu est connue + d'avance. Ceci implique que les contenus dynamiques comme les + sorties CGI, les pages SSI, et les listings de répertoires générés + par le serveur n'utiliseront en général pas les connexions + persistantes avec les clients HTTP/1.0. Avec les clients HTTP/1.1, + les connexions persistantes sont utilisées par défaut, sauf + instructions contraires. Si le client le demande, le transfert par + tronçons de taille fixe (chunked encoding) sera utilisé afin de + transmettre un contenu de longueur inconnue via une connexion + persistante.
+ +Lorsqu'un client utilise une connexion persistante, elle comptera
+ pour une seule requête pour la directive MaxConnectionsPerChild, quel
+ que soit le nombre de requêtes transmises via cette connexion.
| Description: | Durée pendant laquelle le serveur va attendre une requête +avant de fermer une connexion persistante |
|---|---|
| Syntaxe: | KeepAliveTimeout nombre[ms] |
| Défaut: | KeepAliveTimeout 5 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
Le nombre de secondes pendant lesquelles Apache httpd va attendre une
+ requête avant de fermer la connexion. Le délai peut être défini en
+ millisecondes en suffixant sa valeur par ms. La valeur du délai
+ spécifiée par la directive Timeout s'applique dès qu'une requête a
+ été reçue.
Donner une valeur trop élévée à
+ KeepAliveTimeout peut induire des problèmes
+ de performances sur les serveurs fortement chargés. Plus le délai
+ est élévé, plus nombreux seront les processus serveur en attente de
+ requêtes de la part de clients inactifs.
Si la directive KeepAliveTimeout n'est
+ pas définie pour un serveur virtuel à base de nom, c'est
+ la valeur de la paire adresse IP/port du serveur virtuel qui
+ correspond le mieux qui sera utilisée.
| Description: | Limite les contrôles d'accès que la section contient à +certaines méthodes HTTP |
|---|---|
| Syntaxe: | <Limit méthode [méthode] ... > ...
+ </Limit> |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig, Limit |
| Statut: | Noyau httpd |
| Module: | core |
Les contrôles d'accès s'appliquent normalement à
+ toutes les méthodes d'accès, et c'est en général le
+ comportement souhaité. Dans le cas général, les directives
+ de contrôle d'accès n'ont pas à être placées dans une section
+ <Limit>.
La directive <Limit> a pour
+ but de limiter les effets des contrôles d'accès aux méthodes HTTP
+ spécifiées. Pour toutes les autres méthodes, les restrictions
+ d'accès contenues dans la section <Limit> n'auront aucun
+ effet. L'exemple suivant n'applique les contrôles d'accès
+ qu'aux méthodes POST, PUT, et
+ DELETE, en laissant les autres méthodes sans protection
+ :
<Limit POST PUT DELETE> + Require valid-user +</Limit>+ + +
La liste des noms de méthodes peut contenir une ou plusieurs
+ valeurs parmi les suivantes : GET, POST,
+ PUT, DELETE, CONNECT,
+ OPTIONS, PATCH, PROPFIND,
+ PROPPATCH, MKCOL, COPY,
+ MOVE, LOCK, et UNLOCK.
+ Le nom de méthode est sensible à la casse. Si la
+ valeur GET est présente, les requêtes HEAD
+ seront aussi concernées. La méthode TRACE ne peut pas
+ être limitée (voir la directive TraceEnable).
<LimitExcept> doit toujours être préférée à
+ une section <Limit> pour la
+ restriction d'accès, car une section <LimitExcept> fournit une protection contre
+ les méthodes arbitraires.Les directives <Limit> et
+ <LimitExcept>
+ peuvent être imbriquées. Dans ce cas, pour chaque niveau des
+ directives <Limit> ou <LimitExcept>, ces dernières
+ doivent restreindre l'accès pour les méthodes auxquelles les
+ contrôles d'accès s'appliquent.
<Limit> ou <LimitExcept> avec la directive Require, la première directive
+ Require dont la
+ condition est satisfaite autorise la requête, sans tenir compte de
+ la présence d'autres directives Require.Par exemple, avec la configuration suivante, tous les
+ utilisateurs seront autorisés à effectuer des requêtes
+ POST, et la directive Require group
+ editors sera ignorée dans tous les cas :
<LimitExcept GET> + Require valid-user +</LimitExcept> +<Limit POST> + Require group editors +</Limit>+ + +
| Description: | Applique les contrôles d'accès à toutes les méthodes HTTP, +sauf celles qui sont spécifiées |
|---|---|
| Syntaxe: | <LimitExcept méthode [méthode] ... > ...
+ </LimitExcept> |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig, Limit |
| Statut: | Noyau httpd |
| Module: | core |
<LimitExcept> et
+ </LimitExcept> permettent de regrouper des
+ directives de contrôle d'accès qui s'appliqueront à toutes les
+ méthodes d'accès HTTP qui ne font pas partie de la
+ liste des arguments ; en d'autres termes, elles ont un comportement
+ opposé à celui de la section <Limit>, et on peut les utiliser pour
+ contrôler aussi bien les méthodes standards que les méthodes non
+ standards ou non reconnues. Voir la documentation de la section
+ <Limit> pour plus
+ de détails.
Par exemple :
+ +<LimitExcept POST GET> + Require valid-user +</LimitExcept>+ + + +
| Description: | Détermine le nombre maximal de redirections internes et de +sous-requêtes imbriquées |
|---|---|
| Syntaxe: | LimitInternalRecursion nombre [nombre] |
| Défaut: | LimitInternalRecursion 10 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
Une redirection interne survient, par exemple, quand on utilise
+ la directive Action qui
+ redirige en interne la requête d'origine vers un script CGI. Une
+ sous-requête est le mécanisme qu'utilise Apache httpd pour déterminer ce
+ qui se passerait pour un URI s'il faisait l'objet d'une requête. Par
+ exemple, mod_dir utilise les sous-requêtes pour
+ rechercher les fichiers listés dans la directive DirectoryIndex.
La directive LimitInternalRecursion permet
+ d'éviter un crash du serveur dû à un bouclage infini de redirections
+ internes ou de sous-requêtes. De tels bouclages sont dus en général
+ à des erreurs de configuration.
La directive accepte, comme arguments, deux limites qui sont + évaluées à chaque requête. Le premier nombre est le + nombre maximum de redirections internes qui peuvent se succéder. Le + second nombre détermine la profondeur d'imbrication + maximum des sous-requêtes. Si vous ne spécifiez qu'un seul + nombre, il sera affecté aux deux limites.
+ +LimitInternalRecursion 5+ + +
| Description: | limite la taille maximale du corps de la requête HTTP +envoyée par le client |
|---|---|
| Syntaxe: | LimitRequestBody octets |
| Défaut: | LimitRequestBody 0 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
Cette directive spécifie la taille maximale autorisée pour le + corps d'une requête ; la valeur de l'argument octets va + de 0 (pour une taille illimitée), à 2147483647 (2Go). Voir la note + ci-dessous pour la limite d'applicabilité aux requêtes mandatées.
+ +La directive LimitRequestBody permet de
+ définir une limite pour la taille maximale autorisée du corps d'une
+ requête HTTP en tenant compte du contexte dans lequel la directive
+ a été placée (c'est à dire au niveau du serveur, d'un répertoire,
+ d'un fichier ou d'une localisation). Si la requête du client dépasse
+ cette limite, le serveur répondra par un message d'erreur et ne
+ traitera pas la requête. La taille du corps d'une requête normale va
+ varier de manière importante en fonction de la nature de la
+ ressource et des méthodes autorisées pour cette dernière. Les
+ scripts CGI utilisent souvent le corps du message pour extraire les
+ informations d'un formulaire. Les implémentations de la méthode
+ PUT nécessitent une valeur au moins aussi élevée que la
+ taille maximale des représentations que le serveur désire accepter
+ pour cette ressource.
L'administrateur du serveur peut utiliser cette directive pour + contrôler plus efficacement les comportements anormaux des requêtes + des clients, ce qui lui permettra de prévenir certaines formes + d'attaques par déni de service.
+ +Si par exemple, vous autorisez le chargement de fichiers vers une + localisation particulière, et souhaitez limiter la taille des + fichiers chargés à 100Ko, vous pouvez utiliser la directive suivante + :
+ +LimitRequestBody 102400+ + +
Pour une description détaillée de la manière dont cette
+ directive est interprétée par les requêtes mandatées, voir la
+ documentation du module mod_proxy.
| Description: | Limite le nombre de champs d'en-tête autorisés dans une +requête HTTP |
|---|---|
| Syntaxe: | LimitRequestFields nombre |
| Défaut: | LimitRequestFields 100 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
nombre est un entier de 0 (nombre de champs illimité)
+ à 32767. La valeur par défaut est définie à la compilation par la
+ constante DEFAULT_LIMIT_REQUEST_FIELDS (100 selon la
+ distribution).
La directive LimitRequestFields permet à
+ l'administrateur du serveur de modifier le nombre maximum de champs
+ d'en-tête autorisés dans une requête HTTP. Pour un serveur, cette
+ valeur doit être supérieure au nombre de champs qu'une requête
+ client normale peut contenir. Le nombre de champs d'en-tête d'une
+ requête qu'un client utilise dépasse rarement 20, mais ce nombre
+ peut varier selon les implémentations des clients, et souvent en
+ fonction des extensions que les utilisateurs configurent dans leurs
+ navigateurs pour supporter la négociation de contenu détaillée. Les
+ extensions HTTP optionnelles utilisent souvent les
+ champs d'en-tête des requêtes.
L'administrateur du serveur peut utiliser cette directive pour + contrôler plus efficacement les comportements anormaux des requêtes + des clients, ce qui lui permettra de prévenir certaines formes + d'attaques par déni de service. La valeur spécifiée doit être + augmentée si les clients standards reçoivent une erreur du serveur + indiquant que la requête comportait un nombre d'en-têtes trop + important.
+ +Par exemple :
+ +LimitRequestFields 50+ + +
Dans le cas des serveurs virtuels à base de noms, la valeur de + cette directive est extraite du serveur virtuel par défaut (le + premier de la liste) pour la paire adresse IP/port.
+| Description: | Dédinit la taille maximale autorisée d'un en-tête de +requête HTTP |
|---|---|
| Syntaxe: | LimitRequestFieldSize octets |
| Défaut: | LimitRequestFieldSize 8190 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
Cette directive permet de définir le nombre maximum + d'octets autorisés dans un en-tête de requête HTTP.
+ +La directive LimitRequestFieldSize permet
+ à l'administrateur du serveur de définir la taille
+ maximale autorisée d'un en-tête de requête HTTP. Pour un serveur,
+ cette valeur doit être suffisamment grande pour contenir tout
+ en-tête d'une requête client normale. La taille d'un champ d'en-tête
+ de requête normal va varier selon les implémentations des clients,
+ et en fonction des extensions que les utilisateurs
+ configurent dans leurs navigateurs pour supporter la négociation de
+ contenu détaillée. Les en-têtes d'authentification SPNEGO peuvent
+ atteindre une taille de 12392 octets.
>L'administrateur du serveur peut utiliser cette directive pour + contrôler plus efficacement les comportements anormaux des requêtes + des clients, ce qui lui permettra de prévenir certaines formes + d'attaques par déni de service.
+ +Par exemple ::
+ +LimitRequestFieldSize 4094+ + +
Dans le cas des serveurs virtuels à base de noms, la valeur de + cette directive est extraite du serveur virtuel par défaut (le + premier de la liste) pour lequel la paire adresse IP/port + correspond le mieux.
+| Description: | Définit la taille maximale d'une ligne de requête +HTTP |
|---|---|
| Syntaxe: | LimitRequestLine octets |
| Défaut: | LimitRequestLine 8190 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
Cette directive permet de définir la taille maximale autorisée + pour une ligne de requête HTTP en octets.
+ +La directive LimitRequestLine permet à
+ l'administrateur du serveur de définir la taille
+ maximale autorisée d'une ligne de requête HTTP client. Comme une
+ requête comporte une méthode HTTP, un URI, et une version de
+ protocole, la directive LimitRequestLine
+ impose une restriction sur la longueur maximale autorisée pour un
+ URI dans une requête au niveau du serveur. Pour un serveur, cette
+ valeur doit être suffisamment grande pour référencer les noms de
+ toutes ses ressources, y compris toutes informations pouvant être
+ ajoutées dans la partie requête d'une méthode GET.
L'administrateur du serveur peut utiliser cette directive pour + contrôler plus efficacement les comportements anormaux des requêtes + des clients, ce qui lui permettra de prévenir certaines formes + d'attaques par déni de service.
+ +Par exemple :
+ +LimitRequestLine 4094+ + +
Dans le cas des serveurs virtuels à base de noms, la valeur de + cette directive est extraite du serveur virtuel par défaut (le + premier de la liste) pour lequel la paire adresse IP/port + correspond le mieux.
+| Description: | Définit la taille maximale du corps d'une requête au format +XML |
|---|---|
| Syntaxe: | LimitXMLRequestBody octets |
| Défaut: | LimitXMLRequestBody 1000000 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
Taille maximale (en octets) du corps d'une requête au format XML.
+ Une valeur de 0 signifie qu'aucune limite n'est
+ imposée.
Exemple :
+ +LimitXMLRequestBody 0+ + + +
| Description: | N'applique les directives contenues qu'aux URLs +spécifiées |
|---|---|
| Syntaxe: | <Location
+ chemin URL|URL> ... </Location> |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
La directive <Location>
+ limite la portée des directives contenues aux URLs définies par
+ l'argument URL. Elle est similaire à la directive <Directory>, et marque le
+ début d'une section qui se termine par une directive
+ </Location>. Les sections <Location> sont traitées selon l'ordre dans
+ lequel elles apparaissent dans le fichier de configuration, mais
+ après les sections <Directory> et la lecture des
+ fichiers .htaccess, et après les sections <Files>.
Les sections <Location>
+ agissent complètement en dehors du système de fichiers. Ceci a de
+ nombreuses conséquences. Parmi les plus importantes, on ne doit pas
+ utiliser les sections <Location>
+ pour contrôler l'accès aux répertoires du système de fichiers. Comme
+ plusieurs URLs peuvent correspondre au même répertoire du système de
+ fichiers, un tel contrôle d'accès pourrait être contourné.
Les directives que contient cette section seront appliquées aux + requêtes si la partie chemin de l'URL satisfait à l'un au moins de + ces critères : +
++ Dans l'exemple ci-dessous, où aucun slash de fin n'est utilisé, les + directives contenues dans la section s'appliqueront à /private1, + /private1/ et /private1/file.txt, mais pas à /private1other. +
+<Location "/private1"> + # ... +</Location>+ +
+ De même, dans l'exemple ci-dessous, où l'on utilise un slash de fin, les + directives contenues dans la section s'appliqueront à /private2/ et + à /private2/file.txt, mais pas à /private2other. +
+<Location "/private2/"> + # ... +</Location>+ + +
<Location>Vous pouvez utiliser une section <Location> pour appliquer des directives à
+ des contenus situés en dehors du système de fichiers. Pour les
+ contenus situés à l'intérieur du système de fichiers, utilisez
+ plutôt les sections <Directory> et <Files>. <Location
+ "/"> constitue une exception et permet d'appliquer aisément
+ une configuration à l'ensemble du serveur.
Pour toutes les requêtes originales (non mandatées), l'argument
+ URL est un chemin d'URL de la forme
+ /chemin/. Aucun protocole, nom d'hôte, port, ou chaîne
+ de requête ne doivent apparaître. Pour les requêtes mandatées, l'URL
+ spécifiée doit être de la forme
+ protocole://nom_serveur/chemin, et vous devez inclure
+ le préfixe.
L'URL peut contenir des caractères génériques. Dans une chaîne
+ avec caractères génériques, ? correspond à un caractère
+ quelconque, et * à toute chaîne de caractères. Les
+ caractères génériques ne peuvent pas remplacer un / dans le chemin
+ URL.
On peut aussi utiliser les Expressions
+ rationnelles, moyennant l'addition d'un caractère
+ ~. Par exemple :
<Location ~ "/(extra|special)/data"> + #... +</Location>+ + +
concernerait les URLs contenant les sous-chaîne
+ /extra/data ou /special/data. La directive
+ <LocationMatch>
+ présente un comportement identique à la version avec expressions
+ rationnelles de la directive <Location>, et son utilisation est
+ préférable à l'utilisation de cette dernière pour la simple raison
+ qu'il est difficile de distinguer ~ de -
+ dans la plupart des fontes.
La directive <Location>
+ s'utilise principalement avec la directive SetHandler. Par exemple, pour activer les
+ requêtes d'état, mais ne les autoriser que depuis des navigateurs
+ appartenant au domaine example.com, vous pouvez
+ utiliser :
<Location "/status"> + SetHandler server-status + Require host example.com +</Location>+ + +
La signification du caractère slash dépend de l'endroit où il
+ se trouve dans l'URL. Les utilisateurs peuvent être habitués à
+ son comportement dans le système de fichiers où plusieurs slashes
+ successifs sont souvent réduits à un slash unique (en d'autres
+ termes, /home///foo est identique à
+ /home/foo). Dans l'espace de nommage des URLs, ce
+ n'est cependant pas toujours le cas. Pour la directive <LocationMatch> et la
+ version avec expressions rationnelles de la directive <Location>, vous devez spécifier
+ explicitement les slashes multiples si telle est votre
+ intention.
Par exemple, <LocationMatch "^/abc"> va
+ correspondre à l'URL /abc mais pas à l'URL
+ //abc. La directive <Location> sans expression rationnelle se comporte de
+ la même manière lorsqu'elle est utilisée pour des requêtes
+ mandatées. Par contre, lorsque la directive <Location> sans expression rationnelle
+ est utilisée pour des requêtes non mandatées, elle fera
+ correspondre implicitement les slashes multiples à des slashes
+ uniques. Par exemple, si vous spécifiez <Location
+ "/abc/def">, une requête de la forme
+ /abc//def correspondra.
| Description: | N'applique les directives contenues qu'aux URLs +correspondant à une expression rationnelle |
|---|---|
| Syntaxe: | <LocationMatch
+ regex> ... </LocationMatch> |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
La directive <LocationMatch>
+ limite la portée des directives contenues à l'URL spécifiée, de
+ manière identique à la directive <Location>. Mais son argument permettant de
+ spécifier les URLs concernées est une expression rationnelle au lieu d'une simple
+ chaîne de caractères. Par exemple :
<LocationMatch "/(extra|special)/data"> + # ... +</LocationMatch>+ + +
correspondrait à toute URL contenant les sous-chaînes
+ /extra/data ou /special/data.
Si vous recherchez une URL commençant par
+ plutôt que seulement contenant /extra/data, préfixez
+ l'expression rationnelle avec un ^.
<LocationMatch "^/(extra|special)/data">+ +
A partir de la version 2.4.8, les groupes nommés et les
+ références arrières sont extraits et enregistrés dans
+ l'environnement avec leur nom en majuscules et préfixé
+ par "MATCH_". Ceci permet
+ de référencer des URLs dans des expressions
+ ou au sein de modules comme mod_rewrite. Pour
+ éviter toute confusion, les références arrières numérotées (non
+ nommées) sont ignorées. Vous devez utiliser à la place des groupes
+ nommés.
<LocationMatch "^/combined/(?<sitename>[^/]+)">
+ Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
+</LocationMatch>
+
+
+
+| Description: | Contrôle la verbosité du journal des erreurs |
|---|---|
| Syntaxe: | LogLevel [module:]niveau
+ [module:niveau] ...
+ |
| Défaut: | LogLevel warn |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | La configuration du niveau de journalisation par module +et par répertoire est disponible depuis la version 2.3.6 du serveur HTTP +Apache |
La directive LogLevel permet d'ajuster la
+ verbosité des messages enregistrés dans les journaux d'erreur (voir
+ la directive ErrorLog
+ directive). Les niveaux disponibles sont présentés
+ ci-après, par ordre de criticité décroissante :
| Niveau | + +Description | + +Exemple | +
|---|---|---|
emerg |
+
+ Urgences - le système est inutilisable. | + +"Child cannot open lock file. Exiting" | +
alert |
+
+ Des mesures doivent être prises immédiatement. | + +"getpwuid: couldn't determine user name from uid" | +
crit |
+
+ Conditions critiques. | + +"socket: Failed to get a socket, exiting child" | +
error |
+
+ Erreurs. | + +"Premature end of script headers" | +
warn |
+
+ Avertissements. | + +"child process 1234 did not exit, sending another + SIGHUP" | +
notice |
+
+ Evènement important mais normal. | + +"httpd: caught SIGBUS, attempting to dump core in + ..." | +
info |
+
+ Informations. | + +"Server seems busy, (you may need to increase + StartServers, or Min/MaxSpareServers)..." | +
debug |
+
+ Messages de débogage. | + +"Opening config file ..." | +
trace1 |
+
+ Messages de traces | + +"proxy: FTP: control connection complete" | +
trace2 |
+
+ Messages de traces | + +"proxy: CONNECT: sending the CONNECT request to the remote proxy" | +
trace3 |
+
+ Messages de traces | + +"openssl: Handshake: start" | +
trace4 |
+
+ Messages de traces | + +"read from buffered SSL brigade, mode 0, 17 bytes" | +
trace5 |
+
+ Messages de traces | + +"map lookup FAILED: map=rewritemap key=keyname" | +
trace6 |
+
+ Messages de traces | + +"cache lookup FAILED, forcing new map lookup" | +
trace7 |
+
+ Messages de traces, enregistrement d'une grande quantité de + données | + +"| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |" | +
trace8 |
+
+ Messages de traces, enregistrement d'une grande quantité de + données | + +"| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |" | +
Lorsqu'un niveau particulier est spécifié, les messages de tous
+ les autres niveaux de criticité supérieure seront aussi enregistrés.
+ Par exemple, si LogLevel info est spécifié,
+ les messages de niveaux notice et warn
+ seront aussi émis.
Il est recommandé d'utiliser un niveau crit ou
+ inférieur.
Par exemple :
+ +LogLevel notice+ + +
Si la journalisation s'effectue directement dans un fichier,
+ les messages de niveau notice ne peuvent pas être
+ supprimés et sont donc toujours journalisés. Cependant, ceci ne
+ s'applique pas lorsque la journalisation s'effectue vers
+ syslog.
Spécifier un niveau sans nom de module va attribuer ce niveau à
+ tous les modules. Spécifier un niveau avec nom de module va
+ attribuer ce niveau à ce module seulement. Il est possible de
+ spécifier un module par le nom de son fichier source ou par son
+ identificateur, avec ou sans le suffixe _module. Les
+ trois spécifications suivantes sont donc équivalentes :
LogLevel info ssl:warn +LogLevel info mod_ssl.c:warn +LogLevel info ssl_module:warn+ + +
Il est aussi possible d'attribuer un niveau de journalisation par + répertoire :
+ +LogLevel info +<Directory "/usr/local/apache/htdocs/app"> + LogLevel debug +</Directory>+ + +
| Description: | Nombre de requêtes permises pour une connexion +persistante |
|---|---|
| Syntaxe: | MaxKeepAliveRequests nombre |
| Défaut: | MaxKeepAliveRequests 100 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
La directive MaxKeepAliveRequests permet
+ de limiter le nombre de requêtes autorisées par connexion lorsque
+ KeepAlive est à "on". Si sa
+ valeur est 0, le nombre de requêtes autorisées est
+ illimité. Il est recommandé de définir une valeur assez haute pour
+ des performances du serveur maximales.
Par exemple :
+ +MaxKeepAliveRequests 500+ + +
| Description: | Nombre de chevauchements de segments de données autorisé
+ (par exemple 100-200,150-300) avant le renvoi de la
+ ressource complète |
|---|---|
| Syntaxe: | MaxRangeOverlaps default | unlimited | none | nombre de
+ chevauchements |
| Défaut: | MaxRangeOverlaps 20 |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible depuis la version 2.3.15 du serveur HTTP + Apache |
La directive MaxRangeOverlaps permet
+ de limiter le nombre de chevauchements de segments de données HTTP
+ autorisé par le serveur. Si le nombre de
+ chevauchements de segments demandé est supérieur au nombre maximal
+ autorisé, la ressource sera renvoyée dans son intégralité.
| Description: | Nombre d'inversions d'ordre autorisé dans la spécification des
+ segments de données (par exemple 100-200,50-70) avant le renvoi de la
+ ressource complète |
|---|---|
| Syntaxe: | MaxRangeReversals default | unlimited | none | nombre
+ d'inversions |
| Défaut: | MaxRangeReversals 20 |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible depuis la version 2.3.15 du serveur HTTP + Apache |
La directive MaxRangeReversals permet
+ de limiter le nombre d'inversions d'ordre dans la spécification
+ des segments de données HTTP
+ autorisé par le serveur. Si le nombre
+ d'inversions demandé est supérieur au nombre maximal
+ autorisé, la ressource sera renvoyée dans son intégralité.
| Description: | Nombre de segments de données autorisé avant le renvoi de +l'intégralité de la ressource |
|---|---|
| Syntaxe: | MaxRanges default | unlimited | none | nombre de segments |
| Défaut: | MaxRanges 200 |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible depuis la version 2.3.15 du serveur HTTP +Apache |
La directive MaxRanges permet de limiter
+ le nombre de segments de données que le serveur va renvoyer au
+ client. Si un nombre de segments plus important est demandé, la
+ ressource sera renvoyée dans son intégralité.
| Description: | Détermine si les données supplémentaires (trailers) sont +fusionnées avec les en-têtes |
|---|---|
| Syntaxe: | MergeTrailers [on|off] |
| Défaut: | MergeTrailers off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible à partir de la version 2.4.11 du serveur HTTP +Apache |
Cette directive permet de contrôler la fusion des données HTTP + supplémentaires (trailers) avec la représentation interne des + en-têtes. Cette fusion intervient lorsque le corps de la requête a + été entièrement reçu, bien longtemps après que la majeure partie du + traitement des en-têtes ait une chance de pouvoir examiner ou + modifier les en-têtes de la requête.
+Cette option a été introduite dans un souci de compatibilité avec + les versions antérieures à 2.4.11, où les données supplémentaires + étaient systématiquement fusionnées avec les en-têtes de la requête.
+ +| Description: | Définit les mécanismes de mutex et le repertoire du fichier +verrou pour tous les mutex ou seulement les mutex spécifiés |
|---|---|
| Syntaxe: | Mutex mécanisme [default|nom-mutex] ... [OmitPID] |
| Défaut: | Mutex default |
| Contexte: | configuration globale |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible depuis la version 2.3.4 du serveur HTTP Apache |
La directive Mutex permet de définir le
+ mécanisme de mutex, et éventuellement le répertoire du fichier
+ verrou que les modules et httpd utilisent pour sérialiser l'accès aux
+ ressources. Spécifiez default comme second argument
+ pour modifier la configuration de tous les mutex ; spécifiez un nom
+ de mutex (voir la table ci-dessous) comme second argument pour
+ ne modifier que la configuration de ce mutex.
La directive Mutex est typiquement
+ utilisée dans les situations exceptionnelles suivantes :
Cette directive ne configure que les mutex qui ont été
+ enregistrés avec le serveur de base via l'API
+ ap_mutex_register(). Tous les modules fournis avec
+ httpd supportent la directive Mutex, mais il
+ n'en sera pas forcément de même pour les modules tiers.
+ Reportez-vous à la documentation du module tiers considéré afin de
+ déterminer le(s) nom(s) de mutex qui pourront être définis si la
+ directive est supportée.
Les mécanismes de mutex disponibles sont les suivants :
+default | yes
+ C'est l'implémentation du verrouillage par défaut, telle
+ qu'elle est définie par APR. On peut
+ afficher l'implémentation du verrouillage par défaut via la
+ commande httpd avec l'option -V.
none | no
+ Le mutex est désactivé, et cette valeur n'est permise pour un + mutex que si le module indique qu'il s'agit d'un choix valide. + Consultez la documentation du module pour plus d'informations.
posixsem
+ Une variante de mutex basée sur un sémaphore Posix.
+ +La propriété du sémaphore n'est pas restituée si un thread du + processus gérant le mutex provoque une erreur de segmentation, + ce qui provoquera un blocage du serveur web.
+sysvsem
+ Une variante de mutex basée sur un sémaphore IPC SystemV.
+ +Il peut arriver que les sémaphores SysV soient conservés si le + processus se crashe avant que le sémaphore ne soit supprimé.
+L'API des sémaphores permet les attaques par déni de service
+ par tout programme CGI s'exécutant sous le même uid que le
+ serveur web (autrement dit tous les programmes CGI, à moins que
+ vous n'utilisiez un programme du style suexec
+ ou cgiwrapper).
sem
+ Sélection de la "meilleure" implémentation des sémaphores + disponible ; le choix s'effectue entre les sémaphores posix et + IPC SystemV, dans cet ordre.
pthread
+ Une variante de mutex à base de mutex de thread Posix + inter-processus.
+ +Sur la plupart des systèmes, si un processus enfant se + termine anormalement alors qu'il détenait un mutex qui utilise + cette implémentation, le serveur va se bloquer et cesser de + répondre aux requêtes. Dans ce cas, un redémarrage manuel est + nécessaire pour récupérer le mutex.
+Solaris et Linux constituent des exceptions notables, en ceci qu'ils fournissent + un mécanisme qui permet en général de récupérer le mutex après + l'arrêt anormal d'un processus enfant qui détenait le mutex.
+Si votre système est compatible POSIX ou implémente la fonction
+ pthread_mutexattr_setrobust_np(), vous devriez
+ pouvoir utiliser l'option pthread sans problème.
fcntl:/chemin/vers/mutex
+ Une variante de mutex utilisant un fichier verrou physique et
+ la fonction fcntl().
Lorsqu'on utilise plusieurs mutex basés sur ce mécanisme dans
+ un environnement multi-processus, multi-thread, des erreurs de
+ blocage (EDEADLK) peuvent être rapportées pour des opérations de
+ mutex valides si la fonction fcntl() ne gère pas
+ les threads, comme sous Solaris.
flock:/chemin/vers/mutex
+ Méthode similaire à fcntl:/chemin/vers/mutex,
+ mais c'est la fonction flock() qui est utilisée
+ pour gérer le verrouillage par fichier.
file:/chemin/vers/mutex
+ Sélection de la "meilleure" implémentation de verrouillage
+ par fichier disponible ; le choix s'effectue entre
+ fcntl et flock, dans cet ordre.
La plupart des mécanismes ne sont disponibles que sur les + plate-formes où ces dernières et APR les + supportent. Les mécanismes qui ne sont pas disponibles sur toutes + les plate-formes sont posixsem, + sysvsem, sem, pthread, fcntl, + flock, et file.
+ +Avec les mécanismes à base de fichier fcntl et
+ flock, le chemin, s'il est fourni, est un répertoire dans
+ lequel le fichier verrou sera créé. Le répertoire par
+ défaut est le répertoire d'exécution de httpd relatif à la
+ directive ServerRoot.
+ Utilisez toujours un système
+ de fichiers local sur disque pour /chemin/vers/mutex et
+ jamais un répertoire se trouvant dans un système de fichiers NFS ou
+ AFS. Le nom de base du fichier se composera du type de mutex, d'une
+ chaîne optionnelle correspondant à l'instance et fournie par le
+ module ; et, sauf si le mot-clé OmitPID a été spécifié,
+ l'identificateur du processus parent httpd sera ajouté afin de
+ rendre le nom du fichier unique, évitant ainsi tout conflit lorsque
+ plusieurs instances d'httpd partagent le même répertoire de
+ verrouillage. Par exemple, si le nom de mutex est
+ mpm-accept, et si le répertoire de verrouillage est
+ /var/httpd/locks, le nom du fichier verrou pour
+ l'instance httpd dont le processus parent a pour identifiant 12345
+ sera /var/httpd/locks/mpm-accept.12345.
Il est conseillé d'éviter de placer les fichiers mutex
+ dans un répertoire où tout le monde peut écrire comme
+ /var/tmp, car quelqu'un pourrait initier une attaque
+ par déni de service et empêcher le serveur de démarrer en créant un
+ fichier verrou possédant un nom identique à celui que le serveur va
+ tenter de créer.
La table suivante décrit les noms de mutex utilisés par httpd et + ses modules associés.
+ +| Nom mutex | +Module(s) | +Ressource protégée | +
|---|---|---|
mpm-accept |
+ modules MPM prefork et worker |
+ connexions entrantes, afin d'éviter le problème de + l'afflux de requêtes ; pour plus d'informations, voir la + documentation Amélioration des + performances | +
authdigest-client |
+ mod_auth_digest |
+ liste de clients en mémoire partagée | +
authdigest-opaque |
+ mod_auth_digest |
+ compteur en mémoire partagée | +
ldap-cache |
+ mod_ldap |
+ cache de résultat de recherche LDAP | +
rewrite-map |
+ mod_rewrite |
+ communication avec des programmes externes + d'associations de valeurs, afin d'éviter les interférences + d'entrées/sorties entre plusieurs requêtes | +
ssl-cache |
+ mod_ssl |
+ cache de session SSL | +
ssl-stapling |
+ mod_ssl |
+ cache de l'étiquetage OCSP ("OCSP stapling") | +
watchdog-callback |
+ mod_watchdog |
+ fonction de rappel d'un module client particulier | +
Le mot-clé OmitPID permet d'empêcher l'addition de
+ l'identifiant du processus httpd parent au nom du fichier verrou.
Dans l'exemple suivant, le mécanisme de mutex pour le mutex
+ mpm-accept est modifié pour passer du mécanisme par défaut au
+ mécanisme fcntl, avec le fichier verrou associé créé
+ dans le répertoire /var/httpd/locks. Le mécanisme de
+ mutex par défaut pour tous les autres mutex deviendra
+ sysvsem.
Mutex sysvsem default +Mutex fcntl:/var/httpd/locks mpm-accept+ + +
| Description: | OBSOLETE : Définit une adresse IP pour les serveurs virtuels à base de +nom |
|---|---|
| Syntaxe: | NameVirtualHost adresse[:port] |
| Contexte: | configuration globale |
| Statut: | Noyau httpd |
| Module: | core |
Avant la version 2.3.11, il était nécessaire de définir une
+ directive NameVirtualHost pour indiquer au
+ serveur qu'une paire adresse IP/port particulière pouvait être
+ utilisée comme serveur virtuel à base de nom. Depuis la version
+ 2.3.11, chaque fois qu'une paire adresse IP/port est utilisée dans
+ plusieurs serveurs virtuels, l'hébergement virtuel à base de nom est
+ automatiquement activé pour cette adresse.
Cette directive n'a actuellement plus aucun effet.
+ +| Description: | Définit les fonctionnalités disponibles pour un répertoire +particulier |
|---|---|
| Syntaxe: | Options
+ [+|-]option [[+|-]option] ... |
| Défaut: | Options FollowSymlinks |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Options |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Avec la version 2.3.11, la valeur par défaut passe de All +à FollowSymlinks |
La directive Options permet de définir
+ les fonctionnalités de serveur disponibles pour un répertoire
+ particulier.
option peut être défini à None, auquel
+ cas aucune fonctionnalité spécifique n'est activée, ou comprendre
+ une ou plusieurs des options suivantes :
AllMultiViews.ExecCGImod_cgi est permise.FollowSymLinksBien que le serveur suive les liens symboliques, il ne modifie
+ pas le nom de chemin concerné défini par la section
+ <Directory>.
Les options FollowSymLinks et
+ SymLinksIfOwnerMatch ne fonctionnent que dans les
+ sections <Directory> ou les fichiers
+ .htaccess.
Le fait d'omettre cette option ne doit pas être considéré comme + une mesure de sécurité efficace, car il existe toujours une + situation de compétition (race condition) entre l'instant où l'on + vérifie qu'un chemin n'est pas un lien symbolique, et l'instant où + l'on utilise effectivement ce chemin.
+Includesmod_include sont autorisées.IncludesNOEXEC#exec
+ cmd et #exec cgi sont désactivés.
+ L'utilisation de #include virtual pour les scripts
+ CGI est cependant toujours possible depuis des répertoires
+ définis par ScriptAlias.IndexesDirectoryIndex (par
+ exemple index.html) n'est défini pour ce
+ répertoire, le module mod_autoindex va renvoyer
+ un listing formaté du répertoire.MultiViewsmod_negotiation sont autorisées.
+ Cette option est ignorée si elle est
+ définie en tout autre endroit qu'une section <Directory>, car
+ mod_negotiation a besoin de ressources réelles
+ pour effectuer ses comparaisons et ses évaluations.
SymLinksIfOwnerMatchLes options FollowSymLinks et
+ SymLinksIfOwnerMatch ne fonctionnent que dans les
+ sections <Directory> ou les fichiers
+ .htaccess.
Le fait d'omettre cette option ne doit pas être considéré comme + une mesure de sécurité efficace, car il existe toujours une + situation de compétition (race condition) entre l'instant où l'on + vérifie qu'un chemin n'est pas un lien symbolique, et l'instant où + l'on utilise effectivement ce chemin.
+Normalement, si plusieurs directives
+ Options peuvent s'appliquer à un répertoire,
+ c'est la plus spécifique qui est utilisée et les autres sont
+ ignorées ; les options ne sont pas fusionnées (voir comment les sections sont
+ fusionnées). Elles le sont cependant si toutes les
+ options de la directive Options sont
+ précédées d'un symbole + ou -. Toute
+ option précédée d'un + est ajoutée à la liste des
+ options courantes de manière forcée et toute option précédée d'un
+ - est supprimée de la liste des options courantes de la
+ même manière.
Mélanger des Options avec +
+ ou - avec des Options sans
+ + ou - constitue une erreur de syntaxe, et
+ la vérification de la syntaxe au cours du démarrage du serveur fera
+ échouer ce dernier.
Par exemple, sans aucun symbole + et -
+ :
<Directory "/web/docs"> + Options Indexes FollowSymLinks +</Directory> + +<Directory "/web/docs/spec"> + Options Includes +</Directory>+ + +
ici, seule l'option Includes sera prise en compte
+ pour le répertoire /web/docs/spec. Par contre, si la
+ seconde directive Options utilise les
+ symboles + et - :
<Directory "/web/docs"> + Options Indexes FollowSymLinks +</Directory> + +<Directory "/web/docs/spec"> + Options +Includes -Indexes +</Directory>+ + +
alors, les options FollowSymLinks et
+ Includes seront prises en compte pour le répertoire
+ /web/docs/spec.
L'utilisation de -IncludesNOEXEC ou
+ -Includes désactive complètement les inclusions côté
+ serveur sans tenir compte des définitions précédentes.
En l'absence de toute définition d'options, la valeur par défaut
+ est FollowSymlinks.
| Description: | Protocole pour une socket d'écoute |
|---|---|
| Syntaxe: | Protocol protocole |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible depuis la version 2.1.5 d'Apache, mais +seulement depuis la version 2.3.3 sous Windows. |
Cette directive permet de spécifier le protocole utilisé pour une
+ socket d'écoute particulière. Le protocole sert à déterminer quel
+ module doit traiter une requête, et d'appliquer les optimisations
+ spécifiques au protocole via la directive
+ AcceptFilter.
Vous ne devez définir le protocole que si vous travaillez avec
+ des ports non standards ; dans le cas général, le protocole
+ http est associé au port 80 et le protocole
+ https au port 443.
Par exemple, si vous travaillez avec le protocole
+ https sur un port non standard, spécifiez le protocole
+ de manière explicite :
Protocol https+ + +
Vous pouvez aussi spécifier le protocole via la directive
+ Listen.
AcceptFilterListen| Description: | Protocoles disponibles pour un serveur virtuel ou non |
|---|---|
| Syntaxe: | Protocols protocole ... |
| Défaut: | Protocols http/1.1 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible à partir de la version 2.4.17 du serveur + HTTP Apache. |
Cette directive permet de spécifier la liste des protocoles + supportés par un serveur virtuel ou non. Cette liste énumère les + protocoles qu'un client sera autorisé à négocier avec ce + serveur.
+ +Par défaut, + seul le protocole http/1.1 est disponible (compatible avec les + clients http/1.0 et http/0.9). Par conséquent, vous devez + fournir cette liste si vous voulez étendre les protocoles + disponibles pour le serveur.
+ +Par exemple, si vous voulez autoriser le protocole + HTTP/2 pour un serveur avec TLS, utilisez + cette directive comme suit :
+ +Protocols h2 http/1.1+ + +
Les protocoles valides sont http/1.1 pour les
+ connexions http et https, h2 pour les connections
+ https et h2c pour les connexions http. D'autres
+ modules peuvent fournir d'autres protocoles.
Spécifier des protocoles non disponibles ou désactivés n'aura + aucun effet, et ceux-ci seront simplement ignorés.
+ +Si un serveur virtuel ne possède pas de directive Protocols + propre, il hérite des protocoles spécifiés pour le serveur + principal. Autrement dit, les directives Protocols définies au + niveau d'un serveur virtuel remplacent celles définies au niveau + du serveur principal. +
+ + +| Description: | Détermine qui du client ou du serveur détermine l'ordre + des protocoles au cours de la négociation de la connexion |
|---|---|
| Syntaxe: | ProtocolsHonorOrder On|Off |
| Défaut: | ProtocolsHonorOrder On |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible à partir de la version 2.4.17 du serveur + HTTP Apache. |
Cette directive permet de définir si le serveur doit tenir
+ compte de l'ordre des protocoles définis par la directive
+ Protocols.
Si cette directive est définie à Off, l'ordre de la liste des + protocoles fournie par le client l'emporte sur l'ordre défini + dans la configuration du serveur.
+ +Si la directive ProtocolsHonorOrder
+ est définie à on (valeur par défaut),
+ il n'est pas tenu compte de l'ordre de la liste des protocoles
+ fournie par le client, et seul l'ordre de la liste des protocles
+ définie au niveau du serveur influera la
+ négociation du protocole.
Protocols| Description: | Vérifie si la variable d'environnement REDIRECT_URL est +pleinement qualifiée |
|---|---|
| Syntaxe: | QualifyRedirectURL ON|OFF |
| Défaut: | QualifyRedirectURL OFF |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Directive supportée à partir de la version 2.4.18 du +serveur HTTP Apache. Jusqu'à la version 2.4.17, le serveur se comportait +comme si la directive QualifyRedirectURL était définie à ON. |
Cette directive permet de s'assurer que le serveur vérifiera que
+ la variable d'environnement REDIRECT_URL est bien pleinement
+ qualifiée. Par défaut, cette variable contient l'URL textuellement
+ demandée par le client, par exemple "/index.html". Avec QualifyRedirectURL ON, la même requête
+ affectera à la variable REDIRECT_URL une valeur du style
+ "http://www.example.com/index.html".
Même si cette directive n'est pas définie, lorsqu'une requête est + soumise avec une URL pleinement qualifiée, la variable REDIRECT_URL + contiendra quand-même une URL pleinement qualifiée. +
+ +| Description: | Configuration des options globales par défaut pour les + expressions rationnelles |
|---|---|
| Syntaxe: | RegexDefaultOptions [none] [+|-]option [[+|-]option] ... |
| Défaut: | RegexDefaultOptions DOLLAR_ENDONLY |
| Contexte: | configuration globale |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible à partir de la version 2.4.30 du serveur HTTP + Apache. |
Cette directive permet d'ajouter certains comportements par défaut à + TOUTES les expressions rationnelles utilisées ultérieurement.
+ +Toute option précédée d'un '+' est ajoutée aux options déjà définies.
+ Toute option précédée d'un '-' est enlevée des options déjà définies.
+ Toute option non suffixée par '+' ou '-' sera définie et remplacera
+ l'option correspondante éventuellement déjà définie.
+ Le mot-clé none annule toutes les options déjà définies.
option peut être :
+ICASEDOTALLDOLLAR_ENDONLY# +RegexDefaultOptions +ICASE +DOLLAR_ENDONLY +... +# Supprime l'option ICASE, tout en conservant toutes les autres options +# préexistantes +RegexDefaultOptions -ICASE +... +# Définit l'option par défaut à DOTALL et annule toutes les autres options +RegexDefaultOptions DOTALL +... +# Annule toutes les options définies +RegexDefaultOptions none +...+ + +
| Description: | Enregistrement de méthodes HTTP non standards |
|---|---|
| Syntaxe: | RegisterHttpMethod méthode [méthode [...]] |
| Contexte: | configuration globale |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible à partir de la version 2.4.24 du serveur HTTP Apache |
Cette directive permet d'enregistrer des méthodes HTTP supplémentaires. Ceci +s'avérera nécessaire si l'on doit utiliser des méthodes non standards avec des +directives qui acceptent des noms de méthodes en paramètres, ou pour permettre +l'utilisation de méthodes particulières non standards en passant par un serveur +mandataire ou au sein de scripts CGI, et ceci alors que le serveur a été +configuré pour ne transmettre que des méthodes reconnues aux modules.
+ +| Description: | Limite le temps CPU alloué aux processus initiés par les +processus enfants d'Apache httpd |
|---|---|
| Syntaxe: | RLimitCPU secondes|max [secondes|max] |
| Défaut: | Non défini ; utilise les valeurs par défaut du système
+d'exploitation |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
Prend 1 ou 2 paramètres. Le premier definit la limite de
+ consommation de ressources pour tous les processus, et le second la
+ consommation de ressources maximale. Les deux paramètres peuvent
+ contenir soit un nombre, soit max pour indiquer au
+ serveur que la limite de consommation correspond à la valeur
+ maximale autorisée par la configuration du système d'exploitation.
+ Pour augmenter la consommation maximale de ressources, le serveur
+ doit s'exécuter en tant que root, ou se trouver dans sa
+ phase de démarrage.
Cette directive s'applique aux processus initiés par les + processus enfants d'Apache httpd qui traitent les requêtes, et non aux + processus enfants eux-mêmes. Sont concernés les scripts CGI et les + commandes exec des SSI, mais en aucun cas les processus initiés par + le processus parent d'Apache httpd comme les journalisations redirigées + vers un programme.
+ +Les limites de ressources CPU sont exprimées en secondes par + processus.
+ +RLimitMEMRLimitNPROC| Description: | Limite la mémoire allouée aux processus initiés par les +processus enfants d'Apache httpd |
|---|---|
| Syntaxe: | RLimitMEM octets|max [octets|max] |
| Défaut: | Non défini ; utilise les valeurs par défaut du système
+d'exploitation |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
Prend 1 ou 2 paramètres. Le premier definit la limite de
+ consommation de ressources pour tous les processus, et le second la
+ consommation de ressources maximale. Les deux paramètres peuvent
+ contenir soit un nombre, soit max pour indiquer au
+ serveur que la limite de consommation correspond à la valeur
+ maximale autorisée par la configuration du système d'exploitation.
+ Pour augmenter la consommation maximale de ressources, le serveur
+ doit s'exécuter en tant que root, ou se trouver dans sa
+ phase de démarrage.
Cette directive s'applique aux processus initiés par les + processus enfants d'Apache httpd qui traitent les requêtes, et non aux + processus enfants eux-mêmes. Sont concernés les scripts CGI et les + commandes exec des SSI, mais en aucun cas les processus initiés par + le processus parent d'Apache httpd comme les journalisations redirigées + vers un programme.
+ +Les limites de ressources mémoire sont exprimées en octets par + processus.
+ +RLimitCPURLimitNPROC| Description: | Limite le nombre de processus qui peuvent être initiés par +les processus initiés par les processus enfants d'Apache httpd |
|---|---|
| Syntaxe: | RLimitNPROC nombre|max [nombre|max] |
| Défaut: | Unset; uses operating system defaults |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
Prend 1 ou 2 paramètres. Le premier definit la limite de
+ consommation de ressources pour tous les processus, et le second la
+ consommation de ressources maximale. Les deux paramètres peuvent
+ contenir soit un nombre, soit max pour indiquer au
+ serveur que la limite de consommation correspond à la valeur
+ maximale autorisée par la configuration du système d'exploitation.
+ Pour augmenter la consommation maximale de ressources, le serveur
+ doit s'exécuter en tant que root, ou se trouver dans sa
+ phase de démarrage.
Cette directive s'applique aux processus initiés par les + processus enfants d'Apache httpd qui traitent les requêtes, et non aux + processus enfants eux-mêmes. Sont concernés les scripts CGI et les + commandes exec des SSI, mais en aucun cas les processus initiés par + le processus parent d'Apache httpd comme les journalisations redirigées + vers un programme.
+ +Les limites des processus contrôlent le nombre de processus par + utilisateur.
+ +Si les processus CGI s'exécutent sous le même
+ utilisateur que celui du serveur web, cette
+ directive va limiter le nombre de processus que le serveur
+ pourra lui-même créer. La présence de messages
+ cannot fork dans le journal des
+ erreurs indiquera que la limite est atteinte.
| Description: | Permet de localiser l'interpréteur des scripts +CGI |
|---|---|
| Syntaxe: | ScriptInterpreterSource Registry|Registry-Strict|Script |
| Défaut: | ScriptInterpreterSource Script |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Win32 seulement. |
Cette directive permet de contrôler la méthode qu'utilise Apache
+ httpd pour trouver l'interpréteur destiné à exécuter les scripts CGI. La
+ définition par défaut est Script : ceci indique à
+ Apache httpd qu'il doit utiliser l'interpréteur précisé dans la ligne
+ shebang du script (la première ligne, commençant par
+ #!). Sur les systèmes Win32, cette ligne ressemble
+ souvent à ceci :
#!C:/Perl/bin/perl.exe+ + +
ou simplement, dans le cas où perl est dans le
+ PATH :
#!perl+ + +
Avec ScriptInterpreterSource Registry, Windows va
+ effectuer une recherche dans l'arborescence
+ HKEY_CLASSES_ROOT de la base de registre avec comme
+ mot-clé l'extension du fichier contenant le script (par exemple
+ .pl). C'est la commande définie par la sous-clé de
+ registre Shell\ExecCGI\Command ou, si elle n'existe
+ pas, la sous-clé Shell\Open\Command qui est utilisée
+ pour ouvrir le fichier du script. Si ces clés de registre ne sont
+ pas trouvées, Apache httpd utilise la méthode de l'option
+ Script.
Soyez prudent si vous utilisez ScriptInterpreterSource
+ Registry avec des répertoires faisant l'objet d'un ScriptAlias, car Apache httpd va essayer
+ d'exécuter tous les fichiers contenus dans
+ celui-ci. L'option Registry peut causer des appels de
+ programmes non voulus sur des fichiers non destinés à être exécutés.
+ Par exemple, la commande par défaut open sur les fichiers
+ .htm sur la plupart des systèmes Windows va lancer
+ Microsoft Internet Explorer ; ainsi, toute requête HTTP pour un
+ fichier .htm situé dans le répertoire des scripts
+ va lancer le navigateur en arrière-plan sur le serveur, ce qui a
+ toutes les chances de crasher votre système dans les minutes qui
+ suivent.
L'option Registry-Strict, apparue avec la version
+ 2.0 du serveur HTTP Apache,
+ agit de manière identique à Registry, mais n'utilise
+ que la sous-clé Shell\ExecCGI\Command. La présence de
+ la clé ExecCGI n'étant pas systématique, Elle doit être
+ définie manuellement dans le registre Windows et évite ainsi tout
+ appel de programme accidentel sur votre système.
| Description: | Détermine si mod_status affiche les 63 premiers caractères +d'une requête ou les 63 derniers, en supposant que la requête +elle-même possède plus de 63 caractères. |
|---|---|
| Syntaxe: | SeeRequestTail On|Off |
| Défaut: | SeeRequestTail Off |
| Contexte: | configuration globale |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | Disponible depuis la version 2.2.7 +d'Apache httpd. |
Avec ExtendedStatus On, mod_status affiche la
+ véritable requête en cours de traitement. Pour des raisons
+ historiques, seuls 63 caractères de la requête sont réellement
+ stockés à des fins d'affichage. Cette directive permet de déterminer
+ si ce sont les 63 premiers caractères qui seront stockés (c'est le
+ comportement par défaut),
+ ou si ce sont les 63 derniers. Ceci ne s'applique bien entendu que
+ si la taille de la requête est de 64 caractères ou plus.
Si Apache httpd traite la requête GET /disque1/stockage/apache/htdocs/images/rep-images1/nourriture/pommes.jpg HTTP/1.1
+ , l'affichage de la requête par mod_status se présentera comme suit :
+
| Off (défaut) | +GET /disque1/stockage/apache/htdocs/images/rep-images1/nourritu | +
|---|---|
| On | +apache/htdocs/images/rep-images1/nourriture/pommes.jpg HTTP/1.1 | +
| Description: | L'adresse électronique que le serveur inclut dans les +messages d'erreur envoyés au client |
|---|---|
| Syntaxe: | ServerAdmin adresse électronique|URL |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
La directive ServerAdmin permet de définir
+ l'adresse de contact que le serveur va inclure dans tout message
+ d'erreur qu'il envoie au client. Si le programme httpd
+ ne reconnait pas l'argument fourni comme une URL, il suppose que
+ c'est une adresse électronique, et lui ajoute le préfixe
+ mailto: dans les cibles des hyperliens. Il est
+ cependant recommandé d'utiliser exclusivement une adresse
+ électronique, car de nombreux scripts CGI considèrent ceci comme
+ implicite. Si vous utilisez une URL, elle doit pointer vers un autre
+ serveur que vous contrôlez. Dans le cas contraire, les utilisateurs
+ seraient dans l'impossibilité de vous contacter en cas de problème.
Il peut s'avérer utile de définir une adresse dédiée à + l'administration du serveur, par exemple :
+ +ServerAdmin www-admin@foo.example.com+ +
car les utilisateurs ne mentionnent pas systématiquement le + serveur dont ils parlent !
+ +| Description: | Autres noms d'un serveur utilisables pour atteindre des +serveurs virtuels à base de nom |
|---|---|
| Syntaxe: | ServerAlias nom serveur [nom serveur]
+... |
| Contexte: | serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
La directive ServerAlias permet de définir
+ les noms alternatifs d'un serveur utilisables pour atteindre des serveurs virtuels à base de
+ nom. La directive ServerAlias peut
+ contenir des caractères génériques, si nécessaire.
<VirtualHost *:80> + ServerName server.example.com + ServerAlias server server2.example.com server2 + ServerAlias *.example.com + UseCanonicalName Off + # ... +</VirtualHost>+ +
La recherche du serveur virtuel à base de nom correspondant au
+ plus près à la requête s'effectue selon l'ordre d'apparition des
+ directives <virtualhost> dans le fichier de
+ configuration. Le premier serveur virtuel dont le ServerName ou le ServerAlias correspond est choisi, sans
+ priorité particulière si le nom contient des caractères génériques
+ (que ce soit pour ServerName ou ServerAlias).
Tous les noms spécifiés au sein d'une section <VirtualHost> sont traités comme un
+ ServerAlias (sans caractères génériques).
| Description: | Nom d'hôte et port que le serveur utilise pour +s'authentifier lui-même |
|---|---|
| Syntaxe: | ServerName
+[protocole://]nom-de-domaine|adresse-ip[:port] |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
La directive ServerName permet de définir
+ les protocole, nom d'hôte et port d'une requête que le serveur
+ utilise pour s'authentifier lui-même.
La directive ServerName permet (éventuellement en
+ conjonction avec la directive ServerAlias) d'identifier de manière unique un
+ serveur virtuel, lorsqu'elle est utilisée dans un contexte de serveurs virtuels à base de noms.
Cette directive est aussi utilisée lors de la création d'URLs de
+ redirection relatives quand la directive UseCanonicalName est définie à une valeur autre
+ que la valeur par défaut.
Par exemple, si le nom de la
+ machine hébergeant le serveur web est
+ simple.example.com, la machine possède l'alias
+ DNS www.example.com, et si vous voulez que le serveur
+ web s'identifie avec cet alias, vous devez utilisez la définition
+ suivante :
ServerName www.example.com+ + +
La directive ServerName peut apparaître à
+ toutes les étapes de la définition du serveur. Toute occurrence
+ annule cependant la précédente (pour ce serveur).
Si la directive ServerName n'est pas
+ définie, le serveur tente de déterminer le nom
+ d'hôte visible du point de vue du client en demandant tout d'abord au
+ système d'exploitation le nom d'hôte système, et en cas d'échec, en effectuant
+ une recherche DNS inverse sur une adresse IP présente sur le système.
Si la directive
+ ServerName ne précise pas de port, le serveur
+ utilisera celui de la requête entrante. Il est recommandé de
+ spécifier un nom d'hôte et un port spécifiques à l'aide de la
+ directive ServerName pour une fiabilité
+ optimale et à titre préventif.
Si vous définissez des serveurs virtuels à base de
+ nom, une directive ServerName située à
+ l'intérieur d'une section <VirtualHost> spécifiera quel nom d'hôte
+ doit apparaître dans l'en-tête de requête Host: pour
+ pouvoir atteindre ce serveur virtuel.
Parfois, le serveur s'exécute en amont d'un dispositif qui
+ implémente SSL, comme un mandataire inverse, un répartiteur de
+ charge ou un boîtier dédié SSL. Dans ce cas, spécifiez le protocole
+ https:// et le port auquel les clients se connectent
+ dans la directive ServerName, afin de
+ s'assurer que le serveur génère correctement ses URLs
+ d'auto-identification.
+
Voir la description des directives UseCanonicalName et UseCanonicalPhysicalPort pour les
+ définitions qui permettent de déterminer si les URLs
+ auto-identifiantes (par exemple via le module
+ mod_dir) vont faire référence au port spécifié, ou
+ au port indiqué dans la requête du client.
+
Si la valeur de la directive ServerName ne
+ peut pas être résolue en adresse IP, le démarrage du serveur
+ provoquera un avertissement. httpd va alors utiliser le
+ résultat de la commande système hostname pour
+ déterminer le nom du serveur, ce qui ne correspondra pratiquement
+ jamais au nom de serveur que vous souhaitez réellement.
+ httpd: Could not reliably determine the server's fully qualified domain name, using rocinante.local for ServerName
+
| Description: | Nom de chemin d'URL hérité pour un serveur virtuel à base +de nom accédé par un navigateur incompatible |
|---|---|
| Syntaxe: | ServerPath chemin d'URL |
| Contexte: | serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
La directive ServerPath permet de définir
+ le nom de chemin d'URL hérité d'un hôte, à utiliser avec les serveurs virtuels à base de nom.
| Description: | Racine du répertoire d'installation du +serveur |
|---|---|
| Syntaxe: | ServerRoot chemin de répertoire |
| Défaut: | ServerRoot /usr/local/apache |
| Contexte: | configuration globale |
| Statut: | Noyau httpd |
| Module: | core |
La directive ServerRoot permet de définir
+ le répertoire dans lequel le serveur est installé. En particulier,
+ il contiendra les sous-répertoires conf/ et
+ logs/. Les chemins relatifs indiqués dans les autres
+ directives (comme Include ou LoadModule) seront définis par
+ rapport à ce répertoire.
ServerRoot "/home/httpd"+ + +
La valeur par défaut de ServerRoot peut
+ être modifiée via l'argument --prefix de la commande configure, et de
+ nombreuses distributions tierces du serveur proposent une valeur
+ différente de celles listées ci-dessus.
-d
+ options de httpdServerRoot| Description: | Définit un pied de page pour les documents générés par le +serveur |
|---|---|
| Syntaxe: | ServerSignature On|Off|EMail |
| Défaut: | ServerSignature Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Noyau httpd |
| Module: | core |
La directive ServerSignature permet de
+ définir une ligne de pied de page fixe pour les documents générés
+ par le serveur (messages d'erreur, listings de répertoires ftp de
+ mod_proxy, sorties de mod_info,
+ etc...). Dans le cas d'une chaîne de mandataires, l'utilisateur n'a
+ souvent aucun moyen de déterminer lequel des mandataires chaînés a
+ généré un message d'erreur, et c'est une des raisons pour lesquelles
+ on peut être amené à ajouter un tel pied de page.
La valeur par défaut Off supprime la ligne de pied
+ de page (et est ainsi compatible avec le comportement des
+ versions 1.2 et antérieures d'Apache). la valeur On
+ ajoute simplement une ligne contenant le numéro de version du
+ serveur ainsi que le nom du serveur virtuel issu de la directive
+ ServerName, alors que la valeur
+ EMail ajoute en plus une référence "mailto:" à
+ l'administrateur du document référencé issu la directive
+ ServerAdmin.
Après la version 2.0.44, les détails à propos du numéro de
+ version du serveur sont contrôlés à l'aide de la directive
+ ServerTokens.
ServerTokens| Description: | Configure l'en-tête Server de la réponse
+HTTP |
|---|---|
| Syntaxe: | ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full |
| Défaut: | ServerTokens Full |
| Contexte: | configuration globale |
| Statut: | Noyau httpd |
| Module: | core |
Cette directive permet de contrôler le contenu de l'en-tête
+ Server inclus dans la réponse envoyée au client : cet
+ en-tête peut contenir le type de système d'exploitation du serveur,
+ ainsi que des informations à propos des modules compilés avec le
+ serveur.
ServerTokens Full (ou non spécifié)Server: Apache/2.4.2
+ (Unix) PHP/4.2.2 MyMod/1.2ServerTokens Prod[uctOnly]Server:
+ ApacheServerTokens MajorServer:
+ Apache/2ServerTokens MinorServer:
+ Apache/2.4ServerTokens Min[imal]Server:
+ Apache/2.4.2ServerTokens OSServer:
+ Apache/2.4.2 (Unix)Cette définition s'applique à l'ensemble du serveur et ne peut + être activée ou désactivée pour tel ou tel serveur virtuel.
+ +Dans les versions postérieures à 2.0.44, cette directive contrôle
+ aussi les informations fournies par la directive ServerSignature.
ServerTokens à une
+ valeur inférieure à minimal n'est pas
+ recommandé car le débogage des problèmes
+ interopérationnels n'en sera alors que plus difficile. Notez
+ aussi que la désactivation de l'en-tête Server:
+ n'améliore en rien la sécurité de votre
+ serveur ; le concept de "sécurité par
+ l'obscurité" est un mythe et conduit à
+ une mauvaise perception de ce qu'est la sécurité.| Description: | Force le traitement des fichiers spécifiés par un +gestionnaire particulier |
|---|---|
| Syntaxe: | SetHandler handler-name|none|expression |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
| Compatibilité: | L'argument expression est disponible à partir de la version +2.4.19 su serveur HTTP Apache |
Lorsqu'elle se situe à l'intérieur d'un fichier
+ .htaccess, ou d'une section <Directory> ou <Location>, cette directive force le
+ traitement de tous les fichiers spécifiés par le gestionnaire défini par l'argument
+ nom gestionnaire. Par exemple, dans le cas d'un
+ répertoire dont vous voulez interpréter le contenu comme des
+ fichiers de règles d'images cliquables, sans tenir compte des
+ extensions, vous pouvez ajouter la ligne suivante dans un fichier
+ .htaccess de ce répertoire :
SetHandler imap-file+ + +
Autre exemple : si vous voulez que le serveur affiche un
+ compte-rendu d'état chaque fois qu'une URL du type http://nom
+ serveur/status est appelée, vous pouvez ajouter ceci dans
+ httpd.conf :
<Location "/status"> + SetHandler server-status +</Location>+ + +
Vous pouvez aussi utiliser cette directive pour associer un + gestionnaire à des fichiers possèdant une extension de nom de + fichier particulière. Par exemple :
+ +<FilesMatch "\.php$"> + SetHandler application/x-httpd-php +</FilesMatch>+ + +
Pour référencer des variables spécifiques à une requête, y compris les + références arrières vers des expressions rationnelles nommées, vous pouvez + utiliser des expressions ayant pour valeur une chaîne :
+ +<LocationMatch ^/app/(?<sub>[^/]+)/>
+ SetHandler "proxy:unix:/var/run/app_%{env:MATCH_sub}.sock|fcgi://localhost:8080"
+</LocationMatch>
+
+
+ Vous pouvez écraser la définition antérieure d'une directive
+ SetHandler en utilisant la valeur
+ None.
Comme SetHandler l'emporte sur la
+ définition des gestionnaires par défaut, le comportement habituel
+ consistant à traiter les URLs se terminant par un slash (/) comme
+ des répertoires ou des fichiers index est désactivé.
AddHandler| Description: | Définit les filtres par lesquels vont passer les requêtes +client et les données POST |
|---|---|
| Syntaxe: | SetInputFilter filtre[;filtre...] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
La directive SetInputFilter permet de
+ définir le ou les filtres par lesquels vont passer les requêtes
+ client et les données POST au moment où le serveur les reçoit. Cette
+ définition vient en ajout à tout autre filtre défini en
+ quelqu'endroit que ce soit, y compris via la directive AddInputFilter.
Si la directive comporte plusieurs filtres, ils doivent être + séparés par des points-virgules, et spécifiés selon l'ordre dans + lequel vous souhaitez les voir agir sur les contenus.
+ +| Description: | Définit les filtres par lesquels vont passer les réponses +du serveur |
|---|---|
| Syntaxe: | SetOutputFilter filtre[;filtre...] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Noyau httpd |
| Module: | core |
La directive SetOutputFilter permet de
+ définir les filtres par lesquels vont passer les réponses du serveur
+ avant d'être envoyées au client. Cette définition vient en ajout à
+ tout autre filtre défini en quelqu'endroit que ce soit, y compris
+ via la directive AddOutputFilter.
Par exemple, la configuration suivante va traiter tous les
+ fichiers du répertoire /www/data/ comme des inclusions
+ côté serveur (SSI) :
<Directory "/www/data/"> + SetOutputFilter INCLUDES +</Directory>+ + +
Si la directive comporte plusieurs filtres, ils doivent être + séparés par des points-virgules, et spécifiés selon l'ordre dans + lequel vous souhaitez les voir agir sur les contenus.
+ +| Description: | Temps pendant lequel le serveur va attendre certains +évènements avant de considérer qu'une requête a échoué |
|---|---|
| Syntaxe: | TimeOut secondes |
| Défaut: | TimeOut 60 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
La directive TimeOut permet de définir le
+ temps maximum pendant lequel Apache httpd va attendre des entrées/sorties
+ selon les circonstances :
Lors de la lecture de données en provenance du client, le + temps maximum jusqu'à l'arrivée d'un paquet TCP si le tampon est + vide.
+Pour les données initiales d'une nouvelle connexion, et tant qu'une
+ directive AcceptFilter n'aura pas
+ transmis cette nouvelle connexion au serveur, cette directive n'aura aucun
+ effet.
mod_cgi et mod_cgid, le temps
+ d'attente maximum pour un bloc individuel en sortie d'un script CGI.mod_ext_filter, le temps d'attente
+ maximum des sorties d'un processus de filtrage.mod_proxy, la valeur du délai par défaut
+ si ProxyTimeout n'est
+ pas défini.| Description: | Détermine le comportement des requêtes
+TRACE |
|---|---|
| Syntaxe: | TraceEnable [on|off|extended] |
| Défaut: | TraceEnable on |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Noyau httpd |
| Module: | core |
Cette directive l'emporte sur le comportement de
+ TRACE pour le noyau du serveur et
+ mod_proxy. La définition par défaut
+ TraceEnable on permet des requêtes TRACE
+ selon la RFC 2616, qui interdit d'ajouter tout corps à la requête.
+ La définition TraceEnable off indique au noyau du
+ serveur et à mod_proxy de retourner un code
+ d'erreur 405 (Méthode non autorisée) au client.
En fait, et à des fins de test et de diagnostic seulement, on
+ peut autoriser l'ajout d'un corps de requête à l'aide de la
+ définition non standard TraceEnable extended. Le noyau
+ du serveur (dans le cas d'un serveur d'origine) va limiter la taille
+ du corps de requête à 64Kb (plus 8Kb pour les en-têtes de
+ fractionnement si Transfer-Encoding: chunked est
+ utilisé). Le noyau du serveur va reproduire l'ensemble des en-têtes,
+ y compris les en-têtes de fractionnement avec le corps de la
+ réponse. Dans le cas d'un serveur mandataire, la taille du corps de
+ requête n'est pas limitée à 64Kb.
Bien que certains prétendent le contraire, activer la méthode
+ TRACE ne constitue pas un problème de sécurité dans Apache
+ httpd. La méthode TRACE est définie par la spécification
+ HTTP/1.1 et les différentes implémentations sont censées la supporter.
| Description: | Invalide la définition d'une variable |
|---|---|
| Syntaxe: | UnDefine nom-variable |
| Contexte: | configuration globale |
| Statut: | Noyau httpd |
| Module: | core |
Annule l'effet d'une directive Define ou d'un argument -D de
+ httpd en invalidant l'existence de la variable
+ correspondante.
On peut utiliser cette directive pour inverser l'effet d'une
+ section <IfDefine>
+ sans avoir à modifier les arguments -D dans les scripts
+ de démarrage.
Si cette directive est définie au sein d'un bloc VirtualHost, les + changements qu'elle induit sont visibles de toute directive + ultérieure, au delà de tout bloc VirtualHost.
+ +| Description: | Définit la manière dont le serveur détermine son propre nom +et son port |
|---|---|
| Syntaxe: | UseCanonicalName On|Off|DNS |
| Défaut: | UseCanonicalName Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Noyau httpd |
| Module: | core |
Dans de nombreuses situations, Apache httpd doit construire une URL
+ auto-identifiante -- c'est à dire une URL qui fait
+ référence au serveur lui-même. Avec UseCanonicalName
+ On, Apache httpd va utiliser le nom d'hôte et le port spécifiés par
+ la directive ServerName pour
+ construire le nom canonique du serveur. Ce nom est utilisé dans
+ toutes les URLs auto-identifiantes, et affecté aux variables
+ SERVER_NAME et SERVER_PORT dans les
+ programmes CGI.
Avec UseCanonicalName Off, Apache httpd va construire ses
+ URLs auto-identifiantes à l'aide du nom d'hôte et du port fournis
+ par le client, si ce dernier en a fourni un (dans la négative,
+ Apache utilisera le nom canonique, de la même manière que
+ ci-dessus). Ces valeurs sont les mêmes que celles qui sont utilisées
+ pour implémenter les serveurs virtuels à base de
+ nom, et sont disponibles avec les mêmes clients. De même, les
+ variables CGI SERVER_NAME et SERVER_PORT
+ seront affectées des valeurs fournies par le client.
Cette directive peut s'avérer utile, par exemple, sur un serveur
+ intranet auquel les utilisateurs se connectent en utilisant des noms
+ courts tels que www. Si les utilisateurs tapent un nom
+ court suivi d'une URL qui fait référence à un répertoire, comme
+ http://www/splat, sans le slash terminal, vous
+ remarquerez qu'Apache httpd va les rediriger vers
+ http://www.example.com/splat/. Si vous avez activé
+ l'authentification, ceci va obliger l'utilisateur à s'authentifier
+ deux fois (une première fois pour www et une seconde
+ fois pour www.example.com -- voir la
+ foire aux questions sur ce sujet pour plus d'informations).
+ Par contre, si UseCanonicalName est définie à
+ Off, Apache httpd redirigera l'utilisateur vers
+ http://www/splat/.
Pour l'hébergement virtuel en masse à base d'adresse IP, on
+ utilise une troisième option, UseCanonicalName
+ DNS, pour supporter les clients anciens qui ne
+ fournissent pas d'en-tête Host:. Apache httpd effectue alors
+ une recherche DNS inverse sur l'adresse IP du serveur auquel le
+ client s'est connecté afin de construire ses URLs
+ auto-identifiantes.
Les programmes CGI risquent d'être perturbés par cette option
+ s'ils tiennent compte de la variable SERVER_NAME. Le
+ client est pratiquement libre de fournir la valeur qu'il veut comme
+ nom d'hôte. Mais si le programme CGI n'utilise
+ SERVER_NAME que pour construire des URLs
+ auto-identifiantes, il ne devrait pas y avoir de problème.
| Description: | Définit la manière dont le serveur +détermine son propre port |
|---|---|
| Syntaxe: | UseCanonicalPhysicalPort On|Off |
| Défaut: | UseCanonicalPhysicalPort Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Noyau httpd |
| Module: | core |
Dans de nombreuses situations, Apache httpd doit construire une URL
+ auto-identifiante -- c'est à dire une URL qui fait
+ référence au serveur lui-même. Avec UseCanonicalPhysicalPort
+ On, Apache httpd va fournir le numéro de port physique réel utilisé
+ par la requête en tant que port potentiel, pour construire le port
+ canonique afin que le serveur puisse alimenter la directive
+ UseCanonicalName. Avec
+ UseCanonicalPhysicalPort Off, Apache httpd n'utilisera pas le
+ numéro de port physique réel, mais au contraire se référera aux
+ informations de configuration pour construire un numéro de port
+ valide.
L'ordre dans lequel s'effectue la recherche quand on utilise le + port physique est le suivant :
+UseCanonicalName OnServernameUseCanonicalName Off | DNSHost:ServernameAvec UseCanonicalPhysicalPort Off, on reprend
+ l'ordre ci-dessus en supprimant "Port physique".
| Description: | Contient des directives qui ne s'appliquent qu'à un nom +d'hôte spécifique ou à une adresse IP |
|---|---|
| Syntaxe: | <VirtualHost
+ adresse IP[:port] [adresse
+ IP[:port]] ...> ...
+ </VirtualHost> |
| Contexte: | configuration globale |
| Statut: | Noyau httpd |
| Module: | core |
Les balises <VirtualHost> et
+ </VirtualHost> permettent de rassembler un groupe
+ de directives qui ne s'appliquent qu'à un serveur virtuel
+ particulier. Toute directive autorisée dans un contexte de serveur
+ virtuel peut être utilisée. Lorsque le serveur reçoit un requête
+ pour un document hébergé par un serveur virtuel particulier, il
+ applique les directives de configuration rassemblées dans la section
+ <VirtualHost>. adresse
+ IP peut être une des entités suivantes, éventuellement suivies
+ d'un caractère ':' et d'un numéro de port (ou *) :
*, qui agit comme un
+ caractère générique, et correspond à toute adresse IP._default_, dont la signification est
+ identique à celle du caractère *<VirtualHost 10.1.2.3:80> + ServerAdmin webmaster@host.example.com + DocumentRoot "/www/docs/host.example.com" + ServerName host.example.com + ErrorLog "logs/host.example.com-error_log" + TransferLog "logs/host.example.com-access_log" +</VirtualHost>+ + + +
Les adresses IPv6 doivent être entourées de crochets car dans le + cas contraire, un éventuel port optionnel ne pourrait pas être + déterminé. Voici un exemple de serveur virtuel avec adresse IPv6 + :
+ +<VirtualHost [2001:db8::a00:20ff:fea7:ccea]:80> + ServerAdmin webmaster@host.example.com + DocumentRoot "/www/docs/host.example.com" + ServerName host.example.com + ErrorLog "logs/host.example.com-error_log" + TransferLog "logs/host.example.com-access_log" +</VirtualHost>+ + +
Chaque serveur virtuel doit correspondre à une adresse IP, un
+ port ou un nom d'hôte spécifique ; dans le premier cas, le serveur
+ doit être configuré pour recevoir les paquets IP de plusieurs
+ adresses (si le serveur n'a qu'une interface réseau, on peut
+ utiliser à cet effet la commande ifconfig alias -- si
+ votre système d'exploitation le permet).
L'utilisation de la directive <VirtualHost> n'affecte en rien les
+ adresses IP sur lesquelles Apache httpd est en écoute. Vous devez vous
+ assurer que les adresses des serveurs virtuels sont bien incluses
+ dans la liste des adresses précisées par la directive Listen.
Tout bloc <VirtualHost> doit comporter une directive
+ ServerName. Dans le cas
+ contraire, le serveur virtuel héritera de la valeur de la directive
+ ServerName issue de la
+ configuration du serveur principal.
A l'arrivée d'une requête, le serveur tente de la
+ faire prendre en compte par la section <VirtualHost> qui correspond le mieux en ne
+ se basant que sur la paire adresse IP/port. Les chaînes sans
+ caractères génériques l'emportent sur celles qui en contiennent. Si
+ aucune correspondance du point de vue de l'adresse IP/port n'est
+ trouvée, c'est la configuration du serveur "principal" qui sera
+ utilisée.
Si plusieurs serveurs virtuels correspondent du point de vue de + l'adresse IP/port, le serveur sélectionne celui qui correspond le + mieux du point de vue du nom d'hôte de la requête. Si aucune + correspondance du point de vue du nom d'hôte n'est trouvée, c'est le + premier serveur virtuel dont l'adresse IP/port correspond qui sera + utilisé. Par voie de conséquence, le premier serveur virtuel + comportant une certaine paire adresse IP/port est le serveur virtuel + par défaut pour cette paire adresse IP/port.
+ +Voir le document sur les conseils à propos de sécurité + pour une description détaillée des raisons pour lesquelles la + sécurité de votre serveur pourrait être compromise, si le répertoire + contenant les fichiers journaux est inscriptible par tout autre + utilisateur que celui qui démarre le serveur.
+Serveur HTTP Apache Version 2.4
+Ce document décrit les termes utilisés pour décrire chaque directive de configuration d'Apache.
+ Description Syntaxe Défaut Contexte Surcharge/Écrasement Statut Module CompatibilitéUne brève description des fonctions de cette directive.
+Ce terme introduit le format sous lequel la directive doit + apparaître dans le fichier de configuration. Cette syntaxe est très + spécifique à la directive et est décrite en détail dans la + définition de cette dernière. En général, le nom de la directive est + suivi d'un ou plusieurs arguments séparés par des espaces. Si un + argument contient un espace, il doit être entouré de guillemets. Les + arguments optionnels sont entourés de crochets. Lorsqu'un argument + accepte une valeur parmi une liste de valeurs possibles, cette liste + est spécifiée en séparant les valeurs par une barre verticale "|". + Les textes littéraux sont présentés dans la fonte par défaut, alors + que les types d'argument pour lesquels une substitution est + nécessaire sont en gras. La syntaxe des directives + acceptant un nombre variable d'arguments se termine par "...", ce + qui indique que le dernier argument peut être répété.
+ +Les directives utilisent un grand nombre de types d'arguments + différents. Les plus courants sont définis ci-dessous.
+ +http://www.example.com/chemin/vers/fichier.html/chemin/vers/fichier.html. Le
+ chemin-URL représente la ressource vue du web, et est
+ différente de la représentation de cette même ressource vue du
+ système de fichiers./usr/local/apache/htdocs/chemin/vers/fichier.html.
+ Sauf mention contraire, un chemin-fichier qui ne commence
+ pas par un slash sera considéré comme relatif au répertoire défini
+ par la directive ServerRoot./usr/local/apache/htdocs/chemin/vers/.fichier.html.fichier.html.en comporte deux extensions :
+ .html et .en. Pour les directives
+ Apache, vous pouvez spécifier les extensions avec ou sans
+ le point initial. Enfin, les extensions ne sont pas
+ sensibles à la casse.text/html.Si la directive possède une valeur par défaut (en d'autres + termes, si le serveur Web Apache se comporte comme si vous l'aviez + définie à une valeur particulière, alors que vous l'avez omise dans + votre configuration), elle est spécifiée ici. Si la directive ne + possède pas de valeur par défaut, cette section doit spécifier + "Aucune". Notez que la valeur par défaut dont il est + question n'est pas nécessairement la même que la valeur attribuée à + la directive dans le fichier httpd.conf par défaut distribué avec le + serveur.
+Indique les parties des fichiers de configuration du serveur + où cette directive est valide. Il s'agit d'une liste d'une ou + plusieurs des valeurs suivantes séparées par des virgules :
+ +httpd.conf),
+ mais pas à l'intérieur d'un conteneur <VirtualHost> ou <Directory>. De même, elle
+ n'est pas valide dans les fichiers .htaccess.<VirtualHost> dans les fichiers de
+ configuration du serveur.<Directory>, <Location>, <Files>, <If>, et <Proxy> dans les
+ fichiers de configuration du serveur, en tenant compte des
+ restrictions précisées dans la documentation sur les Sections de configuration..htaccess. Elle sera ou
+ ne sera pas traitée, selon la définition de l'option overrides pour le contexte courant.La directive n'est autorisée que dans le contexte + désigné ; si vous essayez de l'utiliser ailleurs, vous générerez une + erreur de configuration qui va soit empêcher le serveur de traiter + les requêtes correctement dans ce contexte, soit tout simplement + empêcher le serveur de fonctionner -- en d'autres termes, le serveur + refusera de démarrer.
+ +Les lieux de définition valides pour une directive résultent en
+ fait d'un
+ OU logique de tous les contextes spécifiés. En d'autres termes, une
+ directive spécifiée comme valide dans "configuration du
+ serveur, .htaccess" peut être utilisée dans le fichier
+ httpd.conf et dans les fichiers .htaccess,
+ mais pas dans un conteneur <Directory> ou <VirtualHost>.
Ce terme indique quelle autorisation de surcharge ("override") doit être
+ active pour que la directive puisse être traitée lorsqu'elle
+ apparaît dans un fichier .htaccess. Si le context de la directive ne lui permet pas
+ d'apparaître dans un fichier .htaccess, aucun contexte
+ ne sera spécifié.
Les autorisations de surcharge sont activées via la directive
+ AllowOverride, et possèdent une
+ portée particulière, comme un répertoire et tous ses
+ sous-répertoires, sauf si une autre directive AllowOverride apparaît à un niveau
+ inférieur. La documentation pour cette directive spécifie aussi les
+ noms d'autorisations de surcharge disponibles.
Cet attribut indique le degré de rapprochement de la directive du + coeur d'Apache ; en d'autres termes, vous pouvez être amené à + recompiler le serveur avec un jeu de modules supplémentaires pour + pouvoir utiliser la directive, et ainsi accéder à ses + fonctionnalités. Les valeurs possible pour cet attribut sont :
+ +Il s'agit d'une simple liste des noms des modules sources qui + fournissent la directive.
+Si la directive ne faisait pas partie de la distribution + originale d'Apache version 2, la version dans laquelle elle a été + introduite est indiquée ici. Cette section indique aussi si la + directive n'est disponible que sur certaines plates-formes.
+Serveur HTTP Apache Version 2.4
++ Toutes les directives Apache disponibles dans la distribution standard + d'Apache sont référencées ici. Elles sont décrites en utilisant un + format normalisé, et un dictionnaire des termes utilisés dans leurs + descriptions est disponible. +
+ ++ Un Document de référence rapide des directives + est également disponible. Il donne des détails à propos de chaque directive + sous une forme abrégée. +
+ +A | B | C | D | E | F | G | H | I | K | L | M | N | O | P | Q | R | S | T | U | V | W | X
+Serveur HTTP Apache Version 2.4
+| Description: | Une variante du MPM worker conçue pour ne
+mobiliser des threads que pour les connexions en cours de traitement |
|---|---|
| Statut: | MPM |
| Identificateur de Module: | mpm_event_module |
| Fichier Source: | event.c |
Le module multi-processus (MPM) event est conçu
+ pour permettre le traitement d'un nombre accru de requêtes
+ simultanées en déléguant certaines tâches
+ aux threads d'écoute, libérant par là-même les
+ threads de travail et leur permettant de traiter les nouvelles requêtes.
Pour utiliser le MPM event, ajoutez
+ --with-mpm=event aux arguments du script
+ configure lorsque vous compilez le programme
+ httpd.
AsyncRequestWorkerFactor
CoreDumpDirectory EnableExceptionHook Group Listen ListenBacklog MaxConnectionsPerChild MaxMemFree MaxRequestWorkers MaxSpareThreads MinSpareThreads PidFile ScoreBoardFile SendBufferSize ServerLimit StartServers ThreadLimit ThreadsPerChild ThreadStackSize UserLe MPM event s'inspire du MPM worker qui
+implémente un serveur hybride multi-processus et multi-threads. Un processus de
+contrôle unique (le parent) est chargé de lancer des processus enfants. Chaque
+processus enfant crée un nombre de threads serveurs défini via la directive
+ThreadsPerChild, ainsi qu'un thread
+d'écoute qui surveille les requêtes entrantes et les distribue aux threads de
+travail pour traitement au fur et à mesure de leur arrivée.
Les directives de configuration à l'exécution sont identiques à celles que
+propose le MPM worker, avec l'unique addition de la directive
+AsyncRequestWorkerFactor.
Ce module MPM tente de résoudre le "problème keep + alive" de HTTP. Lorsqu'un client a effectué une première requête, il peut + garder la connexion ouverte et envoyer les requêtes suivante en utilisant le + même socket, ce qui diminue considérablement la charge qui aurait été + induite par la création de nouvelles connexions TCP. Cependant, le + fonctionnement du serveur HTTP Apache impose de réserver un couple processus + enfant/thread pour attendre les données en provenance du client, ce qui + présente certains inconvénients. + Pour résoudre ce problème, le MPM Event utilise un thread d'écoute dédié + pour chaque processus pour gérer les sockets d'écoute, tous les sockets qui + sont dans un état de connexion persistante, les sockets où les + filtres de gestionnaire et de protocole ont fait leur travail, et ceux pour + lesquels la seule chose restant à faire est l'envoi des données au client. +
+ +Cette nouvelle architecture, en exploitant les sockets non blocants et
+ les fonctionnalités des noyaux modernes mis en valeur par
+ APR (comme epoll de Linux), n'a plus besoin du
+ Mutex mpm-accept pour
+ éviter le problème de "thundering herd".
La directive AsyncRequestWorkerFactor permet de
+ définir le nombre total de connexions qu'un bloc processus/thread peut
+ gérer.
Avec les MPM précédents, les connexions asynchrones nécessitaient
+ un thread de travail dédié, mais ce n'est plus le cas avec le MPM Event.
+ La page d'état de mod_status montre de nouvelles
+ colonnes dans la section "Async connections" :
write() vers le socket
+ renvoie en général EWOULDBLOCK ou EAGAIN
+ pour que l'on puisse y écrire à nouveau après un certain temps
+ d'inactivité. Le thread de travail qui utilise le socket doit alors
+ être en mesure de récupérer la tâche en attente et la restituer au
+ thread d'écoute qui, à son tour, la réattribuera au premier thread
+ de travail disponible, lorsqu'un évènement sera généré pour le socket
+ (par exemple, "il est maintenant possible d'écrire dans le socket").
+ Veuillez vous reporter à la section à propos des limitations pour
+ plus de détails.
+ KeepAliveTimeout est atteint, le socket
+ sera fermé par le thread d'écoute. Les threads de travail n'ont
+ donc plus à s'occuper des sockets inactifs et ils peuvent être
+ réutilisés pour traiter d'autres requêtes.Ces améliorations sont disponible pour les connexions HTTP ou HTTPS.
+ + + +Ce MPM présentait dans le passé des limitations de montée en
+ puissance qui
+ provoquaient l'erreur suivante : "scoreboard is full, not at
+ MaxRequestWorkers". La directive MaxRequestWorkers permet de limiter le
+ nombre de requêtes pouvant être servies simultanément à un moment donné
+ ainsi que le nombre de processus autorisés (MaxRequestWorkers / ThreadsPerChild), alors que le
+ scoreboard représente l'ensemble des processus en cours d'exécution et
+ l'état de leurs threads de travail. Si le scoreboard est plein
+ (autrement dit si aucun des threads n'est dans un état inactif) et si le
+ nombre de requêtes actives servies est inférieur à MaxRequestWorkers, cela signifie que
+ certains d'entre eux bloquent les nouvelles requêtes qui pourraient être
+ servies et sont en l'occurrence mises en attente (dans la limite de la
+ valeur imposée par la directive ListenBacklog). La plupart du temps, ces
+ threads sont bloqués dans un état d'arrêt en douceur car ils attendent
+ de terminer leur travail sur une connexion TCP pour s'arrêter et ainsi libérer
+ une entrée dans le scoreboard (par exemple dans le cas du traitement des
+ requêtes de longue durée, des clients lents ou des connexions en
+ keep-alive). Voici deux scénarios courants :
MaxSpareThreads). Cette situation
+ est problèmatique car lorsque la charge augmente à nouveau, httpd va
+ essayer de lancer de nouveaux processus. Si cette situation se
+ répète, le nombre de processus peut augmenter sensiblement,
+ aboutissant à un mélange d'anciens processus tentant de s'arrêter et
+ de nouveaux processus tentant d'effectuer un travail quelconque.
+ A partir de la version 2.4.24, mpm-event est plus intelligent et peut + traiter les arrêts graceful de manière plus efficace. Voici certaines de + ces améliorations :
+ServerLimit. Les directives
+ MaxRequestWorkers et
+ ThreadsPerChild
+ permettent de limiter le nombre de processus actifs, alors que la
+ directive ServerLimit
+ prend aussi en compte les proccessus en arrêt graceful pour
+ permettre l'utilisation d'entrées supplémentaires du scoreboard en
+ cas de besoin. L'idée consiste à utiliser ServerLimit pour indiquer à httpd
+ conbien de processus supplémentaires seront tolérés avant
+ d'atteindre les limites imposées par les ressources du système.
+ Le comportement décrit dans le dernier point est bien visible via
+ mod_status dans la table des connexions avec les deux
+ nouvelles colonnes "Slot" et "Stopping". La première indique le PID et
+ la seconde si le processus est en cours d'arrêt ou non ; l'état
+ supplémentaire "Yes (old gen)" indique un processus encore en exécution
+ après un redémarrage graceful.
La gestion améliorée des connexions peut ne pas fonctionner pour
+ certains filtres de connexion qui se sont déclarés eux-mêmes
+ incompatibles avec le MPM Event. Dans ce cas, le MPM Event réadoptera le
+ comportement du MPM worker et réservera un thread de
+ travail par connexion. Notez que tous les modules inclus dans la
+ distribution du serveur httpd sont compatibles avec le MPM Event.
Une restriction similaire apparaît lorsqu'une requête utilise un
+ filtre en sortie qui doit pouvoir lire et/ou modifier la totalité du
+ corps de la réponse. Si la connexion avec le client se bloque pendant
+ que le filtre traite les données, et si la quantité de données produites
+ par le filtre est trop importante pour être stockée en mémoire, le
+ thread utilisé pour la requête n'est pas libéré pendant que httpd attend
+ que les données soient transmises au client.
+ Pour illustrer ce cas de figure, nous pouvons envisager les deux
+ situations suivantes : servir une ressource statique (comme un fichier
+ CSS) ou servir un contenu issu d'un programme FCGI/CGI ou d'un serveur
+ mandaté. La première situation est prévisible ; en effet, le MPM Event a
+ une parfaite visibilité sur la fin du contenu, et il peut utiliser les
+ évènements : le thread de travail qui sert la réponse peut envoyer les
+ premiers octets jusqu'à ce que EWOULDBLOCK ou
+ EAGAIN soit renvoyé, et déléguer le reste de la réponse au thread
+ d'écoute. Ce dernier en retour attend un évènement sur le socket, et
+ délègue le reste de la réponse au premier
+ thread de travail disponible. Dans la deuxième situation par contre
+ (FCGI/CGI/contenu mandaté), le MPM n'a pas de visibilité sur la fin de
+ la réponse, et le thread de travail doit terminer sa tâche avant de
+ rendre le contrôle au thread d'écoute. La seule solution consisterait
+ alors à stocker la réponse en mémoire, mais ce ne serait pas l'option la
+ plus sure en matière de stabilité du serveur et d'empreinte mémoire.
+
Le modèle event a été rendu possible par l'introduction de nouvelles + APIs dans les systèmes d'exploitation supportés :
+Avant que ces APIs soient mises à disposition, les APIs
+ traditionnelles select et poll devaient être
+ utilisées. Ces APIs deviennent lentes si on les utilise pour gérer de
+ nombreuses connexions ou si le jeu de connexions possède un taux de
+ renouvellement élevé. Les nouvelles APIs permettent de gérer beaucoup
+ plus de connexions et leur performances sont meilleures lorsque le jeu
+ de connexions à gérer change fréquemment. Ces APIs ont donc rendu
+ possible l'écriture le MPM Event qui est mieux adapté à la situation
+ HTTP typique où de nombreuses connexions sont inactives.
Le MPM Event suppose que l'implémentation de apr_pollset
+ sous-jacente est raisonnablement sure avec l'utilisation des threads
+ (threadsafe). Ceci évite au MPM de devoir effectuer trop verrouillages
+ de haut niveau, ou d'avoir à réveiller le thread d'écoute pour lui
+ envoyer un socket keep-alive. Ceci n'est possible qu'avec KQueue et
+ EPoll.
Ce MPM dépend des opérations atomiques compare-and-swap
+ d'APR pour la synchronisation des threads. Si
+ vous compilez pour une plate-forme x86 et n'avez pas besoin du
+ support 386, ou si vous compilez pour une plate-forme SPARC et
+ n'avez pas besoin du support pre-UltraSPARC, ajoutez
+ --enable-nonportable-atomics=yes aux arguments du
+ script configure. Ceci permettra à APR
+ d'implémenter les opérations atomiques en utilisant des instructions
+ performantes indisponibles avec les processeurs plus
+ anciens.
Ce MPM ne fonctionne pas de manière optimale sur les + plates-formes plus anciennes qui ne gèrent pas correctement les + threads, mais ce problème est sans objet du fait du prérequis + concernant EPoll ou KQueue.
+ +libkse (voir man libmap.conf).glibc a été compilée
+ avec le support pour EPoll.| Description: | Limite le nombre de connexions simultanées par thread |
|---|---|
| Syntaxe: | AsyncRequestWorkerFactor facteur |
| Défaut: | 2 |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event |
| Compatibilité: | Disponible depuis la version 2.3.13 |
Le MPM event gère certaines connexions de manière asynchrone ; + dans ce cas, les threads traitant la requête sont alloués selon les + besoins et pour de courtes périodes. Dans les autres cas, un + thread est réservé par + connexion. Ceci peut conduire à des situations où tous les threads + sont saturés et où aucun thread n'est capable d'effectuer de + nouvelles tâches pour les connexions asynchrones établies.
+ +Pour minimiser les effets de ce problème, le MPM event utilise + deux méthodes :
+Cette directive permet de personnaliser finement la limite du + nombre de connexions par thread. Un processus n'acceptera de + nouvelles connexions que si le nombre actuel de connexions (sans + compter les connexions à l'état "closing") est + inférieur à :
+ +
+ ThreadsPerChild +
+ (AsyncRequestWorkerFactor *
+ nombre de threads inactifs)
+
Il est possible d'effectuer une estimation du nombre maximum de + connexions simultanées pour tous les processus et pour un nombre donné moyen + de threads de travail inactifs comme suit : +
+ + +
+ (ThreadsPerChild +
+ (AsyncRequestWorkerFactor *
+ number of idle workers)) *
+ ServerLimit
+
ThreadsPerChild = 10 +ServerLimit = 4 +AsyncRequestWorkerFactor = 2 +MaxRequestWorkers = 40 + +idle_workers = 4 (moyenne pour tous les processus pour faire simple) + +max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit + = (10 + (2 * 4)) * 4 = 72+ +
Lorsque tous les threads de travail sont inactifs, le nombre maximum + absolu de connexions simultanées peut être calculé de manière plus simple :
+ +
+ (AsyncRequestWorkerFactor + 1) *
+ MaxRequestWorkers
+
ThreadsPerChild = 10 +ServerLimit = 4 +MaxRequestWorkers = 40 +AsyncRequestWorkerFactor = 2+ + +
Si tous les threads de tous les processus sont inactifs, alors :
+ +idle_workers = 10+ + +
Nous pouvons calculer le nombre maximum absolu de connexions simultanées + de deux manières :
+ +max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit + = (10 + (2 * 10)) * 4 = 120 + +max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers + = (2 + 1) * 40 = 120+ +
Le réglage de la directive
+ AsyncRequestWorkerFactor nécessite de connaître le
+ trafic géré par httpd pour chaque style d'utilisation spécifique ; si vous
+ modifiez la valeur par défaut, vous devrez par conséquent effectuer des
+ tests approfondis en vous appuyant étroitement sur les données fournies par
+ mod_status.
La directive MaxRequestWorkers se nommait
+ MaxClients avant la version 2.3.13. La valeur
+ ci-dessus montre que cet ancien nom ne correspondait pas à sa
+ signification exacte pour le MPM event.
La directive AsyncRequestWorkerFactor
+ accepte des valeurs d'argument de type non entier, comme "1.5".
Serveur HTTP Apache Version 2.4
++ Ci-dessous se trouve la liste de tous les modules qui font partie de + la distribution du serveur HTTP Apache. Voir aussi la liste alphabétique complète + de toutes les directives du serveur HTTP Apache. +
+worker conçue pour ne
+mobiliser des threads que pour les connexions en cours de traitementA | B | C | D | E | F | H | I | L | M | N | P | R | S | U | V | W | X
+ls, ou à la commande
+shell Win32 dirmod_davmod_davExpires et
+Cache-Control en fonction de critères spécifiés par
+l'utilisateurmod_proxy_balancermod_proxy_balancermod_proxy_balancermod_proxy_balancer basé sur le comptage de trafic Heartbeatmod_proxymod_proxy pour le support de
+la répartition de chargemod_proxy pour le traitement
+des requêtes CONNECTmod_proxy pour le mandatement
+dynamique inverse de massemod_proxymod_proxymod_proxymod_proxymod_proxymod_proxymod_proxymod_proxymod_proxy supportant les
+websocketssedServeur HTTP Apache Version 2.4
+| Description: | Autorisations de groupe à base de nom d'hôte (nom ou +adresse IP) |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | access_compat_module |
| Fichier Source: | mod_access_compat.c |
| Compatibilité: | Disponible dans la version 2.3 du serveur HTTP Apache
+à des fins de compatibilité
+avec les précédentes versions d'Apache httpd 2.x. Les directives fournies par
+ce module sont devenues obsolètes depuis la refonte d'authz. Voir
+mod_authz_host |
Les directives fournies par le module
+ mod_access_compat s'utilisent dans les sections
+ <Directory>,
+ <Files> et
+ <Location>, ainsi
+ que dans les fichiers .htaccess et permettent
+ de contrôler l'accès à certaines parties du serveur. On peut
+ contrôler cet accès en fonction du nom d'hôte du client, de son
+ adresse IP ou d'autres caractéristiques de la requête, telles
+ qu'elles sont enregistrées dans les variables
+ d'environnement. Les directives Allow et Deny permettent de spécifier
+ quels clients sont ou ne sont pas autorisés à accéder au serveur,
+ alors que la directive Order définit le statut
+ d'accès par défaut, et détermine la manière dont les directives
+ Allow et
+ Deny interagissent
+ entre elles.
Les restrictions d'accès à base de nom d'hôte et
+ l'authentification à base de mot de passe peuvent être implémentées
+ simultanément. Dans ce cas, on utilise la directive Satisfy pour déterminer la
+ manière dont ces deux modes de restrictions interagissent.
Les directives fournies par le module
+ mod_access_compat sont devenues obsolètes depuis
+ la refonte du module mod_authz_host. Mélanger d'anciennes
+ directives comme Order, Allow ou Deny avec des nouvelles comme
+ Require est techniquement
+ possible mais déconseillé. En effet, mod_access_compat a
+ été conçu pour supporter des configurations ne contenant que des anciennes
+ directives afin de faciliter le passage à la version 2.4. Voir le document
+ upgrading pour plus de détails.
+
En général, les directives de restriction d'accès s'appliquent à
+ toutes les méthodes d'accès (GET, PUT,
+ POST, etc...). C'est d'ailleurs ce que l'on souhaite
+ dans la plupart des cas. Il est cependant possible de restreindre
+ certaines méthodes, alors que les autres méthodes ne se verront
+ imposée aucune restriction, en regroupant les directives à
+ l'intérieur d'une section <Limit>.
Lorsqu'une directive fournie par ce module est utilisée dans + une nouvelle section de configuration, cette dernière n'hérite + d'aucune directive définie dans une section précédente.
+| Description: | Spécifie quels hôtes peuvent accéder à une certaine zone du +serveur |
|---|---|
| Syntaxe: | Allow from all|hôte|env=[!]variable
+d'environnement
+[hôte|env=[!]variable d'environnement] ... |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | Limit |
| Statut: | Extension |
| Module: | mod_access_compat |
La directive Allow permet de définir quels
+ hôtes ont le droit d'accéder à une certaine partie du serveur. On
+ peut contrôler l'accès par nom d'hôte, adresse IP, intervalle
+ d'adresses IP, ou toute autre caractéristique de la requête client
+ enregistrée dans les variables d'environnement.
Le premier argument de cette directive est toujours
+ from. Les arguments suivants peuvent prendre trois
+ formes différentes. Si Allow from all est spécifié,
+ tout hôte se voit accordé l'accès, en tenant compte des directives
+ Deny et Order comme décrit plus loin.
+ Pour ne permettre l'accès au serveur qu'à un hôte ou un groupe
+ d'hôtes particuliers, on peut spécifier un nom d'hôte sous
+ une des formes suivantes :
Allow from example.org +Allow from .net example.edu+ +
Les hôtes dont les noms correspondent ou se terminent par la
+ chaîne spécifiée ont l'autorisation d'accès. Seules les
+ composantes entières du nom d'hôte doivent correspondre ; ainsi,
+ dans l'exemple ci-dessus, foo.example.org
+ correspondra, mais fooexample.org ne conviendra pas.
+ Avec cette configuration, Apache httpd va effectuer une double recherche
+ DNS sur l'adresse IP du client, sans tenir compte de la
+ définition de la directive HostnameLookups. Tout d'abord, une
+ recherche DNS inverse sur l'adresse IP est effectuée pour
+ déterminer le nom d'hôte associé, puis une recherche directe sur
+ le nom d'hôte est effectuée afin de s'assurer qu'il correspond
+ bien à l'adresse IP originale. L'accès ne sera accordé que si le
+ nom d'hôte correspond et si les recherches DNS inverse et directe
+ concordent.
Allow from 10.1.2.3 +Allow from 192.168.1.104 192.168.1.205+ +
L'adresse IP d'un hôte auquel on a accordé l'accès
Allow from 10.1 +Allow from 10 172.20 192.168.2+ +
De un à trois des premiers octets d'une adresse IP, afin de + restreindre l'accès à un sous-réseau.
Allow from 10.1.0.0/255.255.0.0+ +
Un réseau a.b.c.d, et un masque de sous-réseau w.x.y.z, pour + une définition plus précise de la restriction d'accès imposée à un + sous-réseau.
Allow from 10.1.0.0/16+ +
Identique au cas précédent, mis à part que le masque est + constitué des nnn bits de poids fort.
Notez que les trois derniers exemples désignent le même ensemble + d'hôtes.
+ +On peut spécifier des adresses et sous-réseaux IPv6 de la manière + suivante :
+ +Allow from 2001:db8::a00:20ff:fea7:ccea +Allow from 2001:db8::a00:20ff:fea7:ccea/10+ + +
Le troisième format d'argument de la directive
+ Allow permet de contrôler l'accès au serveur
+ en fonction de l'existence d'une variable d'environnement. Lorsque Allow
+ from env=variable d'environnement est spécifié, la
+ requête est autorisée si la variable d'environnement variable
+ d'environnement existe. En revanche, lorsque Allow from
+ env=!env-variable est spécifié, la
+ requête est autorisée si la variable d'environnement variable
+ d'environnement n'existe pas. Le serveur permet de définir
+ avec souplesse des variables d'environnement en se basant sur les
+ caractéristiques de la requête client et en utilisant les directives
+ fournies par le module mod_setenvif. Ainsi, on peut
+ utiliser la directive Allow pour permettre
+ l'accès en fonction de paramètres comme le User-Agent
+ (type de navigateur) des clients, le Referer, ou
+ d'autres champs d'en-tête de la requête HTTP.
SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in +<Directory "/docroot"> + Order Deny,Allow + Deny from all + Allow from env=let_me_in +</Directory>+ + +
Dans cet exemple, les navigateurs dont la chaîne user-agent
+ commence par KnockKnock/2.0 se verront accorder
+ l'accès, alors que tous les autres seront rejetés.
Lorsqu'une directive fournie par ce module est utilisée dans + une nouvelle section de configuration, cette dernière n'hérite + d'aucune directive définie dans une section précédente.
+| Description: | Définit quels hôtes ne sont pas autorisés à accéder au +serveur |
|---|---|
| Syntaxe: | Deny from all|hôte|env=[!]variable
+d'environnement
+[hôte|env=[!]variable d'environnement] ... |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | Limit |
| Statut: | Extension |
| Module: | mod_access_compat |
Cette directive permet de restreindre l'accès au serveur en
+ fonction du nom d'hôte, de l'adresse IP ou de variables
+ d'environnement. Les arguments de la directive
+ Deny sont identiques aux arguments de la
+ directive Allow.
| Description: | Définit le statut d'accès par défaut et l'ordre dans lequel
+les directives Allow et
+Deny sont évaluées. |
|---|---|
| Syntaxe: | Order ordre |
| Défaut: | Order Deny,Allow |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | Limit |
| Statut: | Extension |
| Module: | mod_access_compat |
La directive Order, associée aux
+ directives Allow
+ et Deny,
+ implémente un système de contrôle d'accès en trois passes. Au cours
+ de la première passe, ce sont soit toutes les directives Allow, soit toutes les
+ directives Deny qui sont traitées, selon
+ la définition de la directive Order. Le reste des
+ directives (Deny
+ ou Allow) est
+ traité au cours de la seconde passe. La troisième passe s'applique à
+ toutes les requêtes qui ne sont concernées par aucune des deux
+ premières passes.
Notez que toutes les directives Allow et Deny sont traitées, à la
+ différence d'un pare-feu classique où seule la première règle qui
+ correspond est utilisée. La dernière directive qui correspond
+ s'applique ( à la différence là encore d'un pare-feu classique). De
+ plus, l'ordre dans lequel les lignes apparaissent dans le fichier de
+ configuration n'a pas d'incidence -- toutes les lignes Allow sont considérées comme
+ un groupe, toutes les lignes Deny comme un autre, et le
+ statut par défaut a son existence propre.
Ordre peut être :
+ +Allow,DenyAllow sont évaluées ; au
+ moins une d'entre elles doit correspondre, sinon la requête est
+ rejetée. Ensuite, toutes les directives Deny sont évaluées. Si au
+ moins l'une d'entre elles correspond, la requête est rejetée.
+ Enfin, toute requête qui ne correspond à aucune directive
+ Allow ou
+ Deny est rejetée
+ par défaut.Deny,AllowDeny sont évaluées ; Si au
+ moins une d'entre elles correspond, la requête est rejetée,
+ à moins qu'elle corresponde aussi à une directive
+ Allow. Toute
+ requête qui ne correspond à aucune directive Allow ou Deny est autorisée.Mutual-failureAllow,Deny et
+ est devenu de ce fait obsolète.Les mots-clés ne peuvent être séparés que par des virgules ; + aucun espace ne doit s'intercaler entre eux.
+ +| Match | +Résultat Allow,Deny | +Résultat Deny,Allow | +
|---|---|---|
| Correspond à Allow seulement | +Requête autorisée | +Requête autorisée | +
| Correspond à Deny seulement | +Requête rejetée | +Requête rejetée | +
| Aucune correspondance | +Par défaut la seconde directive : rejet | +Par défaut la seconde directive : autorisation | +
| Correspond à Allow & Deny | +La dernière correspondance l'emporte : rejet | +La dernière correspondance l'emporte : autorisation | +
Dans cet exemple, tous les hôtes du domaine example.org ont + l'autorisation d'accès ; tous les autres voient leur accès + refusé.
+ +Order Deny,Allow +Deny from all +Allow from example.org+ + +
Dans l'exemple suivant, tous les hôtes du domaine example.org ont
+ l'autorisation d'accès, sauf ceux du sous-domaine foo.example.org qui
+ voient leur accès refusé. Tous les hôtes qui ne sont pas dans le
+ domaine example.org sont rejetés car le statut par défaut est positionné
+ sur Deny, et consiste donc en un
+ refus d'accès.
Order Allow,Deny +Allow from example.org +Deny from foo.example.org+ + +
Par contre, si la valeur de la directive
+ Order, dans l'exemple précédent, est
+ Deny,Allow, tout le monde a l'autorisation d'accès.
+ Ceci est dû au fait que Allow from example.org sera
+ évalué en dernier, sans tenir compte de l'ordre réel dans lequel les
+ directives apparaissent dans le fichier de configuration, et va
+ l'emporter sur Deny from foo.example.org. Tout hôte qui
+ n'est pas dans le domaine example.org aura aussi
+ l'autorisation d'accès car le statut par défaut est positionné sur
+ Allow et constitue donc une
+ autorisation d'accès.
La présence d'une directive Order peut
+ affecter le contrôle d'accès à une partie du serveur même en
+ l'abscence de directives Allow et Deny associées, à cause de
+ son influence sur le statut par défaut. Par exemple,
<Directory "/www"> + Order Allow,Deny +</Directory>+ + +
va interdire tout accès au répertoire /www à cause
+ du statut d'accès par défaut qui est défini à Deny.
La directive Order ne contrôle l'ordre
+ dans lequel sont traitées les directives d'accès qu'au cours de
+ chaque phase du traitement de la configuration du serveur. Ceci
+ implique, par exemple, qu'une directive Allow ou Deny située dans une section
+ <Location> sera
+ toujours évaluée après une directive Allow ou Deny située dans une section
+ <Directory> ou un
+ fichier .htaccess, sans tenir compte de la
+ définition de la directive Order. Pour plus
+ de détails à propos de la fusion des sections de configuration, voir
+ le document Comment fonctionnent les sections Directory,
+ Location et Files.
Lorsqu'une directive fournie par ce module est utilisée dans + une nouvelle section de configuration, cette dernière n'hérite + d'aucune directive définie dans une section précédente.
+| Description: | Interaction entre le contrôle d'accès en fonction de l'hôte +et l'authentification utilisateur |
|---|---|
| Syntaxe: | Satisfy Any|All |
| Défaut: | Satisfy All |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_access_compat |
| Compatibilité: | Affecté par <Limit> et <LimitExcept> à partir de la version
+2.0.51 |
Politique d'accès dans le cas où on utilise à la fois Allow et Require. L'argument est soit
+ All, soit Any. L'utilisation de cette
+ directive n'a de sens que si l'accès à une zone particulière du
+ serveur est restreinte par utilisateur/mot de passe et en fonction
+ de l'adresse IP de l'hôte client. Dans ce cas, par
+ défaut (All), le client doit satisfaire à la
+ restriction d'adresse, et fournir un couple
+ utilisateur/mot de passe valide. Avec l'argument Any,
+ le client se verra accorder l'accès s'il satisfait à la restriction
+ d'adresse ou fournit un couple utilisateur/mot de passe valide. On
+ peut utiliser cette dernière définition pour restreindre l'accès à
+ une zone par mot de passe, mais accorder l'accès aux clients
+ possédant certaines adresses IP sans qu'ils aient à fournir de mot
+ de passe.
Par exemple, si vous souhaitez que les utilisateurs de votre + réseau accèdent à une zone de votre site web sans restriction, mais + que l'accès à cette zone nécessite un mot de passe pour les autres + utilisateurs, vous pouvez utiliser une configuration du style :
+ +Require valid-user +Allow from 192.168.1 +Satisfy Any+ + +
+ Une autre utilisation fréquente de la directive
+ Satisfy est l'allègement des restrictions
+ d'accès à un sous-répertoire par rapport aux restrictions d'accès au
+ répertoire parent :
+
<Directory "/var/www/private"> + Require valid-user +</Directory> + +<Directory "/var/www/private/public"> + Allow from all + Satisfy Any +</Directory>+ + +
Dans l'exemple ci-dessus, l'accès au répertoire
+ /var/www/private nécessitera une authentification,
+ alors que l'accès au répertoire /var/www/private/public
+ sera accordé sans restriction.
Depuis la version 2.0.51, les directives
+ Satisfy peuvent être restreintes à certaines
+ méthodes particulières à l'aide des sections <Limit> et <LimitExcept>.
Lorsqu'une directive fournie par ce module est utilisée dans + une nouvelle section de configuration, cette dernière n'hérite + d'aucune directive définie dans une section précédente.
+Serveur HTTP Apache Version 2.4
+| Description: | Exécution des scripts CGI en fonction du +type de média ou de la méthode de requête. |
|---|---|
| Statut: | Base |
| Identificateur de Module: | actions_module |
| Fichier Source: | mod_actions.c |
Ce module possède deux directives. La directive Action vous permet de lancer
+ l'exécution de scripts CGI chaque fois qu'un fichier possédant un
+ certain type de contenu MIME
+ fait l'objet d'une requête. La directive Script vous permet de lancer
+ l'exécution de scripts CGI chaque fois que la requête utilise une
+ méthode particulière. Ceci facilite grandement l'exécution de
+ scripts qui traitent des fichiers.
| Description: | Active un script CGI pour un gestionnaire ou un type de +contenu particulier |
|---|---|
| Syntaxe: | Action type d'action script cgi
+[virtual] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_actions |
| Compatibilité: | Le modificateur virtual et le passage de
+gestionnaire ont été introduits dans Apache 2.1 |
Cette directive ajoute une action qui va activer script
+ cgi lorsque type d'action est déclenché par la
+ requête. script cgi est un chemin URL vers une ressource
+ qui a été désignée comme script CGI à l'aide des directives
+ ScriptAlias ou AddHandler. type d'action
+ peut être soit un gestionnaire, soit
+ un type de contenu MIME. L'URL
+ et le chemin du document correspondant sont envoyés en utilisant
+ les variables d'environnement CGI standards PATH_INFO
+ et PATH_TRANSLATED. Le gestionnaire utilisé pour cette
+ requête particulière est transmis à l'aide de la variable
+ REDIRECT_HANDLER.
# Requests for files of a particular MIME content type: +Action image/gif /cgi-bin/images.cgi+
Dans cet exemple, les requêtes pour des fichiers possédant
+ le type de contenu MIME image/gif seront traitées par
+ le script CGI /cgi-bin/images.cgi.
# Files of a particular file extension +AddHandler my-file-type .xyz +Action my-file-type "/cgi-bin/program.cgi"+
Dans cet exemple, les requêtes pour des fichiers possédant
+ l'extension .xyz seront traitées par
+ le script CGI /cgi-bin/programme.cgi.
Le modificateur optionnel virtual permet de
+ désactiver la vérification de l'existence du fichier demandé. Ceci
+ peut s'avérer utile, par exemple, si vous voulez utiliser la
+ directive Action pour des localisations
+ virtuelles.
<Location "/news"> + SetHandler news-handler + Action news-handler "/cgi-bin/news.cgi" virtual +</Location>+ + +
AddHandler| Description: | Active un script CGI dans le cas d'une méthode de requête +particulière. |
|---|---|
| Syntaxe: | Script méthode script cgi |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_actions |
Cette directive ajoute une action qui va activer script
+ cgi lorsqu'un fichier est demandé en utilisant la méthode
+ méthode. script cgi est le chemin URL d'une
+ ressource qui a été désignée comme script CGI en utilisant les
+ directives ScriptAlias ou AddHandler. L'URL et le chemin du
+ document demandé sont envoyés en utilisant les variables
+ d'environnement CGI standards PATH_INFO et
+ PATH_TRANSLATED.
Script PUT et Script put ont des effets
+ totalement différents.
+ Notez que la commande Script ne définit
+ que des actions par défaut. Si un script CGI est appelé, ou toute
+ autre ressource capable de gérer la méthode de la requête en
+ interne, il agira en conséquence. Notez aussi que
+ Script avec une méthode GET ne
+ sera appelé que si la requête possède des arguments (par exemple
+ foo.html?hi). Dans le cas contraire, la requête sera traitée
+ normalement.
# All GET requests go here +Script GET "/cgi-bin/search" + +# A CGI PUT handler +Script PUT "/~bob/put.cgi"+ + +
Serveur HTTP Apache Version 2.4
+| Description: | Permet d'atteindre différentes parties du système de +fichiers depuis l'arborescence des documents du site web, ainsi que la +redirection d'URL |
|---|---|
| Statut: | Base |
| Identificateur de Module: | alias_module |
| Fichier Source: | mod_alias.c |
Les directives fournies par ce module permettent de manipuler et
+ de contrôler les URLs à l'arrivée des requêtes sur le serveur. Les
+ directives Alias et
+ ScriptAlias permettent de
+ faire correspondre des URLs avec des chemins du système de fichiers.
+ Ceci permet de servir des contenus qui ne sont pas situés dans
+ l'arborescence de DocumentRoot comme s'ils y étaient
+ réellement. La directive ScriptAlias a pour effet
+ supplémentaire de marquer le répertoire cible comme conteneur de
+ scripts CGI.
Les directives Redirect
+ indiquent aux clients qu'ils doivent effectuer une nouvelle requête
+ avec une URL différente. Elles sont souvent utilisées lorsqu'une
+ ressource a été déplacée.
Lorsque les directives Alias, ScriptAlias ou Redirect sont définies au sein d'une
+ section <Location>
+ ou <LocationMatch>, vous pouvez utiliser la syntaxe des expressions pour manipuler l'URL
+ ou le chemin de destination.
+
mod_alias est conçu pour traiter des tâches
+ simples de manipulation d'URL. Pour des tâches plus complexes comme
+ la manipulation des chaînes d'arguments des requêtes, utilisez
+ plutôt les outils fournis par le module mod_rewrite
Alias AliasMatch Redirect RedirectMatch RedirectPermanent RedirectTemp ScriptAlias ScriptAliasMatchLes alias et redirections apparaissant dans différents contextes
+ sont traités comme les autres directives en respectant les règles de fusion standards. Par
+ contre, ils sont traités selon une chronologie particulière
+ lorsqu'ils apparaissent dans le même contexte (par exemple, dans la
+ même section <VirtualHost>).
Premièrement, toutes les redirections sont traitées avant les
+ alias, et ainsi, une requête qui correspond à une directive
+ Redirect ou RedirectMatch ne se verra jamais
+ appliquer d'alias. Deuxièmement, les alias et redirections sont
+ traités selon l'ordre dans lequel ils apparaissent dans le fichier
+ de configuration, seule la première correspondance étant prise en
+ compte.
Ainsi, lorsqu'une ou plusieurs de ces directives s'appliquent au + même sous-répertoire, vous devez classer les chemins du plus précis + au moins précis afin que toutes les directives puissent + éventuellement s'appliquer, comme dans l'exemple suivant :
+ +Alias "/foo/bar" "/baz" +Alias "/foo" "/gaq"+ + +
Si l'ordre des directives était inversé, la directive Alias ayant pour argument
+ /foo serait toujours appliquée avant la directive
+ Alias ayant pour argument
+ /foo/bar, et cette dernière serait toujours
+ ignorée.
La définition de directives Alias, ScriptAlias ou Redirect au sein de sections
+ <Location> ou
+ <LocationMatch>
+ l'emporte sur d'autres définitions éventuelles de ces mêmes
+ directives au niveau de la configuration générale du serveur.
| Description: | Met en correspondance des URLs avec des chemins du système +de fichiers |
|---|---|
| Syntaxe: | Alias [chemin URL]
+chemin fichier|chemin répertoire |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_alias |
La directive Alias permet de stocker des
+ documents (destinés à être servis) dans des zones du système de
+ fichiers situées en dehors de l'arborescence du site web DocumentRoot. Les URLs dont le chemin
+ (décodé avec caractères %) commence par chemin URL seront
+ mises en correspondance avec des fichiers locaux dont le chemin
+ commence par chemin répertoire. Le chemin URL
+ est sensible à la casse, même sur les systèmes de fichiers
+ insensibles à la casse.
Alias "/image" "/ftp/pub/image"+ + +
Une requête pour http://example.com/image/foo.gif fera
+ renvoyer par le serveur le fichier
+ /ftp/pub/image/foo.gif. Seuls les éléments de chemin
+ complets sont testés ; ainsi l'alias précédent ne conviendra pas
+ pour une requête du style http://example.com/imagefoo.gif.
+ Pour des mises en correspondance plus complexes faisant intervenir
+ les expressions rationnelles, veuillez vous reporter à la directive
+ AliasMatch.
Notez que si vous ajoutez un slash de fin au chemin + URL, vous devrez aussi ajouter un slash de fin au chemin de la + requête. Autrement dit, si vous définissez
+ +Alias "/icons/" "/usr/local/apache/icons/"+ + +
l'alias précédent ne s'appliquera pas à l'URL
+ /icons à cause de l'absence du slash final. Ainsi, si
+ le slash final est absent du chemin de l'URL, il doit
+ aussi l'être du chemin du fichier.
Notez qu'il pourra s'avérer nécessaire de définir des sections
+ <Directory>
+ supplémentaires qui couvriront la destination des alias.
+ Le traitement des alias intervenant avant le traitement des sections
+ <Directory>,
+ seules les cibles des alias sont affectées (Notez cependant
+ que les sections <Location> sont traitées avant les alias, et
+ s'appliqueront donc).
En particulier, si vous créez un alias ayant pour cible un
+ répertoire situé en dehors de l'arborescence de votre site web
+ DocumentRoot, vous devrez
+ probablement permettre explicitement l'accès à ce répertoire.
Alias "/image" "/ftp/pub/image" +<Directory "/ftp/pub/image"> + Require all granted +</Directory>+ + +
Le nombre de slashes dans le paramètre chemin URL doit + correspondre au nombre de slashes dans le chemin URL de la requête.
+ +Si la directive Alias est définie au sein
+ d'une section <Location> ou <LocationMatch>, chemin URL est
+ omis et chemin fichier est interprété en utilisant la syntaxe des expressions.
+ Cette syntaxe est disponible à partir de la version 2.4.19 du
+ serveur HTTP Apache.
<Location "/image">
+ Alias "/ftp/pub/image"
+</Location>
+<LocationMatch "/error/(?<NUMBER>[0-9]+)">
+ Alias "/usr/local/apache/errors/%{env:MATCH_NUMBER}.html"
+</LocationMatch>
+
+
+
+| Description: | Met en correspondance des URLs avec le système de fichiers +en faisant intervenir les expressions rationnelles |
|---|---|
| Syntaxe: | AliasMatch regex
+chemin fichier|chemin répertoire |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_alias |
Cette directive est identique à la directive Alias, mais fait appel aux expressions rationnelles, à la place d'une
+ simple mise en correspondance de préfixe. L'expression rationnelle
+ fournie est mise en correspondance avec le chemin URL, et si elle
+ correspond, le serveur va substituer toute partie de chemin
+ correspondant à l'expression entre parenthèses dans la chaîne
+ fournie et l'utiliser comme nom de fichier.
+ Par exemple, pour activer le répertoire /icons, on peut
+ utiliser :
AliasMatch "^/icons(.*)" "/usr/local/apache/icons$1$2"+ + +
Toute la puissance des expressions + rationnelles peut être mise à contribution. Par exemple, + il est possible de construire un alias avec un modèle de chemin URL + insensible à la casse :
+ +AliasMatch "(?i)^/image(.*)" "/ftp/pub/image$1"+ + +
Il existe une différence subtile entre Alias et AliasMatch : Alias copie automatiquement toute
+ portion supplémentaire de l'URI située après la partie du modèle qui
+ correspond, à la fin du chemin du fichier de la partie droite, alors
+ que AliasMatch ne le fait
+ pas. Cela signifie qu'il sera préférable dans la plupart des cas de
+ comparer l'expression rationnelle du modèle à la totalité de l'URI
+ de la requête, et d'utiliser les substitutions dans la partie
+ droite.
En d'autres termes, le remplacement d'Alias par AliasMatch ne produira pas le même
+ résultat. Au minimum, vous devez ajouter ^ au début de
+ l'expression rationnelle, (.*)$ à sa fin et
+ $1 à la fin de la chaîne de remplacement.
Par exemple, supposons que nous voulions reformuler cet alias + avec AliasMatch :
+ +Alias "/image/" "/ftp/pub/image/"+ + +
Le simple remplacement d'Alias par AliasMatch ne produira pas le + même résultat. Ainsi, ce qui suit va rediriger toutes les requêtes + qui contiennent /image/ vers /ftp/pub/image/ :
+ +AliasMatch "/image/" "/ftp/pub/image/"+ + +
Voici la directive AliasMatch qui produira le même résultat que + la directive Alias ci-dessus :
+ +AliasMatch "^/image/(.*)$" "/ftp/pub/image/$1"+ + +
Bien entendu, il n'y a aucune raison d'utiliser AliasMatch dans le cas où Alias suffit. AliasMatch vous permet d'effectuer
+ des choses beaucoup plus sophistiquées. Par exemple, vous pouvez
+ servir différentes sortes de fichiers à partir de répertoires
+ différents :
AliasMatch "^/image/(.*)\.jpg$" "/fichiers/jpg.images/$1.jpg" + AliasMatch "^/image/(.*)\.gif$" "/fichiers/gif.images/$1.gif"+ + +
Les éventuels slashes de tête multiples seront supprimés par le + serveur avant que les directives de ce module n'effectuent des + comparaisons avec le chemin URL de la requête. +
+ + +| Description: | Envoie une redirection externe demandant au client +d'effectuer une autre requête avec une URL différente |
|---|---|
| Syntaxe: | Redirect [état] [URL-path]
+URL |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_alias |
La directive Redirect permet de faire correspondre
+ une ancienne URL à une nouvelle en demandant au client d'aller chercher la
+ ressource à une autre localisation.
L'ancien URL-path est un chemin sensible à la casse + (décodé à l'aide de caractères %) commençant par un slash. Les + chemins relatifs ne sont pas autorisés.
+ +La nouvelle URL + peut être une URL absolue commençant par un protocole et un nom + d'hôte, mais on peut aussi utiliser un chemin URL commençant par un + slash, auquel cas le protocole et le nom d'hôte du serveur local + seront ajoutés.
+ +Ensuite, toute requête commençant par URL-path va + renvoyer une redirection au client vers l'URL cible. Tout + élément de chemin supplémentaire situé en aval du URL-path sera + ajouté à l'URL cible.
+ +# Redirige vers une URL sur un serveur différent +Redirect "/service" "http://foo2.example.com/service" + +# Redirige vers une URL sur le même serveur +Redirect "/one" "/two"+ + +
Si le client effectue une requête pour l'URL
+ http://example.com/service/foo.txt, il lui sera demandé
+ d'en effectuer une autre pour l'URL
+ http://foo2.example.com/service/foo.txt. Ceci concerne
+ les requêtes avec paramètres GET, comme
+ http://example.com/service/foo.pl?q=23&a=42, qui
+ seront redirigées vers
+ http://foo2.example.com/service/foo.pl?q=23&a=42.
+ Notez que les POSTs seront ignorés.
+ Seuls les
+ éléments de chemin complets sont testés, si bien que l'exemple
+ précédent ne s'appliquera pas à l'URL
+ http://example.com/servicefoo.txt. Pour des mises en
+ correspondance plus complexes utilisant la syntaxe des expressions, ne spécifiez pas
+ d'argument URL-path comme décrit ci-dessous. En outre,
+ pour une mise en correspondance en utilisant les expressions
+ rationnelles, veuillez vous reporter à la directive RedirectMatch.
Les directives Redirect ont priorité sur les
+ directives Alias et ScriptAlias, quel que soit leur ordre
+ d'apparition dans le fichier de configuration. Les directives
+ Redirect définies au sein d'une section Location
+ l'emportent sur les directives Redirect et Alias comportant un argument
+ URL-path.
Si aucun argument état n'est spécifié, la + redirection sera temporaire (code HTTP 302). Le client est alors + informé que la ressource a été temporairement déplacée. On peut + utiliser l'argument état pour renvoyer d'autres codes HTTP :
+ +On peut renvoyer d'autres codes en spécifiant le code
+ numérique comme valeur de l'argument of état.
+ Si le code est compris entre 300 et 399, l'argument
+ URL doit être présent. Si le code
+ n'est pas compris entre 300 et 399, l'argument
+ URL ne doit pas apparaître. Le code doit être un code
+ HTTP valide, connu du serveur HTTP Apache (voir la
+ fonction send_error_response dans
+ http_protocol.c).
Redirect permanent "/one" "http://example.com/two" +Redirect 303 "/three" "http://example.com/other"+ + +
Si une directive Redirect est définie au
+ sein d'une section <Location> ou <LocationMatch> et si l'argument URL-path est omis, l'argument URL sera interprété en
+ utilisant la syntaxe des expressions.
+ Cette syntaxe est disponible à partir de la version 2.4.19 du
+ serveur HTTP Apache.
<Location "/one">
+ Redirect permanent "http://example.com/two"
+</Location>
+<Location "/three">
+ Redirect 303 "http://example.com/other"
+</Location>
+<LocationMatch "/error/(?<NUMBER>[0-9]+)">
+ Redirect permanent "http://example.com/errors/%{env:MATCH_NUMBER}.html"
+</LocationMatch>
+
+
+
+| Description: | Envoie une redirection externe faisant appel aux +expressions rationnelles pour la mise en correspondance de l'URL +courante |
|---|---|
| Syntaxe: | RedirectMatch [état] regex
+URL |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_alias |
Cette directive est identique à la directive Redirect, mais fait appel aux
+ expressions rationnelles, à la
+ place d'une simple mise en correspondance de préfixe. L'expression
+ rationnelle fournie est mise en correspondance avec le chemin URL,
+ et si elle correspond, le serveur va substituer toute partie de
+ chemin correspondante entre parenthèses dans la chaîne spécifiée et
+ l'utiliser comme nom de fichier. Par exemple, pour rediriger tous
+ les fichiers GIF vers les fichiers JPEG de même nom sur un autre
+ serveur, on peut utiliser :
RedirectMatch "(.*)\.gif$" "http://autre.example.com$1.jpg"+ + +
Les remarques à propos de la différence entre Alias et AliasMatch s'appliquent aussi à la
+ différence entre les directives Redirect et RedirectMatch. Voir la directive
+ AliasMatch pour plus de
+ détails.
| Description: | Envoie une redirection externe permanente demandant au +client d'effectuer une nouvelle requête avec une URL +différente |
|---|---|
| Syntaxe: | RedirectPermanent chemin URL URL |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_alias |
Cette directive informe le client que la redirection est
+ permanente (code 301). Son comportement est exactement le même
+ que celui de Redirect permanent.
| Description: | Envoie une redirection externe temporaire demandant au +client d'effectuer une nouvelle requête avec une URL +différente |
|---|---|
| Syntaxe: | RedirectTemp chemin URL URL |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_alias |
Cette directive informe le client que la redirection n'est
+ que temporaire (code 302). Son comportement est exactement le même
+ que celui de Redirect temp.
| Description: | Fait correspondre une URL à une zone du système de fichiers +et désigne la cible comme script CGI |
|---|---|
| Syntaxe: | ScriptAlias [chemin URL]
+chemin fichier|chemin répertoire |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_alias |
La directive ScriptAlias présente le même
+ comportement que la directive Alias, mais désigne en plus le
+ répertoire cible comme conteneur de scripts CGI qui seront traitées
+ par le gestionnaire cgi-script du module mod_cgi.
+ Les URLs dont le chemin URL sensible à la casse (décodé avec
+ caractères %) commence par chemin URL seront mises en
+ correspondance avec les scripts dont le chemin commence par le
+ second argument, qui est un chemin complet dans le système de
+ fichiers local.
ScriptAlias "/cgi-bin/" "/web/cgi-bin/"+ + +
Une requête pour http://example.com/cgi-bin/foo
+ ferait exécuter par le serveur le script
+ /web/cgi-bin/foo. Cette configuration est sensiblement
+ équivalente à :
Alias "/cgi-bin/" "/web/cgi-bin/" +<Location "/cgi-bin"> + SetHandler cgi-script + Options +ExecCGI +</Location>+ + +
Vous pouvez aussi utiliser ScriptAlias
+ avec un script ou gestionnaire de votre cru. Par exemple :
ScriptAlias "/cgi-bin/" "/web/cgi-handler.pl"+ + +
Dans ce scénario, tous les fichiers faisant l'objet d'une requête
+ dans /cgi-bin/ seront traités par le fichier que vous
+ avez spécifié, ce qui vous permet d'utiliser votre propre
+ gestionnaire. Vous pouvez l'utiliser comme enveloppe (wrapper) pour
+ les scripts CGI afin d'ajouter du contenu, ou autre action "maison".
DocumentRoot afin d'éviter de révéler
+ accidentellement leur code source lors d'une modification de
+ configuration. On y parvient aisément avec
+ ScriptAlias en mettant en correspondance une
+ URL et en désignant la cible comme scripts CGI par la même occasion.
+ Si vous choisissez de placer vos scripts CGI dans un répertoire
+ accessible depuis le web, n'utilisez pas
+ ScriptAlias. Utilisez plutôt <Directory>, SetHandler, et Options comme dans l'exemple suivant :
+ <Directory "/usr/local/apache2/htdocs/cgi-bin"> + SetHandler cgi-script + Options ExecCGI +</Directory>+ + Ceci est nécessaire car plusieurs chemins URL peuvent + correspondre à la même zone du système de fichiers, court-circuitant + ainsi la directive
ScriptAlias et révélant le
+ code source des scripts CGI s'ils ne sont pas protégés par une
+ section Directory.Si la directive ScriptAlias est définie au
+ sein d'une section <Location> ou <LocationMatch> et si l'argument chemin
+ URL est omis, l'argument URL sera interprété en
+ utilisant la syntaxe des expressions.
+ Cette syntaxe est disponible à partir de la version 2.4.19 du
+ serveur HTTP Apache.
<Location "/cgi-bin">
+ ScriptAlias "/web/cgi-bin/"
+</Location>
+<LocationMatch "/cgi-bin/errors/(?<NUMBER>[0-9]+)">
+ ScriptAlias "/web/cgi-bin/errors/%{env:MATCH_NUMBER}.cgi"
+</LocationMatch>
+
+
+
+| Description: | Fait correspondre une URL à une zone du système de fichiers +en faisant appel aux expressions rationnelles et en désignant la cible +comme un script CGI |
|---|---|
| Syntaxe: | ScriptAliasMatch regex
+chemin fichier|chemin répertoire |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_alias |
Cette directive est équivalente à la directive ScriptAlias, mais fait appel aux
+ expressions rationnelles, à la
+ place d'une simple mise en correspondance de préfixe. L'expression
+ rationnelle fournie est mise en correspondance avec le chemin URL,
+ et si elle correspond, le serveur va substituer toute partie de
+ chemin entre parenthèses dans la chaîne spécifiée et l'utiliser
+ comme nom de fichier. Par exemple, pour activer le répertoire
+ standard /cgi-bin, on peut utiliser :
ScriptAliasMatch "^/cgi-bin(.*)" "/usr/local/apache/cgi-bin$1"+ + +
Comme dans le cas d'AliasMatch, toute la puissance des expressions rationnelles peut être mise à + contribution. Par exemple, il est possible de construire un alias + avec une comparaison du modèle du chemin URL insensible à la casse :
+ +ScriptAliasMatch "(?i)^/cgi-bin(.*)" "/usr/local/apache/cgi-bin$1"+ + +
Les remarques à propos de la différence entre Alias et AliasMatch s'appliquent aussi à la
+ différence entre les directives ScriptAlias et ScriptAliasMatch. Voir la directive
+ AliasMatch pour plus de
+ détails.
Serveur HTTP Apache Version 2.4
+| Description: | Ce module permet de restreindre aisément les méthodes HTTP +pouvant être utilisées sur le serveur |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | allowmethods_module |
| Fichier Source: | mod_allowmethods.c |
| Compatibilité: | Disponible à partir de la version 2.3 du serveur HTTP Apache |
Ce module permet de restreindre aisément les méthodes HTTP +pouvant être utilisées sur le serveur. La configuration la plus courante +est du style :
+ +<Location "/"> + AllowMethods GET POST OPTIONS +</Location>+ + +
| Description: | Restreint l'accès aux méthodes HTTP spécifiées |
|---|---|
| Syntaxe: | AllowMethods reset|HTTP-method
+[HTTP-method]... |
| Défaut: | AllowMethods reset |
| Contexte: | répertoire |
| Statut: | Expérimental |
| Module: | mod_allowmethods |
Les noms des méthodes HTTP sont sensibles à la casse, et sont en
+général définis en majuscules, comme dans les RFCs. Les méthodes GET et
+HEAD sont considérées comme équivalentes. Le mot-clé
+reset permet de désactiver
+mod_allowmethods dans les niveaux inférieurs
+d'imbrication :
<Location "/svn"> + AllowMethods reset +</Location>+ + +
La méthode TRACE ne peut pas être rejetée par ce module ; pour ce
+ faire, vous devez utiliser la directive TraceEnable.
Le module mod_allowmethods a été écrit pour
+remplacer l'implémentation "bricolée" des directives Limit et LimitExcept.
Serveur HTTP Apache Version 2.4
+| Description: | Envoie des fichiers contenant leurs propres en-têtes +HTTP |
|---|---|
| Statut: | Base |
| Identificateur de Module: | asis_module |
| Fichier Source: | mod_asis.c |
Ce module fournit le gestionnaire send-as-is qui
+ permet au serveur HTTP Apache d'envoyer le document sans ajouter la plupart des
+ en-têtes HTTP habituels.
On peut l'utiliser pour envoyer tous types de données en + provenance du serveur, y compris les redirections et autres réponses + HTTP spéciales, sans devoir faire appel à un script CGI ou nph.
+ +Pour des raisons historiques, ce module traitera aussi tout
+ fichier dont le type MIME est httpd/send-as-is.
Mode d'emploiCe module ne fournit aucune directive.
+Dans le fichier de configuration, associez les fichiers asis au
+ gestionnaire send-as-is comme ceci :
AddHandler send-as-is asis+ + +
Le contenu de tout fichier possédant l'extension
+ .asis sera envoyé par Apache httpd au client pratiquement tel
+ quel. En particulier, les en-têtes HTTP seront déduits du fichier
+ lui-même selon les règles du module mod_cgi, si
+ bien qu'un fichier asis doit inclure des en-têtes valides, et
+ utiliser l'en-tête CGI Status: pour déterminer le code de réponse
+ HTTP. L'en-tête Content-Length: sera automatiquement
+ inséré ou, s'il est déjà présent, corrigé par httpd.
Voici un exemple de fichier dont le contenu est envoyé tel + quel pour informer un client qu'un fichier a été déplacé.
+ + +
+ Status: 301 Ou se trouve cette URL maintenant
+ Location: http://xyz.example.com/foo/bar.html
+ Content-type: text/html
+
+ <html>
+ <head>
+ <title>Mauvaises excuses</title>
+ </head>
+ <body>
+ <h1>La merveilleuse page de Fred a été déplacée vers
+ <a href="http://xyz.example.com/foo/bar.html">le site de
+ Joe</a>.
+ </h1>
+ </body>
+ </html>
+
Le serveur ajoute systématiquement les en-têtes
+ Date: et Server: aux données qu'il envoie
+ au client, si bien qu'ils n'ont pas besoin d'être inclus dans le
+ fichier. Le serveur n'ajoute pas d'en-tête
+ Last-Modified, ce qu'il devrait probablement faire.
Serveur HTTP Apache Version 2.4
+| Description: | Authentification HTTP de base |
|---|---|
| Statut: | Base |
| Identificateur de Module: | auth_basic_module |
| Fichier Source: | mod_auth_basic.c |
| Compatibilité: | Disponible depuis la version 2.1 d'Apache |
Ce module permet d'utiliser l'authentification basique HTTP pour
+ restreindre l'accès en recherchant les utilisateurs dans les
+ fournisseurs d'authentification spécifiés. Il est en général
+ combiné avec au moins un module d'authentification comme
+ mod_authn_file et un module d'autorisation comme
+ mod_authz_user. L'authentification HTTP à
+ base de condensé (digest), quant à elle, est fournie par le module
+ mod_auth_digest.
| Description: | Définit si les processus d'autorisation et +d'authentification peuvent être confiés à des modules de plus bas +niveau |
|---|---|
| Syntaxe: | AuthBasicAuthoritative On|Off |
| Défaut: | AuthBasicAuthoritative On |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_auth_basic |
Normalement, chaque module d'autorisation énuméré dans la
+ directive AuthBasicProvider va tenter de
+ vérifier l'utilisateur, et si ce dernier n'est trouvé dans aucun des
+ fournisseurs, l'accès sera refusé. Définir explicitement la
+ directive AuthBasicAuthoritative à
+ Off permet de confier l'autorisation et
+ l'authentification à d'autres modules non basés sur les fournisseurs
+ si aucun identifiant utilisateur ou aucune
+ règle ne correspondent à l'identifiant utilisateur
+ spécifié. Ceci ne peut s'avérer nécessaire que lorsque
+ mod_auth_basic est combiné avec des modules tiers
+ qui n'ont pas été configurés à l'aide de la directive AuthBasicProvider. Lorsqu'on
+ utilise de tels modules, l'ordre dans lequel s'effectue le
+ traitement est défini dans le code source des modules et n'est pas
+ configurable.
| Description: | Authentification de base simulée à l'aide des nom +d'utilisateur et mot de passe fournis |
|---|---|
| Syntaxe: | AuthBasicFake off|username [password] |
| Défaut: | none |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_auth_basic |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP +Apache |
Les nom d'utilisateur et mot de passe spécifiés sont rassemblés + dans un en-tête d'autorisation qui est transmis au serveur ou au + service sous-jacent au serveur. Ces nom d'utilisateur et mot de + passe sont interprétés par l'interpréteur + d'expression, ce qui permet de les définir en fonction de + paramètres de la requête.
+ +Si aucun mot de passe n'est spécifié, la valeur par défaut + "password" sera utilisée. Pour désactiver l'authentification de base + simulée pour un espace d'URL, définissez AuthBasicFake à "off".
+ +Dans l'exemple suivant, un nom d'utilisateur et un mot de passe + prédéfinis sont transmis à un serveur d'arrière-plan :
+ +<Location "/demo"> + AuthBasicFake demo demopass +</Location>+
Dans l'exemple suivant, l'adresse email extraite d'un certificat
+ client est transmise au serveur, étendant par là-même la
+ fonctionnalité de l'option FakeBasicAuth de la directive SSLOptions. Comme avec l'option
+ FakeBasicAuth, le mot de passe se voit attribué le contenu fixe de
+ la chaîne "password".
<Location "/secure">
+ AuthBasicFake "%{SSL_CLIENT_S_DN_Email}"
+</Location>
+Pour compléter l'exemple précédent, il est possible de générer la + valeur du mot de passe en procédant à un hashage de l'adresse email + à partir d'un mot d'une passphrase initial fixée, puis de transmettre le + résultat obtenu au serveur d'arrière-plan. Ceci peut s'avérer utile + pour donner accès à des serveurs anciens qui ne supportent pas les + certificats clients.
+ +<Location "/secure">
+ AuthBasicFake "%{SSL_CLIENT_S_DN_Email}" "%{sha1:passphrase-%{SSL_CLIENT_S_DN_Email}}"
+</Location>
+<Location "/public"> + AuthBasicFake off +</Location>+
| Description: | Définit le(les) fournisseur(s) d'authentification pour +cette zone du site web |
|---|---|
| Syntaxe: | AuthBasicProvider nom fournisseur
+[nom fournisseur] ... |
| Défaut: | AuthBasicProvider file |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_auth_basic |
La directive AuthBasicProvider permet de
+ définir le fournisseur utilisé pour authentifier les utilisateurs
+ pour la zone du site web concernée. Le fournisseur par défaut
+ file est implémenté par le module
+ mod_authn_file. Assurez-vous que le module
+ implémentant le fournisseur choisi soit bien présent dans le
+ serveur.
<Location "/secure"> + AuthType basic + AuthName "private area" + AuthBasicProvider dbm + AuthDBMType SDBM + AuthDBMUserFile "/www/etc/dbmpasswd" + Require valid-user +</Location>+
Les fournisseurs sont sollicités dans l'ordre jusqu'à ce que l'un + d'entre eux trouve une correspondance pour le nom d'utilisateur de + la requête ; alors, ce dernier fournisseur sera le seul à vérifier + le mot de passe. Un échec dans la vérification du mot de passe + n'entraîne pas le passage du contrôle au fournisseur suivant.
+ +Les différents fournisseurs disponibles sont implémentés par les
+ modules mod_authn_dbm,
+ mod_authn_file, mod_authn_dbd,
+ mod_authnz_ldap et mod_authn_socache.
| Description: | Vérifie les mots de passe auprès des fournisseurs +d'authentification à la manière de l'authentification de type Digest. + |
|---|---|
| Syntaxe: | AuthBasicUseDigestAlgorithm MD5|Off |
| Défaut: | AuthBasicUseDigestAlgorithm Off |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_auth_basic |
| Compatibilité: | Disponible à partir de la version 2.4.7 du serveur HTTP +Apache |
Normalement, lorsqu'on utilise l'authentification basique, les
+ fournisseurs spécifiés via la directive AuthBasicProvider tentent de
+ contrôler l'identité d'un utilisateur en recherchant dans leurs
+ bases de données l'existence d'un couple utilisateur/mot de passe
+ correspondant. Les mots de passe enregistrés sont en général
+ chiffrés, mais ce n'est pas systématique ; chaque fournisseur peut
+ choisir son propre mode de stockage des mots de passe.
Lorsqu'on utilise l'authentification de type Digest, les
+ fournisseurs spécifiés par la directive AuthDigestProvider effectuent
+ une recherche similaire dans leurs bases de
+ données pour trouver un couple utilisateur/mot de passe
+ correspondant. Cependant, à la différence de l'authentification
+ basique, les données associées à chaque utilisateur et comportant le
+ nom d'utilisateur, le domaine de protection (realm) et le mot de
+ passe doivent être contenues dans une chaîne chiffrée (Voir le
+ document RFC 2617,
+ Section 3.2.2.2 pour plus de détails à propos du type de
+ chiffrement utilisé pour cette chaîne).
A cause de la différence entre les méthodes de stockage des + données des authentifications de type basique et digest, le passage + d'une méthode d'authentification de type digest à une méthode + d'authentification de type basique requiert l'attribution de + nouveaux + mots de passe à chaque utilisateur, car leur mots de passe existant + ne peut pas être extrait à partir du schéma de stockage utilisé + par les fournisseurs d'authentification de type digest.
+ +Si la directive AuthBasicUseDigestAlgorithm est
+ définie à la valeur MD5, le mot de passe d'un
+ utilisateur dans le cas de l'authentification basique sera vérifié
+ en utilisant le même format de chiffrement que dans le cas de
+ l'authentification de type digest. Tout d'abord, une chaîne
+ comportant le nom d'utilisateur, le domaine de protection (realm) et
+ le mot de passe est générée sous forme de condensé (hash) en
+ utilisant l'algorithme MD5 ; puis le nom d'utilisateur et cette
+ chaîne chiffrée sont transmis aux fournisseurs spécifiés via la
+ directive AuthBasicProvider comme si la
+ directive AuthType
+ était définie à Digest et si l'authentification de type
+ Digest était utilisée.
+
Grâce à cette directive, un site peut basculer d'une + authentification de type digest à basique sans devoir changer les + mots de passe des utilisateurs.
+ +AuthBasicUseDigestAlgorithm
+ est définie à MD5. L'utilisation d'un autre
+ fournisseur provoquera un message d'erreur et le client se verra
+ refuser l'accès.Serveur HTTP Apache Version 2.4
+| Description: | Authentification utilisateur utilisant les condensés +MD5 |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | auth_digest_module |
| Fichier Source: | mod_auth_digest.c |
Ce module implémente l'authentification HTTP basée sur les
+ condensés MD5 (RFC2617), et
+ fournit une alternative à mod_auth_basic en
+ ne transmettant plus le mot de passe en clair. Cependant, cela ne
+ suffit pas pour améliorer la sécurité de manière significative par
+ rapport à l'authentification basique. En outre, le stockage du mot
+ de passe sur le serveur est encore moins sûr dans le cas
+ d'une authentification à base de condensé que dans le cas d'une
+ authentification basique. C'est pourquoi l'utilisation de
+ l'authentification basique associée à un chiffrement de la connexion
+ via mod_ssl constitue une bien meilleure
+ alternative.
AuthDigestAlgorithm AuthDigestDomain AuthDigestNonceLifetime AuthDigestProvider AuthDigestQop AuthDigestShmemSizePour utiliser l'authentification à base de condensés MD5, vous
+ devez simplement remplacer AuthType Basic et AuthBasicProvider respectivement
+ par AuthType Digest et AuthDigestProvider lorsque vous
+ configurez l'authentification, puis ajouter une directive AuthDigestDomain contenant au
+ moins la(les) URI(s) racine(s) de la zone à protéger.
On peut créer les fichiers utilisateur appropriés (au format
+ texte) à l'aide de l'outil htdigest.
<Location "/private/"> + AuthType Digest + AuthName "private area" + AuthDigestDomain "/private/" "http://mirror.my.dom/private2/" + + AuthDigestProvider file + AuthUserFile "/web/auth/.digest_pw" + Require valid-user +</Location>+
L'authentification à base de condensé a été conçue pour améliorer
+ la sécurité par rapport à l'authentification basique, mais il
+ s'avère que ce but n'a pas été atteint. Un attaquant de type
+ "man-in-the-middle" peut facilement forcer le navigateur à revenir à
+ une authentification basique. Même une oreille indiscrète passive
+ peut retrouver le mot de passe par force brute avec les moyens
+ modernes, car l'algorithme de hashage utilisé par l'authentification
+ à base de condensé est trop rapide. Autre problème, le stockage des
+ mots de passe sur le serveur n'est pas sûr. Le contenu d'un fichier
+ htdigest volé peut être utilisé directement pour l'authentification
+ à base de condensé. Il est donc fortement recommandé d'utiliser
+ mod_ssl pour chiffrer la connexion.
mod_auth_digest ne fonctionne correctement que
+ sur les plates-formes où APR supporte la mémoire partagée.
| Description: | Sélectionne l'algorithme utilisé pour calculer les +condensés du défit et de sa réponse |
|---|---|
| Syntaxe: | AuthDigestAlgorithm MD5|MD5-sess |
| Défaut: | AuthDigestAlgorithm MD5 |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_auth_digest |
La directive AuthDigestAlgorithm permet de
+ sélectionner l'algorithme utilisé pour calculer les condensés du
+ défit et de sa réponse.
MD5-sess n'est pas encore correctement implémenté.
+ | Description: | Les URIs qui se trouvent dans le même espace de protection +concernant l'authentification à base de condensés |
|---|---|
| Syntaxe: | AuthDigestDomain URI [URI] ... |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_auth_digest |
La directive AuthDigestDomain vous permet
+ de spécifier un ou plusieurs URIs se trouvant dans le même
+ espace de protection (c'est à dire utilisant le même utilisateur/mot
+ de passe et se trouvant dans le même domaine). Les URIs spécifiés
+ sont des préfixes ; le client doit savoir que tous les URIs situés
+ sous ces préfixes seront protégés par le même utilisateur/mot de
+ passe. Les URIs peuvent être soit des URIs absolus (c'est à dire
+ avec protocole, nom serveur, port, etc...), soit des URIs
+ relatifs.
Cette directive doit toujours être présente et contenir au moins + le(s) URI(s) racine(s) pour cet espace. Dans le cas contraire, le + client va envoyer un en-tête d'autorisation avec chaque + requête à destination de ce serveur.
+ +Les URIs spécifiés peuvent aussi référencer différents serveurs, + auquel cas les clients (qui sont à même de le comprendre) vont + partager l'utilisateur/mot de passe entre plusieurs serveurs sans le + demander à l'utilisateur à chaque fois.
+ +| Description: | Durée de validité du nombre à valeur unique du +serveur (nonce) |
|---|---|
| Syntaxe: | AuthDigestNonceLifetime secondes |
| Défaut: | AuthDigestNonceLifetime 300 |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_auth_digest |
La directive AuthDigestNonceLifetime
+ permet de contrôler la durée de validité du nombre à valeur unique
+ du serveur (nonce). Lorsque le client contacte le serveur en
+ utilisant un nonce dont la validité a expiré, le serveur renvoie un
+ code d'erreur 401 avec stale=true. Si
+ secondes est supérieur à 0, il spécifie la durée de
+ validité du nonce ; il est en général déconseillé d'affecter à cet
+ argument une valeur inférieure à 10 secondes. Si
+ secondes est inférieur à 0, le nonce n'expire jamais.
+
+
| Description: | Définit le(s) fournisseurs(s) d'authentification pour la +zone du site web concernée |
|---|---|
| Syntaxe: | AuthDigestProvider nom fournisseur
+[nom fournisseur] ... |
| Défaut: | AuthDigestProvider file |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_auth_digest |
La directive AuthDigestProvider permet de
+ définir quel fournisseur d'authentification sera utilisé pour
+ authentifier les utilisateurs pour la zone du site web concernée.
+ Assurez-vous que le module implémentant le fournisseur
+ d'authentification choisi soit bien présent dans le serveur. Le
+ fournisseur par défaut file est implémenté par le
+ module mod_authn_file.
Voir mod_authn_dbm,
+ mod_authn_file, mod_authn_dbd et
+ mod_authn_socache
+ pour la liste des fournisseurs disponibles.
| Description: | Détermine le niveau de protection fourni par +l'authentification à base de condensé |
|---|---|
| Syntaxe: | AuthDigestQop none|auth|auth-int [auth|auth-int] |
| Défaut: | AuthDigestQop auth |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_auth_digest |
La directive AuthDigestQop permet de
+ définir le niveau de protection fourni. auth
+ ne fournit que l'authentification (nom utilisateur/mot de passe) ;
+ auth-int fournit l'authentification plus un contrôle
+ d'intégrité (un condensé MD5 de l'entité est aussi calculé et
+ vérifié) ; avec none, le module va utiliser l'ancien
+ algorithme de condensés RFC-2069 (qui n'effectue pas de contrôle
+ d'intégrité). On peut spécifier à la fois auth et
+ auth-int, auquel cas c'est le navigateur qui va choisir
+ lequel des deux utiliser. none ne doit être utilisé que
+ dans le cas où le navigateur ne serait pas à même (pour une raison
+ ou pour une autre) de relever le défit qu'il recevrait si un autre
+ niveau de protection était défini.
auth-int n'est pas encore implémenté.
+ | Description: | La quantité de mémoire partagée à allouer afin de conserver +les informations à propos des clients |
|---|---|
| Syntaxe: | AuthDigestShmemSize taille |
| Défaut: | AuthDigestShmemSize 1000 |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_auth_digest |
La directive AuthDigestShmemSize permet de
+ définir la quantité de mémoire partagée à allouer au démarrage du
+ serveur afin de conserver les informations à propos des clients.
+ Notez que le segment de mémoire partagée ne peut pas être défini à
+ une taille inférieure à l'espace nécessaire pour conserver les
+ informations à propos d'un client. Cette valeur dépend de
+ votre système. Si vous voulez en déterminer la valeur exacte, vous
+ pouvez simplement définir AuthDigestShmemSize
+ à 0 et consulter le message d'erreur que renverra le
+ serveur lorsqu'on essaiera de le démarrer.
L'argument size s'exprime par défaut en octets, mais
+ vous pouvez suffixer le nombre par un K ou un
+ M pour spécifier respectivement des KiloOctets ou des
+ MégaOctets. Par exemple, les directives qui suivent sont toutes
+ équivalentes :
AuthDigestShmemSize 1048576 +AuthDigestShmemSize 1024K +AuthDigestShmemSize 1M+ + +
Serveur HTTP Apache Version 2.4
+| Description: | Authentification à l'aide d'un formulaire |
|---|---|
| Statut: | Base |
| Identificateur de Module: | auth_form_module |
| Fichier Source: | mod_auth_form.c |
| Compatibilité: | Disponible à partir d'Apache 2.3 |
L'authentification à base de formulaire dépend des modules
+ mod_session qui utilisent les cookies HTTP, et en
+ tant que tels s'exposent à des attaques de type Cross Site
+ Scripting, ou risquent de divulguer des informations à caractère
+ privé aux clients. Assurez-vous que ces risques ont bien été pris
+ en compte avant d'activer les sessions sur votre serveur.
Ce module permet de restreindre l'accès en recherchant les + utilisateurs dans les fournisseurs spécifiés à l'aide d'un + formulaire de connexion HTML. Les formulaires HTML requièrent + davantage de configuration que les méthodes d'authentification + alternatives, mais ils peuvent s'avérer beaucoup plus conviviaux + pour les utilisateurs. +
+ +L'authentification HTTP de base est fournie par le module
+ mod_auth_basic, et l'authentification HTTP à base
+ de condensé par le module mod_auth_digest. Le
+ module mod_auth_form doit être utilisé avec au
+ moins un module d'authentification du style
+ mod_authn_file et un module d'autorisation comme
+ mod_authz_user.
Lorsque l'utilisateur a été authentifié avec succès, ses
+ informations de connexion sont stockés dans une session fournie par
+ le module mod_session.
+
Configuration de base Page de connexion dédiée Connexion à la volée Connexion à la volée avec
+ conservation du contenu Déconnexion Noms d'utilisateurs et mots de
+ passe AuthFormAuthoritative AuthFormBody AuthFormDisableNoStore AuthFormFakeBasicAuth AuthFormLocation AuthFormLoginRequiredLocation AuthFormLoginSuccessLocation AuthFormLogoutLocation AuthFormMethod AuthFormMimetype AuthFormPassword AuthFormProvider AuthFormSitePassphrase AuthFormSize AuthFormUsernamePour protéger une URL particulière avec le module
+ mod_auth_form, vous devez déterminer l'endroit où
+ vous allez stocker votre session, ainsi que la méthode
+ d'authentification. Dans cet exemple simple, les informations de
+ connexion sont stockées dans une session à l'aide du module
+ mod_session_cookie, et l'authentification utilise
+ un fichier en s'appuyant sur le module
+ mod_authn_file. Si l'authentification échoue,
+ l'utilisateur dera redirigé vers la page du formulaire de
+ connexion.
<Location "/admin"> + AuthFormProvider file + AuthUserFile "conf/passwd" + AuthType form + AuthName "/admin" + AuthFormLoginRequiredLocation "http://example.com/login.html" + + Session On + SessionCookieName session path=/ + + Require valid-user +</Location>+
L'authentification mod_auth_form est activée
+ en affectant la valeur form à la directive AuthType. Les directives
+ AuthFormProvider et
+ AuthUserFile
+ spécifient que les noms d'utilisateurs et mots de passe seront
+ vérifiés en utilisant le fichier choisi.
Les directives Session et SessionCookieName créent une
+ session chiffrée stockée dans un cookie HTTP au niveau
+ du navigateur. Pour plus d'informations à propos des différentes
+ options de configuration des sessions, reportez-vous à la
+ documentation du module mod_session.
Vous pouvez éventuellement ajouter une directive SessionCryptoPassphrase pour créer
+ un cookie de session chiffré. Pour utiliser cette directive, le module
+ mod_session_crypto doit avoir été préalablement chargé.
Dans l'exemple simple ci-dessus, une URL a été protégée par
+ mod_auth_form, mais on doit maintenant fournir
+ à l'utilisateur un moyen d'entrer un nom et un mot de passe. À cet
+ effet, on peut soit écrire une page de connexion indépendante
+ dédiée, soit inclure le formulaire de connexion dans la page
+ courante.
Le formulaire de connexion peut être contenu dans une page + indépendante, ou être inclus dans la page courante.
+ +Lorsque la connexion s'effectue à partir d'une page
+ indépendante et si la tentative d'authentification échoue,
+ l'utilisateur doit être redirigé vers un formulaire de connexion,
+ créé à cet effet sur le site web, en utilisant la directive
+ AuthFormLoginRequiredLocation.
+ En général, la page de connexion contiendra un formulaire HTML
+ demandant à l'utilisateur de fournir un nom et un mot de passe.
<form method="POST" action="/dologin.html"> + Username: <input type="text" name="httpd_username" value="" /> + Password: <input type="password" name="httpd_password" value="" /> + <input type="submit" name="login" value="Login" /> +</form>+
La partie où s'effectue la connexion proprement dite est + traitée par le gestionnaire form-login-handler. + L'action de ce formulaire doit pointer vers ce gestionnaire, ce + que l'on configure dans Apache httpd comme suit :
+ +<Location "/dologin.html"> + SetHandler form-login-handler + AuthFormLoginRequiredLocation "http://example.com/login.html" + AuthFormLoginSuccessLocation "http://example.com/admin/index.html" + AuthFormProvider file + AuthUserFile "conf/passwd" + AuthType form + AuthName /admin + Session On + SessionCookieName session path=/ + SessionCryptoPassphrase secret +</Location>+
L'URL spécifiée par la directive
+ AuthFormLoginRequiredLocation
+ référencera en général une page expliquant à l'utilisateur que sa
+ tentative de connexion a échoué, et qu'il doit la renouveler. La
+ directive AuthFormLoginSuccessLocation
+ spécifie l'URL vers laquelle l'utilisateur doit être redirigé s'il
+ s'est authentifié avec succès.
Alternativement, l'URL vers laquelle doit être redirigé + l'utilisateur s'il s'est authentifié avec succès peut être + intégrée dans le formulaire de connexion, comme dans l'exemple + ci-dessous. Il en découle que le même gestionnaire + form-login-handler pourra être utilisé pour différentes + zones du site web.
+ +<form method="POST" action="/dologin.html"> + Username: <input type="text" name="httpd_username" value="" /> + Password: <input type="password" name="httpd_password" value="" /> + <input type="submit" name="login" value="Login" /> + <input type="hidden" name="httpd_location" value="http://example.com/success.html" /> +</form>+
Il existe un risque, dans certaines circonstances, que le + formulaire de connexion configuré pour une connexion à la volée + soit soumis plusieurs fois, révélant de ce fait les paramètres + de connexion à l'application sous-jacente. L'administrateur doit + s'assurer que cette dernière est correctement sécurisée afin + d'éviter les éventuels abus. En cas de doute, utilisez une page + de connexion indépendante dédiée.
+Comme alternative à la page de connexion dédiée pour un site
+ web, il est possible de configurer mod_auth_form
+ pour authentifier les utilisateurs à la volée, sans les rediriger
+ vers une autre page, ce qui permet de conserver l'état de la page
+ courante au cours de la tentative de connexion. Ceci peut s'avérer
+ utile dans le cas d'une session limitée dans le temps, si le délai
+ de la session a expiré pendant la requête de l'utilisateur. Ce
+ dernier peut alors se réauthentifier à la même place, et
+ poursuivre son activité à partir du point où il en était resté.
Si un utilisateur non authentifié tente d'accéder à une page
+ protégée par mod_auth_form, et si ce dernier
+ n'est pas configuré avec une directive AuthFormLoginRequiredLocation,
+ un code de statut HTTP_UNAUTHORIZED est renvoyé vers le
+ navigateur, indiquant à l'utilisateur qu'il n'est pas autorisé à
+ accéder à cette page.
Pour configurer l'authentification à la volée, l'administrateur + remplace le message d'erreur renvoyé par le code de statut + HTTP_UNAUTHORIZED par un message d'erreur personnalisé + contenant le formulaire de connexion comme suit :
+ +AuthFormProvider file +ErrorDocument 401 "/login.shtml" +AuthUserFile "conf/passwd" +AuthType form +AuthName realm +AuthFormLoginRequiredLocation "http://example.com/login.html" +Session On +SessionCookieName session path=/+
La page du message d'erreur doit contenir un formulaire de + connexion dont la propriété action est vide, comme dans l'exemple + ci-dessous. Ceci a pour effet de soumettre le formulaire à l'URL + protégée originale, cette dernière n'ayant pas besoin d'être + connue de la page en cours.
+ +<form method="POST" action=""> + Username: <input type="text" name="httpd_username" value="" /> + Password: <input type="password" name="httpd_password" value="" /> + <input type="submit" name="login" value="Login" /> +</form>+
Lorsque l'utilisateur final a entré ses informations de
+ connexion, le formulaire effectue une requête HTTP POST pour l'URL
+ originale protégée par mot de passe.
+ mod_auth_form va alors intercepter cette requête
+ POST, et dans le cas où des champs HTML Utilisateur et Mot de
+ passe corrects sont présents, l'utilisateur sera connecté, et
+ l'URL originale protégée par mot de passe lui sera retournée en
+ tant que requête GET.
Il existe une limite à la technique de connexion à la volée + décrite ci-dessus ; si un formulaire HTML POST entraîne une + demande d'authentification ou de réauthentification, le contenu du + formulaire original envoyé par le navigateur sera perdu. Cela peut + s'avérer plus ou moins gênant pour l'utilisateur final selon la + fonction du site web.
+ +Comme solution à ce problème, mod_auth_form
+ permet d'intégrer la méthode et le contenu de la requête originale
+ dans le formulaire de connexion. Si l'authentification réussit,
+ Apache httpd pourra refaire une tentative avec la méthode et le contenu
+ originaux, tout en conservant l'état de la requête originale.
Pour mettre en oeuvre la conservation du contenu, vous devez + ajouter trois champs supplémentaires au formulaire de connexion + comme dans l'exemple suivant :
+ +<form method="POST" action=""> + Username: <input type="text" name="httpd_username" value="" /> + Password: <input type="password" name="httpd_password" value="" /> + <input type="submit" name="login" value="Login" /> ++
<input type="hidden" name="httpd_method" value="POST" /> + <input type="hidden" name="httpd_mimetype" value="application/x-www-form-urlencoded" /> + <input type="hidden" name="httpd_body" value="name1=value1&name2=value2" />
+</form>
La manière dont la méthode, le type MIME et le contenu de la + requête originale seront intégrés dans le formulaire de connexion + vont dépendre de la plate-forme et de la technologie utilisées au + sein du site web. +
+ +Une option consiste à utiliser le module
+ mod_include en association avec la directive
+ KeptBodySize, ainsi
+ qu'un script CGI adapté pour intégrer les variables dans le
+ formulaire.
Une autre option consiste à présenter le formulaire de + connexion en utilisant un script CGI ou une autre technologie + dynamique.
+ +AuthFormProvider file + ErrorDocument 401 "/cgi-bin/login.cgi" + ...+
Pour permettre à un utilisateur de se déconnecter d'une session + particulière, vous devez configurer une page pour qu'elle soit + traitée par le gestionnaire form-logout-handler. Tout + accès à cette URL va entraîner la suppression de l'Utilisateur et + du Mot de passe de la session courante, ce qui aura pour effet de + déconnecter l'utilisateur.
+ +Vous pouvez spécifier une URL vers laquelle le navigateur sera
+ redirigé en cas de déconnection réussie, en définissant la
+ directive AuthFormLogoutLocation. Cette
+ URL devra expliquer à l'utilisateur qu'il a été déconnecté, et lui
+ donner la possibilité de se connecter à nouveau.
SetHandler form-logout-handler +AuthName realm +AuthFormLogoutLocation "http://example.com/loggedout.html" +Session On +SessionCookieName session path=/+
Notez que la déconnexion d'un utilisateur ne supprime pas la
+ session ; elle supprime seulement l'utilisateur et le mot de passe
+ de la session. Si la session qui en résulte est vide, elle sera
+ probablement supprimée, mais ce n'est pas garanti. Si vous voulez
+ être sûr que la session sera supprimée, affectez une valeur faible
+ à la directive SessionMaxAge, par exemple 1
+ (affecter à cette directive la valeur zéro signifie une session
+ sans limite d'âge).
+
SetHandler form-logout-handler +AuthFormLogoutLocation "http://example.com/loggedout.html" +Session On +SessionMaxAge 1 +SessionCookieName session path=/+
Notez que la soumission d'un formulaire implique l'encodage URL + (URLEncoding) des données du formulaire, ici le nom d'utilisateur et + le mot de passe. Vous devez donc choisir des noms d'utilisateurs et + mots de passe qui ne contiennent pas de caractères susceptibles + d'être encodés URL lors de la soumission du formulaire, sous peine + d'obtenir des résultats inattendus.
+| Description: | Détermine si l'autorisation et l'authentification sont confiés à +des modules de plus bas niveau |
|---|---|
| Syntaxe: | AuthFormAuthoritative On|Off |
| Défaut: | AuthFormAuthoritative On |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_auth_form |
Normalement, chacun des modules d'autorisation spécifiés par la
+ directive AuthFormProvider va tenter de
+ vérifier l'identité de l'utilisateur, et si ce dernier n'est trouvé
+ dans aucun fournisseur, l'accès sera refusé. En définissant
+ explicitement la directive
+ AuthFormAuthoritative à Off on
+ confie les processus d'authentification et d'autorisation à des
+ modules ne s'appuyant pas sur des fournisseurs, si aucun
+ identifiant utilisateur ou aucune règle ne
+ correspond à l'identifiant utilisateur fourni. Ceci ne peut s'avérer
+ nécessaire que si l'on combine mod_auth_form avec
+ des modules tiers qui ne se configurent pas avec la directive
+ AuthFormProvider.
+ Lorsqu'on utilise de tels modules, la chronologie du processus est
+ déterminée dans leur code source, et n'est pas configurable.
| Description: | Le nom du champ de formulaire contenant le corps de la +requête à effectuer en cas de connexion réussie |
|---|---|
| Syntaxe: | AuthFormBody nom du champ |
| Défaut: | httpd_body |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP Apache |
La directive AuthFormBody
+ spécifie le nom du champ HTML qui, s'il existe, contiendra le corps
+ de la requête à effectuer en cas de connexion réussie.
En ajoutant au formulaire les champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, un site web sera en
+ mesure de relancer une requête qui a été éventuellement interrompue
+ par l'écran de connexion, ou par l'expiration d'un délai de
+ session.
| Description: | Désactive l'en-tête CacheControl no-store sur la page de +connexion |
|---|---|
| Syntaxe: | AuthFormDisableNoStore On|Off |
| Défaut: | AuthFormDisableNoStore Off |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP Apache |
Le drapeau AuthFormDisableNoStore supprime
+ l'envoi d'un en-tête Cache-Control no-store lorsqu'une
+ page avec code d'erreur 401 est renvoyée, si l'utilisateur n'est pas
+ encore connecté. Avec cette en-tête, il est plus difficile pour une
+ application ecmascript de resoumettre un formulaire de connexion, et
+ ainsi révéler le nom d'utilisateur et le mot de passe à
+ l'application sous-jacente. Vous devez être conscient des risques
+ encourus si vous le désactivez.
| Description: | Simule une en-tête d'authentification de base |
|---|---|
| Syntaxe: | AuthFormFakeBasicAuth On|Off |
| Défaut: | AuthFormFakeBasicAuth Off |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP Apache |
Le drapeau AuthFormFakeBasicAuth
+ détermine si une en-tête d'Authentification de base
+ sera ajoutée aux en-têtes de la requête. On peut utiliser cette
+ méthode pour présenter le nom d'utilisateur et le mot de passe à
+ l'application sous-jacente, sans que cette dernière ait besoin de
+ connaître la manière dont le processus de connexion a été mené à
+ bien.
| Description: | Le nom du champ de formulaire qui contiendra l'URL vers +laquelle l'utilisateur sera redirigé en cas de connexion +réussie |
|---|---|
| Syntaxe: | AuthFormLocation nom du champ |
| Défaut: | httpd_location |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP Apache |
La directive AuthFormLocation
+ spécifie le nom du champ HTML qui, s'il existe, contiendra l'URL
+ vers laquelle rediriger le navigateur en cas de connexion
+ réussie.
| Description: | L'URL de la page vers laquelle on doit être redirigé si une +authentification est requise |
|---|---|
| Syntaxe: | AuthFormLoginRequiredLocation url |
| Défaut: | none |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP +Apache. L'interprétation des expressions rationnelles est supportée +depuis la version 2.4.4. |
La directive AuthFormLoginRequiredLocation
+ spécifie l'URL vers laquelle l'utilisateur devra être
+ redirigé s'il n'est pas autorisé à accéder à une page. Sa valeur est
+ interprétée via l'interpréteur ap_expr
+ avant d'être envoyée au client. Par défaut,
+ si un utilisateur n'est pas autorisé à accéder à une page, le code
+ de réponse HTTP HTTP_UNAUTHORIZED est renvoyé avec la
+ page spécifiée par la directive ErrorDocument. La directive AuthFormLoginRequiredLocation
+ permet de remplacer cette valeur par défaut.
Vous pouvez utiliser cette directive si vous voulez présenter une + page de connexion personnalisée à vos utilisateurs.
+ + +| Description: | L'URL de la page vers laquelle on doit être redirigé en cas +de connexion réussie |
|---|---|
| Syntaxe: | AuthFormLoginSuccessLocation url |
| Défaut: | none |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP +Apache. L'interprétation des expressions rationnelles est supportée +depuis la version 2.4.4. |
La directive AuthFormLoginSuccessLocation
+ spécifie l'URL vers laquelle l'utilisateur doit être
+ redirigé en cas de connexion réussie. Sa valeur est
+ interprétée via l'interpréteur ap_expr
+ avant d'être envoyée au client. L'effet de cette directive
+ peut être annulé si l'on a défini un champ de formulaire contenant
+ une autre URL à l'aide de la directive AuthFormLocation.
Vous pouvez utiliser cette directive si vous possédez une URL de + connexion personnalisée, et si vous n'avez pas intégré la page de + destination dans le formulaire de connexion.
+ + +| Description: | L'URL vers laquelle un utilisateur devra être redirigé +après s'être déconnecté |
|---|---|
| Syntaxe: | AuthFormLogoutLocation uri |
| Défaut: | none |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP +Apache. L'interprétation des expressions rationnelles est supportée +depuis la version 2.4.4. |
La directive AuthFormLogoutLocation
+ spécifie l'URL de la page du serveur vers laquelle l'utilisateur
+ devra être redirigé s'il se déconnecte. Sa valeur est
+ interprétée via l'interpréteur ap_expr
+ avant d'être envoyée au client.
Lorsqu'un accès est tenté sur un URI traité par le gestionnaire
+ form-logout-handler, la page spécifiée par cette
+ directive sera présentée à l'utilisateur final. Par exemple :
<Location "/logout"> + SetHandler form-logout-handler + AuthFormLogoutLocation "http://example.com/loggedout.html" + Session on + #... +</Location>+
Si un utilisateur tente d'accéder à l'URI /logout/, il + sera déconnecté, et la page /loggedout.html lui sera + présentée. Assurez-vous que la page loggedout.html n'est + pas protégée par mot de passe, car dans le cas contraire, elle ne + serait pas affichée.
+ + +| Description: | Le nom du champ de formulaire contenant la méthode de la +requête à effectuer en cas de connexion réussie |
|---|---|
| Syntaxe: | AuthFormMethod nom du champ |
| Défaut: | httpd_method |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP Apache |
La directive AuthFormMethod
+ spécifie le nom du champ HTML qui, s'il existe, contiendra le type
+ MIME de la requête à effectuer en cas de connexion réussie.
En ajoutant au formulaire les champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, un site web sera en
+ mesure de relancer une requête qui a été éventuellement interrompue
+ par l'écran de connexion, ou par l'expiration d'un délai de
+ session.
| Description: | Le nom du champ de formulaire contenant le type MIME du +corps de la requête à effectuer en cas de connexion +réussie |
|---|---|
| Syntaxe: | AuthFormMimetype nom du champ |
| Défaut: | httpd_mimetype |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP Apache |
La directive AuthFormMimetype
+ spécifie le nom du champ HTML qui, s'il existe, contiendra le type
+ MIME de la requête à effectuer en cas de connexion réussie.
En ajoutant au formulaire les champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, un site web sera en
+ mesure de relancer une requête qui a été éventuellement interrompue
+ par l'écran de connexion, ou par l'expiration d'un délai de
+ session.
| Description: | Le nom du champ de formulaire qui contient le mot de passe +de connexion |
|---|---|
| Syntaxe: | AuthFormPassword nom du champ |
| Défaut: | httpd_password |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP Apache |
La directive AuthFormPassword permet de
+ spécifier le nom du champ HTML qui, s'il existe, contiendra le mot
+ de passe qui sera utilisé pour la connexion.
| Description: | Définit le(s) fournisseur(s) d'authentification pour la +zone concernée |
|---|---|
| Syntaxe: | AuthFormProvider nom fournisseur
+[nom fournisseur] ... |
| Défaut: | AuthFormProvider file |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_auth_form |
La directive AuthFormProvider permet de
+ définir quel fournisseur sera utilisé pour authentifier les
+ utilisateurs pour la zone concernée. Le fournisseur par défaut
+ file est implémenté par le module
+ mod_authn_file. Assurez-vous que le fournisseur
+ choisi soit bien présent dans le serveur.
<Location "/secure"> + AuthType form + AuthName "private area" + AuthFormProvider dbm + AuthDBMType SDBM + AuthDBMUserFile "/www/etc/dbmpasswd" + Require valid-user + #... +</Location>+
Les différents fournisseurs sont implémentés par les modules
+ mod_authn_dbm, mod_authn_file,
+ mod_authn_dbd et
+ mod_authnz_ldap.
| Description: | Court-circuite l'authentification pour les sites à fort +trafic |
|---|---|
| Syntaxe: | AuthFormSitePassphrase secret |
| Défaut: | none |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP Apache |
La directive AuthFormSitePassphrase
+ spécifie un mot de passe qui, s'il est présent dans la session
+ utilisateur, indique à Apache httpd de court-circuiter l'authentification
+ pour l'URL considérée. On peut l'utiliser dans le cas de sites web à
+ fort trafic afin de réduire la charge induite sur l'infrastructure
+ d'authentification.
On peut insérer le mot de passe dans une session utilisateur en + ajoutant cette directive à la configuration concernant le + gestionnaire form-login-handler. Le gestionnaire + form-login-handler, quant à lui, effectuera toujours les + vérifications d'authentification, qu'un mot de passe soit spécifié + ou non.
+ +Si la session est présentée à l'utilisateur à l'aide du module
+ mod_session_cookie, et si la session n'est pas
+ protégée par le module mod_session_crypto, le mot
+ de passe peut faire l'objet d'une attaque de type dictionnaire.
+ Quelle que soit la configuration de la session, assurez-vous que
+ cette directive n'est pas utilisée dans un espace d'URLs contenant
+ des données privées, ou à partir desquelles des transactions
+ sensibles pourraient être menées. En tout état de cause, vous
+ devez être conscient des risques encourus avant de l'utiliser.
| Description: | La taille maximale en octets du formulaire dont seront +extraites les informations de connexion |
|---|---|
| Syntaxe: | AuthFormSize taille |
| Défaut: | 8192 |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP Apache |
La directive AuthFormSize spécifie
+ la taille maximale du corps de la requête qui sera utilisée pour
+ trouver le formulaire de connexion.
Si une requête de connexion entrante possède une taille
+ supérieure à cette valeur, elle sera rejetée avec le code de réponse
+ HTTP HTTP_REQUEST_TOO_LARGE.
Si vous avez ajouté au formulaire des champs décrits dans AuthFormMethod, AuthFormMimetype et AuthFormBody, il est recommandé
+ de définir cette directive à une valeur similaire à celle de la
+ directive KeptBodySize.
| Description: | Le nom du champ de formulaire qui contient le nom de +connexion |
|---|---|
| Syntaxe: | AuthFormUsername nom du champ |
| Défaut: | httpd_username |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_auth_form |
| Compatibilité: | Disponible depuis la version 2.3.3 du serveur HTTP Apache |
La directive AuthFormUsername permet de
+ spécifier le nom du champ HTML qui, s'il existe, contiendra le nom
+ d'utilisateur qui sera utilisé pour la connexion.
Serveur HTTP Apache Version 2.4
+| Description: | Permet un accès "anonyme" à des zones +protégées |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | authn_anon_module |
| Fichier Source: | mod_authn_anon.c |
| Compatibilité: | Disponible depuis la version 2.1 d'Apache |
Ce module permet aux frontaux d'authentification comme
+ mod_auth_basic d'authentifier les utilisateurs
+ à la manière des sites FTP anonymes, c'est à dire
+ en fournissant l'identifiant utilisateur spécial 'anonymous' et
+ l'adresse email comme mot de passe. Ces adresses email peuvent être
+ journalisées.
En combinaison avec d'autres méthodes de contrôle d'accès (base + de données), ce module permet d'effectuer un véritable suivi des + utilisateurs et une personnalisation de leurs accès en fonction de + leur profil, tout en conservant l'accessibilité du site aux + utilisateurs 'non enregistrés'. Un avantage du suivi des + utilisateurs basé sur l'authentification réside dans le fait qu'il + est, à l'opposé des cookies magiques et des drôles d'URLs avec + préfixes ou suffixes, entièrement indépendant du navigateur et qu'il + permet de partager des URLs entre plusieurs utilisateurs.
+ +Si l'on utilise le module mod_auth_basic, le
+ module mod_authn_anon est invoqué en affectant la
+ valeur anon à la directive AuthBasicProvider.
Exemple Anonymous Anonymous_LogEmail Anonymous_MustGiveEmail Anonymous_NoUserID Anonymous_VerifyEmailL'exemple ci-dessous présente un exemple de combinaison avec + l'authentification à base de fichier htpasswd "normale", et permet + la connexion d'utilisateurs en tant qu'invités avec les propriétés + suivantes :
+ +Anonymous_NoUserID)Anonymous_MustGiveEmail)Anonymous_VerifyEmail)anonymous, guest, www, test ou welcome, et la
+ vérification n'est pas sensible à la casse.
+ (Anonymous)Anonymous_LogEmail)<Directory "/var/www/html/private"> + AuthName "Use 'anonymous' & Email address for guest entry" + AuthType Basic + AuthBasicProvider file anon + AuthUserFile "/path/to/your/.htpasswd" + + Anonymous_NoUserID off + Anonymous_MustGiveEmail on + Anonymous_VerifyEmail on + Anonymous_LogEmail on + Anonymous anonymous guest www test welcome + + Require valid-user +</Directory>+
| Description: | Définit la liste des identifiants utilisateur autorisés à +accéder sans vérification du mot de passe |
|---|---|
| Syntaxe: | Anonymous utilisateur [utilisateur]
+... |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authn_anon |
Une liste d'un ou plusieurs identifiants utilisateur spéciaux + autorisés à accéder sans vérification du mot de passe. Les + identifiants doivent être séparés par un espace. Pour spécifier un + identifiant contenant un espace, on peut utiliser les guillemets ' + ou ", ou le caractère d'échappement \.
+ +Veuillez noter que la vérification n'est pas sensible à
+ la casse.
+ Il est fortement conseillé d'intégrer l'utilisateur spécial
+ 'anonymous' dans la liste des identifiants.
Anonymous anonymous "Not Registered" "I don't know"+
Dans cet exemple, l'utilisateur peut accéder au site sans + vérification du mot de passe en utilisant l'identifiant "anonymous", + "Not Registered", "I Don't Know" ou encore "AnonyMous".
+ +Depuis Apache 2.1, il est possible de remplacer la liste des
+ identifiants autorisés par le caractère "*", ce qui
+ permet d'utiliser n'importe quel identifiant pour pouvoir
+ accéder au site.
| Description: | Détermine si le mot de passe fourni sera enregistré dans le +journal des erreurs |
|---|---|
| Syntaxe: | Anonymous_LogEmail On|Off |
| Défaut: | Anonymous_LogEmail On |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authn_anon |
Lorsque cette directive est définie à On, valeur
+ par défaut, le 'mot de passe' fourni (censé contenir une adresse
+ email valide) est enregistré dans le journal des erreurs.
| Description: | Détermine si l'abscence de mot de passe est +autorisée |
|---|---|
| Syntaxe: | Anonymous_MustGiveEmail On|Off |
| Défaut: | Anonymous_MustGiveEmail On |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authn_anon |
Détermine si l'utilisateur doit spécifier une adresse email comme
+ mot de passe. Lorsque cette directive est définie à On,
+ l'abscence de mot de passe est interdite.
| Description: | Détermine si le champ identifiant peut être +vide |
|---|---|
| Syntaxe: | Anonymous_NoUserID On|Off |
| Défaut: | Anonymous_NoUserID Off |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authn_anon |
Lorsque cette directive est définie à On, les
+ utilisateurs peuvent laisser le champ identifiant vide (et peut-être
+ aussi le champ mot de passe selon la définition de la directive
+ Anonymous_MustGiveEmail). Ceci
+ peut s'avérer très utile pour les utilisateurs de MS-Explorer qui
+ n'ont pour seule possibilité que d'appuyer sur Entrée ou de cliquer
+ directement sur le bouton OK, ce qui semble être une réaction
+ naturelle.
| Description: | Détermine s'il faut vérifier que le format de l'adresse +email fournie comme mot de passe est correct |
|---|---|
| Syntaxe: | Anonymous_VerifyEmail On|Off |
| Défaut: | Anonymous_VerifyEmail Off |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authn_anon |
Lorsque cette directive est définie à On, Apache
+ vérifie que le 'mot de passe' entré contient au moins un '@' et un
+ '.' afin d'inciter les utilisateurs à fournir des adresses email
+ valides (voir ci-dessus la directive Anonymous_LogEmail).
Serveur HTTP Apache Version 2.4
+| Description: | Le noyau de l'authentification |
|---|---|
| Statut: | Base |
| Identificateur de Module: | authn_core_module |
| Fichier Source: | mod_authn_core.c |
| Compatibilité: | Disponible depuis la version 2.3 d'Apache |
Ce module fournit le coeur des fonctionnalités d'authentification
+ permettant d'accorder ou de refuser l'accès à certaines zones du
+ site web. Les directives fournies par le module
+ mod_authn_core sont communes à tous les
+ fournisseurs d'authentification.
AuthName <AuthnProviderAlias> AuthTypeIl est possible de créer des fournisseurs d'authentification
+ étendus dans le fichier de configuration et de leur assigner un
+ alias. Le fournisseur ainsi nommé peut alors être référencé à l'aide
+ des directives AuthBasicProvider ou AuthDigestProvider tout comme
+ un fournisseur d'authentification de base. Outre la possibilité de
+ créer et attribuer un alias à un fournisseur étendu, le même
+ fournisseur d'authentification peut aussi être référencé par
+ plusieurs sections relatives à une zone du site web.
Cet exemple vérifie les mots de passe dans deux fichiers + textes différents.
+ +# Première vérification +<AuthnProviderAlias file file1> + AuthUserFile "/www/conf/passwords1" +</AuthnProviderAlias> + +# Vérification suivante +<AuthnProviderAlias file file2> + AuthUserFile "/www/conf/passwords2" +</AuthnProviderAlias> + +<Directory "/var/web/pages/secure"> + AuthBasicProvider file1 file2 + + AuthType Basic + AuthName "Protected Area" + Require valid-user +</Directory>+
Dans l'exemple ci-dessous, deux fournisseurs + d'authentification ldap sont créés à partir du fournisseur ldap + de base, et se voient attribuer un alias. L'authentification + d'une même zone peut alors être traitée par plusieurs serveurs + ldap :
+ +<AuthnProviderAlias ldap ldap-alias1> + AuthLDAPBindDN cn=youruser,o=ctx + AuthLDAPBindPassword yourpassword + AuthLDAPURL ldap://ldap.host/o=ctx + </AuthnProviderAlias> + <AuthnProviderAlias ldap ldap-other-alias> + AuthLDAPBindDN cn=yourotheruser,o=dev + AuthLDAPBindPassword yourotherpassword + AuthLDAPURL ldap://other.ldap.host/o=dev?cn +</AuthnProviderAlias> + +Alias "/secure" "/webpages/secure" +<Directory "/webpages/secure"> + + AuthBasicProvider ldap-other-alias ldap-alias1 + + AuthType Basic + AuthName LDAP_Protected Place + Require valid-user + # Notez que Require ldap-* ne fonctionnerait pas ici, car + # AuthnProviderAlias ne fournit pas de configuration pour les + # fournisseurs d'autorisation implémentés dans le même module que le + # fournisseur d'authentification. +</Directory>+
| Description: | L'identifiant de l'autorisation à utiliser avec +l'authentification HTTP |
|---|---|
| Syntaxe: | AuthName domaine d'autorisation |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_authn_core |
Cette directive permet de définir l'identifiant d'autorisation
+ pour un répertoire. Cet identifiant est fourni au client de façon à
+ ce qu'il sache quels nom d'utilisateur et mot de passe envoyer.
+ AuthName accepte un seul argument ; s'il
+ contient des espaces, il doit être entouré de guillemets. Pour
+ pouvoir fonctionner, la directive AuthName
+ doit être utilisée en combinaison avec les directives AuthType et Require, ainsi que des
+ directives comme AuthUserFile et AuthGroupFile.
Par exemple :
+ +AuthName "Top Secret"+ + +
La chaîne fournie comme argument à AuthName
+ apparaîtra dans la boîte de dialogue d'authentification pour la
+ plupart des navigateurs.
| Description: | Regroupe un ensemble de directives qui constituent une +extension d'un fournisseur d'authentification de base et lui attribue +l'alias spécifié |
|---|---|
| Syntaxe: | <AuthnProviderAlias alias-fournisseur>
+... </AuthnProviderAlias> |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_authn_core |
Les balises <AuthnProviderAlias> et
+ </AuthnProviderAlias> permettent de regrouper un
+ ensemble de directives d'authentification qui seront référencées par
+ l'alias spécifié à l'aide des directives AuthBasicProvider ou AuthDigestProvider.
| Description: | Type d'authentification utilisateur |
|---|---|
| Syntaxe: | AuthType None|Basic|Digest|Form |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_authn_core |
Cette directive permet de définir le type d'authentification
+ utilisateur pour un répertoire. Les types d'authentification
+ disponibles sont None, Basic (implémenté
+ par mod_auth_basic), Digest
+ (implémenté par mod_auth_digest), et
+ Form (implémenté par
+ mod_auth_form).
Pour mettre en oeuvre l'authentification, vous devez aussi
+ utiliser les directives AuthName et Require. De plus, le serveur
+ doit pouvoir disposer d'un module fournisseur d'authentification
+ comme mod_authn_file et d'un module d'autorisation
+ comme mod_authz_user.
Le type d'authentification None désactive
+ l'authentification. Lorsqu'une authentification est définie, elle
+ est en général héritée par chacune des sections de configuration qui
+ suivent, à moins qu'un autre type d'authentification ne soit
+ spécifié. Si l'on ne souhaite pas mettre en oeuvre
+ d'authentification pour une sous-section d'une section authentifiée,
+ on doit utiliser le type d'authentification None ; dans
+ l'exemple suivant, les clients peuvent accéder au répertoire
+ /www/docs/public sans devoir s'authentifier :
<Directory "/www/docs"> + AuthType Basic + AuthName Documents + AuthBasicProvider file + AuthUserFile "/usr/local/apache/passwd/passwords" + Require valid-user +</Directory> + +<Directory "/www/docs/public"> + AuthType None + Require all granted +</Directory>+ + +
Serveur HTTP Apache Version 2.4
+| Description: | Authentification utilisateur à l'aide d'une base de données +SQL |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | authn_dbd_module |
| Fichier Source: | mod_authn_dbd.c |
| Compatibilité: | Disponible depuis la version 2.1 d'Apache |
Ce module permet aux frontaux d'authentification comme
+ mod_auth_digest et mod_auth_basic
+ d'authentifier les utilisateurs en les recherchant dans une base de
+ données SQL. mod_authn_file, par exemple, fournit
+ une fonctionnalité similaire.
Ce module s'appuie sur mod_dbd pour spécifier le
+ pilote de la base de données sous-jacente et les paramètres de
+ connexion, mais aussi pour gérer les connexions à la base de
+ données.
Si l'on utilise mod_auth_basic ou
+ mod_auth_digest, on peut invoquer ce module en
+ affectant la valeur dbd à la directive AuthBasicProvider ou AuthDigestProvider.
Performances et mise en cache Exemple de configuration Mise à disposition des informations de connexionCertains utilisateurs de l'authentification DBD sous HTTPD 2.2/2.4 ont
+signalé une charge problématique au niveau de la base de données. Cela
+se produit en général lorsqu'une page HTML contient des centaines d'objets
+(comme des images, des scripts, etc...), chacun d'entre eux nécessitant
+une authentification. Les utilisateurs qui rencontrent ce genre de
+problème peuvent utiliser le module mod_authn_socache
+qui permet de mettre les données d'authentification en cache, et
+soulager ainsi la base de données de la plus grande partie de la charge.
Voici un exemple simple d'utilisation de ce module dans un contexte +d'authentification et de bases de données.
+# configuration de mod_dbd +# MISE À JOUR pour inclure la mise en cache de l'authentification +DBDriver pgsql +DBDParams "dbname=apacheauth user=apache password=xxxxxx" + +DBDMin 4 +DBDKeep 8 +DBDMax 20 +DBDExptime 300 + +<Directory "/usr/www/mon-serveur/private"> + # configuration de mod_authn_core et mod_auth_basic + # pour mod_authn_dbd + AuthType Basic + AuthName "Mon serveur" + + # Pour mettre en cache les données d'authentification, placez socache + # avant dbd + AuthBasicProvider socache dbd + + # Aussi nécessaire à la mise en cache : dire au cache de mettre en + # cache les recherches dbd ! + AuthnCacheProvideFor dbd + AuthnCacheContext mon-serveur + + # configuration de mod_authz_core + Require valid-user + + # la requête SQL de mod_authn_dbd pour authentifier un utilisateur + AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s" +</Directory>+ +
+Si httpd a été compilé avec la version 1.3.0 ou supérieure de +l'APR, pour chaque requête envoyée au serveur de +base de données, toutes les valeurs de colonnes du premier +enregistrement renvoyé par la requête sont affectées à des variables +d'environnement avec le préfixe "AUTHENTICATE_". +
+Par exemple, si une requête renvoie un nom d'utilisateur, un nom +complet et un numéro de téléphone, un programme CGI pourra accéder à ces +informations sans avoir besoin d'effectuer une deuxième requête vers la +base de données.
+Ceci va entraîner une simplification considérable du code et de la +configuration nécessaire de certaines applications web. +
+| Description: | Requête SQL servant à vérifier le mot de passe d'un +utilisateur |
|---|---|
| Syntaxe: | AuthDBDUserPWQuery requête |
| Contexte: | répertoire |
| Statut: | Extension |
| Module: | mod_authn_dbd |
La directive AuthDBDUserPWQuery permet de
+ spécifier une requête servant à vérifier le mot de passe d'un
+ utilisateur donné. L'identifiant utilisateur sera transmis comme
+ paramètre sous forme d'une seule chaîne de caractères lorsque la
+ requête sera exécutée. Cet identifiant est référencé dans la requête
+ en utilisant le spécificateur de format %s.
AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"+ +
La première colonne du premier enregistrement renvoyé par la
+ requête se présentera sous la forme d'une chaîne de caractères
+ contenant le mot de passe chiffré. Les enregistrements suivants sont
+ ignorés. Si aucun enregistrement n'est renvoyé, l'utilisateur ne
+ sera pas authentifié par mod_authn_dbd.
Si httpd a été compilé avec la version 1.3.0 ou supérieure de
+ l'APR, toute valeur de colonne supplémentaire
+ du premier enregistrement renvoyé par la requête sera stockée dans
+ une variable d'environnement dont le nom aura la forme
+ AUTHENTICATE_valeur-colonne.
+
Le format du mot de passe chiffré dépend du frontal
+ d'authentification utilisé (par exemple
+ mod_auth_basic ou
+ mod_auth_digest). Voir la documentation sur les Formats de mots de passe pour
+ plus de détails.
| Description: | Requête SQL servant à vérifier une empreinte de mot de +passe pour un utilisateur et un identifiant d'authentification. + |
|---|---|
| Syntaxe: | AuthDBDUserRealmQuery requête |
| Contexte: | répertoire |
| Statut: | Extension |
| Module: | mod_authn_dbd |
La directive AuthDBDUserRealmQuery permet
+ de spécifier une requête SQL servant à vérifier une empreinte de mot
+ de passe pour un utilisateur et un identifiant d'authentification
+ donnés au cours d'un processus d'authentification digest. Les
+ identifiants de l'utilisateur et de l'authentification
+ sont passés dans cet ordre comme paramètres à l'exécution de la
+ requête. Ils sont référencés dans la chaîne de la requête en
+ utilisant des spécificateurs de format %s.
AuthDBDUserRealmQuery "SELECT password FROM authn WHERE user = %s AND realm = %s"+ +
La première colonne du premier enregistrement renvoyé par la
+ requête se présentera sous la forme d'une chaîne de caractères
+ contenant le mot de passe chiffré. Les enregistrements suivants
+ seront ignorés. Si aucun enregistrement n'est renvoyé, l'utilisateur
+ ne sera pas authentifié par mod_authn_dbd.
Si httpd a été compilé avec une version 1.3.0 ou supérieure de
+ l'APR, toute valeur de colonne supplémentaire
+ du premier enregistrement renvoyé par la requête sera stockée dans
+ une variable d'environnement avec un nom de la forme
+ AUTHENTICATE_COLONNE.
+
Le format du mot de passe chiffré dépend du frontal
+ d'authentification utilisé (par exemple
+ mod_auth_basic ou
+ mod_auth_digest). Voir la documentation sur les Formats de mots de passe pour
+ plus de détails.
Serveur HTTP Apache Version 2.4
+| Description: | Authentification utilisateur utilisant des fichiers +DBM |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | authn_dbm_module |
| Fichier Source: | mod_authn_dbm.c |
| Compatibilité: | Disponible depuis les versions 2.1 et supérieures +d'Apache |
Ce module permet aux frontaux comme
+ mod_auth_digest et mod_auth_basic
+ d'authentifier les utilisateurs en les recherchant dans des fichiers
+ de mots de passe dbm. mod_authn_file
+ fournit une fonctionnalité similaire.
Lorsqu'on utilise mod_auth_basic ou
+ mod_auth_digest, ce module est invoqué en affectant
+ la valeur dbm à la directive AuthBasicProvider ou AuthDigestProvider.
| Description: | Définit le type de fichier de base de données utilisé pour +stocker les mots de passe |
|---|---|
| Syntaxe: | AuthDBMType default|SDBM|GDBM|NDBM|DB |
| Défaut: | AuthDBMType default |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authn_dbm |
Cette directive permet de définir le type de fichier de base de + données utilisé pour stocker les mots de passe. Le type de base de + données par défaut est défini à la compilation. La liste des autres + types de bases de données disponibles dépend aussi de la configuration de la + compilation.
+ +Par exemple, pour activer le support de Berkeley DB (correspondant au
+ type db), il faut ajouter l'option
+ --with-berkeley-db à la ligne de commande configure de httpd
+ pour générer le DSO approprié.
Il est impératif que le programme que vous utilisez pour créer + vos fichiers de mots de passe soit configuré pour utiliser le même + type de base de données.
+ +| Description: | Définit le nom d'un fichier de base de données pour +l'authentification contenant la liste +des utilisateurs et de leurs mots de passe |
|---|---|
| Syntaxe: | AuthDBMUserFile chemin-fichier |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authn_dbm |
La directive AuthDBMUserFile permet de
+ définir le nom d'un fichier de base de données pour
+ l'authentification contenant la liste des utilisateurs et de leurs
+ mots de passe. chemin-fichier doit être un chemin absolu
+ vers le fichier de base de données.
La clé du fichier de base de données est le nom de l'utilisateur. + La valeur associée est le mot de passe chiffré, éventuellement suivi + par un ':' et des données arbitraires. Ce ':' ainsi que les données + arbitraires qui suivent seront ignorées par le serveur.
+ +Faites en sorte que le fichier spécifié par la directive
+ AuthDBMUserFile soit stocké en dehors de
+ l'arborescence des documents du serveur web ; en particulier, ne
+ l'enregistrez pas dans le répertoire qu'il protège, faute
+ de quoi, les clients auraient la possibilité de
+ télécharger le fichier des mots de passe.
Le format de mot de passe chiffré dépend du frontal
+ d'authentification utilisé (par exemple
+ mod_auth_basic ou
+ mod_auth_digest). Voir la documentation sur les Formats de mots de
+ passe pour plus de détails.
Note importante concernant la compatibilité : l'implémentation de
+ dbmopen dans les modules d'Apache lit la longueur de la
+ chaîne correspondant aux données chiffrées dans la structure des
+ données DBM, plutôt que de calculer cette longueur en se basant sur
+ le caractère nul final. Certaines applications par contre, comme le
+ serveur web Netscape, calculent cette longueur en se basant sur
+ le caractère nul final ; par conséquent, si vous rencontrez des
+ difficultés en échangeant des fichiers DBM entre plusieurs
+ applications, le problème peut éventuellement s'expliquer par cette
+ différence d'implémentation.
Un script perl nommé dbmmanage est fourni avec
+ Apache. On peut utiliser ce programme pour créer et mettre à jour
+ les fichiers de mots de passe au format DBM que ce module
+ utilise. Il existe également un autre outil pour gérer les fichiers DBM,
+ inclus dans le programme htdbm.
Serveur HTTP Apache Version 2.4
+| Description: | Authentification utilisateur à l'aide de fichiers +texte |
|---|---|
| Statut: | Base |
| Identificateur de Module: | authn_file_module |
| Fichier Source: | mod_authn_file.c |
| Compatibilité: | Disponible depuis les versions 2.1 et supérieures +d'Apache |
Ce module permet aux frontaux d'authentification comme
+ mod_auth_digest et mod_auth_basic
+ d'authentifier les utilisateurs en les recherchant dans des fichiers
+ de mots de passe au format texte. mod_authn_dbm
+ fournit une fonctionnalité similaire.
Lorsqu'on utilise mod_auth_basic ou
+ mod_auth_digest, ce module peut être invoqué en
+ affectant la valeur file à la directive AuthBasicProvider ou AuthDigestProvider.
| Description: | Définit le nom d'un fichier texte pour l'authentification +contenant la liste des utilisateurs et de leurs mots de +passe |
|---|---|
| Syntaxe: | AuthUserFile chemin-fichier |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_authn_file |
La directive AuthUserFile permet de
+ définir le nom d'un fichier texte pour l'authentification contenant
+ la liste des utilisateurs et de leurs mots de passe.
+ chemin-fichier est le chemin vers le fichier
+ des utilisateurs. S'il n'est pas absolu, il est considéré comme
+ relatif au répertoire défini par la directive ServerRoot.
Chaque ligne du fichier des utilisateurs se compose du nom de
+ l'utilisateur, du caractère ':' et du mot de passe chiffré. Si le
+ même identifiant utilisateur est référencé plusieurs fois,
+ mod_authn_file utilisera la première occurrence pour
+ vérifier le mot de passe.
Le format du mot de passe chiffré dépend du frontal
+ d'authentification utilisé (par exemple
+ mod_auth_basic ou
+ mod_auth_digest). Voir la documentation sur les
+ Formats de mots de
+ passe pour plus de détails.
Pour mod_auth_basic, utilisez le programme
+ htpasswd fourni avec la distribution binaire,
+ mais que vous trouverez aussi dans le répertoire
+ src/support de l'arborescence des sources. Voir sa page de manuel pour plus de
+ détails. En bref :
On crée un fichier de mots de passe nom-fichier avec
+ nom-utilisateur comme identifiant initial. Le mot de
+ passe correspondant sera alors demandé :
+ htpasswd -c nom-fichier nom-utilisateur
+
Pour ajouter ou modifier nom-utilisateur2 dans le
+ fichier de mots de passe nom-fichier :
+ htpasswd nom-fichier nom-utilisateur2
+
Noter qu'une recherche dans de grands fichiers texte peut être
+ très longue ; dans ce cas, il vaut mieux utiliser les fichiers DBM
+ avec la directive AuthDBMUserFile.
Pour mod_auth_digest, vous devez utiliser
+ le programme htdigest.
+ Notez que vous ne pouvez pas mélanger des données utilisateur pour
+ l'Authentification HTTP à base de condensé et des données pour
+ l'Authentification de Base dans le même fichier.
Assurez-vous que le fichier AuthUserFile
+ soit bien stocké en dehors de l'arborescence des documents du
+ serveur web. Ne placez pas ce fichier dans le
+ répertoire qu'il protège. Dans le cas contraire, les clients
+ seraient en mesure de télécharger le fichier des mots de passe.
Serveur HTTP Apache Version 2.4
+| Description: | Gère un cache des données d'authentification pour diminuer +la charge des serveurs d'arrière-plan |
|---|---|
| Statut: | Base |
| Identificateur de Module: | authn_socache_module |
| Fichier Source: | mod_authn_socache.c |
| Compatibilité: | Versions 2.3 et ultérieures |
Maintient un cache des données d'authentification pour limiter + les sollicitations du serveur d'arrière-plan.
+ Mise en cache des données d'authentification Utilisation La mise en cache avec les modules tiers AuthnCacheContext AuthnCacheEnable AuthnCacheProvideFor AuthnCacheSOCache AuthnCacheTimeoutCertains utilisateurs qui mettent en oeuvre une authentification
+ lourde s'appuyant par exemple sur des requêtes SQL
+ (mod_authn_dbd) ont signalé une charge induite
+ inacceptable sur leur fournisseur d'authentification. Cela se
+ produit typiquement dans le cas où une page HTML contient des
+ centaines d'objets (images, scripts, pages de styles, media,
+ etc...), et où une requête pour cette page génère des centaines de
+ sous-requêtes à effet immédiat pour des contenus supplémentaires
+ authentifiés.
Pour résoudre ce problème, mod_authn_socache fournit une solution + qui permet de maintenir un cache des données d'authentification.
+Le cache d'authentification doit être utilisé lorsque les
+ requêtes d'authentification induisent une charge significative sur le
+ serveur, le serveur d'arrière-plan ou le réseau. Cette mise en cache
+ n'apportera probablement aucune amélioration dans le cas d'une
+ authentification à base de fichier (mod_authn_file)
+ ou de base de données dbm (mod_authn_dbm) car ces
+ méthodes sont de par leur conception rapides et légères (la mise en
+ cache peut cependant s'avérer utile dans le cas où le fichier est
+ situé sur un montage réseau). Les fournisseurs d'authentification
+ basés sur SQL ou LDAP ont plus de chances de tirer parti de cette
+ mise en cache, en particulier lorsqu'un problème de performances est
+ détecté. mod_authnz_ldap gérant son propre cache,
+ seul mod_authn_dbd est concerné par notre sujet.
Les principales règles à appliquer pour la mise en cache sont :
+AuthnCacheProvideFor.AuthBasicProvider
+ ou AuthDigestProvider.Voici un exemple simple permettant d'accélérer
+ mod_authn_dbd et utilisant dbm comme moteur de la
+ mise en cache :
#AuthnCacheSOCache est optionnel. S'il est défini, il l'est pour + #l'ensemble du serveur +AuthnCacheSOCache dbm +<Directory "/usr/www/myhost/private"> + AuthType Basic + AuthName "Cached Authentication Example" + AuthBasicProvider socache dbd + AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s" + AuthnCacheProvideFor dbd + Require valid-user + #Optionnel + AuthnCacheContext dbd-authn-example +</Directory>+ +
Les développeurs de modules doivent savoir que la mise en cache + avec mod_authn_socache doit être activée dans leurs modules. La + fonction de l'API ap_authn_cache_store permet de + mettre en cache les données d'authentification qu'un fournisseur + vient de rechercher ou de générer. Vous trouverez des exemples + d'utilisation à r957072, où trois fournisseurs authn sont activés pour la mise + en cache.
+| Description: | Spécifie une chaîne de contexte à utiliser dans la clé du +cache |
|---|---|
| Syntaxe: | AuthnCacheContext directory|server|chaîne-personnalisée |
| Défaut: | directory |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_authn_socache |
Cette directive permet de spécifier une chaîne à utiliser avec le + nom d'utilisateur fourni (et le domaine d'authentification - realm - + dans le cas d'une authentification à base de condensés) lors de la + construction d'une clé de cache. Ceci permet de lever l'ambiguïté + entre plusieurs noms d'utilisateurs identiques servant différentes + zones d'authentification sur le serveur.
+Il y a deux valeurs spéciales pour le paramètre : directory, + qui utilise le contexte de répertoire de la requête comme chaîne, et + server, qui utilise le nom du serveur virtuel.
+La valeur par défaut est directory, qui est aussi la + définition la plus courante. Ceci est cependant loin d'être optimal, + car par exemple, $app-base, $app-base/images, + $app-base/scripts et $app-base/media + possèderont chacun leur propre clé de cache. Il est préférable + d'utiliser le fournisseur de mot de passe : par exemple un fichier + htpasswd ou une table de base de données.
+Les contextes peuvent être partagés entre différentes zones du + serveur, où les données d'authentification sont partagées. Ceci est + cependant susceptible de créer des trous de sécurité de type + cross-site ou cross-application, et cette directive n'est donc pas + disponible dans les contextes .htaccess.
+ +| Description: | Active la mise en cache de l'authentification en tout +endroit |
|---|---|
| Syntaxe: | AuthnCacheEnable |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_authn_socache |
Normalement, cette directive n'est pas nécessaire : l'activation + est implicite si la mise en cache de l'authentification a été + activée en tout autre endroit du fichier httpd.conf. Par + contre, si cette mise en cache n'a pas été activée, par défaut, elle + ne sera pas initialisée, et ne sera donc pas disponible dans un + contexte de fichier .htaccess. Cette directive permet + d'être sûr que la mise en cache a bien été activée et pourra + donc être utilisée dans les fichiers .htaccess.
+ +| Description: | Spécifie le fournisseur pour lequel on veut effectuer une +mise en cache |
|---|---|
| Syntaxe: | AuthnCacheProvideFor fournisseur-authn [...] |
| Défaut: | None |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_authn_socache |
Cette directive permet de spécifier un ou plusieurs fournisseurs + pour le(s)quel(s) on veut effectuer une mise en cache. Les données + d'authentification trouvées par un fournisseur non spécifié dans une + directive AuthnCacheProvideFor ne seront pas mises en cache.
+ +Par exemple, pour mettre en cache les données d'authentification
+ trouvées par mod_authn_dbd ou par un fournisseur
+ personnalisé mon-fournisseur, et ne pas mettre en cache
+ celles trouvées par les fournisseurs légers comme file ou dbm :
AuthnCacheProvideFor dbd mon-fournisseur+ + +
| Description: | Sélectionne le fournisseur socache d'arrière-plan à +utiliser |
|---|---|
| Syntaxe: | AuthnCacheSOCache nom-fournisseur[:arguments-fournisseur] |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_authn_socache |
| Compatibilité: | Les arguments optionnels du fournisseur sont disponibles +à partir de la version 2.4.7 du serveur HTTP Apache |
Cette définition s'applique à l'ensemble du serveur et permet de + sélectionner un fournisseur pour le cache + d'objets partagés, ainsi que des arguments éventuels pour ce + fournisseur. Les fournisseurs disponibles sont, entre autres, "dbm", + "dc", "memcache", ou "shmcb", chacun d'entre eux nécessitant le chargement + du module approprié. Si elle est + absente, c'est la valeur par défaut pour votre plate-forme qui sera + utilisée.
+ +| Description: | Définit une durée de vie pour les entrées du cache |
|---|---|
| Syntaxe: | AuthnCacheTimeout durée-de-vie (secondes) |
| Défaut: | 300 (5 minutes) |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_authn_socache |
La mise en cache des données d'authentification peut constituer + un trou de sécurité, bien qu'un mise en cache de courte durée ne + posera probablement pas de problème. En général, il est conseillé de + conserver les entrées du cache de façon à ce que la charge du serveur + d'arrière-plan reste normale, mais pas plus longtemps ; + une durée de vie plus longue peut être paramétrée si les + changements d'utilisateurs et de mots de passe sont peu fréquents. + La durée de vie par défaut de 300 secondes (5 minutes) est à la fois + raisonnable et suffisamment importante pour réduire la charge d'un + serveur d'arrière-plan comme dbd (requêtes SQL).
+Cette durée de vie ne doit pas être confondue avec la durée de + vie de session qui est un tout autre sujet. Cependant, vous devez + utiliser votre logiciel de gestion de session pour vérifier si les + données d'authentification mises en cache peuvent allonger + accidentellement une session, et en tenir compte lorsque vous + définissez la durée de vie.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Permet à une application d'autorisation FastCGI de gérer +l'authentification et l'autorisation httpd. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | authnz_fcgi_module |
| Fichier Source: | mod_authnz_fcgi.c |
| Compatibilité: | Disponible à partir de la version 2.4.10 du serveur HTTP +Apache |
Ce module permet aux applications d'autorisation FastCGI + d'authentifier les utilisateurs et de contrôler leur accès aux + ressources. Il supporte les systèmes d'autorisation FastCGI + génériques qui participent en une seule phase à l'authentification + et à l'autorisation, ainsi que les processus d'authentification et + d'autorisation spécifiques à Apache httpd qui interviennent en une + ou plusieurs phases.
+ +Les processus d'autorisation FastCGI peuvent authentifier un + utilisateur via son identificateur et son mot de passe comme dans le + processus d'authentification basique, ou via un mécanisme + arbitraire.
+Les modes d'invocation des processus d'autorisation FastCGI que + ce module supporte se distinguent par deux caractéristiques : le + type et le mécanisme d'authentification.
+ +Le Type est simplement authn pour
+ l'authentification, authz pour l'autorisation et
+ authnz l'authentification et l'autorisation.
Le mécanisme d'authentification fait référence aux
+ mécanismes d'authentification et aux phases de traitement de la
+ configuration de Apache httpd, et peut être
+ AuthBasicProvider, Require, ou
+ check_user_id. Les deux premiers mécanismes
+ correspondent aux directives utilisées pour participer aux phases de
+ traitement appropriées.
Description de chaque mode:
+ +authn, mechanism
+ AuthBasicProviderFCGI_ROLE est définie à
+ AUTHORIZER, et la variable
+ FCGI_APACHE_ROLE à AUTHENTICATOR.
+ L'application doit être spécifiée en tant que fournisseur de type
+ authn via la directive AuthnzFcgiDefineProvider, et
+ activée via la directive AuthBasicProvider. Lorsqu'elle
+ est invoquée, l'application est censée authentifier le client à
+ l'aide de l'identifiant et du mot de passe de l'utilisateur.
+ Exemple d'application :
+
+#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+ die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHENTICATOR";
+ die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
+ die if !$ENV{'REMOTE_PASSWD'};
+ die if !$ENV{'REMOTE_USER'};
+
+ print STDERR "This text is written to the web server error log.\n";
+
+ if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
+ $ENV{'REMOTE_PASSWD'} eq "bar" ) {
+ print "Status: 200\n";
+ print "Variable-AUTHN_1: authn_01\n";
+ print "Variable-AUTHN_2: authn_02\n";
+ print "\n";
+ }
+ else {
+ print "Status: 401\n\n";
+ }
+}
+
+
+ Exemple de configuration httpd :
+AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10102/ +<Location "/protected/"> + AuthType Basic + AuthName "Restricted" + AuthBasicProvider FooAuthn + Require ... +</Location>+ +
authz, mechanism
+ RequireFCGI_ROLE est définie à
+ AUTHORIZER et FCGI_APACHE_ROLE à
+ AUTHORIZER. L'application doit être spécifiée en tant
+ que fournisseur de type authz via la directive AuthnzFcgiDefineProvider.
+ Lorsqu'elle est invoquée, l'application est censée contrôler les
+ accès du client à l'aide de l'identifiant utilisateur et d'autres
+ données contenues dans la requête. Exemple d'application :
+#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+ die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHORIZER";
+ die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
+ die if $ENV{'REMOTE_PASSWD'};
+
+ print STDERR "This text is written to the web server error log.\n";
+
+ if ($ENV{'REMOTE_USER'} eq "foo1") {
+ print "Status: 200\n";
+ print "Variable-AUTHZ_1: authz_01\n";
+ print "Variable-AUTHZ_2: authz_02\n";
+ print "\n";
+ }
+ else {
+ print "Status: 403\n\n";
+ }
+}
+
+
+ Exemple de configuration httpd :
+AuthnzFcgiDefineProvider authz FooAuthz fcgi://localhost:10103/ +<Location "/protected/"> + AuthType ... + AuthName ... + AuthBasicProvider ... + Require FooAuthz +</Location>+ +
authnz, mechanism
+ AuthBasicProvider + RequireFCGI_ROLE est
+ définie à AUTHORIZER et FCGI_APACHE_ROLE
+ n'est pas définie. L'application doit être spécifiée en tant que
+ fournisseur de type authnz via la directive AuthnzFcgiDefineProvider.
+ L'application est censée assurer l'authentification et
+ l'autorisation au cours d'une même invocation à l'aide de
+ l'identifiant et du mot de passe de l'utilisateur et d'autres
+ données contenues dans la requête. L'invocation de l'application
+ intervient au cours de la phase d'authentification de l'API Apache
+ httpd. Si l'application renvoie le code 200, et si le même
+ fournisseur est invoqué au cours de la phase d'autorisation (via
+ une directive Require), mod_authnz_fcgi
+ renverra un code de type success pour la phase d'autorisation sans
+ invoquer l'application. Exemple d'application :
+#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+ die if $ENV{'FCGI_APACHE_ROLE'};
+ die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
+ die if !$ENV{'REMOTE_PASSWD'};
+ die if !$ENV{'REMOTE_USER'};
+
+ print STDERR "This text is written to the web server error log.\n";
+
+ if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
+ $ENV{'REMOTE_PASSWD'} eq "bar" &&
+ $ENV{'REQUEST_URI'} =~ m%/bar/.*%) {
+ print "Status: 200\n";
+ print "Variable-AUTHNZ_1: authnz_01\n";
+ print "Variable-AUTHNZ_2: authnz_02\n";
+ print "\n";
+ }
+ else {
+ print "Status: 401\n\n";
+ }
+}
+
+
+ Exemple de configuration httpd :
+AuthnzFcgiDefineProvider authnz FooAuthnz fcgi://localhost:10103/ +<Location "/protected/"> + AuthType Basic + AuthName "Restricted" + AuthBasicProvider FooAuthnz + Require FooAuthnz +</Location>+ +
authn, mechanism
+ check_user_idFCGI_ROLE est définie à
+ AUTHORIZER et FCGI_APACHE_ROLE à
+ AUTHENTICATOR. L'application doit être spécifiée en
+ tant que fournisseur de type authn via une directive
+ AuthnzFcgiDefineProvider. La
+ directive AuthnzFcgiCheckAuthnProvider
+ permet de l'invoquer. Exemple d'application :
+#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+ die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHENTICATOR";
+ die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
+
+ # This authorizer assumes that the RequireBasicAuth option of
+ # AuthnzFcgiCheckAuthnProvider is On:
+ die if !$ENV{'REMOTE_PASSWD'};
+ die if !$ENV{'REMOTE_USER'};
+
+ print STDERR "This text is written to the web server error log.\n";
+
+ if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
+ $ENV{'REMOTE_PASSWD'} eq "bar" ) {
+ print "Status: 200\n";
+ print "Variable-AUTHNZ_1: authnz_01\n";
+ print "Variable-AUTHNZ_2: authnz_02\n";
+ print "\n";
+ }
+ else {
+ print "Status: 401\n\n";
+ # If a response body is written here, it will be returned to
+ # the client.
+ }
+}
+
+
+ Exemple de configuration httpd :
+AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10103/
+<Location "/protected/">
+ AuthType ...
+ AuthName ...
+ AuthnzFcgiCheckAuthnProvider FooAuthn \
+ Authoritative On \
+ RequireBasicAuth Off \
+ UserExpr "%{reqenv:REMOTE_USER}"
+ Require ...
+</Location>
+
+ AUTHENTICATOR et
+ AUTHORIZER), vous pouvez définir des fournisseurs
+ séparés comme suit, même s'ils correspondent à la même application :
+
+AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10102/ +AuthnzFcgiDefineProvider authz FooAuthz fcgi://localhost:10102/+ + + Spécifie le fournisseur authn via la directive +
AuthBasicProvider
+ et le fournisseur authz via la directive
+ Require:
+
+AuthType Basic +AuthName "Restricted" +AuthBasicProvider FooAuthn +Require FooAuthz+ +
AUTHORIZER (authentification et autorisation en une
+ seule invocation), vous pouvez définir un fournisseur unique comme
+ suit :
+
+AuthnzFcgiDefineProvider authnz FooAuthnz fcgi://localhost:10103/+ + + Spécifie le fournisseur authnz via les directives +
AuthBasicProvider et
+ Require :
+
+AuthType Basic +AuthName "Restricted" +AuthBasicProvider FooAuthnz +Require FooAuthnz+ +
Les fonctionnalités suivantes ne sont pas encore implémentées :
+ +FCGI_APACHE_ROLE
+ est définie à ACCESS_CHECKER.fcgistarter permet de
+ les démarrer.ProxyPass utilisée avec les répondeurs
+ FastCGI.error ou supérieur.warn.debug.trace2. La valeur de la
+ variable REMOTE_PASSWD sera occultée, mais
+ toute autre donnée sensible sera visible dans le
+ journal.trace5. Toutes les données sensibles seront
+ visibles dans le journal.La directive LogLevel permet
+ de configurer un niveau de journalisation spécifique à
+ mod_authnz_fcgi. Par exemple :
LogLevel info authnz_fcgi:trace8+ + +
| Description: | Permet à une application FastCGI de gérer l'accroche +d'authentification check_authn. |
|---|---|
| Syntaxe: | AuthnzFcgiCheckAuthnProvider provider-name| |
| Défaut: | none |
| Contexte: | répertoire |
| Statut: | Extension |
| Module: | mod_authnz_fcgi |
Cette directive permet de confier à une application FastCGI la + gestion d'une phase spécifique du processus d'authentification ou + d'autorisation.
+ +Certaines fonctionnalités des fournisseurs d'autorisation FastCGI
+ nécessitent cette directive en lieu et place de
+ AuthBasicProvider pour pouvoir être activées :
UserExpr ci-dessousAuthnzFcgiDefineProvider.NoneNone pour désactiver un fournisseur
+ activé avec cette même directive dans une autre portée, par
+ exemple dans un répertoire parent.UserExpr est défini et correspond à une chaîne
+ vide, (par exemple, si le fournisseur d'autorisation ne renvoie
+ aucune variable), c'est cette valeur qui sera utilisée comme id
+ utilisateur par défaut. Cela se produit souvent lorsqu'on se trouve dans
+ un contexte d'invité, ou d'utilisateur non authentifié ;
+ les utilisateurs et invités se voient alors attribué un id
+ utilisateur spécifique qui permettra de se connecter et
+ d'accéder à certaines ressources.Variable-XXX renvoyée par le
+ fournisseur d'autorisation via une option du style
+ UserExpr "%{reqenv:XXX}". Si cette option
+ est spécifiée, et si l'id utilisateur ne peut pas être définie
+ via l'expression après une authentification réussie, la requête
+ sera rejetée avec un code d'erreur 500.| Description: | Définit une application FastCGI en tant que fournisseur +d'authentification et/ou autorisation |
|---|---|
| Syntaxe: | AuthnzFcgiDefineProvider type provider-name
+backend-address |
| Défaut: | none |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_authnz_fcgi |
Cette directive permet de définir une application FastCGI en tant + que fournisseur pour une phase particulière d'authentification ou + d'autorisation.
+ +AuthBasicProvider et
+ Require.fcgistarter.Serveur HTTP Apache Version 2.4
+| Description: | Permet d'utiliser un annuaire LDAP pour l'authentification +HTTP de base. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | authnz_ldap_module |
| Fichier Source: | mod_authnz_ldap.c |
| Compatibilité: | Disponible depuis les versions 2.1 et supérieures +d'Apache |
Ce module permet aux frontaux d'authentification comme
+ mod_auth_basic d'authentifier les utilisateurs via
+ un annuaire ldap.
mod_authnz_ldap supporte les fonctionnalités
+ suivantes :
Lorsqu'on utilise mod_auth_basic, ce module est
+ invoqué en affectant la valeur ldap à la directive
+ AuthBasicProvider.
Sommaire Mises en garde à caractère général Mode opératoire Les directives requises Exemples Utilisation de TLS Utilisation de SSL Mise à disposition des informations de
+connexion Utilisation d'Active
+Directory Utilisation de Microsoft
+ FrontPage avec mod_authnz_ldap AuthLDAPAuthorizePrefix AuthLDAPBindAuthoritative AuthLDAPBindDN AuthLDAPBindPassword AuthLDAPCharsetConfig AuthLDAPCompareAsUser AuthLDAPCompareDNOnServer AuthLDAPDereferenceAliases AuthLDAPGroupAttribute AuthLDAPGroupAttributeIsDN AuthLDAPInitialBindAsUser AuthLDAPInitialBindPattern AuthLDAPMaxSubGroupDepth AuthLDAPRemoteUserAttribute AuthLDAPRemoteUserIsDN AuthLDAPSearchAsUser AuthLDAPSubGroupAttribute AuthLDAPSubGroupClass AuthLDAPUrlmod_authnz_ldap
+
+
+ Ce module effectue une mise en cache des résultats du processus
+d'authentification et d'autorisation en fonction de la configuration du
+module mod_ldap. Les modifications effectuées au niveau
+du serveur LDAP d'arrière-plan comme les
+verrouillages ou révocations d'utilisateurs, les changements de mot de
+passe, ou les changements d'appartenance à un groupe (et cette liste
+n'est pas exhaustive), ne seront pas immédiatement propagées jusqu'au
+serveur HTTP. Consultez les directives du module
+mod_ldap pour plus de détails à propos de la
+configuration de la mise en cache.
+
L'utilisateur se voit accorder l'accès selon un processus en deux
+ phases. La première phase est l'authentification, au cours de
+ laquelle le fournisseur d'authentification
+ mod_authnz_ldap vérifie que les informations de
+ connexion de l'utilisateur sont valides. Elle est aussi connue sous
+ le nom de phase de recherche/connexion (NdT : en anglais ou
+ dans le code source : search/bind). La deuxième
+ phase est l'autorisation, au cours de laquelle
+ mod_authnz_ldap détermine si l'utilisateur
+ authentifié a la permission d'accéder à la ressource considérée.
+ Elle est aussi connue sous le nom de phase de
+ comparaison (compare).
mod_authnz_ldap comporte un fournisseur
+ d'authentification authn_ldap et un gestionnaire d'autorisation
+ authz_ldap. Le fournisseur d'authentification authn_ldap peut être
+ invoqué en affectant la valeur ldap à la directive
+ AuthBasicProvider. Le
+ gestionnaire d'autorisation authz_ldap enrichit la liste des types
+ d'autorisations de la directive Require en y ajoutant les
+ valeurs ldap-user, ldap-dn et
+ ldap-group.
Au cours de la phase d'authentification,
+ mod_authnz_ldap recherche une entrée de l'annuaire
+ LDAP qui correspond au nom d'utilisateur fourni par le client HTTP.
+ Si une correspondance unique est trouvée,
+ mod_authnz_ldap tente de se connecter au serveur
+ hébergeant l'annuaire LDAP en utilisant le DN de l'entrée et le mot
+ de passe fourni par le client HTTP. Comme ce processus effectue tout
+ d'abord une recherche, puis une connexion, il est aussi connu sous
+ le nom de phase de recherche/connexion. Voici le détail des étapes
+ constituant la phase de recherche/connexion :
AuthLDAPURL avec le nom d'utilisateur et le mot de
+ passe fournis par le client HTTP.Les directives utilisées durant la phase de recherche/connexion + sont les suivantes :
+ +AuthLDAPURL |
+
+ Spécifie le serveur LDAP, le DN de base, l'attribut à + utiliser pour la recherche, ainsi que les filtres de recherche + supplémentaires. | +
AuthLDAPBindDN |
+
+ Un DN optionnel pour se connecter durant la phase de + recherche. | +
AuthLDAPBindPassword |
+
+ Un mot de passe optionnel pour se connecter durant la phase + de recherche. | +
Au cours de la phase d'autorisation,
+ mod_authnz_ldap tente de déterminer si
+ l'utilisateur est autorisé à accéder à la ressource considérée. Une
+ grande partie de cette vérification consiste pour
+ mod_authnz_ldap en des opérations de comparaison au
+ niveau du serveur LDAP. C'est pourquoi cette phase est aussi connue
+ sous le nom de phase de comparaison.
+ mod_authnz_ldap accepte les directives Require suivantes pour
+ déterminer si les informations de connexion permettent d'accorder
+ l'accès à l'utilisateur :
Require ldap-user,
+ l'autorisation d'accès est accordée si le nom d'utilisateur
+ spécifié par la directive correspond au nom d'utilisateur fourni
+ par le client.Require
+ ldap-dn, l'autorisation d'accès est accordée si le DN
+ spécifié par la directive correspond au DN extrait du résultat de
+ la recherche dans l'annuaire LDAP.Require ldap-group,
+ l'autorisation d'accès est accordée si le DN extrait du résultat de
+ la recherche dans l'annuaire LDAP (ou le nom d'utilisateur fourni
+ par le client) appartient au groupe LDAP spécifié par la
+ directive, ou éventuellement à un de ses sous-groupes.Require ldap-attribute, l'autorisation d'accès
+ est accordée si la valeur de l'attribut extraite de la recherche
+ dans l'annuaire LDAP correspond à la valeur spécifiée par la
+ directive.Require ldap-filter, l'autorisation d'accès
+ est accordée si le filtre de recherche renvoie un objet
+ utilisateur unique qui corresponde au DN de l'utilisateur
+ authentifié.Sous réserve du chargement de modules d'autorisation
+ supplémentaires, d'autres valeurs de la directive Require peuvent être
+ spécifiées.
Require
+ valid-user est présente (nécessite le module
+ mod_authz_user).Require group, l'autorisation
+ d'accès est accordée si le module
+ mod_authz_groupfile a été chargé et si la
+ directive AuthGroupFile a été
+ définie.Durant la phase de comparaison, mod_authnz_ldap
+ utilise les directives suivantes :
AuthLDAPURL
+ |
+
+ On utilise l'attribut spécifié dans l'URL pour les
+ opérations de comparaison initiées par la directive
+ Require ldap-user. |
+
AuthLDAPCompareDNOnServer |
+
+ Détermine le comportement de la directive Require
+ ldap-dn. |
+
AuthLDAPGroupAttribute |
+
+ Détermine l'attribut utilisé pour les opérations de
+ comparaison initiées par la directive Require
+ ldap-group. |
+
AuthLDAPGroupAttributeIsDN |
+
+ Spécifie si l'on doit utiliser le DN ou le nom de
+ l'utilisateur lors des opérations de comparaison initiées par la
+ directive Require ldap-group. |
+
AuthLDAPMaxSubGroupDepth |
+
+ Détermine la profondeur maximale de l'arborescence des
+ sous-groupes qui seront évalués au cours des opérations de
+ comparaisons initiées par la directive Require
+ ldap-group. |
+
AuthLDAPSubGroupAttribute |
+
+ Détermine l'attribut à utiliser lors de l'extraction de
+ membres de sous-groupes du groupe courant au cours des
+ opérations de comparaison initiées par la directive
+ Require ldap-group. |
+
AuthLDAPSubGroupClass |
+
+ Spécifie les valeurs de classe d'objet LDAP à utiliser pour
+ déterminer si les objets extraits de l'annuaire sont bien des
+ objets de type groupe (et non des objets de type utilisateur),
+ au cours du traitement des sous-groupes initié par la directive
+ Require ldap-group. |
+
Les directives Require d'Apache sont utilisées
+ au cours de la phase d'autorisation afin de s'assurer que
+ l'utilisateur est autorisé à accéder à une ressource.
+ mod_authnz_ldap enrichit la liste des types d'autorisations avec les
+ valeurs ldap-user, ldap-dn,
+ ldap-group, ldap-attribute et
+ ldap-filter. D'autres types d'autorisations sont
+ disponibles, sous réserve du chargement de modules d'autorisation
+ supplémentaires.
Depuis la version 2.4.8, les directives require LDAP supportent + les expressions.
+ +La directive Require ldap-user permet de spécifier
+ les noms des utilisateurs autorisés à accéder à la ressource.
+ Lorsque mod_authnz_ldap a extrait un DN unique de
+ l'annuaire LDAP, il effectue une opération de comparaison LDAP en
+ utilisant le nom d'utilisateur spécifié par la directive
+ Require ldap-user, pour vérifier si ce nom
+ d'utilisateur correspond à l'entrée LDAP extraite. On peut accorder
+ l'accès à plusieurs utilisateurs en plaçant plusieurs nom
+ d'utilisateurs sur la même ligne séparés par des espaces. Si un nom
+ d'utilisateur contient des espaces, il doit être entouré de
+ guillemets. On peut aussi accorder l'accès à plusieurs utilisateurs
+ en utilisant une directive Require ldap-user par
+ utilisateur. Par exemple, avec la directive AuthLDAPURL définie à
+ ldap://ldap/o=Example?cn (spécifiant donc que l'attribut
+ cn sera utilisé pour les recherches), on pourra
+ utiliser les directives Require suivantes pour restreindre l'accès
+ :
Require ldap-user "Barbara Jenson" +Require ldap-user "Fred User" +Require ldap-user "Joe Manager"+ + +
De par la manière dont mod_authnz_ldap traite
+ cette directive, Barbara Jenson peut s'authentifier comme
+ Barbara Jenson, Babs Jenson ou tout autre
+ cn sous lequel elle est enregistrée dans l'annuaire
+ LDAP. Une seule ligne Require ldap-user suffit pour
+ toutes les valeurs de l'attribut dans l'entrée LDAP de
+ l'utilisateur.
Si l'attribut uid avait été spécifié à la place de
+ l'attribut cn dans l'URL précédente, les trois lignes
+ ci-dessus auraient pû être condensées en une seule ligne :
Require ldap-user bjenson fuser jmanager+ + + +
Cette directive permet de spécifier un groupe LDAP dont les + membres auront l'autorisation d'accès. Elle prend comme argument le + DN du groupe LDAP. Note : n'entourez pas le nom du groupe avec des + guillemets. Par exemple, supposons que l'entrée suivante existe dans + l'annuaire LDAP :
+dn: cn=Administrators, o=Example +objectClass: groupOfUniqueNames +uniqueMember: cn=Barbara Jenson, o=Example +uniqueMember: cn=Fred User, o=Example
La directive suivante autoriserait alors l'accès à Fred et + Barbara :
+Require ldap-group cn=Administrators, o=Example+ + +
Les membres peuvent aussi se trouver dans les sous-groupes du
+ groupe LDAP spécifié si la directive AuthLDAPMaxSubGroupDepth a été
+ définie à une valeur supérieure à 0. Par exemple, supposons que les
+ entrées suivantes existent dans l'annuaire LDAP :
dn: cn=Employees, o=Example +objectClass: groupOfUniqueNames +uniqueMember: cn=Managers, o=Example +uniqueMember: cn=Administrators, o=Example +uniqueMember: cn=Users, o=Example + +dn: cn=Managers, o=Example +objectClass: groupOfUniqueNames +uniqueMember: cn=Bob Ellis, o=Example +uniqueMember: cn=Tom Jackson, o=Example + +dn: cn=Administrators, o=Example +objectClass: groupOfUniqueNames +uniqueMember: cn=Barbara Jenson, o=Example +uniqueMember: cn=Fred User, o=Example + +dn: cn=Users, o=Example +objectClass: groupOfUniqueNames +uniqueMember: cn=Allan Jefferson, o=Example +uniqueMember: cn=Paul Tilley, o=Example +uniqueMember: cn=Temporary Employees, o=Example + +dn: cn=Temporary Employees, o=Example +objectClass: groupOfUniqueNames +uniqueMember: cn=Jim Swenson, o=Example +uniqueMember: cn=Elliot Rhodes, o=Example
Les directives suivantes autoriseraient alors l'accès à Bob + Ellis, Tom Jackson, Barbara Jenson, Fred User, Allan Jefferson, et + Paul Tilley, mais l'interdiraient à Jim Swenson, ou Elliot Rhodes + (car ils sont situés dans un sous-groupe de niveau de profondeur 2) + :
+Require ldap-group cn=Employees, o=Example +AuthLDAPMaxSubGroupDepth 1+ + +
Le comportement de cette directive est modifié par les directives
+ AuthLDAPGroupAttribute,
+ AuthLDAPGroupAttributeIsDN,
+ AuthLDAPMaxSubGroupDepth,
+ AuthLDAPSubGroupAttribute, et
+ AuthLDAPSubGroupClass.
La directive Require ldap-dn permet à
+ l'administrateur d'accorder l'utorisation d'accès en fonction du DN.
+ Elle permet de spécifier un DN pour lequel l'accès est autorisé. Si
+ le DN extrait de
+ l'annuaire correspond au DN spécifié par la directive Require
+ ldap-dn, l'autorisation d'accès est accordée. Note :
+ n'entourez pas Le DN de guillemets.
La directive suivante accorderait l'accès à un DN spécifique + :
+Require ldap-dn cn=Barbara Jenson, o=Example+ + +
Le comportement ce cette directive est modifié par la directive
+ AuthLDAPCompareDNOnServer.
La directive Require ldap-attribute permet à
+ l'administrateur d'accorder l'autorisation d'accès en fonction des
+ attributs de l'utilisateur authentifié dans l'annuaire LDAP. Si la
+ valeur de l'attribut dans l'annuaire correspond à la valeur
+ spécifiée par la directive, l'autorisation d'accès est accordée.
La directive suivante accorderait l'autorisation d'accès à tout + utilisateur dont l'attribut employeeType a pour valeur "actif" :
+ +Require ldap-attribute employeeType="active"+ + +
Plusieurs paires attribut/valeur peuvent être spécifiées par une
+ même directive en les séparant par des espaces, ou en définissant
+ plusieurs directives Require ldap-attribute. La logique
+ sous-jacente à une liste de paires attribut/valeur est une opération
+ OU. L'autorisation d'accès sera accordée si au moins une paire
+ attribut/valeur de la liste spécifiée correspond à la paire
+ attribut/valeur de l'utilisateur authentifié. Si elle contient des
+ espaces, la valeur, et seulement la valeur, doit être entourée de
+ guillemets.
La directive suivante accorderait l'autorisation d'accès à tout + utilisateur dont l'attribut city aurait pour valeur "San Jose", ou + donc l'attribut status aurait pour valeur "actif" :
+ +Require ldap-attribute city="San Jose" status="active"+ + + + +
La directive Require ldap-filter permet à
+ l'administrateur d'accorder l'autorisation d'accès en fonction d'un
+ filtre de recherche LDAP complexe. L'autorisation d'accès est
+ accordée si le DN renvoyé par le filtre de recherche correspond au
+ DN de l'utilisateur authentifié.
La directive suivante accorderait l'autorisation d'accès à tout + utilisateur possédant un téléphone cellulaire et faisant partie du + département "marketing" :
+ +Require ldap-filter &(cell=*)(department=marketing)+ + +
Alors que la directive Require ldap-attribute se
+ contente d'une simple comparaison d'attributs, la directive
+ Require ldap-filter effectue une opération de recherche
+ dans l'annuaire LDAP en utilisant le filtre de recherche spécifié.
+ Si une simple comparaison d'attributs suffit, l'opération de
+ comparaison effectuée par ldap-attribute sera plus
+ rapide que l'opération de recherche effectuée par
+ ldap-filter, en particulier dans le cas d'un annuaire
+ LDAP de grande taille.
AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)" +Require valid-user+ +
AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example" +Require valid-user+ +
cn,
+ car une recherche sur le cn doit
+ retourner une entrée et une seule. C'est pourquoi cette
+ approche n'est pas recommandée : il est préférable de choisir un
+ attribut de votre annuaire dont l'unicité soit garantie, comme
+ uid.
+AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn" +Require valid-user+ +
AuthLDAPURL ldap://ldap.example.com/o=Example?uid +Require ldap-group cn=Administrators, o=Example+ +
AuthLDAPURL ldap://ldap.example.com/o=Example?uid
+Require ldap-group cn=%{SERVER_NAME}, o=Example
+
+ qpagePagerID. Seuls ces utilisateurs
+ (authentifiés via leur UID) se verront accorder l'autorisation
+ d'accès :
+AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*) +Require valid-user+ +
L'exemple suivant illustre la puissance des filtres pour + effectuer des requêtes complexes. Sans les filtres, il aurait + été nécessaire de créer un nouveau groupe LDAP et de s'assurer + de la synchronisation des membres du groupe avec les + utilisateurs possédant un bippeur. Tout devient limpide avec les + filtres. Nous avons pour but d'accorder l'autorisation d'accès à + tout utilisateur disposant d'un bippeur ainsi qu'à Joe Manager + qui ne possède pas de bippeur, mais doit tout de même pouvoir + accéder à la ressource :
+AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager)) +Require valid-user+ + +
Ce dernier exemple peut sembler confus au premier abord ; en
+ fait, il permet de mieux comprendre à quoi doit ressembler le
+ filtre en fonction de l'utilisateur qui se connecte. Si Fred
+ User se connecte en tant que fuser, le filtre devra
+ ressembler à :
(&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))
Un recherche avec le filtre ci-dessus ne retournera un + résultat positif que si fuser dispose d'un bippeur. Si + Joe Manager se connecte en tant que jmanager, le filtre + devra ressembler à :
+ +(&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))
Un recherche avec le filtre ci-dessus retournera un + résultat positif que jmanager dispose d'un + bippeur ou non
+Pour l'utilisation de TLS, voir les directives du module
+ mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.
Un second paramètre optionnel peut être ajouté à la directive
+ AuthLDAPURL pour
+ remplacer le type de connexion par défaut défini par la directive
+ LDAPTrustedMode. Ceci
+ permettra de promouvoir la connexion établie via une URL du type
+ ldap:// au statut de connection sécurisée sur le même
+ port.
Pour l'utilisation de SSL, voir les directives du module
+ mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert et LDAPTrustedMode.
Pour spécifier un serveur LDAP sécurisé, utilisez
+ ldaps:// au lieu de
+ ldap:// dans la directive AuthLDAPURL.
Au cours du processus d'authentification, les attributs LDAP
+ spécifiés par la directive authldapurl sont enregistrés
+ dans des variables d'environnement préfixées par la chaîne
+ "AUTHENTICATE_".
Au cours du processus d'autorisation, les attributs LDAP
+ spécifiés par la directive authldapurl sont enregistrés
+ dans des variables d'environnement préfixées par la chaîne
+ "AUTHORIZE_".
Si les champs attribut contiennent le nom, le CN et le numéro de + téléphone d'un utilisateur, un programme CGI pourra accéder à ces + informations sans devoir effectuer une autre requête LDAP pour + les extraire de l'annuaire.
+ +Ceci a pour effet de simplifier considérablement le code et la + configuration nécessaire de certaines applications web.
+ +Active Directory peut supporter plusieurs domaines à la fois. + Pour faire la distinction entre les utilisateurs de plusieurs + domaines, on peut ajouter à l'entrée de l'utilisateur dans + l'annuaire un identifiant appelé Nom + Principal d'Utilisateur (User Principle Name ou UPN). Cet UPN se + compose en général du nom de compte de l'utilisateur, suivi du nom + du domaine considéré, par exemple untel@nz.example.com.
+ +Vous voudrez probablement configurer le module
+ mod_authnz_ldap afin de pouvoir authentifier les
+ utilisateurs de n'importe quel domaine de la forêt Active Directory.
+ Ainsi, untel@nz.example.com et
+ untel@au.example.com pourront être authentifiés en une
+ seule fois par la même requête.
Pour y parvenir, on utilise le concept de Catalogue Global + d'Active Directory. Ce Catalogue Global est une copie en lecture + seule des attributs sélectionnés de tous les serveurs de la forêt + Active Directory. Une requête vers le + Catalogue Global permet donc d'atteindre tous les domaines en une + seule fois, sans avoir à se connecter aux différents serveurs, via + des liaisons dont certaines peuvent être lentes.
+ +Lorsqu'il est activé, la Catalogue Global est un serveur + d'annuaire indépendant accessible sur le port 3268 (3269 pour SSL). + Pour rechercher un utilisateur, effectuez une recherche sur + l'attribut userPrincipalName, avec une base de recherche + vide, comme suit :
+ +AuthLDAPBindDN apache@example.com +AuthLDAPBindPassword password +AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub+ + +
Les utilisateurs devront s'authentifier en entrant leur UPN, de + la formeuntel@nz.example.com.
+ +Normalement, FrontPage utilise des fichiers utilisateur/groupe
+ spécifiques à FrontPage-web (c'est à dire les modules
+ mod_authn_file et
+ mod_authz_groupfile) pour effectuer toute
+ l'authentification. Malheureusement, il ne suffit pas de modifier
+ l'authentification LDAP en ajoutant les directives appropriées, car
+ ceci corromprait les formulaires de Permissions dans le
+ client FrontPage, qui sont censés modifier les fichiers
+ d'autorisation standards au format texte.
Lorsqu'un site web FrontPage a été créé, lui adjoindre
+ l'authentification LDAP consiste à ajouter les directives suivantes
+ à chaque fichier .htaccess qui sera créé dans
+ le site web :
AuthLDAPURL "the url" +AuthGroupFile "mygroupfile" +Require group "mygroupfile"+ + +
FrontPage restreint l'accès à un site web en ajoutant la
+ directive Require valid-user aux fichiers
+ .htaccess. La directive Require valid-user
+ permettra l'accès à tout utilisateur valide du point de vue
+ LDAP. Cela signifie que tout utilisateur possédant une entrée
+ dans l'annuaire LDAP sera considéré comme valide, alors que
+ FrontPage ne considère comme valides que les utilisateurs
+ enregistrés dans le fichier des utilisateurs local. En remplaçant
+ l'autorisation par groupe LDAP par une autorisation par fichier de
+ groupe, Apache sera en mesure de consulter le fichier des
+ utilisateurs local (géré par FrontPage) - au lieu de l'annuaire LDAP
+ - lors du processus d'autorisation des utilisateurs.
Une fois les directives ajoutées selon ce qui précède, les + utilisateurs FrontPage pourront effectuer toutes les opérations de + gestion à partir du client FrontPage.
+ + +mod_authn_file. A cette fin,
+ l'UID est idéal.mod_auth_basic, mod_authn_file
+ et mod_authz_groupfile. Ceci est dû au fait
+ qu'Apache doit utiliser le fichier de groupes de
+ mod_authz_groupfile pour déterminer le niveau
+ d'accès d'un utilisateur au site web FrontPage..htaccess. Elles ne fonctionneront pas si vous les
+ placez dans une section <Location> ou <Directory>. Ceci est dû au fait que pour savoir
+ où se trouve la liste des utilisateurs valides,
+ mod_authnz_ldap doit être en mesure d'atteindre
+ la directive AuthGroupFile qui se trouve
+ dans les fichiers .htaccess de FrontPage. Si les directives
+ de mod_authnz_ldap ne sont pas situées dans le
+ même fichier .htaccess que les directives FrontPage,
+ la configuration ne fonctionnera pas, car
+ mod_authnz_ldap ne sera jamais en mesure de
+ traiter le fichier .htaccess, et par conséquent ne
+ pourra jamais trouver le fichier des utilisateurs géré par
+ FrontPage.| Description: | Spécifie le préfixe ajouté aux variables d'environnement +durant la phase d'autorisation |
|---|---|
| Syntaxe: | AuthLDAPAuthorizePrefix préfixe |
| Défaut: | AuthLDAPAuthorizePrefix AUTHORIZE_ |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
| Compatibilité: | Disponible depuis la version 2.3.6 |
Cette directive permet de spécifier le préfixe ajouté aux + variables d'environnement durant la phase d'autorisation. Si la + valeur spécifiée est AUTHENTICATE_, les utilisateurs de ces + variables d'environnement verront les mêmes informations, que le + serveur effectue une authentification, une autorisation, ou les + deux.
+ +Require
+ valid-user.
+ | Description: | Détermine si l'on doit utiliser d'autres fournisseurs +d'authentification lorsque le serveur ne peut pas valider les données +d'authentification de l'utilisateur, alors que ce dernier possède un +DN. |
|---|---|
| Syntaxe: | AuthLDAPBindAuthoritative off|on |
| Défaut: | AuthLDAPBindAuthoritative on |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
Par défaut, des fournisseurs d'authentification sont appelés
+ si un utilisateur ne possède pas de DN, mais ne le sont pas si
+ l'utilisateur possède un DN et si son mot de passe ne peut pas être
+ vérifié lors d'une connexion au serveur LDAP. Si la directive
+ AuthLDAPBindAuthoritative est
+ définie à off, d'autres modules d'authentification
+ configurés auront une chance de valider le mot de passe de
+ l'utilisateur si la tentative de connexion au serveur LDAP échoue
+ pour une raison quelconque (avec les données d'authentification
+ fournies).
Ceci permet aux utilisateurs présent à la fois dans l'annuaire
+ LDAP et dans un fichier AuthUserFile de s'authentifier
+ lorsque le serveur LDAP est disponible, alors que le compte de
+ l'utilisateur est verrouillé ou que son mot de passe est
+ inutilisable pour une raison quelconque.
| Description: | Un DN optionnel pour se connecter au serveur +LDAP |
|---|---|
| Syntaxe: | AuthLDAPBindDN dn |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
Cette directive permet de définir un DN optionnel pour se
+ connecter au serveur afin d'y rechercher des entrées. Si aucun DN
+ n'est spécifié, mod_authnz_ldap tentera une
+ connexion anonyme.
| Description: | Mot de passe à utiliser en conjonction avec le DN de +connexion |
|---|---|
| Syntaxe: | AuthLDAPBindPassword mot-de-passe |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
| Compatibilité: | exec: est disponible depuis la version 2.4.5 du +serveur HTTP Apache. |
Cette directive permet de spécifier un mot de passe à utiliser en
+ conjonction avec le DN de connexion. Notez que ce mot de passe
+ constitue en général une donnée sensible, et doit donc être protégé
+ de manière appropriée. Vous ne devez utiliser les directives
+ AuthLDAPBindDN et
+ AuthLDAPBindPassword que si
+ vous en avez vraiment besoin pour effectuer une recherche dans
+ l'annuaire.
Si la valeur spécifiée débute par "exec:", la commande qui suit sera + exécutée, et la première ligne renvoyée par la commande sur la + sortie standard sera utilisée comme mot de passe.
+# Mot de passe spécifié directement +AuthLDAPBindPassword secret + +# Exécution de /path/to/program pour obtenir le mot de passe +AuthLDAPBindPassword exec:/path/to/program + +# Exécution de /path/to/otherProgram avec un argument pour obtenir le mot de passe +AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"+ + + +
| Description: | Chemin du fichier de configuration de la correspondance +langage/jeu de caractères |
|---|---|
| Syntaxe: | AuthLDAPCharsetConfig chemin-fichier |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
La directive AuthLDAPCharsetConfig permet
+ de définir le chemin du fichier de configuration de la
+ correspondance langage/jeu de caractères. chemin-fichier
+ est un chemin relatif au répertoire défini par la directive
+ ServerRoot. Ce fichier contient une liste
+ de correspondances extension de langage/jeu de caractères. La
+ plupart des administrateurs utilisent le fichier
+ charset.conv fourni qui associe les extensions de
+ langage courantes à leurs jeux de caractères.
Le fichier contient des lignes au format suivant :
+ +
+ extension de langage jeu de caractères
+ [Nom du langage] ...
+
L'extension est insensible à la casse. Les lignes vides et les
+ lignes commençant par un dièse (#) sont ignorées.
| Description: | Utilisation des données d'authentification de l'utilisateur +pour effectuer les comparaisons pour l'attribution des autorisations |
|---|---|
| Syntaxe: | AuthLDAPCompareAsUser on|off |
| Défaut: | AuthLDAPCompareAsUser off |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
| Compatibilité: | Disponible depuis la version version 2.3.6 |
Lorsque cette directive est définie, et si
+ mod_authnz_ldap a authentifié l'utilisateur, les
+ recherches LDAP pour les autorisations utilisent le nom distinctif
+ trouvé (DN) et le mot de passe d'authentification basique HTTP de
+ l'utilisateur authentifié au lieu des données d'authentification
+ configurées au niveau du serveur.
Les vérifications d'autorisation ldap-attribute, + ldap-user, et ldap-group (niveau simple seulement) + utilisent des comparaisons.
+ +Cette directive n'a d'effet sur les comparaisons effectuées au
+ cours des traitements de groupe imbriqués, et lorsque la directive
+ AuthLDAPSearchAsUser
+ est aussi activée.
Cette directive ne doit être utilisée que si votre serveur LDAP
+ n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
+ utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.
+
| Description: | Utilise le serveur LDAP pour comparer les DNs |
|---|---|
| Syntaxe: | AuthLDAPCompareDNOnServer on|off |
| Défaut: | AuthLDAPCompareDNOnServer on |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
Lorsque cette directive est définie à on,
+ mod_authnz_ldap utilise le serveur LDAP pour
+ comparer les DNs. Il s'agit de la seule méthode infaillible pour
+ comparer les DNs. mod_authnz_ldap va rechercher
+ dans l'annuaire le DN spécifié par la directive Require dn, puis extraire ce DN et le
+ comparer avec le DN extrait de l'entrée de l'utilisateur. Si cette
+ directive est à off, mod_authnz_ldap effectue une
+ simple comparaison de chaînes. Cette dernière approche peut produire
+ des faux négatifs, mais elle est beaucoup plus rapide. Notez
+ cependant que le cache de mod_ldap peut accélérer
+ la comparaison de DNs dans la plupart des situations.
| Description: | À quel moment le module va déréférencer les +alias |
|---|---|
| Syntaxe: | AuthLDAPDereferenceAliases never|searching|finding|always |
| Défaut: | AuthLDAPDereferenceAliases always |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
Cette directive permet de spécifier à quel moment
+ mod_authnz_ldap va déréférencer les alias au cours
+ des opérations liées à LDAP. La valeur par défaut est
+ always.
| Description: | L'attribut LDAP utilisé pour vérifier l'appartenance d'un +utilisateur à un groupe. |
|---|---|
| Syntaxe: | AuthLDAPGroupAttribute attribut |
| Défaut: | AuthLDAPGroupAttribute member uniquemember |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
Cette directive permet de spécifier quel attribut LDAP est
+ utilisé pour vérifier l'appartenance d'un utilisateur à un
+ groupe. On peut spécifier plusieurs attributs en répétant cette
+ directive plusieurs fois. Si la directive n'est pas définie,
+ mod_authnz_ldap utilise les attributs
+ member et uniquemember.
| Description: | Utilise le DN de l'utilisateur pour vérifier son +appartenance à un groupe |
|---|---|
| Syntaxe: | AuthLDAPGroupAttributeIsDN on|off |
| Défaut: | AuthLDAPGroupAttributeIsDN on |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
Lorsqu'elle est définie à on, cette directive
+ indique que c'est le DN de l'utilisateur qui doit être utilisé pour
+ vérifier son appartenance à un groupe. Dans le cas contraire, c'est
+ le nom de l'utilisateur qui sera utilisé. Par exemple, supposons que
+ le client envoie le nom d'utilisateur bjenson, qui
+ correspond au DN LDAP cn=Babs Jenson,o=Example. Si la
+ directive est à on, mod_authnz_ldap va
+ vérifier si cn=Babs Jenson, o=Example est un membre du
+ groupe. Dans le cas contraire, mod_authnz_ldap
+ vérifiera si bjenson est un membre du groupe.
| Description: | Détermine si le serveur effectue la recherche initiale du +DN en utilisant le nom propre de l'utilisateur pour l'authentification +de base +et non de manière anonyme, ou en utilisant des données d'authentification +codées en dur pour le serveur |
|---|---|
| Syntaxe: | AuthLDAPInitialBindAsUser off|on |
| Défaut: | AuthLDAPInitialBindAsUser off |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
| Compatibilité: | Disponible depuis la version 2.3.6 |
Par défaut, le serveur convertit le nom d'utilisateur pour + l'authentification de base en nom distinctif LDAP (DN) soit de + manière anonyme, soit avec un couple nom/mot de passe dédié. Cette + directive permet de forcer le serveur à utiliser les véritables nom + d'utilisateur et mot de passe fournis par l'utilisateur pour + effectuer la recherche initiale du DN.
+ +Si le nom d'utilisateur ne peut pas s'authentifier directement
+ et nécessite de légères modifications, voir la directive AuthLDAPInitialBindPattern.
Cette directive ne doit être utilisée que si votre serveur LDAP
+ n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
+ utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.
+
| Description: | Spécifie la modification a apporter au nom d'utilisateur +pour l'authentification de base lors de l'authentification auprès du +serveur LDAP pour effectuer une recherche de DN |
|---|---|
| Syntaxe: | AuthLDAPInitialBindPattern regex substitution |
| Défaut: | AuthLDAPInitialBindPattern (.*) $1 (nom de l'utilisateur
+distant utilisé tel quel) |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
| Compatibilité: | Disponible depuis la version 2.3.6 |
Si la directive AuthLDAPInitialBindAsUser est
+ définie à ON, le nom utilisateur pour l'authentification de
+ base sera transformé selon l'expression rationnelle
+ regex et l'argument substitution spécifiés.
L'expression rationnelle est comparée au nom d'utilisateur pour + l'authentification de base courant. L'argument + substitution peut contenir des références arrières, mais + n'effectue aucune autre interpolation de variable.
+ +Cette directive ne doit être utilisée que si votre serveur LDAP
+ n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
+ utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.
+
AuthLDAPInitialBindPattern (.+) $1@example.com+ +
AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com+ + +
| Description: | Spécifie la profondeur d'imbrication des sous-groupes +maximale prise en compte avant l'abandon de la recherche de +l'utilisateur. |
|---|---|
| Syntaxe: | AuthLDAPMaxSubGroupDepth Nombre |
| Défaut: | AuthLDAPMaxSubGroupDepth 10 |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
| Compatibilité: | Disponible à partir de la version 2.3.0 du serveur HTTP +Apache |
Lorsque cette directive est définie à une valeur X
+ non nulle, en combinaison avec l'utilisation de la directive
+ Require ldap-group DN-groupe, les données de connexion
+ fournies seront utilisées pour vérifier l'appartenance de
+ l'utilisateur à l'objet de l'annuaire DN-groupe ou à
+ tout sous-groupe du groupe courant en tenant compte de la profondeur
+ d'imbrication maximale X spécifiée par la directive.
Se référer à la section Require
+ ldap-group pour un exemple plus détaillé.
Lorsque les directives
+ AuthLDAPSubGroupAttribute et
+ AuthLDAPGroupAttribute se recouvrent (comme
+ c'est le cas par défaut et requis par les schémas LDAP courants), la
+ recherche de sous-groupes au sein de grands groupes peut être très
+ longue. Si vos groupes sont très grands et non imbriqués, définissez
+ la directive AuthLDAPMaxSubGroupDepth à 0.
| Description: | Spécifie l'attribut dont la valeur renvoyée au cours de la +requête de l'utilisateur sera utilisée pour définir la variable +d'environnement REMOTE_USER |
|---|---|
| Syntaxe: | AuthLDAPRemoteUserAttribute uid |
| Défaut: | none |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
Lorsque cette directive est définie, la variable d'environnement
+ REMOTE_USER sera définie à la valeur de l'attribut
+ spécifié. Assurez-vous que cet attribut soit bien inclus dans la
+ liste d'attributs spécifiés dans la définition de AuthLDAPUrl ; dans
+ le cas contraire, cette directive n'aurait aucun effet. Si elle est
+ présente, cette directive l'emporte sur AuthLDAPRemoteUserIsDN. Elle
+ peut s'avérer utile par exemple, si vous souhaitez que les
+ utilisateurs se connectent à un site web en utilisant leur adresse
+ email, alors qu'une application sous-jacente nécessite un nom
+ d'utilisateur comme identifiant.
| Description: | Utilise le DN de l'utilisateur pour définir la variable +d'environnement REMOTE_USER |
|---|---|
| Syntaxe: | AuthLDAPRemoteUserIsDN on|off |
| Défaut: | AuthLDAPRemoteUserIsDN off |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
Lorsque cette directive est à on, la variable d'environnement
+ REMOTE_USER sera définie avec la valeur du DN complet
+ de l'utilisateur authentifié, et non plus avec simplement le nom
+ d'utilisateur fourni par le client. Elle est définie à off par
+ défaut.
| Description: | Utilise les données d'authentification de l'utilisateur +pour la recherche des autorisations |
|---|---|
| Syntaxe: | AuthLDAPSearchAsUser on|off |
| Défaut: | AuthLDAPSearchAsUser off |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
| Compatibilité: | Disponible depuis la version 2.3.6 |
Lorsque cette directive est définie, et si
+ mod_authnz_ldap a authentifié l'utilisateur, les
+ recherches LDAP pour définir les autorisations utilisent le nom
+ distinctif (DN) trouvé et le mot de passe pour l'authentification de
+ base HTTP de l'utilisateur authentifié, au lieu des données
+ d'authentification configurées au niveau du serveur.
Les vérifications d'autorisation ldap-filter et + ldap-dn utilisent des recherches.
+ +Cette directive n'a d'effet sur les comparaisons effectuées au
+ cours des traitements de groupe imbriqués, et lorsque la directive
+ AuthLDAPCompareAsUser
+ est aussi activée.
Cette directive ne doit être utilisée que si votre serveur LDAP
+ n'autorise pas les recherches anonymes, ou si vous ne pouvez pas
+ utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.
+
| Description: | Spécifie les noms d'attribut, un par directive, utilisés +pour différencier les membres du groupe courant qui sont eux-mêmes des +groupes. |
|---|---|
| Syntaxe: | AuthLDAPSubGroupAttribute attribut |
| Défaut: | AuthLDAPSubgroupAttribute member uniquemember |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
| Compatibilité: | Disponible à partir de la version 2.3.0 du serveur HTTP +Apache |
Un objet groupe LDAP peut contenir des membres qui sont des
+ utilisateurs et des membres qui sont eux-mêmes des groupes (appelés
+ sous-groupes ou groupes imbriqués). La directive
+ AuthLDAPSubGroupAttribute spécifie l'attribut utilisé
+ pour identifier les groupes, alors que la directive
+ AuthLDAPGroupAttribute
+ spécifie l'attribut utilisé pour identifier les utilisateurs. On peut
+ spécifier plusieurs attributs en répétant la directive plusieurs fois. Si
+ elle n'est pas définie, mod_authnz_ldap utilise les
+ attributs member et uniqueMember.
| Description: | Spécifie quelles valeurs d'objectClass LDAP identifient les +objets de l'annuaire qui sont des groupes au cours du traitement des +sous-groupes. |
|---|---|
| Syntaxe: | AuthLDAPSubGroupClass ObjectClass-LDAP |
| Défaut: | AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
| Compatibilité: | Disponible à partir de la version 2.3.0 du serveur HTTP +Apache |
Un objet groupe LDAP peut contenir des membres qui sont des
+ utilisateurs et des membres qui sont eux-mêmes des groupes (appelés
+ sous-groupes ou groupes imbriqués). La directive
+ AuthLDAPSubGroupAttribute
+ permet d'identifier les
+ membres qui sont des sous-groupes du groupe courant (à l'opposé des
+ membres utilisateurs). La directive
+ AuthLDAPSubGroupClass permet de spécifier les valeurs
+ d'objectClass LDAP utilisées pour vérifier que certains membres sont
+ en fait des objets groupe. Les sous-groupes ainsi identifiés peuvent
+ alors faire l'objet d'une recherche d'autres membres utilisateurs ou
+ sous-groupes. On peut spécifier plusieurs attributs en répétant
+ cette directive plusieurs fois. Si cette directive n'est pas
+ définie, mod_authnz_ldap utilise les attributs
+ groupOfNames et groupOfUniqueNames.
| Description: | L'URL permettant de spécifier les paramètres de la +recherche LDAP |
|---|---|
| Syntaxe: | AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS] |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authnz_ldap |
Une URL conforme à la RFC 2255 qui permet de spécifier les + paramètres à utiliser pour la recherche dans l'annuaire LDAP. La + syntaxe de l'URL est :
+ldap://hôte:port/DN-de-base?attribut?portée?filtre
Si vous souhaitez mettre à la disposition d'Apache plusieurs URLs + LDAP, la syntaxe sera :
+AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..."+ +
Mise en garde : Si vous spécifiez plusieurs +serveurs, vous devez en entourer la liste avec des guillemets ; dans le +cas contraire, vous générerez une erreur : "AuthLDAPURL takes one +argument, URL to define LDAP connection..". Vous pouvez bien +entendu ajouter des paramètres de recherche à chacun des serveurs +spécifiés.
+ +ldap. Pour ldap sécurisé, utilisez à la place la
+ chaîne ldaps. LDAP sécurisé n'est disponible que si
+ Apache a été lié avec une bibliothèque LDAP supportant SSL.Il s'agit du nom/port du serveur ldap
+ (dont la valeur par défaut est
+ localhost:389 pour ldap, et
+ localhost:636 pour ldaps). Pour
+ spécifier plusieurs serveurs LDAP redondants, indiquez
+ simplement leur liste en les séparant par des espaces.
+ mod_authnz_ldap tentera alors de se connecter
+ à chacun des serveurs jusqu'à ce qu'il parvienne à se
+ connecter avec succès. Notez qu'en cas de multiples serveurs
+ LDAP, l'ensemble de l'URL LDAP doit être entourée de
+ guillemets.
lorsqu'une connection a été établie avec un serveur, elle
+ reste active pendant toute la durée de vie du processus
+ httpd, ou jusqu'à ce que le serveur LDAP
+ cesse de fonctionner.
Si le serveur LDAP cesse de fonctionner, et ainsi
+ interrompt une
+ connexion existante, mod_authnz_ldap tentera
+ de se reconnecter en commençant par le premier serveur de la
+ liste, et ainsi de suite avec les serveurs redondants
+ suivants. Notez que ce processus n'a rien à voir avec une
+ véritable recherche de type round-robin.
uid. Il est judicieux de choisir un
+ attribut dont la valeur sera unique parmi toutes les entrées de
+ la branche de l'annuaire que vous aurez définie. Tous les
+ attributs spécifiés seront enregistrés dans des variables
+ d'environnement avec le préfixe AUTHENTICATE_, afin de pouvoir
+ être utilisés par d'autres modules.one ou sub. Notez que la
+ RFC 2255 supporte aussi une portée de valeur base,
+ mais cette dernière n'est pas supportée par le module. Si la
+ portée n'est pas définie, ou si elle est définie à
+ base, c'est la valeur de portée par défaut
+ sub qui sera utilisée.(objectClass=*) sera utilisé, ce qui corrspond à
+ une recherche de tous les types d'objets de l'arborescence. La
+ taille des filtres est limitée à environ 8000 caractères (valeur
+ de la macro MAX_STRING_LEN dans le code source
+ d'Apache), ce qui s'avère plus que suffisant pour la plupart des
+ applications. Depuis la version 2.4.10, il est possible
+ d'utiliser le paramètre none pour spécifier qu'aucun filtre
+ n'est activé ; ce paramètre est obligatoire avec certains
+ serveurs LDAP primitifs.Pour une recherche, les attribut, filtre et nom d'utilisateur
+ fournis par le client HTTP sont combinés pour créer un filtre de
+ recherche du style :
+ (&(filtre)(attribut
+ =nom-utilisateur)).
Par exemple, considérons l'URL
+ ldap://ldap.example.com/o=Example?cn?sub?(posixid=*).
+ Lorsqu'un client tentera de se connecter en utilisant le nom
+ d'utilisateur Babs Jenson, le filtre de recherche sera
+ : (&(posixid=*)(cn=Babs Jenson)).
On peut encore ajouter un paramètre optionnel pour permettre à + l'URL LDAP de surcharger le type de connexion. Ce paramètre peut + prendre l'une des valeurs suivantes :
+ +ldap:// sur le port
+ 389.ldaps://.Voir plus haut pour des exemples d'URLs définies par la directive
+ AuthLDAPUrl.
Serveur HTTP Apache Version 2.4
+| Description: | Autorisation basique |
|---|---|
| Statut: | Base |
| Identificateur de Module: | authz_core_module |
| Fichier Source: | mod_authz_core.c |
| Compatibilité: | Disponible depuis la version 2.3 +d'Apache HTTPD |
Ce module fournit des fonctionnalités d'autorisation basiques
+ permettant d'accorder ou refuser l'accès à certaines zones du site
+ web aux utilisateurs authentifiés. mod_authz_core
+ donne la possibilité d'enregistrer divers fournisseurs
+ d'autorisation. Il est en général utilisé avec un module fournisseur
+ d'authentification comme mod_authn_file, et un
+ module d'autorisation comme mod_authz_user. Il
+ permet aussi l'application d'une logique élaborée au déroulement du
+ processus d'autorisation.
Conteneurs d'autorisation Les directives Require Création des alias du fournisseur
+d'autorisation AuthMerging <AuthzProviderAlias> AuthzSendForbiddenOnFailure Require <RequireAll> <RequireAny> <RequireNone>Les directives de conteneur d'autorisation <RequireAll>,
+ <RequireAny> et <RequireNone>
+ peuvent être combinées entre elles et avec la directive Require pour confectionner une
+ logique d'autorisation complexe.
L'exemple ci-dessous illustre la logique d'autorisation suivante.
+ Pour pouvoir accéder à la ressource, l'utilisateur doit être
+ l'utilisateur superadmin, ou appartenir aux deux
+ groupes LDAP admins et Administrateurs et
+ soit appartenir au groupe ventes ou avoir
+ ventes comme valeur de l'attribut LDAP
+ dept. De plus, pour pouvoir accéder à la ressource,
+ l'utilisateur ne doit appartenir ni au groupe temps, ni
+ au groupe LDAP Employés temporaires.
<Directory "/www/mydocs"> + <RequireAll> + <RequireAny> + Require user superadmin + <RequireAll> + Require group admins + Require ldap-group "cn=Administrators,o=Airius" + <RequireAny> + Require group sales + Require ldap-attribute dept="sales" + </RequireAny> + </RequireAll> + </RequireAny> + <RequireNone> + Require group temps + Require ldap-group "cn=Temporary Employees,o=Airius" + </RequireNone> + </RequireAll> +</Directory>+ +
Le module mod_authz_core met à disposition des
+ fournisseurs d'autorisation génériques utilisables avec la directive
+ Require.
Le fournisseur env permet de contrôler l'accès au
+ serveur en fonction de l'existence d'une variable d'environnement. Lorsque Require
+ env env-variable est spécifié, la requête se voit
+ autoriser l'accès si la variable d'environnement
+ env-variable existe. Le serveur permet de définir
+ facilement des variables d'environnement en fonction des
+ caractéristiques de la requête du client via les directives fournies
+ par le module mod_setenvif. Cette directive Require
+ env permet donc de contrôler l'accès en fonction des
+ valeurs des en-têtes de la requête HTTP tels que
+ User-Agent (type de navigateur), Referer,
+ entre autres.
SetEnvIf User-Agent "^KnockKnock/2\.0" let_me_in +<Directory "/docroot"> + Require env let_me_in +</Directory>+ + +
Avec cet exemple, les navigateurs dont la chaîne user-agent
+ commence par KnockKnock/2.0 se verront autoriser
+ l'accès, alors que tous les autres seront rejetés.
Lorsque le serveur cherche un chemin via une sous-requête interne (par exemple la
+ recherche d'un DirectoryIndex), ou lorsqu'il génère un
+ listing du contenu d'un répertoire via le module
+ mod_autoindex, la sous-requête n'hérite pas des
+ variables d'environnement spécifiques à la requête. En outre, à cause
+ des phases de l'API auxquelles mod_setenvif prend
+ part, les directives SetEnvIf ne sont pas évaluées
+ séparément dans la sous-requête.
Le fournisseur all reproduit la fonctionnalité
+ précédemment fournie par les directives 'Allow from all' et 'Deny
+ from all'. Il accepte un argument dont les deux valeurs possibles
+ sont : 'granted' ou 'denied'. Les exemples suivants autorisent ou
+ interdisent l'accès à toutes les requêtes.
Require all granted+ + +
Require all denied+ + + + +
Le fournisseur method permet d'utiliser la méthode
+ HTTP dans le processus d'autorisation. Les méthodes GET et HEAD sont
+ ici considérées comme équivalentes. La méthode TRACE n'est pas
+ supportée par ce fournisseur ; utilisez à la place la directive
+ TraceEnable.
Dans l'exemple suivant, seules les méthodes GET, HEAD, POST, et + OPTIONS sont autorisées :
+ +Require method GET POST OPTIONS+ + +
Dans l'exemple suivant, les méthodes GET, HEAD, POST, et OPTIONS + sont autorisées sans authentification, alors que toutes les autres + méthodes nécessitent un utilisateur valide :
+ +<RequireAny> + Require method GET POST OPTIONS + Require valid-user +</RequireAny>+ + + +
Le fournisseur expr permet d'accorder l'autorisation
+ d'accès de base en fonction d'expressions arbitraires.
Require expr "%{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17"
+
+
+ <RequireAll>
+ Require expr "!(%{QUERY_STRING} =~ /secret/)"
+ Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
+</RequireAll>
+
+
+ Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
+
+
+ La syntaxe de l'expression est décrite dans la documentation de ap_expr. Avant la version 2.4.16, les doubles-quotes + étaient prohibées
+ +Normalement, l'expression est évaluée avant l'authentification.
+ Cependant, si l'expression renvoie false et se réfère à la variable
+ %{REMOTE_USER}, le processus d'authentification sera
+ engagé et l'expression réévaluée.
Il est possible de créer des fournisseurs d'autorisation étendus
+ dans le fichier de configuration et de leur assigner un nom d'alias.
+ On peut ensuite utiliser ces fournisseurs aliasés dans une
+ directive Require de
+ la même manière qu'on le ferait pour des fournisseurs d'autorisation
+ de base. En plus de la possibilité de créer et d'aliaser un
+ fournisseur étendu, le même fournisseur d'autorisation étendu peut
+ être référencé par plusieurs localisations.
+
Dans l'exemple suivant, on crée deux alias de fournisseur + d'autorisation ldap différents basés sur le fournisseur + d'autorisation ldap-group. Il est ainsi possible pour un seul + répertoire de vérifier l'appartenance à un groupe dans plusieurs + serveurs ldap : +
+ +<AuthzProviderAlias ldap-group ldap-group-alias1 "cn=my-group,o=ctx"> + AuthLDAPBindDN "cn=youruser,o=ctx" + AuthLDAPBindPassword yourpassword + AuthLDAPURL "ldap://ldap.host/o=ctx" +</AuthzProviderAlias> + +<AuthzProviderAlias ldap-group ldap-group-alias2 "cn=my-other-group,o=dev"> + AuthLDAPBindDN "cn=yourotheruser,o=dev" + AuthLDAPBindPassword yourotherpassword + AuthLDAPURL "ldap://other.ldap.host/o=dev?cn" +</AuthzProviderAlias> + +Alias "/secure" "/webpages/secure" +<Directory "/webpages/secure"> + Require all granted + + AuthBasicProvider file + + AuthType Basic + AuthName LDAP_Protected_Place + + #implied OR operation + Require ldap-group-alias1 + Require ldap-group-alias2 +</Directory>+ + + +
| Description: | Définit la manière dont chaque logique d'autorisation des +sections de configuration se combine avec celles des sections de +configuration précédentes. |
|---|---|
| Syntaxe: | AuthMerging Off | And | Or |
| Défaut: | AuthMerging Off |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_authz_core |
Lorsque l'autorisation est activée, elle est normalement héritée
+ par chaque section de
+ configuration suivante, à moins qu'un jeu de directives
+ d'autorisations différent ne soit spécifié. Il s'agit du
+ comportement par défaut, qui correspond à la définition explicite
+ AuthMerging Off.
Dans certaines situations cependant, il peut être souhaitable de
+ combiner la logique d'autorisation d'une section de configuration
+ avec celle de la section précédente lorsque les sections de
+ configuration se combinent entre elles. Dans ce cas, deux options
+ sont disponibles, And et Or.
Lorsqu'une section de configuration contient AuthMerging
+ And ou AuthMerging Or, sa logique d'autorisation
+ se combine avec celle de la section de configuration qui la précède
+ (selon l'ordre général des sections de configuration), et qui
+ contient aussi une logique d'autorisation, comme si les deux
+ sections étaient concaténées respectivement dans une directive
+ <RequireAll> ou <RequireAny>.
AuthMerging ne concerne que la section de
+ configuration dans laquelle elle apparaît. Dans l'exemple suivant,
+ seuls les utilisateurs appartenant au groupe alpha sont
+ autorisés à accéder à /www/docs. Les utilisateurs
+ appartenant au groupe alpha ou au groupe
+ beta sont autorisés à accéder à
+ /www/docs/ab. Cependant, la définition implicite à
+ Off de la directive AuthMerging
+ s'applique à la section de configuration <Directory> concernant le répertoire
+ /www/docs/ab/gamma, ce qui implique que les directives
+ d'autorisation de cette section l'emportent sur celles des sections
+ précédentes. Par voie de conséquence, seuls les utilisateurs
+ appartenant au groupe gamma sont autorisés à accéder à
+ /www/docs/ab/gamma.<Directory "/www/docs"> + AuthType Basic + AuthName Documents + AuthBasicProvider file + AuthUserFile "/usr/local/apache/passwd/passwords" + Require group alpha +</Directory> + +<Directory "/www/docs/ab"> + AuthMerging Or + Require group beta +</Directory> + +<Directory "/www/docs/ab/gamma"> + Require group gamma +</Directory>+ + +
| Description: | Regroupe des directives représentant une extension d'un +fournisseur d'autorisation de base qui pourra être référencée à l'aide +de l'alias spécifié |
|---|---|
| Syntaxe: | <AuthzProviderAlias fournisseur-de-base Alias
+Paramètres-Require>
+... </AuthzProviderAlias>
+ |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_authz_core |
Les balises <AuthzProviderAlias> et
+ </AuthzProviderAlias> permettent de regrouper des
+ directives d'autorisation auxquelles on pourra faire référence à
+ l'aide de l'alias spécifié dans une directive Require.
Si Require-Parameters comporte plusieurs paramètres, la liste + de ces derniers doit être entourée de guillemets. Dans le cas contraire, + seul le premier paramètre de la liste sera pris en compte.
+ +# Dans cet exemple, pour que les deux adresses IP soient prises en compte, elles +# DOIVENT être entourées de guillemets +<AuthzProviderAlias ip blacklisted-ips "XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY"> +</AuthzProviderAlias> + +<Directory "/path/to/dir"> + <RequireAll> + Require not blacklisted-ips + Require all granted + </RequireAll> +</Directory>+ + +
| Description: | Envoie '403 FORBIDDEN' au lieu de '401 UNAUTHORIZED' si +l'authentification réussit et si l'autorisation a été refusée. + |
|---|---|
| Syntaxe: | AuthzSendForbiddenOnFailure On|Off |
| Défaut: | AuthzSendForbiddenOnFailure Off |
| Contexte: | répertoire, .htaccess |
| Statut: | Base |
| Module: | mod_authz_core |
| Compatibilité: | Disponible depuis la version 2.3.11 d'Apache HTTPD |
Par défaut, si l'authentification réussit, alors que
+ l'autorisation est refusée, Apache HTTPD renvoie un code de réponse
+ HTTP '401 UNAUTHORIZED'. En général, les navigateurs proposent alors
+ une nouvelle fois à l'utilisateur la boîte de dialogue de saisie du
+ mot de passe, ce qui n'est pas toujours souhaitable. La directive
+ AuthzSendForbiddenOnFailure permet de changer
+ le code de réponse en '403 FORBIDDEN'.
La modification de la réponse en cas de refus d'autorisation + diminue la sécurité du mot de passe, car elle indique à un éventuel + attaquant que le mot de passe qu'il a saisi était correct.
+| Description: | Vérifie si un utilisateur authentifié a une +autorisation d'accès accordée par un fournisseur +d'autorisation. |
|---|---|
| Syntaxe: | Require [not] nom-entité [nom-entité]
+... |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_authz_core |
Cette directive permet de vérifier si un utilisateur authentifié
+ a l'autorisation d'accès accordée pour un certain fournisseur
+ d'autorisation et en tenant compte de certaines restrictions.
+ mod_authz_core met à disposition les fournisseurs
+ d'autorisation génériques suivants :
Require all grantedRequire all deniedRequire env env-var [env-var]
+ ...Require method http-method [http-method]
+ ...Require expr expression Voici quelques exemples de syntaxes autorisées par
+ mod_authz_user, mod_authz_host et
+ mod_authz_groupfile :
Require user identifiant utilisateur
+ [identifiant utilisateur]
+ ...Require group nom groupe [nom
+ groupe]
+ ...Require valid-userRequire ip 10 172.20 192.168.2D'autres modules d'autorisation comme
+ mod_authnz_ldap, mod_authz_dbm,
+ mod_authz_dbd,
+ mod_authz_owner et mod_ssl
+ implémentent des options de la directive Require.
Pour qu'une configuration d'authentification et d'autorisation
+ fonctionne correctement, la directive Require
+ doit être accompagnée dans la plupart des cas de directives AuthName, AuthType et AuthBasicProvider ou AuthDigestProvider, ainsi que
+ de directives telles que AuthUserFile et AuthGroupFile (pour la
+ définition des utilisateurs et des groupes). Exemple :
AuthType Basic +AuthName "Restricted Resource" +AuthBasicProvider file +AuthUserFile "/web/users" +AuthGroupFile "/web/groups" +Require group admin+ + +
Les contrôles d'accès appliqués de cette manière sont effectifs
+ pour toutes les méthodes. C'est d'ailleurs
+ ce que l'on souhaite en général. Si vous voulez n'appliquer
+ les contrôles d'accès qu'à certaines méthodes, tout en laissant les
+ autres méthodes sans protection, placez la directive
+ Require dans une section <Limit>.
Le résultat de la directive Require peut
+ être inversé en utilisant l'option not. Comme dans le
+ cas de l'autre directive d'autorisation inversée <RequireNone>, si la directive
+ Require est inversée, elle ne peut qu'échouer
+ ou produire un résultat neutre ; elle ne peut donc alors pas
+ autoriser une requête de manière indépendante.
Dans l'exemple suivant, tous les utilisateurs appartenant aux
+ groupes alpha et beta ont l'autorisation
+ d'accès, à l'exception de ceux appartenant au groupe
+ reject.
<Directory "/www/docs"> + <RequireAll> + Require group alpha beta + Require not group reject + </RequireAll> +</Directory>+ + +
Lorsque plusieurs directives Require sont
+ placées dans une même section de
+ configuration, et ne se trouvent pas dans une autre directive
+ d'autorisation comme <RequireAll>, elles sont implicitement
+ contenues dans une directive <RequireAny>. Ainsi, la première directive
+ Require qui autorise l'accès à un utilisateur
+ autorise l'accès pour l'ensemble de la requête, et les directives
+ Require suivantes sont ignorées.
Prettez une attention particulière aux directives d'autorisation
+ définies
+ au sein des sections Location
+ qui se chevauchent avec des contenus servis depuis le système de
+ fichiers. Par défaut, les configurations définies dans ces sections l'emportent sur les
+ configurations d'autorisations définies au sein des sections
+ Directory et Files sections.
La directive AuthMerging permet de contrôler
+ la manière selon laquelle les configurations d'autorisations sont
+ fusionnées au sein des sections précitées.
| Description: | Regroupe plusieurs directives d'autorisation dont aucune ne +doit échouer et dont au moins une doit retourner un résultat positif +pour que la directive globale retourne elle-même un résultat +positif. |
|---|---|
| Syntaxe: | <RequireAll> ... </RequireAll> |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_authz_core |
Les balises <RequireAll> et
+ </RequireAll> permettent de regrouper des
+ directives d'autorisation dont aucune ne doit échouer, et dont au
+ moins une doit retourner un résultat positif pour que la directive
+ <RequireAll> retourne elle-même
+ un résultat positif.
Si aucune des directives contenues dans la directive <RequireAll> n'échoue, et si au moins une
+ retourne un résultat positif, alors la directive <RequireAll> retourne elle-même un résultat
+ positif. Si aucune ne retourne un résultat positif, et si aucune
+ n'échoue, la directive globale retourne un résultat neutre. Dans
+ tous les autres cas, elle échoue.
| Description: | Regroupe des directives d'autorisation dont au moins une +doit retourner un résultat positif pour que la directive globale +retourne elle-même un résultat positif. |
|---|---|
| Syntaxe: | <RequireAny> ... </RequireAny> |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_authz_core |
Les balises <RequireAny> et
+ </RequireAny> permettent de regrouper des
+ directives d'autorisation dont au moins une doit retourner un
+ résultat positif pour que la directive <RequireAny> retourne elle-même un résultat
+ positif.
Si une ou plusieurs directives contenues dans la directive
+ <RequireAny> retournent un
+ résultat positif, alors la directive <RequireAny> retourne elle-même un résultat
+ positif. Si aucune ne retourne un résultat positif et aucune
+ n'échoue, la directive globale retourne un résultat neutre. Dans
+ tous les autres cas, elle échoue.
<RequireAny> (elles pourraient tout au plus
+ faire échouer la directive dans le cas où elles échoueraient
+ elles-mêmes, et où
+ toutes les autres directives retourneraient un résultat neutre).
+ C'est pourquoi il n'est pas permis d'utiliser les directives
+ d'autorisation inversées dans une directive <RequireAny>.| Description: | Regroupe des directives d'autorisation dont aucune ne doit +retourner un résultat positif pour que la directive globale n'échoue +pas. |
|---|---|
| Syntaxe: | <RequireNone> ... </RequireNone> |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_authz_core |
Les balises <RequireNone> et
+ </RequireNone> permettent de regrouper des
+ directives d'autorisation dont aucune ne doit retourner un résultat
+ positif pour que la directive <RequireNone> n'échoue pas.
Si une ou plusieurs directives contenues dans la directive
+ <RequireNone> retournent un
+ résultat positif, la directive <RequireNone> échouera. Dans tous les
+ autres cas, cette dernière retournera un résultat neutre. Ainsi,
+ comme pour la directive d'autorisation inversée Require
+ not, elle ne peut jamais autoriser une requête de manière
+ indépendante car elle ne pourra jamais retourner un résultat
+ positif. Par contre, on peut l'utiliser pour restreindre l'ensemble
+ des utilisateurs autorisés à accéder à une ressource.
<RequireNone>.
+ C'est pourquoi il n'est pas permis d'utiliser les directives
+ d'autorisation inversées dans une directive <RequireNone>.Serveur HTTP Apache Version 2.4
+| Description: | Autorisation en groupe et reconnaissance d'identité avec base +SQL |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | authz_dbd_module |
| Fichier Source: | mod_authz_dbd.c |
| Compatibilité: | Disponible dans les versions 2.4 et supérieures +d'Apache |
Ce module fournit des fonctionnalités d'autorisation permettant
+ d'accorder ou de refuser aux utilisateurs authentifiés l'accès à
+ certaines zones du site web en fonction de leur appartenance à tel
+ ou tel groupe. Les modules mod_authz_groupfile et
+ mod_authz_dbm fournissent une fonctionnalité
+ similaire, mais ici le module interroge une base de données SQL pour
+ déterminer si un utilisateur appartient ou non à tel ou tel groupe.
Ce module propose également des fonctionnalités de connexion
+ utilisateur s'appuyant sur une base de données, ce qui peut se révéler
+ particulièrement utile lorsque le module est utilisé conjointement avec
+ mod_authn_dbd.
Ce module s'appuie sur mod_dbd pour spécifier le
+ pilote de la base de données sous-jacente et les paramètres de
+ connexion, et gérer les connexions à la base de données.
Les directives Require Reconnaissance d'identité s'appuyant sur une base de données Reconnaissance d'identité côté client Exemple de configurationRequireAuthDBDUserPWQuery
+DBDriverDBDParamsLes directives Require d'Apache permettent,
+ au cours de la phase d'autorisation, de s'assurer qu'un utilisateur
+ est bien autorisé à accéder à une ressource. mod_authz_dbd ajoute
+ les types d'autorisation dbd-group,
+ dbd-login et dbd-logout.
A partir de la version 2.4.8, les directives require DBD + supportent les expressions.
+ +Cette directive permet de spécifier à quel groupe un utilisateur + doit appartenir pour obtenir l'autorisation d'accès.
+ +Require dbd-group team +AuthzDBDQuery "SELECT group FROM authz WHERE user = %s"+ + + + +
Cette directive permet de spécifier une requête à exécuter pour + indiquer que l'utilisateur s'est authentifié.
+ +Require dbd-login +AuthzDBDQuery "UPDATE authn SET login = 'true' WHERE user = %s"+ + + + +
Cette directive permet de spécifier une requête à exécuter pour + indiquer que l'utilisateur s'est déconnecté.
+ +Require dbd-logout +AuthzDBDQuery "UPDATE authn SET login = 'false' WHERE user = %s"+ + + + +
+Outre sa fonction d'autorisation standard consistant à vérifier +l'appartenance à des groupes, ce module permet aussi de gérer des +sessions utilisateur côté serveur grâce à sa fonctionnalité de connexion utilisateur +en s'appuyant sur une base de données. En particulier, il peut mettre à +jour le statut de session de l'utilisateur dans la base de données +chaque fois que celui-ci visite certaines URLs (sous réserve bien +entendu que l'utilisateur fournissent les informations de connexion +nécessaires).
+Pour cela, il faut definir deux directives Require spéciales : Require
+dbd-login et Require dbd-logout. Pour les détails de
+leur utilisation, voir l'exemple de configuration ci-dessous.
Certains administrateurs peuvent vouloir implémenter une gestion de +session côté client fonctionnant de concert avec les fonctionnalités de +connexion/déconnexion des utilisateurs côté serveur offertes par ce module, en +définissant ou en annulant par exemple un cookie HTTP ou un jeton +similaire lorsqu'un utilisateur se connecte ou se déconnecte.
+ +Pour supporter une telle intégration, mod_authz_dbd exporte
+un programme à déclenchement optionnel (hook) qui sera lancé chaque fois
+que le statut d'un utilisateur sera mis à jour dans la base de données.
+D'autres modules de gestion de session pourront alors utiliser ce
+programme pour implémenter des fonctions permettant d'ouvrir et de
+fermer des sessions côté client.
# configuration de mod_dbd +DBDriver pgsql +DBDParams "dbname=apacheauth user=apache pass=xxxxxx" + +DBDMin 4 +DBDKeep 8 +DBDMax 20 +DBDExptime 300 + +<Directory "/usr/www/mon.site/team-private/"> + # configuration de mod_authn_core et mod_auth_basic + # pour mod_authn_dbd + AuthType Basic + AuthName Team + AuthBasicProvider dbd + + # requête SQL de mod_authn_dbd pour authentifier un utilisateur qui se + # connecte + AuthDBDUserPWQuery \ + "SELECT password FROM authn WHERE user = %s AND login = 'true'" + + # configuration de mod_authz_core pour mod_authz_dbd + Require dbd-group team + + # configuration de mod_authz_dbd + AuthzDBDQuery "SELECT group FROM authz WHERE user = %s" + + # lorsqu'un utilisateur échoue dans sa tentative d'authentification ou + # d'autorisation, on l'invite à se connecter ; cette page doit + # contenir un lien vers /team-private/login.html + ErrorDocument 401 "/login-info.html" + + <Files "login.html"> + # il n'est pas nécessaire que l'utilisateur soit déjà connecté ! + AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s" + + # le processus de connexion dbd exécute une requête pour enregistrer + # la connexion de l'utilisateur + Require dbd-login + AuthzDBDQuery "UPDATE authn SET login = 'true' WHERE user = %s" + + # redirige l'utilisateur vers la page d'origine (si elle existe) + # après une connexion réussie + AuthzDBDLoginToReferer On + </Files> + + <Files "logout.html"> + # le processus de déconnexion dbd exécute une requête pour + # enregistrer la déconnexion de l'utilisateur + Require dbd-logout + AuthzDBDQuery "UPDATE authn SET login = 'false' WHERE user = %s" + </Files> +</Directory>+ +
| Description: | Définit si le client doit être redirigé vers la page
+d'origine en cas de connexion ou de déconnexion réussie si un en-tête
+de requête Referer est présent |
|---|---|
| Syntaxe: | AuthzDBDLoginToReferer On|Off |
| Défaut: | AuthzDBDLoginToReferer Off |
| Contexte: | répertoire |
| Statut: | Extension |
| Module: | mod_authz_dbd |
Utilisée en conjonction avec Require dbd-login ou
+ Require dbd-logout, cette directive permet de rediriger
+ le client vers la page d'origine (l'URL contenue dans l'en-tête
+ de requête HTTP Referer, s'il est présent). En
+ l'absence d'en-tête Referer, la définition
+ AuthzDBDLoginToReferer On sera ignorée.
| Description: | Définit la requête SQL pour l'opération requise |
|---|---|
| Syntaxe: | AuthzDBDQuery requête |
| Contexte: | répertoire |
| Statut: | Extension |
| Module: | mod_authz_dbd |
La directive AuthzDBDQuery permet de
+ spécifier une requête SQL à exécuter. Le but de cette requête dépend
+ de la directive Require en cours de
+ traitement.
Require dbd-group, elle spécifie
+ une requête permettant de rechercher les groupes d'appartenance de
+ l'utilisateur courant. Ceci correspond à la fonctionnalité standard
+ d'autres modules d'autorisation comme
+ mod_authz_groupfile et
+ mod_authz_dbm.
+ La première colonne de chaque enregistrement renvoyé par la requête
+ doit contenir une chaîne de caractères correspondant à un nom de
+ groupe. La requête peut renvoyer zéro, un ou plusieurs
+ enregistrements.
+ Require dbd-group +AuthzDBDQuery "SELECT group FROM groups WHERE user = %s"+ +
Require dbd-login ou
+ Require dbd-logout, elle ne refusera jamais l'accès,
+ mais au contraire exécutera une requête SQL permettant d'enregistrer
+ la connexion ou la déconnexion de l'utilisateur. Ce dernier doit
+ être déjà authentifié avec mod_authn_dbd.
+ Require dbd-login +AuthzDBDQuery "UPDATE authn SET login = 'true' WHERE user = %s"+ +
Dans tous les cas, l'identifiant utilisateur sera transmis comme
+ paramètre sous la forme d'une simple chaîne lorsque la requête SQL
+ sera exécutée. Il y sera fait référence dans la requête en utilisant
+ le spécificateur de format %s.
| Description: | Définit une requête pour rechercher une page vers laquelle +rediriger l'utilisateur après une connexion réussie |
|---|---|
| Syntaxe: | AuthzDBDRedirectQuery requête |
| Contexte: | répertoire |
| Statut: | Extension |
| Module: | mod_authz_dbd |
Spécifie une requête SQL optionnelle à utiliser après une
+ connexion (ou une déconnexion) réussie pour rediriger l'utilisateur
+ vers une URL, qui peut être spécifique à l'utilisateur.
+ L'identifiant utilisateur sera transmis comme paramètre sous la
+ forme d'une simple chaîne lorsque la requête SQL sera exécutée. Il y
+ sera fait référence dans la requête en utilisant le spécificateur de
+ format %s.
AuthzDBDRedirectQuery "SELECT userpage FROM userpages WHERE user = %s"+ +
La première colonne du premier enregistrement renvoyé par la + requête doit contenir une chaîne de caractères correspondant à une + URL vers laquelle rediriger le client. Les enregistrements suivants + sont ignorés. Si aucun enregistrement n'est renvoyé, le client ne + sera pas redirigé.
+Notez que AuthzDBDLoginToReferer l'emporte
+ sur cette directive si les deux sont définies.
Serveur HTTP Apache Version 2.4
+| Description: | Autorisation basée sur les groupes à l'aide de fichiers +DBM |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | authz_dbm_module |
| Fichier Source: | mod_authz_dbm.c |
| Compatibilité: | Disponible depuis les versions 2.1 et supérieures +d'Apache |
Ce module permet d'autoriser ou d'interdire l'accès à certaines
+ zones du site web aux utilisateurs authentifiés en fonction de leur
+ appartenance à un groupe spécifié. Le module
+ mod_authz_groupfile fournit une fonctionnalité
+ similaire.
Les directives Require d'Apache permettent,
+ au cours de la phase d'autorisation, de s'assurer qu'un utilisateur
+ est bien autorisé à accéder à une ressource. mod_authz_dbm ajoute
+ les types d'autorisation dbm-group et dbm-file-group.
A partir de la version 2.4.8, les directives require DBM + supportent les expressions.
+ +Cette directive permet de spécifier à quel groupe un utilisateur + doit appartenir pour obtenir l'autorisation d'accès.
+ +Require dbm-group admin+ + + + +
Lorsque cette directive est définie, l'utilisateur doit + appartenir au groupe du fichier pour pouvoir y accéder.
+ +Require dbm-file-group+ + + + +
Notez que si vous utilisez mod_authz_dbm, le mot-clé pour les
+groupes d'authentification qui était auparavant group est
+maintenant dbm-group :
+
<Directory "/foo/bar"> + AuthType Basic + AuthName "Secure Area" + AuthBasicProvider dbm + AuthDBMUserFile "site/data/users" + AuthDBMGroupFile "site/data/users" + Require dbm-group admin +</Directory>+ +
| Description: | Définit le nom du fichier de base de données contenant la +liste des groupes d'utilisateurs permettant de définir les +autorisations des utilisateurs |
|---|---|
| Syntaxe: | AuthDBMGroupFile chemin-fichier |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authz_dbm |
La directive AuthDBMGroupFile sert à
+ définir le nom d'un fichier DBM contenant la liste des groupes
+ d'utilisateurs. Les utilisateurs peuvent dès lors se voir autoriser ou
+ refuser leurs accès selon l'appartenance à tel ou tel groupe.
+ chemin-fichier est le chemin absolu du
+ fichier de groupes.
La clé du fichier de groupes est le nom d'utilisateur. La valeur + de chaque clé est la liste des groupes, séparés par des virgules, + auxquels l'utilisateur appartient. Cette liste ne doit comporter + ni espace, ni caractère ':'.
+ +Le fichier spécifié par la directive
+AuthDBMGroupFile doit être situé en dehors de
+l'arborescence des documents du serveur web. Ne le placez
+surtout pas dans le répertoire qu'il protège, faute
+de quoi, les clients pourraient le télécharger, en l'abscence de
+protection supplémentaire.
Utilisation combinée de fichiers DBM de groupes et de mots de + passe : dans certains cas, il est plus simple de gérer une seule + base de données contenant les groupes et mots de passe de chaque + utilisateur. L'écriture de programmes de support en est ainsi + simplifiée car ils n'ont plus qu'un seul fichier DBM à gérer et + à verrouiller. Pour ce faire, on attribue le même nom de fichier + DBM aux fichiers de groupes et de mots de passe :
+ +AuthDBMGroupFile "/www/userbase" +AuthDBMUserFile "/www/userbase"+ + +
La clé du fichier DBM unique est le nom d'utilisateur. La + valeur associée à la clé contient :
+ +
+ Mot de passe chiffré : Liste de groupes [ : (ignoré) ]
+
La partie mot de passe contient comme d'habitude le mot de + passe chiffré. Viennent ensuite le caractère ':' et la liste des + groupes séparés par des virgules. Il est possible d'ajouter + d'autres données en fin de ligne après un autre caractère ':', + mais elles seront ignorées par le module d'autorisation. Il s'agit + du format utilisé par www.telescope.org pour sa base de données + combinée groupes et mots de passe.
+ +| Description: | Définit le type de fichier de base de données contenant +la liste des groupes d'utilisateurs |
|---|---|
| Syntaxe: | AuthzDBMType default|SDBM|GDBM|NDBM|DB |
| Défaut: | AuthzDBMType default |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_authz_dbm |
Définit le type de fichier de base de données contenant la + liste des groupes d'utilisateurs. Le type de base de données par + défaut est déterminé à la compilation. Les autres types de bases + de données disponibles dépendent aussi de la + configuration de la + compilation.
+ +Quel que soit le programme que vous utilisez pour créer votre + fichier de groupes, il est impératif que celui-ci soit configuré + pour utiliser le même type de base de données.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Autorisation basée sur les groupes à l'aide de fichiers +textes |
|---|---|
| Statut: | Base |
| Identificateur de Module: | authz_groupfile_module |
| Fichier Source: | mod_authz_groupfile.c |
| Compatibilité: | Disponible depuis les versions 2.1 et supérieures +d'Apache |
Ce module permet d'autoriser ou d'interdire l'accès à
+certaines zones du site web aux utilisateurs authentifiés en
+fonction de leur appartenance à un groupe spécifié. Le module
+mod_authz_dbm fournit une fonctionnalité similaire.
Les directives Require d'Apache permettent,
+ au cours de la phase d'autorisation, de s'assurer qu'un utilisateur
+ est bien autorisé à accéder à une ressource. mod_authz_groupfile ajoute
+ les types d'autorisation group et file-group.
+
A partir de la version 2.4.8, les directives require groupfile + supportent les expressions.
+ +Cette directive permet de spécifier à quel groupe un utilisateur + doit appartenir pour obtenir l'autorisation d'accès.
+ +Require group admin+ + + + +
Lorsque cette directive est définie, Les permissions système du fichier
+ auquel on veut accéder sont vérifiées. L'utilisateur doit être un membre d'un
+ groupe de même nom que le groupe qui possède le fichier. Voir
+ mod_authz_owner pour plus de détails.
Require file-group+ + + + +
| Description: | Définit le nom d'un fichier texte contenant la liste des +groupes d'utilisateurs permettant de définir les autorisations des +utilisateurs |
|---|---|
| Syntaxe: | AuthGroupFile chemin-fichier |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Base |
| Module: | mod_authz_groupfile |
La directive AuthGroupFile permet de définir
+le nom d'un fichier texte contenant la liste des groupes d'utilisateurs.
+L'appartenance d'un utilisateur à tel ou tel groupe pourra dès lors être utilisée
+pour définir les permissions d'accès de l'utilisateur.
+chemin-fichier est le chemin du fichier de groupes. S'il n'est
+pas absolu, ce chemin est considéré comme relatif au répertoire défini par
+la directive ServerRoot.
Chaque ligne du fichier de groupes contient un nom de groupe +suivi du caractère ':' et des noms des utilisateurs membres du groupe +séparés par des espaces.
+ +
+ mon-groupe : bob joe anne
+
Notez que la recherche dans de grands fichiers textes est
+très inefficace ; la directive AuthDBMGroupFile fournit de bien meilleures
+ performances.
Le fichier AuthGroupFile ne doit pas
+être stocké dans l'arborescence des documents du site web ; ne le placez
+surtout pas dans le répertoire qu'il protège, faute de quoi les
+clients pourraient le télécharger.
Serveur HTTP Apache Version 2.4
+| Description: | Autorisations de groupe basées sur l'hôte (nom ou adresse +IP) |
|---|---|
| Statut: | Base |
| Identificateur de Module: | authz_host_module |
| Fichier Source: | mod_authz_host.c |
| Compatibilité: | Le fournisseur forward-dns est disponible à partir
+de la version 2.4.19 du serveur HTTP Apache |
Les fournisseurs d'autorisation implémentés par le module
+ mod_authz_host sont enregistrés à l'aide de
+ la directive Require. On peut
+ utiliser cette directive à l'intérieur de sections <Directory>, <Files>, ou <Location> ou de fichiers
+ .htaccess pour
+ contrôler l'accès à certaines zones du serveur. Le contrôle d'accès
+ peut être effectué en fonction du nom d'hôte ou de l'adresse IP.
En général, les directives de restriction d'accès s'appliquent à
+ toutes les méthodes d'accès (GET, PUT,
+ POST, etc...). C'est d'ailleurs ce que l'on souhaite
+ dans la plupart des cas. Il est cependant possible de ne restreindre
+ l'accès que pour certaines méthodes, tout en laissant les autres
+ méthodes sans protection, en plaçant les directives dans une section
+ <Limit>.
Ce module ne fournit aucune directive.
+La directive Apache Require est utilisée au cours de
+ la phase d'autorisation pour vérifier si un utilisateur se voit
+ accorder ou refuser l'accès à une ressource. mod_authz_host fournit
+ les types d'autorisation ip, host,
+ forward-dns et local. D'autres
+ types d'autorisation sont aussi disponibles, mais nécessitent le chargement
+ des modules d'autorisation appropriés.
Ces fournisseurs d'autorisation permettent de déterminer quels + hôtes peuvent accéder à une zone du serveur. On peut contrôler + l'accès en fonction du nom d'hôte, de l'adresse IP, ou d'un intervalle + d'adresses IP.
+ +A partir de la version 2.4.8, les directives require host + supportent les expressions.
+ +Le fournisseur ip permet de contrôler l'accès au
+ serveur en fonction de l'adresse IP du client distant. Lorsque
+ Require ip adresse-ip est spécifié, la
+ requête est autorisée si l'adresse IP du client distant correspond
+ à
Une adresse IP complète :
+ +Require ip 10.1.2.3 +Require ip 192.168.1.104 192.168.1.205+ + +
L'adresse IP d'un hôte pour qui l'accès est accordé
+ +Une adresse IP partielle :
+ +Require ip 10.1 +Require ip 10 172.20 192.168.2+ +
Les 1 à 3 premiers octets d'une adresse IP, pour une restriction + à un sous-réseau.
+ +Une paire réseau/masque de sous-réseau :
+ +Require ip 10.1.0.0/255.255.0.0+ +
Un réseau a.b.c.d, et un masque de sous-réseau w.x.y.z. pour une + restriction de sous-réseau plus fine.
+ +Une spécification CIDR réseau/nnn :
+ +Require ip 10.1.0.0/16+ +
Identique au cas précédent, excepté que le masque de sous-réseau + représente les nnn premiers bits de poids fort.
+ +Notez que les trois derniers exemples correspondent exectement au + même ensemble d'hôtes.
+ +On peut spécifier des adresses et des sous-réseaux IPv6 comme + suit :
+ +Require ip 2001:db8::a00:20ff:fea7:ccea +Require ip 2001:db8:1:1::a +Require ip 2001:db8:2:1::/64 +Require ip 2001:db8:3::/48+ + +
Note: comme les adresses IP sont lues au démarrage, les + expressions ne sont pas évaluées au moment de la requête.
+ + + +Le fournisseur host permet de contrôler l'accès au
+ serveur en fonction du nom d'hôte du client distant. Lorsque
+ Require host nom-hôte est spécifié, la
+ requête est autorisée si le nom d'hôte correspond à
Un nom de domaine (éventuellement partiel)
+ +Require host example.org +Require host .net example.edu+ + +
Les hôtes dont les noms correspondent ou se terminent par la
+ chaîne spécifiée se voient accorder l'accès. Seuls les élément de
+ nom de domaine complets sont mis en correspondance ; ainsi,
+ l'exemple ci-dessus correspondra à foo.example.org, mais
+ ne correspondra pas à fooexample.org. Avec cette
+ configuration, Apache va effectuer une double recherche DNS sur
+ l'adresse IP du client, sans tenir compte de la définition de la
+ directive HostnameLookups. Il
+ va effectuer une recherche DNS inverse sur l'adresse IP pour trouver
+ le nom d'hôte associé, puis une recherche DNS directe sur le nom
+ d'hôte pour vérifier qu'il correspond bien à l'adresse IP originale.
+ L'accès ne sera accordé que si le nom d'hôte correspond et si les
+ recherches DNS inverse et directe sont cohérentes.
Le fournisseur forward-dns permet d'accéder au serveur
+ sécurisé en fonction de simples noms d'hôte. Lorsque Require
+ forward-dns host-name est spécifié, toute adresse IP
+ correspondant à host-name se voit autoriser l'accès.
A la différence du fournisseur host, ce fournisseur
+ n'effectue pas de recherche DNS inverse : il effectue simplement une requête
+ DNS directe pour le nom d'hôte spécifié et donne accès au client si son
+ adresse IP correspond. Il ne fonctionnera donc qu'avec des noms d'hôte, et
+ non avec des noms de domaine. Par contre, comme le DNS inverse n'est pas
+ sollicité, il fonctionnera avec des clients qui utilisent un service de DNS
+ dynamique.
Require forward-dns bla.example.org+ + +
Un client dont l'adresse IP correspond au nom d'hôte
+ bla.example.org se verra autoriser l'accès.
Le fournisseur local autorise l'accès au serveur si
+ l'une au moins de ces conditions est satisfaite :
L'exemple suivant montre une méthode simple pour sélectionner les + connexions en provenance de l'hôte local :
+ +Require local+ + + + +
Si le contenu de votre serveur est mandaté, vous devez garder à
+ l'esprit que l'adresse client correspondra à l'adresse de votre
+ serveur mandataire et non à l'adresse du client, et l'utilisation de
+ la directive Require dans ce contexte ne provoquera pas
+ forcément l'effet désiré. Voir mod_remoteip pour
+ une solution possible à ce problème.
Serveur HTTP Apache Version 2.4
+| Description: | Autorisation basée sur l'appartenance des +fichiers |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | authz_owner_module |
| Fichier Source: | mod_authz_owner.c |
| Compatibilité: | Disponible depuis les versions 2.1 et supérieures +d'Apache |
Ce module permet de contrôler l'accès aux fichiers en comparant
+ l'identifiant utilisateur ayant servi à l'authentification HTTP
+ (l'identifiant utilisateur web) avec le propriétaire ou le groupe
+ du fichier demandé du point de vue du système de fichiers. Le nom
+ d'utilisateur et le mot de passe doivent déjà avoir été vérifiés par
+ un module d'authentification comme mod_auth_basic
+ ou mod_auth_digest.
+ mod_authz_owner reconnaît deux arguments pour la
+ directive Require :
+ file-owner et file-group :
file-ownerjones comme
+ propriétaire du fichier demandé, le nom d'utilisateur fourni pour
+ l'authentification HTTP doit aussi être jones.file-groupmod_authz_groupfile ou
+ mod_authz_dbm, et le nom d'utilisateur web fourni
+ pour l'authentification doit être un membre de ce groupe. Par
+ exemple, si le système indique que le groupe (système) du fichier
+ demandé est accounts, le groupe accounts
+ doit apparaître dans la base de données des groupes, et le nom
+ d'utilisateur web utilisé pour l'authentification doit être un
+ membre de ce groupe.Si le module mod_authz_owner est utilisé pour
+ vérifier l'autorisation d'accès à une ressource qui n'est pas
+ vraiment présente dans le système de fichiers (en d'autres termes
+ une ressource virtuelle), il refusera l'accès.
En particulier, il n'accordera jamais l'accès à une ressource + du type "Vues + multiples" (MultiViews) d'un contenu négocié.
+Ce module ne fournit aucune directive.
+Considérons un serveur Web Apache fonctionnant sous un système
+ multi-utilisateurs, où les fichiers de chaque utilisateur sont
+ stockés dans ~/public_html/private. En supposant
+ qu'il n'existe qu'une seule base de données contenant les noms
+ d'utilisateurs web, et que ces noms d'utilisateurs correspondent
+ aux noms d'utilisateurs système qui sont les propriétaires
+ effectifs des fichiers, la configuration de l'exemple suivant
+ n'accordera l'autorisation d'accès aux fichiers qu'à leur
+ propriétaire. L'utilisateur jones ne sera pas
+ autorisé à accéder aux fichiers situés dans
+ /home/smith/public_html/private, à moins que leur
+ propriétaire ne soit jones au lieu de
+ smith.
<Directory "/home/*/public_html/private"> + AuthType Basic + AuthName MyPrivateFiles + AuthBasicProvider dbm + AuthDBMUserFile "/usr/local/apache2/etc/.htdbm-all" + Require file-owner +</Directory>+ + + +
Considérons un système similaire à celui décrit ci-dessus, mais
+ où certains utilisateurs partagent leurs fichiers de projets dans
+ ~/public_html/project-foo. Le groupe système des
+ fichiers est foo, et il n'existe qu'une seule base de
+ données AuthDBMGroupFile qui contient
+ tous les noms d'utilisateurs web et leurs groupes d'appartenance.
+ Ces noms d'utilisateurs web doivent alors appartenir au moins au
+ groupe foo. En d'autres termes, si jones
+ et smith sont tous deux membres du groupe
+ foo, ils seront autorisés à accéder aux
+ répertoires project-foo de chacun d'entre eux.
<Directory "/home/*/public_html/project-foo"> + AuthType Basic + AuthName "Project Foo Files" + AuthBasicProvider dbm + + # combined user/group database + AuthDBMUserFile "/usr/local/apache2/etc/.htdbm-all" + AuthDBMGroupFile "/usr/local/apache2/etc/.htdbm-all" + + Satisfy All + Require file-group +</Directory>+ + +
Serveur HTTP Apache Version 2.4
+| Description: | Autorisation basée sur l'utilisateur |
|---|---|
| Statut: | Base |
| Identificateur de Module: | authz_user_module |
| Fichier Source: | mod_authz_user.c |
| Compatibilité: | Disponible depuis les versions 2.1 et supérieures +d'Apache |
Ce module permet d'accorder ou de refuser l'accès à certaines
+ zones du site web aux utilisateurs authentifiés.
+ mod_authz_user accorde l'accès si l'utilisateur
+ authentifié fait partie de la liste spécifiée par une directive
+ Require user. On peut aussi utiliser la directive
+ Require valid-user pour accorder l'accès à tous les
+ utilisateurs qui ont été authentifiés avec succès.
Ce module ne fournit aucune directive.
+Les directives Require d'Apache permettent,
+ au cours de la phase d'autorisation, de s'assurer qu'un utilisateur
+ est bien autorisé à accéder à une
+ ressource. mod_authz_user ajoute
+ les types d'autorisation user et valid-user.
+
A partir de la version 2.4.8, les directives require DBM + supportent les expressions.
+ +Cette directive permet de spécifier une liste d'utilisateurs + autorisés à accéder à la ressource.
+ +Require user john paul george ringo+ + + + +
Lorsque cette directive est définie, tout utilisateur qui s'est + authentifié avec succès aura l'autorisation d'accès à la ressource.
+ +Require valid-user+ + + + +
Serveur HTTP Apache Version 2.4
+| Description: | Génère automatiquement des index de répertoires d'une
+manière similaire à la commande Unix ls, ou à la commande
+shell Win32 dir |
|---|---|
| Statut: | Base |
| Identificateur de Module: | autoindex_module |
| Fichier Source: | mod_autoindex.c |
L'index d'un répertoire peut être généré de deux manières :
+ +index.html, mais dont le nom de ce ou ces fichiers peut être défini par la
+ directive DirectoryIndex. C'est le module
+ mod_dir qui traite alors cet index.AddIcon, AddIconByEncoding et AddIconByType permettent de
+ définir une liste d'icônes à afficher en fonction des différents
+ types de fichiers ; pour chaque fichier listé, le premier icône
+ qui correspond au type du fichier est affiché. C'est le module
+ mod_autoindex qui traite alors cet index.Les deux fonctions sont séparées, si bien que vous pouvez + entièrement supprimer (ou remplacer) la génération automatique + d'index, si vous le souhaitez.
+ +On active la génération automatique d'index en spécifiant
+ Options +Indexes. Voir la directive Options pour plus de détails.
Si la directive IndexOptions est spécifiée avec
+ l'option FancyIndexing, les en-têtes de colonnes sont des liens
+ qui permettent de contrôler l'ordre de tri de l'affichage. Si vous
+ actionnez le lien d'un en-tête, le listing sera généré à nouveau,
+ trié en fonction des valeurs de la colonne concernée. Si l'on
+ actionne de manière répétitive le même en-tête, l'ordre de tri est
+ commuté entre les ordres croissant et décroissant. On peut supprimer
+ ces liens d'en-têtes de colonnes à l'aide de l'option
+ SuppressColumnSorting
+ de la directive IndexOptions.
Notez que lorsque l'affichage est trié en fonction de la taille, + c'est la taille réelle qui est prise en compte, et non la + valeur affichée - ainsi, un fichier de 1010 octets sera toujours + affiché avant un fichier de 1011 octets (en ordre croissant), même + si la taille affichée des deux fichiers est "1K".
+ AddAlt AddAltByEncoding AddAltByType AddDescription AddIcon AddIconByEncoding AddIconByType DefaultIcon HeaderName IndexHeadInsert IndexIgnore IndexIgnoreReset IndexOptions IndexOrderDefault IndexStyleSheet ReadmeNameLa chaîne de paramètres de la requête peut contenir de nombreux
+ arguments permettant dans une certaine mesure au client de contrôler
+ l'ordre de l'index du répertoire, ainsi que la liste des fichiers à
+ afficher. Si vous souhaitez désactiver cette fonctionnalité,
+ utilisez l'option IndexOptions
+ IgnoreClient.
Les en-têtes de tri des colonnes eux-mêmes sont des hyper-liens + auto-référant qui ajoutent les options de tri à la requête énumérées + ci-dessous qui peuvent être ajoutées à toute requête concernant la + ressource répertoire.
+ +C=N trie l'affichage en fonction du nom de
+ fichierC=M trie l'affichage en fonction de la date de
+ dernière modification, puis du nom de fichierC=S trie l'affichage en fonction de la taille,
+ puis du nom de fichierC=D trie l'affichage en fonction
+ de la description, puis du nom de fichierO=A trie l'affichage selon l'ordre croissantO=D trie l'affichage selon
+ l'ordre décroissantF=0 affiche le listing sous la forme d'une simple
+ liste (sans FancyIndex)F=1 affiche le listing avec en-têtes de colonnes
+ sous forme de liens hyper-textes (FancyIndexed)F=2 affiche le listing sous
+ forme de table HTML avec en-têtes de colonnes contenant des liens
+ hyper-textes (FancyIndexed)V=0 désactive le tri en fonction de la
+ versionV=1 active le tri en fonction de
+ la versionP=modèle n'affiche que les fichiers
+ correspondant au modèle spécifiéNotez que l'argument 'P' (pour Pattern) n'est testé
+ qu'après que les directives habituelles IndexIgnore ont été traitées,
+ et que tous les noms de fichiers sont encore assujettis aux mêmes
+ critères que pour tout autre listing auto-indexé. L'interpréteur
+ d'arguments de requête de mod_autoindex s'arrête
+ immédiatement s'il rencontre une option non reconnue. Les arguments
+ de requête doivent être bien formés, selon la table ci-dessus.
Les options de requêtes sont illustrées par l'exemple ci-dessous, + qui peut être copié et collé dans un fichier header.html. Notez que + l'argument inconnu "X", pour le bouton submit, est introduit en + dernier afin de s'assurer que tous les arguments ont été + interprétés avant que mod_autoindex ne rencontre l'entrée X=Go.
+ +
+ <form action="" method="get">
+
+ Montre moi une <select name="F">
+
+ <option value="0"> liste simple</option>
+ <option value="1" selected="selected"> liste avec
+ en-têtes</option>
+ <option value="2"> liste avec en-tête sous forme de
+ table</option>
+
+ </select>
+ triée par <select name="C">
+
+ <option value="N" selected="selected"> nom</option>
+ <option value="M"> date de modification</option>
+ <option value="S"> taille</option>
+ <option value="D"> description</option>
+
+ </select>
+ <select name="O">
+
+ <option value="A" selected="selected"> croissant</option>
+ <option value="D"> décroissant</option>
+
+ </select>
+ <select name="V">
+
+ <option value="0" selected="selected"> dans l'ordre
+ normal</option>
+ <option value="1"> en fonction de la version</option>
+
+ </select>
+ correspondant à <input type="text" name="P" value="*" />
+ <input type="submit" name="X" value="Go" />
+
+ </form>
+
| Description: | Texte optionnel à afficher à la place d'un icône pour un +fichier en fonction de son nom |
|---|---|
| Syntaxe: | AddAlt texte fichier [fichier] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
La directive AddAlt permet d'afficher un
+ texte optionnel pour un fichier, à la place d'un icône, dans le cas
+ d'un affichage FancyIndexing.
+ fichier est une extension de fichier, un nom de fichier
+ partiel, une expression avec caractères génériques ou un nom de
+ fichier complet permettant de caractériser le(s) fichier(s)
+ concerné(s). Si texte contient des espaces, vous devez
+ l'entourer de guillemets ou d'apostrophes (" ou
+ '). Ce texte optionnel sera affiché si le client ne
+ peut pas afficher d'images, si le chargement d'images est désactivé
+ ou si l'icône ne peut pas être trouvé.
AddAlt "PDF file" *.pdf +AddAlt Compressed *.gz *.zip *.Z+ + +
| Description: | Texte optionnel à afficher à la place d'un icône pour un +fichier en fonction de son codage MIME |
|---|---|
| Syntaxe: | AddAltByEncoding texte codage MIME
+[codage MIME] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
La directive AddAltByEncoding permet
+ d'afficher un texte optionnel à la place d'un icône pour un fichier
+ dans le cas d'un affichage FancyIndexing.
+ codage MIME doit être un type valide, comme
+ x-compress. Si texte contient des espaces,
+ vous devez l'entourer de guillemets ou d'apostrophes ("
+ ou '). Ce texte optionnel sera affiché si le client ne
+ peut pas afficher d'images, si le chargement d'images est désactivé
+ ou si l'icône ne peut pas être trouvé.
AddAltByEncoding gzip x-gzip+ + +
| Description: | Texte optionnel à afficher à la place d'un icône pour un +fichier en fonction de son type MIME |
|---|---|
| Syntaxe: | AddAltByType texte type MIME
+[type MIME] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
La directive AddAltByType permet
+ d'afficher un texte optionnel à la place d'un icône pour un fichier
+ dans le cas d'un affichage FancyIndexing.
+ type MIME doit être un type MIME valide, comme
+ text/html. Si texte contient des espaces,
+ vous devez l'entourer de guillemets ou d'apostrophes ("
+ ou '). Ce texte optionnel sera affiché si le client ne
+ peut pas afficher d'images, si le chargement d'images est désactivé
+ ou si l'icône ne peut pas être trouvé.
AddAltByType 'Fichier texte' text/plain+ + +
| Description: | Afficher la description d'un fichier |
|---|---|
| Syntaxe: | AddDescription texte [fichier] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
Cette directive permet d'afficher une description pour un
+ fichier, dans le cas d'un affichage FancyIndexing.
+ fichier est une extension de fichier, un nom de fichier
+ partiel, une expression avec caractères génériques ou un nom de
+ fichier complet permettant de caractériser le fichier.
+ texte doit être entouré de guillemets
+ (").
AddDescription "The planet Mars" mars.gif +AddDescription "My friend Marshall" friends/mars.gif+ + +
La taille par défaut, habituelle du champ de description est de
+ 23 octets. L'option IndexOptions SuppressIcon ajoute 6 octets, l'option
+ IndexOptions
+ SuppressSize en ajoute 7 et l'option IndexOptions
+ SuppressLastModified en ajoute 19. Ainsi, la plus grande
+ taille par défaut qui peut être assignée à la colonne description
+ est de 55 octets.
Comme l'argument fichier peut être un nom de fichier
+ partiel, vous devez garder à l'esprit qu'un nom de fichier partiel
+ trop court pourra correspondre à des fichiers non voulus. Par
+ exemple, le.html correspondra au fichier
+ le.html, mais aussi au fichier
+ example.html. En cas d'ambiguïté, utilisez un nom de
+ fichier aussi complet que possible, et ordonnez votre liste de
+ directives AddDescription en conséquence.
Voir le mot-clé DescriptionWidth de la directive IndexOptions pour plus de
+ détails sur la manière d'augmenter la taille de cette colonne, ou
+ pour permettre des descriptions de taille illimitée.
Le texte descriptif défini par la directive
+ AddDescription peut contenir des marquages
+ HTML, comme des balises ou des entités caractères. Si la limite de
+ taille de la colonne description venait à tronquer une balise (par
+ exemple couper la fin d'une phrase en caractères gras), le
+ résultat pourrait en affecter toute la suite du listing du
+ répertoire.
Les chemins absolus ne sont actuellement pas supportés et ne + peuvent correspondre à aucun chemin réel à l'exécution. Les + arguments contenant des chemins relatifs, qui ne devraient être + normalement utilisés que dans les fichiers htaccess, sont + implicitement préfixés par '*/' afin d'éviter toute association + avec des noms de répertoires partiels.
+| Description: | Icône à afficher pour un fichier en fonction de son +nom |
|---|---|
| Syntaxe: | AddIcon icône nom [nom]
+... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
Cette directive permet de déterminer l'icône à afficher à côté
+ d'un fichier dont le nom se termine par nom, dans le cas
+ d'un affichage FancyIndexing. icône est une URL relative
+ (échappée par des caractères '%') vers
+ l'icône, une URL distante pleinement qualifiée, ou de la forme
+ (alttext,url), où
+ alttext est le symbole texte correspondant à l'icône à
+ afficher dans les navigateurs en mode texte.
nom correspond à ^^DIRECTORY^^ pour les
+ répertoires, ^^BLANKICON^^ pour les lignes vides
+ (pour personnaliser la présentation du listing), une extension de
+ fichier, une expression avec caractères génériques, un nom de
+ fichier partiel ou un nom de fichier complet.
^^BLANKICON^^ n'est utilisé que pour le formatage,
+ et n'est donc pas nécessaire si vous utilisez IndexOptions
+ HTMLTable.
#Examples +AddIcon (IMG,/icons/image.png) .gif .jpg .png +AddIcon /icons/dir.png ^^DIRECTORY^^ +AddIcon /icons/backup.png *~+ + +
Lorsque c'est possible, il est préférable d'utiliser AddIconByType plutôt que
+ AddIcon.
| Description: | Icône à afficher à côté d'un fichier en fonction de son +codage MIME |
|---|---|
| Syntaxe: | AddIconByEncoding icône codage MIME
+[codage MIME] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
Cette directive permet de déterminer l'icône à afficher à côté
+ d'un fichier dans le cas d'un affichage FancyIndexing.
+ icône est une URL relative
+ (échappée par des caractères '%') vers
+ l'icône, une URL pleinement qualifiée, ou de la forme
+ (alttext,url), où
+ alttext est le symbole texte correspondant à l'icône à
+ afficher dans les navigateurs en mode texte.
codage MIME doit être un codage valide, comme
+ x-compress.
AddIconByEncoding /icons/compress.png x-compress+ + +
| Description: | Icône à afficher à côté d'un fichier en fonction de son +type MIME |
|---|---|
| Syntaxe: | AddIconByType icône type MIME
+[type MIME] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
Cette directive permet de déterminer l'icône à afficher à côté
+ d'un fichier de type MIME type MIME dans le cas d'un
+ affichage FancyIndexing.
+ icône est une URL relative
+ (échappée par des caractères '%') vers
+ l'icône, une URL pleinement qualifiée, ou de la forme
+ (alttext,url), où
+ alttext est le symbole texte correspondant à l'icône à
+ afficher dans les navigateurs en mode texte.
type MIME est une expression avec caractères + génériques représentant le type MIME.
+ +AddIconByType (IMG,/icons/image.png) image/*+ + +
| Description: | Icône à afficher par défaut lorsqu'aucun icône spécifique +n'est précisé |
|---|---|
| Syntaxe: | DefaultIcon chemin URL |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
La directive DefaultIcon permet de définir
+ l'icône à afficher à côté d'un fichier lorsqu'aucun icône spécifique
+ n'a été précisé, dans le cas d'un affichage FancyIndexing.
+ chemin URL est une URL relative (échappée par des
+ caractères '%') vers l'icône ou une URL pleinement qualifiée.
DefaultIcon /icon/unknown.png+ + +
| Description: | Nom du fichier qui sera inséré au début de la page +contenant l'index |
|---|---|
| Syntaxe: | HeaderName nom fichier |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
La directive HeaderName permet de définir
+ le nom du fichier qui sera inséré au début de la page contenant
+ l'index. nom fichier est le nom du fichier à inclure.
HeaderName HEADER.html+ + +
Les deux directives HeaderName et ReadmeName traitent maintenant
+ nom fichier comme un chemin URI relatif au chemin
+ utilisé pour accéder au répertoire faisant l'objet de l'index. Si
+ nom fichier commence par un slash '/', il sera
+ considéré comme relatif au répertoire défini par la directive
+ DocumentRoot.
HeaderName /include/HEADER.html+ + +
nom fichier doit correspondre à un document dont le
+ type MIME est du style text/* (par exemple
+ text/html, text/plain, etc...). Cela
+ signifie que nom fichier peut faire référence à un
+ script CGI si le véritable type MIME du script (et non celui de sa
+ sortie) est marqué comme text/html par exemple à
+ l'aide d'une directive comme :
AddType text/html .cgi+ + +
Une négociation de
+ contenu sera effectuée si Options MultiViews a été
+ précisé. Si nom fichier correspond à un document
+ statique text/html (et non à un script CGI), et une
+ des deux options
+ Includes ou IncludesNOEXEC est activée,
+ le fichier sera traité en tant qu'inclusion côté serveur (Server
+ Side Include) (voir la documentation de
+ mod_include).
Si le fichier spécifié par la directive
+ HeaderName contient les en-têtes d'un
+ document HTML ((<html>, <head>, etc...), vous serez
+ probablement amené à définir IndexOptions
+ +SuppressHTMLPreamble, de manière à ce que ces balises ne
+ soient pas répétées.
ReadmeName| Description: | Insère du texte dans la section HEAD de la page +d'index. |
|---|---|
| Syntaxe: | IndexHeadInsert "marque ..." |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
La directive IndexHeadInsert permet de
+ spécifier une chaîne de caractères à insérer dans la section
+ <head> du code HTML généré pour la page
+ d'index.
IndexHeadInsert "<link rel=\"sitemap\" href=\"/sitemap.html\">"+ + +
| Description: | Ajouts à la liste des fichiers à cacher lors de l'affichage +de l'index d'un répertoire |
|---|---|
| Syntaxe: | IndexIgnore fichier [fichier] ... |
| Défaut: | IndexIgnore "." |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
La directive IndexIgnore permet
+ d'effectuer des ajouts à la liste des fichiers à cacher lors de
+ l'affichage de l'index d'un répertoire. fichier est une
+ expression avec caractères génériques de style shell ou un nom de
+ fichier complet. Plusieurs directives IndexIgnore effectuent des
+ ajouts à la liste, et ne remplacent pas la liste des fichiers à
+ ignorer. Par défaut, la liste contient . (le répertoire
+ courant).
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t+ + +
Cette directive est actuellement incompatible avec les sections
+ de configuration qui comportent des arguments avec expressions
+ rationnelles comme <DirectoryMatch>
| Description: | Vide la liste des fichiers à cacher lors de l'affichage du +contenu d'un répertoire |
|---|---|
| Syntaxe: | IndexIgnoreReset ON|OFF |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
| Compatibilité: | Versions 2.3.10 et supérieures |
La directive IndexIgnoreReset supprime
+ toute liste de fichiers définie par la directive
+ IndexIgnore et héritée par ailleurs d'autres
+ sections de configuration.
<Directory "/var/www"> + IndexIgnore *.bak .??* *~ *# HEADER* README* RCS CVS *,v *,t +</Directory> +<Directory "/var/www/backups"> + IndexIgnoreReset ON + IndexIgnore .??* *# HEADER* README* RCS CVS *,v *,t +</Directory>+ + +
Revoyez la configuration par défaut pour une + liste de modèles que vous voulez ignorer explicitement après usage + de cette directive.
| Description: | Diverses options de configuration pour l'indexation d'un +répertoire |
|---|---|
| Syntaxe: | IndexOptions [+|-]option [[+|-]option]
+... |
| Défaut: | Par défaut, aucune option n'est activée. |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
La directive IndexOptions permet de
+ spécifier les options de configuration de l'indexation du
+ répertoire. option peut prendre l'une des valeurs
+ suivantes :
IndexOptions HTMLTable est activé et où un
+ IndexStyleSheet a été défini. Plutôt que d'appliquer
+ à chaque enregistrement de la table les classes standards
+ even et odd, c'est ici une classe
+ even-ALT ou odd-ALT
+ qui sera appliquée, où ALT sera soit le texte alternatif
+ standard associé au style du fichier (par exemple snd,
+ txt, img, etc...), soit le texte alternatif
+ défini par une des différentes directives AddAlt*.
+ Charset vous permet de spécifier le
+ jeu de caractères de la page générée. La valeur par défaut est
+ UTF-8 sous Windows et MAC OS X, et
+ ISO-8859-1 dans les autres cas (en fait selon que le
+ système de fichiers sous-jacent utilise les noms de fichiers en
+ Unicode ou non).
+
+ IndexOptions Charset=UTF-8+ +
DescriptionWidth vous permet de
+ spécifier la taille en caractères de la colonne description.-DescriptionWidth (ou si l'option n'est pas
+ définie), mod_autoindex calcule la meilleure
+ taille.DescriptionWidth=n fixe la taille de
+ la colonne à n octets.DescriptionWidth=* ajuste la taille de la colonne
+ à la plus longue chaîne de description.
+
+ Voir la section concernant AddDescription pour les dangers
+ inhérants à la troncature des descriptions.FoldersFirst est
+ activé, le sous-répertoire Zed sera affiché avant le
+ sous-répertoire Beta, qui sera lui-même affiché avant
+ les fichiers normaux Gamma et Alpha.
+ Cette option n'a d'effet que si FancyIndexing
+ est aussi activé.
+ FancyIndexing permet de construire une table simple
+ pour l'affichage de l'index du répertoire. Cette option s'avèrera
+ particulièrement nécessaire pour les plates-formes où utf-8 est
+ activé et dans le cas où les noms de fichiers ou les chaînes
+ de description alternent entre les ordres de lecture gauche à
+ droite et droite à gauche.IconWidth, le serveur va inclure les attributs
+ height et width dans la balise
+ img qui référence le fichier de l'icône. Ceci va
+ permettre au navigateur de prévoir les caractéristiques de la page
+ sans devoir attendre que toutes les images aient été chargées. En
+ l'absence de cette option, c'est la hauteur standard définie par
+ le logiciel Apache httpd qui est choisie comme valeur par défaut.
+
+ Cette option n'a d'effet que si FancyIndexing
+ est aussi activé.
+ IconHeight, le serveur va inclure les attributs
+ height et width dans la balise
+ img qui référence le fichier de l'icône. Ceci va
+ permettre au navigateur de prévoir les caractéristiques de la page
+ sans devoir attendre que toutes les images aient été chargées. En
+ l'absence de cette option, c'est la largeur standard définie par
+ le logiciel Apache httpd qui est choisie comme valeur par défaut.IgnoreCase est activé,
+ le fichier Zeta apparaîtra après le fichier alfa (Note : le
+ fichier GAMMA apparaîtra toujours avant le fichier gamma).
+ mod_autoindex va
+ ignorer toutes les variables de requête fournies par le client, y
+ compris les informations de tri (ce qui implique l'activation de
+ l'option SuppressColumnSorting).NameWidth vous permet de spécifier la
+ largeur en octets de la colonne correspondant au nom du
+ fichier.-NameWidth (ou si l'option n'est pas
+ définie), mod_autoindex va calculer la meilleure largeur
+ possible, mais jusqu'à une largeur maximale de 20 octets.NameWidth=n fixe la largeur de la
+ colonne à n octets.NameWidth=* définit la largeur de colonne à la
+ valeur nécessaire.AddDescription, httpd va lire
+ le document pour tenter d'en extraire le titre. Ce
+ processus est coûteux en ressources disque et CPU.HTTP_UNAUTHORIZED ou HTTP_FORBIDDEN par
+ la sous-requête.IndexOptions
+ IgnoreClient.AddDescription pour plus d'informations à propos de
+ la définition des descriptions de fichiers. Voir aussi l'option
+ d'index DescriptionWidth
+ pour limiter la taille de la colonne description.
+
+ Cette option n'a d'effet que si FancyIndexing
+ est aussi activé.
+ HeaderName, le module inclut
+ en général le contenu du fichier après avoir inséré un préambule
+ HTML standard (<html>,
+ <head>, etc...). L'activation de
+ l'option SuppressHTMLPreamble supprime l'insertion de
+ ce préambule, et le module va alors commencer l'affichage
+ directement par le contenu du fichier d'en-tête. Dans ce cas par
+ contre, le fichier d'en-tête doit contenir des instructions HTML
+ appropriées. S'il n'y a pas de fichier d'en-tête, le préambule est
+ généré comme dans le cas général. Si vous spécifiez aussi une
+ directive ReadmeName, et si ce
+ fichier existe, les balises de fermeture closing
+ </body></html> seront aussi omises dans la sortie, en
+ supposant que vous ayez placé ces balises de fermeture dans ce
+ fichier.SuppressIcon et SuppressRules permet de
+ générer une sortie au format HTML 3.2 qui, selon les dernières
+ spécifications, interdit les éléments img et
+ hr dans les blocs pre (utilisés pour
+ formater les affichages "améliorés").FancyIndexing
+ est aussi activé.
+ hr) dans les index de
+ répertoires. La combinaison de
+ SuppressIcon et SuppressRules permet de
+ générer une sortie au format HTML 3.2 qui, selon les dernières
+ spécifications, interdit les éléments img et
+ hr dans les blocs pre (utilisés pour
+ formater les affichages "améliorés").
+
+ Cette option n'a d'effet que si FancyIndexing
+ est aussi activé.
+ FancyIndexing
+ est aussi activé.
+ Last-Modified et
+ ETag pour le répertoire indexé dans l'en-tête HTTP.
+ Elle n'est valide que si le système d'exploitation et le système
+ de fichiers renvoient des résultats appropriés pour la fonction
+ stat(). C'est le cas de certains systèmes Unix, ainsi que JFS sous
+ OS/2 ou
+ les volumes NTFS sous Win32. Ce n'est par contre pas le cas
+ des volumes FAT Win32 et OS/2. Lorsque cette option est activée, le
+ client ou le mandataire peuvent détecter les changements dans la
+ liste des fichiers lorsqu'ils effectuent une requête
+ HEAD. Notez que certains systèmes d'exploitation
+ détectent correctement les nouveaux fichiers et les fichiers
+ supprimés, mais ne détectent pas les modifications de tailles ou
+ de dates des fichiers du répertoire. Les modifications de
+ taille ou de date d'un fichier existant ne mettent pas à jour
+ l'en-tête Last-Modified sur toutes les plate-formes
+ Unix. Si c'est le cas, laissez cette option
+ désactivée.Type vous permet de spécifier le type
+ MIME de la page générée. La valeur par défaut est
+ text/html.
+
+ IndexOptions Type=text/plain+ +
Last Modified
+ avait été modifié par inadvertance de "%d-%b-%Y %H:%M" en
+ "%Y-%m-%d %H:%M" dans la version 2.4.0. Cette option permet
+ de restaurer le format de date des versions 2.2 et antérieures.VersionSort permet de trier les
+ fichiers contenant des numéros de version d'une manière
+ spécifique. Les chaînes sont triées comme d'habitude, excepté les
+ sous-chaînes de chiffres du nom de fichier et de sa description
+ qui sont comparées en fonction de leur valeur numérique.
+
+
+ foo-1.7
+ foo-1.7.2
+ foo-1.7.12
+ foo-1.8.2
+ foo-1.8.2a
+ foo-1.12
+
Si le nombre commence par le chiffre 0, il est considéré comme + la partie fractionnaire d'un nombre :
+ +
+ foo-1.001
+ foo-1.002
+ foo-1.030
+ foo-1.04
+
XHTML enjoint
+ mod_autoindex de générer du code XHTML 1.0 au
+ lieu de HTML 3.2.
+
+ Cette option n'a d'effet que si FancyIndexing
+ est aussi activé.
+ Vous devez porter une attention particulière à la manière dont
+ les IndexOptions multiples sont traitées.
IndexOptions
+ apparaissant dans la même section directory sont maintenant
+ fusionnées. Le résultat de :
+
+ <Directory "/foo"> + IndexOptions HTMLTable + IndexOptions SuppressColumnsorting +</Directory>+ + +
est équivalent à
+ +IndexOptions HTMLTable SuppressColumnsorting+ +
+ ou -).Chaque fois qu'un mot-clé préfixé par '+' ou '-' est trouvé, il
+ est appliqué aux définitions des
+ IndexOptions courantes (qui ont été
+ éventuellement héritées d'un directory de niveau supérieur). Par
+ contre, si un mot-clé non préfixé est trouvé, il supprime toutes
+ les definitions héritées, ainsi que toute
+ définition incrémentale. Considérons l'exemple
+ suivant :
IndexOptions +ScanHTMLTitles -IconsAreLinks FancyIndexing +IndexOptions +SuppressSize+ + +
L'effet global est équivalent à l'effet qu'aurait provoqué
+ IndexOptions FancyIndexing +SuppressSize, car l'option
+ non préfixée FancyIndexing annule les mots-clés
+ incrémentaux situés avant elle, mais leur permet ensuite de
+ s'incrémenter à nouveau.
Pour définir inconditionnellement les
+ IndexOptions pour un répertoire particulier,
+ tout en supprimant les définitions héritées, spécifiez les
+ mots-clés sans préfixe + ou -
| Description: | Définit l'ordre d'affichage par défaut d'un index de +répertoire |
|---|---|
| Syntaxe: | IndexOrderDefault Ascending|Descending
+Name|Date|Size|Description |
| Défaut: | IndexOrderDefault Ascending Name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
La directive IndexOrderDefault s'utilise
+ en combinaison avec l'option d'index FancyIndexing. Par
+ défaut, les index de répertoires "améliorés" sont affichés selon l'ordre
+ croissant des noms de fichiers ; la directive
+ IndexOrderDefault vous permet de modifier ce
+ comportement.
La directive IndexOrderDefault accepte
+ deux arguments. Le premier est soit Ascending, soit
+ Descending, et indique l'ordre de tri. Le second doit
+ prendre une des valeurs Name, Date,
+ Size, ou Description, et permet
+ d'identifier la clé primaire. La clé secondaire est
+ toujours le nom du fichier selon un ordre croissant.
Si vous le désirez, vous pouvez empêcher le client de modifier
+ l'ordre de tri de la liste en ajoutant l'option d'index SuppressColumnSorting
+ qui supprime le lien de définition du tri de l'en-tête de la
+ colonne, ainsi que l'option IgnoreClient qui
+ empêche ce même client de passer outre vos préférences de tri en
+ ajoutant manuellement des options de tri à la chaîne de paramètres
+ de la requête.
| Description: | Ajoute une feuille de style CSS à l'index du +répertoire |
|---|---|
| Syntaxe: | IndexStyleSheet chemin-url |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
La directive IndexStyleSheet permet de
+ définir le nom du fichier qui servira de feuille de style CSS pour
+ l'index.
+
IndexStyleSheet "/css/style.css"+ + +
L'utilisation de cette directive en conjonction avec IndexOptions
+ HTMLTable ajoute plusieurs classes CSS au document HTML
+ résultant. Un identifiant CSS indexlist est attribué à
+ l'ensemble de la table et les classes suivantes sont associées aux
+ différentes parties du listing :
| Classe | Définition |
|---|---|
| tr.indexhead | Ligne d'en-tête du listing |
| th.indexcolicon and td.indexcolicon | Colonne de + l'icône |
| th.indexcolname and td.indexcolname | Colonne du nom + du fichier |
| th.indexcollastmod and td.indexcollastmod | Colonne + de la date de dernière modification |
| th.indexcolsize and td.indexcolsize | Colonne de la + taille du fichier |
| th.indexcoldesc and td.indexcoldesc | Colonne de la + description |
| tr.breakrow | Pied de page |
| tr.odd and tr.even | Alternance des lignes paires et + impaires |
| Description: | Nom du fichier dont le contenu sera inséré à la fin de +l'index |
|---|---|
| Syntaxe: | ReadmeName nom-fichier |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_autoindex |
La directive ReadmeName permet de définir
+ le nom du fichier dont le contenu sera ajouté à la fin de l'index.
+ nom-fichier est le nom du fichier à inclure, et est
+ considéré comme relatif au répertoire faisant l'objet de l'index. Si
+ nom-fichier commence par un slash '/', comme dans
+ l'exemple 2, il sera considéré
+ comme relatif au répertoire défini par la directive DocumentRoot.
+
# Example 1 +ReadmeName FOOTER.html+ + +
# Example 2 +ReadmeName /include/FOOTER.html+ + +
Voir aussi la directive HeaderName, où cette fonctionnalité est décrite plus en
+ détails.
Serveur HTTP Apache Version 2.4
+| Description: | Compression du contenu via Brotli avant sa livraison au client |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | brotli_module |
| Fichier Source: | mod_brotli.c |
| Compatibilité: | Disponible à partir de la version 2.4.26 du serveur HTTP Apache |
Le module mod_brotli fournit le filtre en sortie
+ BROTLI_COMPRESS qui permet de compresser un contenu avant sa
+ livraison au client en utilisant la bibliothèque brotli. Ce filtre est
+ implémenté en utilisant la bibliothèque Brotli que l'on peut trouver à https://github.com/google/brotli.
Exemples de configurations Activation de la compression Interaction avec les serveurs mandataires Servir un contenu pré-compressé BrotliAlterETag BrotliCompressionMaxInputBlock BrotliCompressionQuality BrotliCompressionWindow BrotliFilterNoteCertaines applications web sont vulnérables à une attaque de type vol + d'informations lorsqu'une connexion TLS transmet des données + compressées. Pour plus d'informations, étudiez en détail la famille + d'attaques "BREACH".
+Voici une configuration simple qui compresse des types de contenus + courants au format texte :
+ +AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css text/javascript application/javascript+
Certaines applications web sont vulnérables à une attaque de type vol + d'informations lorsqu'une connexion TLS transmet des données + compressées. Pour plus d'informations, étudiez en détail la famille + d'attaques "BREACH".
+La compression est implémentée par le filtre BROTLI_COMPRESS. La
+ directive suivante active la compression pour les documents correspondant
+ au conteneur dans lequel elle est placée :
SetOutputFilter BROTLI_COMPRESS +SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-brotli+ + +
Si vous voulez restreindre la compression à certains types MIME
+ particuliers, vous pouvez utiliser la directive AddOutputFilterByType. Dans l'exemple
+ suivant, l'activation de la compression est restreinte aux fichiers html
+ de la documentation d'Apache :
<Directory "/your-server-root/manual"> + AddOutputFilterByType BROTLI_COMPRESS text/html +</Directory>+ + +
BROTLI_COMPRESS est toujours inséré après les
+ filtres RESOURCE comme PHP ou SSI. Il n'affecte jamais les sous-requêtes
+ internes.
+ SetEnv, la variable
+ d'environnement no-brotli permet de désactiver la
+ compression brotli pour une requête particulière, et ceci même si elle
+ est supportée par le client.
+ Le module mod_brotli envoie un en-tête de réponse HTTP
+ Vary:Accept-Encoding pour indiquer aux mandataires qu'une
+ réponse mise en cache ne doit être envoyée qu'aux clients qui envoient
+ l'en-tête de requête Accept-Encoding approprié. Ceci permet
+ d'éviter d'envoyer du contenu compressé à un client qui ne sera pas en
+ mesure de le décompresser.
Si vous utilisez des exclusions spéciales dépendant, par exemple, de
+ l'en-tête User-Agent, vous devez faire un ajout manuel à
+ l'en-tête Vary afin d'informer les mandataires des restrictions
+ supplémentaires. Par exemple, dans une configuration typique où l'addition
+ du filtre BROTLI_COMPRESS dépend de l'en-tête User-Agent,
+ vous devez ajouter :
Header append Vary User-Agent+ + +
Si votre décision d'utiliser la compression ou non dépend d'autres
+ informations que le contenu d'en-têtes de requêtes (par exemple la version
+ HTTP), vous devez affecter la valeur * à l'en-tête
+ Vary. Ceci permet d'éviter que des mandataires qui le
+ supportent n'effectuent une mise en cache intégrale.
Header set Vary *+
comme mod_brotli compresse systématiquement un contenu
+ pour chaque requête le concernant, il est possible d'obtenir un gain en
+ performance en pré-compressant le contenu et en disant à mod_brotli de le
+ servir sans le recompresser. Pour cela, vous pouvez utiliser une
+ configuration du style :
<IfModule mod_headers.c>
+ # Sert des fichiers CSS compressés par brotli, s'ils existent
+ # et si le client supporte brotli.
+ RewriteCond "%{HTTP:Accept-encoding}" "br"
+ RewriteCond "%{REQUEST_FILENAME}\.br" "-s"
+ RewriteRule "^(.*)\.css" "$1\.css\.br" [QSA]
+
+ # Sert des fichiers JS compressés par brotli, s'ils existent
+ # et si le client supporte brotli.
+ RewriteCond "%{HTTP:Accept-encoding}" "br"
+ RewriteCond "%{REQUEST_FILENAME}\.br" "-s"
+ RewriteRule "^(.*)\.js" "$1\.js\.br" [QSA]
+
+
+ # Sert des types de contenu corrects, et évite la double compression.
+ RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-brotli:1]
+ RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-brotli:1]
+
+
+ <FilesMatch "(\.js\.br|\.css\.br)$">
+ # Sert un type d'encodage correct.
+ Header append Content-Encoding br
+
+ # Force les mandataires à mettre en cache séparément les fichiers css/js
+ # compressés ou non par brotli.
+ Header append Vary Accept-Encoding
+ </FilesMatch>
+</IfModule>
+
+
+| Description: | Comment l'en-tête de réponse ETag doit être modifié au cours de la +compression |
|---|---|
| Syntaxe: | BrotliAlterETag AddSuffix|NoChange|Remove |
| Défaut: | BrotliAlterETag AddSuffix |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_brotli |
La directive BrotliAlterETag permet d'indiquer
+ comment l'en-tête ETag doit être modifié lorsqu'une réponse est compressée.
Ajoute la méthode de compression à la fin de l'en-tête ETag, ce qui + implique que les représentations compressées et non compressées possèderont + des en-têtes ETag uniques. C'était le comportement par défaut depuis la + version 2.4.0 avec un autre module de compression dynamique, + mod-deflate. Ce paramètre permet d'éviter l'envoi de messages + "HTTP Not Modified" (304) en réponse aux requêtes conditionnelles pour des + contenus compressés.
Ne modifie pas l'en-tête ETag d'une réponse compressée. C'était le + comportement par défaut depuis la version 2.4.0 avec un autre module de + compression dynamique, mod-deflate. Ce paramètre ne respecte pas la + propriété HTTP/1.1 selon laquelle toutes les représentations d'une même + ressource ont des en-têtes ETag uniques.
Supprime l'en-tête ETag des réponses compressées, ce qui rend + impossibles certaines requêtes conditionnelles, mais évite les inconvénients + des options précédentes.
| Description: | Taille maximale du bloc de données en entrée |
|---|---|
| Syntaxe: | BrotliCompressionMaxInputBlock value |
| Défaut: | (automatic) |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_brotli |
La directive BrotliCompressionMaxInputBlock permet
+ de spécifier la taille maximale du bloc de données en entrée entre 16 et 24,
+ sachant que plus cette taille sera grande, plus grande sera la quantité de
+ mémoire consommée.
| Description: | Qualité de la compression |
|---|---|
| Syntaxe: | BrotliCompressionQuality value |
| Défaut: | BrotliCompressionQuality 5 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_brotli |
La directive BrotliCompressionQuality permet de
+ spécifier la qualité de la compression (une valeur entre 0 et
+ 11). Les valeurs les plus hautes correspondent à une compression de
+ meilleure qualité mais plus lente.
+
| Description: | Taille de la fenêtre de compression glissante brotli |
|---|---|
| Syntaxe: | BrotliCompressionWindow value |
| Défaut: | BrotliCompressionWindow 18 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_brotli |
La directive BrotliCompressionWindow permet de
+ spécifier la taille de la fenêtre de compression glissante brotli (une
+ valeur comprise entre 10 et 24). Une taille de fenêtre plus grande peut
+ améliorer la qualité de la compression mais consomme d'avantage de mémoire.
| Description: | Enregistre le taux de compression dans une note à des fins de +journalisation |
|---|---|
| Syntaxe: | BrotliFilterNote [type] notename |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_brotli |
La directive BrotliFilterNote permet d'indiquer
+ qu'une note à propos du taux de compression doit être attachée à la
+ requête. L'argument notename permet de spécifier le nom de la
+ note. Vous pouvez utiliser cette note à des fins de statistiques en ajoutant
+ l'information correspondante à votre access
+ log.
BrotliFilterNote ratio
+
+LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' brotli
+CustomLog "logs/brotli_log" brotli
+Si vous souhaitez que l'information enregistrée dans vos journaux soit + plus pertinente, vous pouvez renseigner l'argument optionnel type + afin de spécifier le type de données à enregistrer dans la note à + journaliser. L'argument type accepte les valeurs suivantes :
+ +InputOutputRatiooutput/input *
+ 100). Il s'agit de l'option par défaut si l'argument
+ type est omis.Vous pouvez alors configurer vos journaux de la manière suivante :
+ +BrotliFilterNote Input instream
+BrotliFilterNote Output outstream
+BrotliFilterNote Ratio ratio
+
+LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' brotli
+CustomLog "logs/brotli_log" brotli
+Serveur HTTP Apache Version 2.4
+| Description: | Support de la mise en tampon des requêtes |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | buffer_module |
| Fichier Source: | mod_buffer.c |
| Compatibilité: | Disponible depuis les versions 2.3 et supérieures +d'Apache |
Ce module fournit la possibilité de mettre en tampon les piles + des filtres en entrée et sortie.
+ +Dans certaines situations, les générateurs de contenu créent des + contenus composés de petits tronçons. Afin de permettre la + réutilisation de la mémoire, les éléments de mémoire attribués aux + tronçons ont toujours une taille de 8k, quelle que soit la taille du + tronçon lui-même. Lorsqu'une requête génère de nombreux petits + tronçons, une grande quantité de mémoire peut être mobilisée par le + traitement de la requête, et une grande quantité de données + transmises sans nécessité. Pour y remédier, l'utilisation d'un + tampon rassemble la réponse en un nombre de tronçons le plus petit + possible.
+ +Lorsque httpd est utilisé comme frontal d'un générateur de + contenu consommant beaucoup de ressources, la mise en tampon de la + réponse peut permettre à ce dernier d'effectuer le traitement et de + libérer les ressources plus ou moins rapidement, en fonction de la + manière dont il a été conçu.
+ +Le filtre de mise en tampon peut être ajouté aux piles des
+ filtres en entrée ou en sortie, selon les besoins, à l'aide des
+ directives SetInputFilter,
+ SetOutputFilter, AddOutputFilter ou AddOutputFilterByType.
AddOutputFilterByType INCLUDES;BUFFER text/html+
| Description: | Taille maximale en octets du filtre par tampon |
|---|---|
| Syntaxe: | BufferSize entier |
| Défaut: | BufferSize 131072 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_buffer |
La directive BufferSize permet de spécifier la
+ quantité de données en octets qui sera mise en tampon avant d'être
+ lue depuis ou écrite vers chaque requête. La valeur par défaut est
+ 128 ko.
Serveur HTTP Apache Version 2.4
+| Description: | Filtre de mise en cache HTTP conforme à la RFC 2616 |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | cache_module |
| Fichier Source: | mod_cache.c |
CacheQuickHandler est définie à sa
+ valeur par défaut on, les directives Allow and Deny sont court-circuitées. Vous
+ ne devez donc pas activer la gestion rapide de la mise en cache pour
+ un contenu auquel vous souhaitez limiter l'accès en fonction du nom
+ d'hôte du client, de l'adresse IP ou d'une variable
+ d'environnement.mod_cache implémente un filtre de mise
+ en cache de contenu HTTP conforme à la RFC 2616, avec
+ support de la mise en cache des réponses dont le contenu a été
+ négocié et comportant l'en-tête Vary.
La mise en cache conforme à la RFC 2616 fournit un mécanisme + permettant de vérifier si un contenu expiré ou dépassé est encore à + jour, et peut apporter un gain de performances significatif si le + serveur original supporte les requêtes + conditionnelles en prenant en compte l'en-tête de requête + HTTP If-None-Match. + Le contenu n'est ainsi régénéré que lorsqu'il a été modifié, et non + lorsqu'il a expiré.
+ +En tant que filtre, mod_cache peut être placé
+ en face d'un contenu issu de tout gestionnaire, y compris
+ des fichiers à accès séquentiel (servis depuis un
+ disque lent mis en
+ cache sur un gros disque), la sortie d'un script
+ CGI ou d'un générateur de contenu
+ dynamique, ou du contenu mandaté depuis un autre
+ serveur.
Dans la configuration par défaut, mod_cache
+ place le filtre de mise en cache aussi loin que possible dans la
+ pile de filtres, utilisant le gestionnaire rapide
+ pour court-circuiter tout traitement par requête lors de l'envoi du
+ contenu au client. Dans ce mode opératoire,
+ mod_cache peut être considéré comme un serveur
+ mandataire avec cache fixé en tête du serveur web, alors qu'il
+ s'exécute dans ce même serveur web.
Lorsque le gestionnaire rapide est désactivé via la directive
+ CacheQuickHandler, il
+ devient possible d'insérer le filtre CACHE à un
+ point de la pile de filtres choisi par l'administrateur. Ceci permet
+ de mettre en cache un contenu avant que celui-ci ne soit
+ personnalisé par le filtre mod_include, ou
+ éventuellement compressé par le filtre mod_deflate.
Dans le mode de fonctionnement normal, mod_cache
+ peut être contrôlé par les en-têtes Cache-Control
+ et Pragma
+ envoyés par un client dans une requête, ou par un serveur dans une
+ réponse. Dans des circonstances exceptionnelles,
+ mod_cache peut cependant être configuré pour
+ outrepasser ces en-têtes et forcer un comportement spécifique au
+ site, bien qu'un tel comportement sera limité à ce cache seulement,
+ et n'affectera pas les opérations des autres caches qui peuvent
+ s'insérer entre le client et le serveur, et ce type de configuration
+ ne doit donc être utiliser qu'en cas de nécessité absolue.
La RFC 2616 permet au cache de renvoyer des données périmées
+ pendant que l'entrée périmée correspondante est mise à jour depuis
+ le serveur original, et mod_cache supporte cette
+ fonctionnalité lorsque la directive CacheLock est configurée en
+ conséquence. De telles réponses comportent un en-tête HTTP Warning
+ contenant un code de réponse 110. La RFC 2616 permet aussi au cache
+ de renvoyer des données périmées lorsque la tentative de mise à jour
+ des données périmées renvoie une erreur 500 ou supérieure, et cette
+ fonctionnalité est supportée par défaut par
+ mod_cache. De telles réponses comportent un en-tête HTTP Warning
+ contenant un code de réponse 111.
mod_cache requiert les services d'un ou
+ plusieurs modules de gestion de stockage. La distribution Apache de base
+ inclut les modules de gestion de stockage suivants :
mod_cache_diskhtcacheclean permet de lister et de supprimer les
+ URLs mises en cache, et de maintenir le cache en deçà de
+ certaines limites de taille et de nombre d'inodes.mod_cache_socachePour de plus amples détails, une description, et des exemples, + reportez-vous au Guide de la mise en + cache.
+ Modules apparentés et directives Exemple de configuration Eviter une tempête de requête Contrôle fin via le filtre CACHE Etat du cache et journalisation CacheDefaultExpire CacheDetailHeader CacheDisable CacheEnable CacheHeader CacheIgnoreCacheControl CacheIgnoreHeaders CacheIgnoreNoLastMod CacheIgnoreQueryString CacheIgnoreURLSessionIdentifiers CacheKeyBaseURL CacheLastModifiedFactor CacheLock CacheLockMaxAge CacheLockPath CacheMaxExpire CacheMinExpire CacheQuickHandler CacheStaleOnError CacheStoreExpired CacheStoreNoStore CacheStorePrivate| Modules Apparentés | Directives Apparentées |
|---|---|
# +# Exemple de configuration du cache +# +LoadModule cache_module modules/mod_cache.so +<IfModule mod_cache.c> + LoadModule cache_disk_module modules/mod_cache_disk.so + <IfModule mod_cache_disk.c> + CacheRoot "c:/cacheroot" + CacheEnable disk "/" + CacheDirLevels 5 + CacheDirLength 3 + </IfModule> + + # Lorsqu'on sert de mandataire, on ne met pas en cache la liste +# des mises à jour de sécurité + CacheDisable "http://security.update.server/update-list/" +</IfModule>+
Lorsqu'une entrée du cache est périmée, mod_cache
+ soumet une requête conditionnelle au processus d'arrière-plan, qui est
+ censé confirmer la validité de l'entrée du cache, ou dans la négative
+ envoyer une entrée mise à jour.
Un court mais non négligeable laps de temps existe entre le moment + où l'entrée du cache est périmée, et le moment où elle est mise à + jour. Sur un serveur fortement chargé, un certain nombre de requêtes + peut arriver pendant ce laps de temps, et provoquer une + tempête de requêtes susceptibles de saturer le + processus d'arrière-plan de manière soudaine et imprédictible.
+Pour contenir cette tempête, on peut utiliser la directive
+ CacheLock afin de définir un répertoire où
+ seront créés à la volée des verrous pour les URLs.
+ Ces verrous sont utilisés comme autant d'indications
+ par les autres requêtes, soit pour empêcher une tentative de mise en
+ cache (un autre processus est en train de récupérer l'entité), soit
+ pour indiquer qu'une entrée périmée est en cours de mise à jour
+ (pendant ce temps, c'est le contenu périmé qui sera renvoyé).
+
Lorsqu'une entité est mise en cache pour la première fois, un + verrou est créé pour cette entité jusqu'à ce que la réponse ait été + entièrement mise en cache. Pendant la durée de vie du verrou, le + cache va empêcher une seconde tentative de mise en cache de la même + entité. Bien que cela ne suffise pas à contenir la tempête de + requêtes, toute tentative de mettre en cache la même entité + plusieurs fois simultanément est stoppée. +
+ +Lorsqu'une entrée atteint la limite de sa durée de vie, et + devient par conséquent périmée, un verrou est créé pour cette entité + jusqu'à ce que la réponse ait été soit confirmée comme encore + valide, soit remplacée par le processus d'arrière-plan. Pendant la + durée de vie du verrou, une seconde requête entrante va provoquer le + renvoi de la donnée périmée, et la tempête de requêtes sera + contenue.
+ +Les verrous ne sont utilisés qu'à titre + indicatif pour enjoindre le cache à être plus coopératif + avec les serveurs d'arrière-plan, et il est possible de passer outre + si nécessaire. Si le client envoie une requête contenant un en-tête + Cache-Control imposant un nouveau téléchargement de l'entité, tout + verrou éventuel sera ignoré, la requête du client sera honorée + immédiatement, et l'entrée du cache mise à jour.
+ +Comme mécanisme de sécurité supplémentaire, la durée de vie
+ maximale des verrous est configurable. Lorsque cette limite est
+ atteinte, le verrou est supprimé et une autre requête peut alors en
+ créer un nouveau. Cette durée de vie peut être définie via la
+ directive CacheLockMaxAge, et sa valeur par
+ défaut est de 5 secondes.
+
# +# Active le verrouillage du cache +# +<IfModule mod_cache.c> + CacheLock on + CacheLockPath "/tmp/mod_cache-lock" + CacheLockMaxAge 5 +</IfModule>+
Dans son mode de fonctionnement par défaut, le cache s'exécute sous + la forme d'un gestionnaire rapide, court-circuitant la majorité des + traitements du serveur et fournissant ainsi une mise en cache + possédant les plus hautes performances disponibles.
+ +Dans ce mode, le cache s'incruste devant le + serveur, comme si un mandataire de mise en cache indépendant RFC 2616 + était placé devant ce dernier.
+ +Bien que que ce mode offre les meilleures performances, les + administrateurs peuvent souhaiter, dans certaines circonstances, + effectuer des traitements sur la requête après que cette dernière ait + été mise en cache, comme ajouter du contenu personnalisé à la page + mise en cache, ou appliquer des restrictions d'autorisations au + contenu. Pour y parvenir, l'administrateur sera alors souvent forcé de + placer des serveurs mandataires inverses indépendants soit derrière, + soit devant le serveur de mise en cache.
+ +Pour résoudre ce problème, la directive CacheQuickHandler peut être définie à
+ off, afin que le serveur traite toutes les phases
+ normalement exécutées par une requête non mise en cache, y compris les
+ phases d'authentification et d'autorisation.
En outre, l'administrateur peut éventuellement spécifier le + point précis dans la chaîne de filtrage où devra + intervenir la mise en cache en ajoutant le filtre + CACHE à la chaîne de filtrage en sortie.
+ +Par exemple, pour mettre en cache le contenu avant d'appliquer une + compression à la réponse, placez le filtre CACHE + avant le filtre DEFLATE comme dans l'exemple suivant + :
+ +# Mise en cache du contenu avant la compression optionnelle +CacheQuickHandler off +AddOutputFilterByType CACHE;DEFLATE text/plain+ + +
Une autre possibilité consiste à mettre en cache le contenu avant
+ l'ajout de contenu personnalisé via mod_include (ou
+ tout autre filtre de traitement de contenu). Dans l'exemple suivant,
+ les modèles contenant des balises comprises par
+ mod_include sont mis en cache avant d'être
+ interprétés :
# Mise en cache du contenu avant l'intervention de mod_include et + # mod_deflate +CacheQuickHandler off +AddOutputFilterByType CACHE;INCLUDES;DEFLATE text/html+ + +
Vous pouvez insérer le filtre CACHE en tout point
+ de la chaîne de filtrage. Dans l'exemple suivant, le contenu est mis
+ en cache après avoir été interprété par mod_include,
+ mais avant d'être traité par mod_deflate :
# Mise en cache du contenu entre les interventions de mod_include et + # mod_deflate +CacheQuickHandler off +AddOutputFilterByType INCLUDES;CACHE;DEFLATE text/html+ + +
mod_cache n'est pas
+ en mesure d'effectuer cette opération à votre place.Lorsque mod_cache a décidé s'il devait ou non
+ servir une entité depuis le cache, les raisons précises de cette
+ décision sont enregistrées dans l'environnement du sous-processus
+ interne à la requête sous la clé cache-status.
+ Cette information peut être journalisée via la directive LogFormat comme suit :
LogFormat "%{cache-status}e ..."
+
+
+ En fonction de la décision prise, l'information est aussi écrite + dans l'environnement du sous-processus sous une des quatre clés + suivantes :
+ +Il est alors possible d'envisager une journalisation conditionnelle + du traitement des requêtes par rapport au cache comme dans l'exemple + suivant :
+ +CustomLog "cached-requests.log" common env=cache-hit +CustomLog "uncached-requests.log" common env=cache-miss +CustomLog "revalidated-requests.log" common env=cache-revalidate +CustomLog "invalidated-requests.log" common env=cache-invalidate+ + +
Pour les concepteurs de modules, une accroche (hook) nommée + cache_status est disponible et permet aux modules de + répondre aux résultats de la vérification du cache ci-dessus de manière + personnalisée.
+ +| Description: | La durée par défaut de mise en cache d'un document +lorsqu'aucune date d'expiration n'a été spécifiée. |
|---|---|
| Syntaxe: | CacheDefaultExpire secondes |
| Défaut: | CacheDefaultExpire 3600 (une heure) |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheDefaultExpire permet de
+ spécifier un temps par défaut, en secondes, pendant lequel sera
+ conservé dans le cache un document qui ne possède ni date
+ d'expiration, ni date de dernière modification. La valeur de cette
+ directive est écrasée par la valeur de la directive
+ CacheMaxExpire si cette dernière est
+ utilisée.
CacheDefaultExpire 86400+ + +
| Description: | Ajoute un en-tête X-Cache-Detail à la réponse. |
|---|---|
| Syntaxe: | CacheDetailHeader on|off |
| Défaut: | CacheDetailHeader off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache |
| Compatibilité: | Disponible depuis la version 2.3.9 d'Apache |
Lorsque la directive CacheDetailHeader est définie à on, un
+ en-tête X-Cache-Detail est ajouté à la réponse et
+ contient les raisons précises d'une décision d'utilisation du cache
+ vis à vis de cette dernière.
Ceci peut s'avérer utile au cours du développement de services
+ RESTful mis en cache pour obtenir des informations supplémentaires à
+ propos des décisions vis à vis du cache écrites dans les en-têtes de
+ la réponse. Il est ainsi possible de vérifier si
+ Cache-Control et d'autres en-têtes ont été correctement
+ utilisés par le service et le client.
Si le gestionnaire normal est utilisé, cette directive peut se
+ situer dans une section <Directory> ou <Location>. Si c'est le gestionnaire
+ rapide qui est utilisé, elle doit se situer dans un contexte de
+ serveur principal ou de serveur virtuel, sinon elle sera ignorée.
# Active l'en-tête X-Cache-Detail +CacheDetailHeader on+ + +
+ X-Cache-Detail: "conditional cache hit: entity refreshed" from localhost
+
| Description: | Désactive la mise en cache des URLs +spécifiées |
|---|---|
| Syntaxe: | CacheDisable chaîne-url | on |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheDisable enjoint
+ mod_cache de ne pas mettre en cache l'URL
+ spécifiée par chaîne URL, ainsi que les URLs de niveaux
+ inférieurs.
CacheDisable "/fichiers_locaux"+
Si la directive se trouve à l'intérieur d'une section <Location>, le chemin doit être spécifié en
+ dessous de la Location, et si le mot "on" est utilisé, la mise en
+ cache sera désactivée pour l'ensemble de l'arborescence concernée
+ par la section Location.
<Location "/foo"> + CacheDisable on +</Location>+
Avec les versions 2.2.12 et ultérieures, on peut définir la
+ variable d'environnement no-cache pour une définition
+ plus fine des ressources à mettre en cache.
| Description: | Active la mise en cache des URLs spécifiées en utilisant le +gestionnaire de stockage précisé |
|---|---|
| Syntaxe: | CacheEnable type de cache [chaîne
+URL] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_cache |
| Compatibilité: | Une chaîne URL telle que '/' s'appliquait à tout contenu +en mandat direct dans les versions 2.2 et antérieures. |
La directive CacheEnable enjoint
+ mod_cache de mettre en cache l'URL précisée par
+ chaîne URL, ainsi que les URLs de niveaux inférieurs. Le
+ gestionnaire de stockage du cache est spécifié à l'aide de
+ l'argument type de cache. La directive
+ CacheEnable peut être placée à l'intérieur d'une
+ section <Location> ou <LocationMatch> pour indiquer que le
+ contenu considéré peut être mis en cache. Si type de cache
+ a pour valeur disk, mod_cache
+ utilisera le gestionnaire de stockage sur disque implémenté par
+ mod_cache_disk. Pour que mod_cache
+ utilise le gestionnaire de stockage basé sur le cache d'objets
+ partagés implémenté par mod_cache_socache,
+ spécifiez socache comme valeur du paramètre type
+ de cache.
Si les différentes directives CacheEnable
+ spécifient des URLs qui se recoupent (comme dans l'exemple
+ ci-dessous), tous les gestionnaires de stockage possibles seront
+ lancés, jusqu'au premier d'entre eux qui traitera effectivement la
+ requête.
+ L'ordre dans lequel les gestionnaires de stockage sont lancés est
+ déterminé par l'ordre dans lequel apparaissent les directives
+ CacheEnable dans le fichier de
+ configuration. Les directives CacheEnable
+ situées à l'intérieur de sections <Location> ou <LocationMatch> sont traitées avant les
+ directives CacheEnable définies au niveau
+ global.
En fonctionnement du type serveur mandataire direct, chaîne + URL doit au moins débuter par un protocole pour lequel la mise + en cache doit être activée.
+ +# Mise en cache de contenu (gestionnaire normal seulement) +CacheQuickHandler off +<Location "/foo"> + CacheEnable disk +</Location> + +# Mise en cache via une expression rationnelle (gestionnaire normal seulement) +CacheQuickHandler off +<LocationMatch "foo$"> + CacheEnable disk +</LocationMatch> + +# Mise en cache de tous les contenus, à l'exception des URLs +# mandatées en direct (gestionnaire normal ou rapide) +CacheEnable disk / + +# Mise en cache des URLs FTP mandatées (gestionnaire normal ou rapide) +CacheEnable disk ftp:// + +# Mise en cache des contenus mandatés en direct depuis www.example.org (gestionnaire normal ou rapide) +CacheEnable disk http://www.example.org/+ + +
Un nom d'hôte commençant par un caractère "*" + correspondra à tout nom d'hôte se terminant par le suffixe + considéré. Un nom d'hôte commençant par un caractère + "." correspondra à tout nom d'hôte contenant le + composant de nom de domaine qui suit ce caractère.
+ +# Correspond à www.example.org et fooexample.org +CacheEnable disk "http://*example.org/" +# Correspond à www.example.org, mais pas à fooexample.org +CacheEnable disk "http://.example.org/"+ + +
Depuis la version 2.2.12, on peut définir la variable
+ d'environnement no-cache pour une définition plus fine
+ des ressources à mettre en cache.
| Description: | Ajoute un en-tête X-Cache à la réponse. |
|---|---|
| Syntaxe: | CacheHeader on|off |
| Défaut: | CacheHeader off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache |
| Compatibilité: | Disponible depuis la version 2.3.9 d'Apache |
Lorsque la directive CacheHeader est définie à on, un
+ en-tête X-Cache est ajouté à la réponse et contient
+ l'état du cache pour cette dernière. Si le gestionnaire normal est
+ utilisé, cette directive peut se situer dans une section
+ <Directory> ou
+ <Location>. Si c'est
+ le gestionnaire rapide qui est utilisé, elle doit se situer dans un
+ contexte de serveur principal ou de serveur virtuel, sinon elle sera
+ ignorée.
# Active l'en-tête X-Cache +CacheHeader on+ + +
X-Cache: HIT from localhost+ + + + +
| Description: | Ignore les en-têtes de requête enjoignant de ne pas servir +le contenu au client depuis le cache |
|---|---|
| Syntaxe: | CacheIgnoreCacheControl On|Off |
| Défaut: | CacheIgnoreCacheControl Off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
Normalement, les requêtes contenant des en-têtes tels que
+ Cache-Control: no-cache ou Pragma: no-cache ne sont pas servies
+ depuis le cache. La directive
+ CacheIgnoreCacheControl permet de modifier ce
+ comportement. Avec CacheIgnoreCacheControl
+ On, le serveur tentera de servir la ressource depuis le
+ cache, même si la requête contient un des en-têtes cités plus haut.
+ Les ressources qui requièrent une autorisation ne seront
+ jamais mises en cache.
CacheIgnoreCacheControl On+ + +
| Description: | Ne pas stocker le(s) en-tête(s) spécifié(s) dans le cache. + |
|---|---|
| Syntaxe: | CacheIgnoreHeaders en-tête [en-tête] ... |
| Défaut: | CacheIgnoreHeaders None |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
En accord avec la RFC 2616, les en-têtes HTTP hop-by-hop ne sont
+ pas stockés dans le cache. Les en-têtes HTTP suivant sont des
+ en-têtes hop-by-hop, et en tant que tels, ne sont en aucun
+ cas stockés dans le cache, quelle que soit la définition de la
+ directive CacheIgnoreHeaders :
ConnectionKeep-AliveProxy-AuthenticateProxy-AuthorizationTETrailersTransfer-EncodingUpgradeLa directive CacheIgnoreHeaders permet de
+ spécifier quels en-têtes HTTP ne doivent pas être stockés dans le
+ cache. Par exemple, il peut s'avérer pertinent dans certains cas de
+ ne pas stocker les cookies dans le cache.
La directive CacheIgnoreHeaders accepte
+ une liste d'en-têtes HTTP séparés par des espaces, qui ne doivent
+ pas être stockés dans le cache. Si les en-têtes hop-by-hop sont les
+ seuls à ne pas devoir être stockés dans le cache (le comportement
+ compatible RFC 2616), la directive
+ CacheIgnoreHeaders peut être définie à
+ None.
CacheIgnoreHeaders Set-Cookie+
CacheIgnoreHeaders None+
Expires, ne sont pas stockés suite à la définition
+ d'une directive CacheIgnoreHeaders, le
+ comportement de mod_cache sera imprévisible.
+ | Description: | Ignore le fait qu'une réponse ne possède pas d'en-tête Last +Modified. |
|---|---|
| Syntaxe: | CacheIgnoreNoLastMod On|Off |
| Défaut: | CacheIgnoreNoLastMod Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache |
Normalement, les documents qui ne possèdent pas de date de
+ dernière modification ne sont pas mis en cache. Dans certaines
+ circonstances, la date de dernière modification est supprimée (au
+ cours des traitements liés à mod_include par
+ exemple), ou n'existe tout simplement pas. La directive
+ CacheIgnoreNoLastMod permet de spécifier si
+ les documents ne possèdant pas de date de dernière modification
+ doivent être mis en cache, même sans date de dernière modification.
+ Si le document ne possède ni date d'expiration, ni date de dernière
+ modification, la valeur spécifiée par la directive
+ CacheDefaultExpire servira à générer une date
+ d'expiration.
+
CacheIgnoreNoLastMod On+ + +
| Description: | Ignore la chaîne de paramètres lors de la mise en +cache |
|---|---|
| Syntaxe: | CacheIgnoreQueryString On|Off |
| Défaut: | CacheIgnoreQueryString Off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
Normalement, les requêtes comportant une chaîne de paramètres
+ sont mises en cache séparément si leurs chaînes de paramètres
+ diffèrent.
+ En accord avec la RFC 2616/13.9, cette mise en cache n'est effectuée
+ séparément que si une date d'expiration est spécifiée. La directive
+ CacheIgnoreQueryString permet la mise en
+ cache de requêtes même si aucune date d'expiration est spécifiée, et
+ de renvoyer une réponse depuis la cache même si les chaînes de
+ paramètres diffèrent. Du point de vue du cache, la requête est
+ traitée comme si elle ne possèdait pas de chaîne de paramètres
+ lorsque cette directive est activée.
CacheIgnoreQueryString On+ + + +
| Description: | Ignore les identifiants de session définis encodés dans +l'URL lors de la mise en cache + |
|---|---|
| Syntaxe: | CacheIgnoreURLSessionIdentifiers identifiant
+[identifiant] ... |
| Défaut: | CacheIgnoreURLSessionIdentifiers None |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
Certaines applications encodent l'identifiant de session dans + l'URL comme dans l'exemple suivant : +
+/une-application/image.gif;jsessionid=123456789/une-application/image.gif?PHPSESSIONID=12345678Ceci implique la mise en cache des ressources séparément pour
+ chaque session, ce qui n'est en général pas souhaité. La directive
+ CacheIgnoreURLSessionIdentifiers permet de
+ définir une liste d'identifiants qui seront supprimés de la clé
+ utilisée pour identifier une entité dans le cache, de façon à ce que
+ les ressources ne soient pas stockées séparément pour chaque
+ session.
+
CacheIgnoreURLSessionIdentifiers None vide la liste
+ des identifiants ignorés. Autrement, chaque identifiant spécifié est
+ ajouté à la liste.
CacheIgnoreURLSessionIdentifiers jsessionid+
CacheIgnoreURLSessionIdentifiers None+
| Description: | Remplace l'URL de base des clés du cache mandatées en +inverse |
|---|---|
| Syntaxe: | CacheKeyBaseURL URL |
| Défaut: | CacheKeyBaseURL http://example.com |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
| Compatibilité: | Disponible depuis la version 2.3.9 d'Apache |
Lorsque la directive CacheKeyBaseURL est utilisée, l'URL
+ spécifiée sera utilisée comme URL de base pour calculer l'URL des clés
+ du cache dans la configuration du mandataire inverse. Par défaut,
+ c'est le protocole/nom d'hôte/port du serveur virtuel courant qui sera
+ utilisé pour construire la clé de cache. Dans le cas d'un cluster de
+ machines, si toutes les entrées du cache doivent posséder la même clé,
+ cette directive permet de spécifier une nouvelle URL de base.
# Remplace l'URL de base de la clé de cache. +CacheKeyBaseURL "http://www.example.com/"+ + +
| Description: | Le facteur utilisé pour générer une date d'expiration en +fonction de la date de dernière modification. |
|---|---|
| Syntaxe: | CacheLastModifiedFactor flottant |
| Défaut: | CacheLastModifiedFactor 0.1 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache |
Si un document ne possède pas de date d'expiration, elle peut
+ être calculée en fonction de la date de dernière modification, si
+ elle existe. La directive
+ CacheLastModifiedFactor permet de spécifier
+ un facteur à utiliser pour la génération de cette date
+ d'expiration au sein de la formule suivante :
+
+ délai-expiration = durée-depuis-date-dernière-modification *
+ facteur
+ date-expiration = date-courante + délai-expiration
+
+ Par exemple, si la dernière modification du document date de 10
+ heures, et si facteur a pour valeur 0.1, le délai
+ d'expiration sera de 10*0.1 = 1 heure. Si l'heure courante est
+ 3:00pm, la date d'expiration calculée sera 3:00pm + 1 heure =
+ 4:00pm.
+
+ Si le délai d'expiration est supérieur à celui spécifié par la
+ directive CacheMaxExpire, c'est ce dernier
+ qui l'emporte.
CacheLastModifiedFactor 0.5+ + +
| Description: | Active la protection contre les tempêtes de requêtes. |
|---|---|
| Syntaxe: | CacheLock on|off |
| Défaut: | CacheLock off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
| Compatibilité: | Disponible depuis la version 2.2.15 d'Apache |
La directive CacheLock active la protection
+ contre les tempêtes de requêtes pour l'espace d'adressage donné.
La configuration minimale pour activer le verrouillage contre les + tempêtes de requêtes dans le répertoire temp par défaut du système est + la suivante :
+ +# Active le verrouillage du cache +CacheLock on+ + + +
| Description: | Définit la durée de vie maximale d'un verrou de cache. |
|---|---|
| Syntaxe: | CacheLockMaxAge entier |
| Défaut: | CacheLockMaxAge 5 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheLockMaxAge permet de
+ spécifier la durée de vie maximale d'un verrou de cache.
Un verrou plus ancien que cette valeur exprimée en secondes sera + ignoré, et la prochaine requête entrante sera alors en mesure de + recréer le verrou. Ce mécanisme permet d'éviter les mises à jour trop + longues initiées par des clients lents.
+ + +| Description: | Définit le répertoire des verrous. |
|---|---|
| Syntaxe: | CacheLockPath répertoire |
| Défaut: | CacheLockPath /tmp/mod_cache-lock |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheLockPath permet de
+ spécifier le répertoire dans lequel les verrous sont créés. Par
+ défaut, c'est le répertoire temporaire du système qui est utilisé. Les
+ verrous sont des fichiers vides qui n'existent que pour les URLs
+ périmées en cours de mise à jour, et consomment donc bien moins de
+ ressources que le traditionnel cache sur disque.
| Description: | La durée maximale en secondes de mise en cache d'un +document |
|---|---|
| Syntaxe: | CacheMaxExpire secondes |
| Défaut: | CacheMaxExpire 86400 (une journée) |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheMaxExpire permet de
+ spécifier le nombre maximum de secondes pendant lequel les documents
+ HTTP suceptibles d'être mis en cache seront conservés sans vérifier
+ leur contenu sur le serveur d'origine. Ce nombre de secondes
+ correspond donc à la durée maximale pendant laquelle un document ne
+ sera pas à jour. L'utilisation de cette valeur maximale est forcée,
+ même si le document possède une date d'expiration.
CacheMaxExpire 604800+ + + +
| Description: | La durée minimale en secondes de mise en cache d'un +document |
|---|---|
| Syntaxe: | CacheMinExpire secondes |
| Défaut: | CacheMinExpire 0 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache |
La directive CacheMaxExpire permet de
+ spécifier le nombre maximum de secondes pendant lequel les documents
+ HTTP suceptibles d'être mis en cache seront conservés sans vérifier
+ leur contenu sur le serveur d'origine. Elle n'est prise en compte
+ que dans le cas où le document ne possède aucune date d'expiration
+ valide.
CacheMinExpire 3600+ + +
| Description: | Exécute le cache à partir d'un gestionnaire rapide. |
|---|---|
| Syntaxe: | CacheQuickHandler on|off |
| Défaut: | CacheQuickHandler on |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache |
| Compatibilité: | Disponible à partir de la version 2.3.3 du serveur HTTP + Apache |
La directive CacheQuickHandler permet de contrôler
+ la phase au cours de laquelle la mise en cache est effectuée.
Avec la configuration par défaut, le cache agit au cours de la + phase du gestionnaire rapide. Cette phase court-circuite la majorité + des traitements du serveur, et constitue le mode d'opération le plus + performant pour un serveur typique. Le cache + s'incruste devant le serveur, et la majorité des + traitements du serveur est court-circuitée.
+ +Lorsque cette directive est définie à off, le cache agit comme un + gestionnaire normal, et est concerné par toutes les phases de + traitement d'une requête. Bien que ce mode soit moins performant que + le mode par défaut, il permet d'utiliser le cache dans les cas où un + traitement complet de la requête est nécessaire, comme par exemple + lorsque le contenu est soumis à autorisation.
+ +# Exécute le cache comme un gestionnaire normal +CacheQuickHandler off+ + +
Lorsque le gestionnaire rapide est désactivé, l'administrateur a + aussi la possibilité de choisir avec précision le point de la chaîne + de filtrage où la mise en cache sera effectuée, en utilisant le + filtre CACHE.
+ +# Mise en cache du contenu avant l'intervention de mod_include et + # mod_deflate +CacheQuickHandler off +AddOutputFilterByType CACHE;INCLUDES;DEFLATE text/html+ + +
Si le filtre CACHE est spécifié plusieurs fois, c'est la dernière + instance qui sera prise en compte.
+ + +| Description: | Sert du contenu non à jour à la place de réponses 5xx. |
|---|---|
| Syntaxe: | CacheStaleOnError on|off |
| Défaut: | CacheStaleOnError on |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache |
| Compatibilité: | Disponible depuis la version 2.3.9 d'Apache |
Lorsque la directive CacheStaleOnError est définie à on, et
+ si des données non mises à jour sont disponibles dans le cache, ce
+ dernier renverra ces données, plutôt qu'une éventuelle réponse 5xx en
+ provenance du serveur d'arrière-plan. Alors que l'en-tête
+ Cache-Control envoyé par les clients sera respecté, et que les clients
+ recevront donc dans ce cas la réponse 5xx brute à leur requête, cette
+ réponse 5xx renvoyée au client n'invalidera pas le contenu dans le
+ cache.
# Sert des données non mises à jour en cas d'erreur. +CacheStaleOnError on+ + + +
| Description: | Tente de mettre en cache les réponses que le serveur +considère comme arrivées à expiration |
|---|---|
| Syntaxe: | CacheStoreExpired On|Off |
| Défaut: | CacheStoreExpired Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache |
Depuis la version 2.2.4, les réponses qui sont arrivées à
+ expiration ne sont pas stockées dans le cache. La directive
+ CacheStoreExpired permet de modifier ce
+ comportement. Avec CacheStoreExpired On, le
+ serveur tente de mettre en cache la ressource si elle est périmée.
+ Les requêtes suivantes vont déclencher une requête si-modifié-depuis
+ de la part du serveur d'origine, et la réponse sera renvoyée à
+ partir du cache si la ressource d'arrière-plan n'a pas été modifiée.
CacheStoreExpired On+ + + +
| Description: | Tente de mettre en cache les requêtes ou réponses dont +l'entête Cache-Control: a pour valeur no-store. |
|---|---|
| Syntaxe: | CacheStoreNoStore On|Off |
| Défaut: | CacheStoreNoStore Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache |
Normalement, les requêtes ou réponses dont l'en-tête
+ Cache-Control: a pour valeur no-store ne sont pas stockées dans le
+ cache. La directive CacheStoreNoStore permet
+ de modifier ce comportement. Si
+ CacheStoreNoStore est définie à On, le
+ serveur tente de mettre la ressource en cache même si elle contient
+ des en-têtes ayant pour valeur no-store. Les ressources
+ nécessitant une autorisation ne sont jamais mises en
+ cache.
CacheStoreNoStore On+ + + +
CacheStoreNoCache pourrait provoquer le
+ stockage d'informations sensibles dans le cache. Vous avez donc
+ été prévenus.
+ | Description: | Tente de mettre en cache des réponses que le serveur a +marquées comme privées |
|---|---|
| Syntaxe: | CacheStorePrivate On|Off |
| Défaut: | CacheStorePrivate Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache |
Normalement, les réponse comportant un en-tête Cache-Control:
+ dont la valeur est private ne seront pas stockées dans le cache. La
+ directive CacheStorePrivate permet de
+ modifier ce comportement. Si
+ CacheStorePrivate est définie à On, le
+ serveur tentera de mettre la ressource en cache, même si elle
+ contient des en-têtes ayant pour valeur private. Les ressources
+ nécessitant une autorisation ne sont jamais mises en
+ cache.
CacheStorePrivate On+ + + +
Serveur HTTP Apache Version 2.4
+| Description: | Module de stockage sur disque pour le filtre de mise en +cache HTTP. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | cache_disk_module |
| Fichier Source: | mod_cache_disk.c |
mod_cache_disk implémente un gestionnaire de
+ stockage sur disque pour le module mod_cache.
Les en-têtes et corps des réponses mises en cache sont stockés + séparément sur le disque, dans une structure de répertoires basée + sur le condensé md5 de l'URL mise en cache.
+ +Plusieurs réponses au contenu négocié peuvent être stockées en + même temps, mais la mise en cache de contenus partiels n'est pas + supportée actuellement par ce module.
+ +Les mises à jour atomiques du cache pour les fichiers d'en-tête + et de corps peuvent être effectuées sans verrouillage en + enregistrant les numéros d'inode et de périphérique du fichier de + corps dans le fichier d'en-tête. Ceci implique que les entrées du + cache déplacées manuellement dans le cache seront ignorées.
+ +L'utilitaire htcacheclean permet de lister et
+ de supprimer les URLs du cache, ou de maintenir le cache en deçà de
+ certaines limites de taille et/ou de nombre d'inodes. L'utilitaire
+ peut être exécuté à la demande, ou automatiquement pour assurer un
+ contrôle continu des tailles des répertoires.
mod_cache doit être chargé avant
+ mod_cache_disk pour que ce dernier puisse
+ fonctionner.
Lorsque la plate-forme la supporte, et si elle est activée via la
+ directive EnableSendfile,
+ mod_cache_disk utilise la fonctionnalité sendfile
+ pour servir les fichiers à partir du cache. Cependant,
+ mod_cache_disk ignore la configuration de la
+ directive EnableSendfile dans
+ un contexte de répertoire ou de fichier .htaccess, car le module ne
+ dispose pas des définitions correspondantes lorsque la requête est
+ servie depuis le cache.
CacheDirLength CacheDirLevels CacheMaxFileSize CacheMinFileSize CacheReadSize CacheReadTime CacheRoot| Description: | Le nombre de caractères des noms des +sous-répertoires |
|---|---|
| Syntaxe: | CacheDirLength longueur |
| Défaut: | CacheDirLength 2 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache_disk |
la directive CacheDirLength permet de
+ définir le nombre de caractères que comportera chaque nom de
+ sous-répertoire de la hiérarchie du cache. On peut l'utiliser en
+ conjonction avec CacheDirLevels pour
+ déterminer une structure approximative de la hiérarchie de
+ cache.
Une valeur haute pour CacheDirLength
+ combinée avec une valeur basse pour
+ CacheDirLevels générera une hiérarchie
+ relativement peu profonde, avec un grand nombre de sous-répertoires
+ à chaque niveau.
La valeur du produit CacheDirLevels *
+ CacheDirLength ne
+ doit pas dépasser 20.
| Description: | Le nombre de niveaux de sous-répertoires que comportera le +cache. |
|---|---|
| Syntaxe: | CacheDirLevels niveaux |
| Défaut: | CacheDirLevels 2 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache_disk |
La directive CacheDirLevels permet de
+ définir le nombre de niveaux de sous-répertoires que comportera le
+ cache. Les données du cache seront stokées au niveau correspondant
+ par rapport au répertoire CacheRoot.
Une valeur haute pour CacheDirLevels
+ combinée avec une valeur basse pour
+ CacheDirLength générera une arborescence
+ très développée, avec un petit nombre de sous-répertoires à chaque
+ niveau.
La valeur du produit CacheDirLevels *
+ CacheDirLength ne
+ doit pas dépasser 20.
| Description: | >La taille maximale (en octets) d'un document pour pouvoir +être stocké dans le cache |
|---|---|
| Syntaxe: | CacheMaxFileSize octets |
| Défaut: | CacheMaxFileSize 1000000 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache_disk |
La directive CacheMaxFileSize permet de
+ définir la taille maximale d'un document, en octets, pour que
+ celui-ci puisse faire l'objet d'un stockage dans le cache.
CacheMaxFileSize 64000+ + +
| Description: | La taille minimale (en octets) d'un document pour pouvoir +être stocké dans le cache |
|---|---|
| Syntaxe: | CacheMinFileSize octets |
| Défaut: | CacheMinFileSize 1 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache_disk |
La directive CacheMinFileSize permet de
+ définir la taille minimale d'un document, en octets, pour que
+ celui-ci puisse faire l'objet d'un stockage dans le cache.
CacheMinFileSize 64+ + +
| Description: | La quantité minimale (en octets) de données à lire et à +mettre en cache avant de les envoyer au client |
|---|---|
| Syntaxe: | CacheReadSize octets |
| Défaut: | CacheReadSize 0 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache_disk |
La directive CacheReadSize permet de
+ définir la quantité minimale de données, en octets, à lire depuis le
+ serveur d'arrière-plan avant de les envoyer au client. Avec la
+ valeur par défaut zéro, toute donnée de toutes tailles est envoyée
+ au client dès qu'elle est disponible. Avec une valeur non nulle, le
+ cache disque met en tampon au moins la quantité de données
+ correspondante avant d'envoyer la réponse au client. Les
+ performances peuvent s'en trouver améliorées lorsqu'on met en cache
+ du contenu en provenance d'un mandataire inverse.
Cette directive ne prend effet que lorsque les données sont + enregistrées dans le cache, et non lorsque les données sont servies à + partir du cache.
+ +CacheReadSize 102400+ + +
| Description: | Le temps minimum (en millisecondes) qui doit s'écouler +avant d'envoyer les données au client |
|---|---|
| Syntaxe: | CacheReadTime millisecondes |
| Défaut: | CacheReadTime 0 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache_disk |
La directive CacheReadTime permet de
+ définir le temps minimum qui doit s'écouler avant d'essayer
+ d'envoyer des données au client. Pendant ce temps, les données sont
+ mises en tampon avant de pouvoir être envoyées au client. Les
+ performances peuvent s'en trouver améliorées lorsqu'on met en cache
+ du contenu en provenance d'un mandataire inverse.
La valeur par défaut zéro désactive cette option.
+ +Cette directive ne prend effet que lorsque les données sont
+ enregistrées dans le cache, et non lorsque les données sont servies à
+ partir du cache. Il est recommandé d'harmoniser l'utilisation de cette
+ directive avec celle de la directive CacheReadSize, afin de s'assurer
+ que le serveur n'effectue pas une mise en tampon excessive au cas
+ où les données arriveraient plus vite que prévu.
CacheReadTime 1000+ + +
| Description: | La racine du répertoire dans lequel les fichiers du cache +seront stockés |
|---|---|
| Syntaxe: | CacheRoot répertoire |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache_disk |
La directive CacheRoot permet de définir
+ le nom du répertoire sur disque qui contiendra les fichiers du
+ cache. Si le module mod_cache_disk a été chargé ou
+ compilé dans le serveur Apache, cette directive doit être
+ définie. L'absence de définition de la directive
+ CacheRoot provoquera une erreur de traitement
+ du fichier de configuration. Les directives CacheDirLevels et CacheDirLength permettent de
+ définir la structure des sous-répertoires du répertoire racine
+ spécifié.
CacheRoot c:/cacheroot+ + +
Serveur HTTP Apache Version 2.4
+| Description: | Module de stockage à base de cache d'objets partagés +(socache) pour le filtre de mise en cache HTTP. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | cache_socache_module |
| Fichier Source: | mod_cache_socache.c |
Le module mod_cache_socache implémente un
+ gestionnaire de stockage à base de cache d'objets partagés (socache)
+ pour le module mod_cache.
Les en-têtes et corps des réponses mises en cache sont rassemblés + et stockés sous une même clé dans le cache d'objets partagés. Il est + possible de choisir entre plusieurs implémentations de caches d'objets + partagés.
+ +Des réponses avec différents contenus négociés peuvent être + stockées simultanément ; cependant, la mise en cache de contenus + partiels n'est pas encore supportée par ce module.
+ +# Activation de la mise en cache +CacheSocache shmcb +CacheSocacheMaxSize 102400 +<Location "/foo"> + CacheEnable socache +</Location> + +# Possibilité de se rabattre sur le cache disque +CacheSocache shmcb +CacheSocacheMaxSize 102400 +<Location "/foo"> + CacheEnable socache + CacheEnable disk +</Location>+ + +
Le module mod_cache_socache requiert les
+ services du module mod_cache qui doit donc avoir
+ été préalablement chargé.
CacheSocache CacheSocacheMaxSize CacheSocacheMaxTime CacheSocacheMinTime CacheSocacheReadSize CacheSocacheReadTime| Description: | Implémentation du cache d'objets partagés à utiliser |
|---|---|
| Syntaxe: | CacheSocache type[:args] |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_cache_socache |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP +Apache |
La directive CacheSocache
+ définit l'implémentation du cache d'objets partagés à utiliser,
+ suivie d'arguments optionnels. Il est
+ possible de choisir entre plusieurs implémentations de caches d'objets
+ partagés.
CacheSocache shmcb+ + +
| Description: | La taille maximale d'une entrée pouvant être placée dans le +cache |
|---|---|
| Syntaxe: | CacheSocacheMaxSize octets |
| Défaut: | CacheSocacheMaxSize 102400 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache_socache |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP +Apache |
La directive CacheSocacheMaxSize
+ définit la taille maximale, en octets, de la somme des en-têtes et
+ du corps d'un document pouvant être stocké dans le cache. Bien
+ entendu, plus la taille des en-têtes sera grande, plus la taille
+ maximale du corps du document s'en trouvera réduite.
Le module mod_cache_socache ne tentera de mettre
+ en cache que des réponses qui possèdent une taille de contenu
+ explicite, ou dont la taille est suffisamment petite pour qu'elles
+ soient écrites en une seule passe. Ceci permet au module
+ mod_cache_disk de mettre en cache des réponses dont
+ la taille est trop importante pour pouvoir être mises en cache par
+ mod_cache_socache.
CacheSocacheMaxSize 102400+ + +
| Description: | La durée maximale de stockage d'un document dans le cache +avant péremption |
|---|---|
| Syntaxe: | CacheSocacheMaxTime secondes |
| Défaut: | CacheSocacheMaxTime 86400 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache_socache |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP +Apache |
La directive CacheSocacheMaxTime
+ définit la durée de stockage maximale en secondes d'un document dans
+ le cache avant péremption. Cette définition l'emporte sur la durée
+ de fraîcheur définie pour le document par le protocole HTTP.
CacheSocacheMaxTime 86400+ + +
| Description: | La durée minimale de stockage d'un document dans le cache |
|---|---|
| Syntaxe: | CacheSocacheMinTime seconds |
| Défaut: | CacheSocacheMinTime 600 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache_socache |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP +Apache |
La directive CacheSocacheMinTime
+ définit le nombre de secondes au delà de la durée de fraîcheur de la
+ réponse pendant lesquelles cette dernière devra être stockée dans le
+ cache d'objets partagés. En effet, si une réponse n'est stockée que
+ pour une durée égale à sa durée de fraîcheur, elle n'a pas besoin
+ d'être rafraîchie.
CacheSocacheMinTime 600+ + +
| Description: | La quantité minimale de données du document à lire et +mettre en cache avant envoi au client |
|---|---|
| Syntaxe: | CacheSocacheReadSize octets |
| Défaut: | CacheSocacheReadSize 0 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache_socache |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP +Apache |
La directive CacheSocacheReadSize
+ définit la quantité minimale de données, en octets, à lire depuis
+ l'arrière-plan avant envoi au client. Avec la valeur par défaut 0,
+ les données sont transmises au client dès leur arrivée et quelle que
+ soit leur taille. Si la valeur définie est non nulle, le cache
+ disque va mettre en tampon au moins la quantité de données
+ correspondante avant envoi au client. Ceci peut améliorer les
+ performances en cas de mise en cache de contenu en provenance d'un
+ mandataire inverse lent.
Cette directive n'a d'effet qu'au moment où les données sont + stockées dans le cache, et non lorsqu'elles sont servies depuis le + cache.
+ +CacheSocacheReadSize 102400+ + +
| Description: | La durée minimale de lecture avant l'envoi des données |
|---|---|
| Syntaxe: | CacheSocacheReadTime millisecondes |
| Défaut: | CacheSocacheReadTime 0 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_cache_socache |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP +Apache |
La directive CacheSocacheReadTime
+ définit le temps minimal qui doit s'écouler avant de tenter
+ l'envoi des données au client. Cette durée sera mise à profit pour
+ lire et mettre en tampon les données avant leur envoi au client.
+ Ceci peut améliorer les performances en cas de mise en cache de
+ contenu en provenance d'un mandataire inverse.
La valeur par défaut 0 désactive cette directive.
+ +Cette directive n'a d'effet qu'au moment où les données sont
+ stockées dans le cache, et non lorsqu'elles sont servies depuis le
+ cache. Il est recommandé d'utiliser cette directive en concomitance
+ avec la directive CacheSocacheReadSize afin de
+ s'assurer que le serveur ne mette pas les données en tampon de
+ manière excessive dans le cas où les données arriveraient plus vite
+ que prévu.
CacheSocacheReadTime 1000+ + +
Serveur HTTP Apache Version 2.4
+| Description: | La sémantique des métafichiers du serveur httpd du +CERN |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | cern_meta_module |
| Fichier Source: | mod_cern_meta.c |
Il s'agit d'une émulation de la sémantique des métafichiers du + serveur httpd du CERN. Les métafichiers consistent en en-têtes HTTP + qui peuvent s'ajouter au jeu d'en-têtes habituels pour chaque + fichier accédé. Ils ressemblent beaucoup aux fichiers .asis + d'Apache, et permettent d'influencer de manière rudimentaire + l'en-tête Expires:, ainsi que d'autres curiosités. Il existe de + nombreuses méthodes pour gérer les métainformations, mais le choix + s'est porté sur celle-ci car il existe déjà un grand nombre + d'utilisateurs du CERN qui peuvent exploiter ce module.
+ +Pour plus d'information, voir le document sur la sémantique des métafichiers du CERN.
+| Description: | Le nom du répertoire où trouver les fichiers de +métainformations dans le style du CERN |
|---|---|
| Syntaxe: | MetaDir répertoire |
| Défaut: | MetaDir .web |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Extension |
| Module: | mod_cern_meta |
Spécifie le nom du répertoire dans lequel Apache pourra trouver
+ les fichiers de métainformations. Ce répertoire est en général un
+ sous-répertoire 'caché' du répertoire qui contient le fichier à
+ accéder. Définissez cette directive à "." pour
+ rechercher les métafichiers dans le même répertoire que le fichier à
+ accéder :
MetaDir .+ + +
Ou, pour rechercher dans un sous-répertoire du répertoire + contenant le fichier à accéder :
+ +MetaDir .meta+ + +
| Description: | Active le traitement des métafichiers du CERN |
|---|---|
| Syntaxe: | MetaFiles on|off |
| Défaut: | MetaFiles off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Extension |
| Module: | mod_cern_meta |
Active ou désactive le traitement des métafichiers pour certains + répertoires.
+ +| Description: | Suffixe du fichier contenant les métainformations dans le +style du CERN |
|---|---|
| Syntaxe: | MetaSuffix suffixe |
| Défaut: | MetaSuffix .meta |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Extension |
| Module: | mod_cern_meta |
Spécifie le suffixe du fichier contenant les métainformations.
+ Par exemple, si on conserve les valeurs par défaut des deux
+ directives précédentes, une requête pour
+ DOCUMENT_ROOT/un-rep/index.html provoquera la recherche
+ du métafichier
+ DOCUMENT_ROOT/un-rep/.web/index.html.meta, et utilisera
+ son contenu pour générer les informations quant aux en-têtes MIME
+ additionnels.
MetaSuffix .meta+
Serveur HTTP Apache Version 2.4
+| Description: | Exécution des scripts CGI |
|---|---|
| Statut: | Base |
| Identificateur de Module: | cgi_module |
| Fichier Source: | mod_cgi.c |
Tout fichier pris en compte par le gestionnaire
+ cgi-script sera traité en tant que script CGI et
+ exécuté par le serveur, sa sortie étant renvoyée au client. Les
+ fichiers sont associés à ce gestionnaire soit parce qu'ils possèdent
+ un nom contenant une extension définie par la directive AddHandler, soit parce qu'ils se
+ situent dans un répertoire défini par une directive ScriptAlias.
Comme introduction à l'utilisation des scripts CGI avec Apache, + voir notre tutoriel Les contenus + dynamiques avec CGI.
+ +Il est recommandé d'utiliser le module mod_cgid
+ à la place de mod_cgi lorsqu'on utilise un module MPM
+ multi-threadé sous Unix. Vus de l'utilisateur, les deux modules
+ sont pratiquement identiques.
À des fins de compatibilité ascendante, le gestionnaire
+ cgi-script sera aussi activé pour tout fichier possédant le type
+ MIME application/x-httpd-cgi. L'utilisation du type
+ MIME magic est obsolète.
ScriptLog ScriptLogBuffer ScriptLogLengthLe serveur va définir les variables d'environnement CGI comme + décrit dans la Spécification CGI, de la + manière suivante :
+ +AcceptPathInfo est
+ explicitement définie à off. Par défaut, si la
+ directive AcceptPathInfo n'est pas définie,
+ mod_cgi acceptera des informations de chemin (en
+ ajoutant /infos/chemin après le nom du script dans l'URI), alors
+ que le serveur de base retournera une erreur 404 NOT FOUND pour
+ les requêtes contenant des informations de chemin supplémentaires.
+ Ne pas définir la directive AcceptPathInfo
+ a le même effet sur les requêtes avec mod_cgi que
+ de la définir à On.HostnameLookups est définie à
+ on (elle est à off par défaut), et si
+ une recherche DNS inverse sur l'adresse IP de l'hôte client
+ aboutit effectivement à un nom d'hôte.IdentityCheck
+ est définie à on, et si l'hôte client supporte le
+ protocole ident. Notez que l'on ne peut accorder une confiance
+ aveugle au contenu de cette variable car il peut être aisément
+ falsifié, et si un mandataire s'intercale entre le client et le
+ serveur, il est totalement inutilisable.Ce module utilise aussi les fonctions de base ap_add_common_vars + et ap_add_cgi_vars + pour ajouter des variables d'environnement comme :
+DocumentRoot.ServerAdmin.Pour une liste exhaustive de ces variables, vous pouvez écrire un script + CGI basique qui extrait toutes les variables d'environnement passées par + Apache selon un format adapté. +
+Le débogage des scripts CGI était difficile par le passé, + principalement parce qu'il n'était pas possible d'étudier la sortie + (sortie standard et erreurs) des scripts dont l'exécution échouait. + Les directives qui suivent permettent une journalisation plus détaillée des + erreurs.
+ +Lorsqu'il est configuré, le journal des erreurs CGI enregistre + la sortie de tout programme CGI dont l'exécution ne s'effectue pas + correctement. Un script CGI dont l'exécution échoue provoque la + journalisation d'une grande quantité d'informations. Les deux + premières lignes possèdent toujours le format suivant :
+ +
+ %% [date] requête
+ %% état HTTP nom du script CGI
+
Si le script CGI n'a pas pu démarrer, le fichier journal + contiendra les deux lignes supplémentaires suivantes :
+ +
+ %%erreur
+ message d'erreur
+
Par contre, si l'erreur provient du renvoi par le script + d'informations incorrectes dans les en-têtes (dû souvent à une + bogue du script), les informations suivantes sont journalisées + :
+ +
+ %requête
+ Tous les en-têtes de requête HTTP reçus
+ Les entités POST ou PUT (s'il en existe)
+ %réponse
+ Tous les en-têtes générés par le script CGI
+ %stdout
+ la sortie standard CGI
+ %stderr
+ la sortie d'erreurs standard CGI
+
(Les parties %stdout et %stderr seront absentes si le script + n'a rien envoyé sur la sortie standard ou la sortie + d'erreurs).
+ +| Description: | Chemin du fichier journal des erreurs du script +CGI |
|---|---|
| Syntaxe: | ScriptLog chemin fichier |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_cgi, mod_cgid |
La directive ScriptLog permet de définir
+ le chemin du fichier journal des erreurs du script CGI. Si cette
+ directive n'est pas définie, aucune journalisation des erreurs n'est
+ effectuée. Si elle est définie, toute erreur CGI sera enregistrée
+ dans le fichier dont le nom est fourni en argument. S'il s'agit d'un
+ chemin de fichier relatif, il est considéré par rapport au
+ répertoire défini par la directive ServerRoot.
+
ScriptLog logs/cgi_log+
Ce journal sera ouvert par l'utilisateur sous lequel les
+ processus enfants s'exécutent, c'est à dire l'utilisateur spécifié
+ par la directive du serveur User. Ceci implique que le
+ répertoire dans lequel se trouve le journal doit être accessible en
+ écriture pour cet utilisateur, ou bien que le fichier est créé
+ manuellement et accessible en écriture pour cet utilisateur. Si vous
+ placez le journal du script dans votre répertoire principal des
+ journaux, ne modifiez JAMAIS les permissions de ce
+ dernier afin de le le rendre accessible en écriture par
+ l'utilisateur sous lequel les processus enfants s'exécutent.
Notez que l'on ne doit activer la journalisation des scripts + qu'à des fins de débogage lors de l'écriture de scripts CGI, et non + de manière permanente sur un serveur en production. Elle n'est pas + optimisée en terme de performances et d'efficacité, et peut + présenter des problèmes de sécurité si on l'utilise dans un cadre + autre que celui pour lequel elle a été conçue.
+ +| Description: | Taille maximale des requêtes PUT ou POST qui seront +enregistrées dans le journal du script |
|---|---|
| Syntaxe: | ScriptLogBuffer octets |
| Défaut: | ScriptLogBuffer 1024 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_cgi, mod_cgid |
Cette directive permet de limiter la taille du corps de toute + entité PUT ou POST qui sera enregistrée dans le journal, afin + de prévenir une croissance trop importante et trop rapide du fichier + journal due à la réception de corps de requête de grandes tailles. + Cette directive permet de modifier cette taille maximale, dont la + valeur par défaut est de 1024 octets.
+ +| Description: | Taille maximale du fichier journal des scripts +CGI |
|---|---|
| Syntaxe: | ScriptLogLength octets |
| Défaut: | ScriptLogLength 10385760 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_cgi, mod_cgid |
La directive ScriptLogLength permet de
+ définir la taille maximale du fichier journal des scripts CGI. Comme
+ le fichier journal accumule une grande quantité d'informations par
+ erreur CGI (tous les en-têtes de la requête, toutes les sorties du
+ script), il peut vite atteindre une grande taille. En limitant la
+ taille du fichier, cette directive permet d'éviter les problèmes que
+ causerait sa croissance sans limites. Lorsque le fichier a atteint
+ cette taille maximale, plus aucune information n'y est
+ enregistrée.
Serveur HTTP Apache Version 2.4
+| Description: | Exécution des scripts CGI par l'intermédiaire d'un démon +CGI externe |
|---|---|
| Statut: | Base |
| Identificateur de Module: | cgid_module |
| Fichier Source: | mod_cgid.c |
| Compatibilité: | Uniquement compatible avec les MPMs Unix +threadés |
Exceptées les optimisations et la directive additionnelle
+ ScriptSock décrite
+ ci-dessous, mod_cgid a un comportement similaire à
+ celui de mod_cgi. Voir le résumé de
+ mod_cgi pour plus de détails à propos d'Apache et
+ CGI.
Sur certains systèmes d'exploitation de type unix, le lancement
+ (forking) d'un processus depuis un serveur multi-threadé est une
+ opération très lourde car le nouveau processus va répliquer tous les
+ threads du processus parent. Pour éviter cette dépense de ressouces
+ pour chaque invocation d'un programme CGI, mod_cgid
+ crée un démon externe qui est responsable du branchement de
+ processus enfants destinés au lancement de scripts CGI. Le serveur
+ principal communique avec ce démon par l'intermédiaire d'une socket
+ de domaine unix.
Si un MPM multi-threadé a été sélectionné lors du processus de
+ compilation, c'est ce module qui est utilisé par défaut à la place
+ de mod_cgi. Du point de vue de l'utilisateur, ce
+ module est identique à mod_cgi quant à sa
+ configuration et son utilisation. La seule différence est la
+ directive additionnelle ScriptSock qui permet de
+ définir le nom du socket à utiliser pour la communication avec le
+ démon CGI.
| Description: | Durée maximale d'attente de la prochaine sortie du +programme CGI |
|---|---|
| Syntaxe: | CGIDScriptTimeout time[s|ms] |
| Défaut: | Valeur de la directive |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Base |
| Module: | mod_cgid |
| Compatibilité: | La valeur de CGIDScriptTimeout est 0 dans les versions +2.4 et antérieures + |
Cette directive permet de limiter la durée d'attente avant les prochaines données + reçues en sortie du programme CGI. Si ce temps est dépassé, la requête et le + programme CGI se terminent.
+ +CGIDScriptTimeout 20+
| Description: | Le préfixe du nom de fichier du socket à utiliser pour +communiquer avec le démon CGI |
|---|---|
| Syntaxe: | ScriptSock chemin fichier |
| Défaut: | ScriptSock cgisock |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_cgid |
Cette directive permet de définir le préfixe du nom de fichier de la + socket à utiliser pour communiquer avec le démon CGI, préfixe auquel + sera ajouté une extension correspondant à l'identifiant processus du + serveur. La socket sera ouverte avec les permissions de l'utilisateur + qui a démarré Apache (en général root). Afin de préserver la + sécurité des communications avec les scripts CGI, il est impératif + de n'accorder à aucun autre utilisateur la permission d'écrire dans + le répertoire où se trouve la socket.
+ +Si chemin fichier n'est pas un chemin absolu, il est
+ relatif au chemin défini par la directive DefaultRuntimeDir.
ScriptSock /var/run/cgid.sock+
Serveur HTTP Apache Version 2.4
+| Description: | Spécifie dans quel jeu de caractère doivent s'effectuer les +traductions ou les réencodages |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | charset_lite_module |
| Fichier Source: | mod_charset_lite.c |
Le module mod_charset_lite permet au serveur de
+ modifier le jeu de caractères des réponses avant de les envoyer aux
+ clients. Dans un environnement EBCDIC, Apache traduit toujours les
+ contenus au protocole HTTP (par exemples les en-têtes de réponses)
+ de la page de code de la locale du processus Apache vers ISO-8859-1,
+ mais pas le corps des réponses. Dans tous les environnements, on
+ peut utiliser mod_charset_lite pour spécifier que
+ les corps des réponses doivent être traduits. Par exemple, si les
+ fichiers sont stockés sous forme EBCDIC,
+ mod_charset_lite pourra les traduire en ISO-8859-1
+ avant de les envoyer au client.
Ce module fournit quelques procédés de configuration implémentés
+ par Apache version russe, ainsi que son module
+ mod_charset associé.
Les noms des jeux de caractères passés en paramètres aux
+ directives CharsetSourceEnc et
+ CharsetDefault
+ doivent être reconnus par le mécanisme de traduction utilisé par
+ APR sur le système où
+ mod_charset_lite est utilisé. Ces noms de jeux de
+ caractères ne sont pas standardisés, et sont en général différents
+ des valeurs qui leur correspondent dans les en-têtes HTTP.
+ Actuellement, APR ne peut utiliser que iconv(3) ; vous pouvez donc
+ tester facilement vos noms de jeux de caractères en utilisant le
+ programme iconv(1), de la manière suivante :
+ iconv -f valeur-charsetsourceenc -t valeur-charsetdefault
+
Si les règles de traduction ne peuvent s'appliquer au contenu, + la traduction peut échouer avec des conséquences diverses, comme + :
+ +| Description: | Jeu de caractère vers lequel la traduction doit +s'effectuer |
|---|---|
| Syntaxe: | CharsetDefault jeu de caractères |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_charset_lite |
La directive CharsetDefault permet de
+ spécifier le jeu de caractères vers lequel le contenu situé dans le
+ conteneur associé devra être traduit.
La valeur de l'argument jeu de caractères doit être + un nom de jeu de caractères valide du point de vue du support des + jeux de caractères dans APR. En général, cela + implique qu'elle doit être reconnue par iconv.
+ +<Directory "/export/home/trawick/apacheinst/htdocs/convert"> + CharsetSourceEnc UTF-16BE + CharsetDefault ISO-8859-1 +</Directory>+
CharsetSourceEnc
+ et CharsetDefault
+ désactive la traduction. Le jeu de caractères ne doit pas forcément
+ correspondre au jeu de caractères de la réponse, mais il doit être
+ valide du point de vue du système.
+ | Description: | Précise les détails de la traduction du jeu de +caractères |
|---|---|
| Syntaxe: | CharsetOptions option [option] ... |
| Défaut: | CharsetOptions ImplicitAdd |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_charset_lite |
La directive CharsetOptions permet de
+ préciser certains détails du comportement du module
+ mod_charset_lite. Option accepte les
+ valeurs suivantes :
ImplicitAdd | NoImplicitAddImplicitAdd indique que
+ mod_charset_lite doit insérer son filtre de
+ manière implicite lorsque la configuration indique que le jeu de
+ caractère du contenu doit être traduit. Si la chaîne de filtrage
+ est configurée de manière explicite via la directive AddOutputFilter, l'option
+ NoImplicitAdd doit être utilisée afin que
+ mod_charset_lite n'ajoute pas son propre
+ filtre.TranslateAllMimeTypes | NoTranslateAllMimeTypesmod_charset_lite n'effectuera
+ une traduction qu'en présence d'un petit nombre de types MIME
+ parmi tous les types possibles. Lorsque l'option
+ TranslateAllMimeTypes est utilisée pour une section
+ de configuration donnée, la traduction est effectuée sans se
+ préoccuper du type MIME.| Description: | Jeu de caractères source des fichiers |
|---|---|
| Syntaxe: | CharsetSourceEnc jeu de caractères |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_charset_lite |
La directive CharsetSourceEnc permet de
+ spécifier un jeu de caractères source pour les fichiers situés dans
+ le conteneur associé.
La valeur de l'argument jeu de caractères doit être + un nom de jeu de caractères valide du point de vue du support des + jeux de caractères dans APR. En général, cela + implique qu'elle doit être reconnue par iconv.
+ +<Directory "/export/home/trawick/apacheinst/htdocs/convert"> + CharsetSourceEnc UTF-16BE + CharsetDefault ISO-8859-1 +</Directory>+
Les noms de jeux de caractères de cet exemple sont reconnus par + le mécanisme de traduction d'iconv sous Solaris 8.
+ +CharsetSourceEnc
+ et CharsetDefault
+ désactive la traduction. Le jeu de caractères ne doit pas forcément
+ correspondre au jeu de caractères de la réponse, mais il doit être
+ valide du point de vue du système.
+ Serveur HTTP Apache Version 2.4
+| Description: | Convertit un corps de réponse en URL de type données RFC2397 |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | data_module |
| Fichier Source: | mod_data.c |
| Compatibilité: | Disponible depuis la version 2.3 du serveur HTTP Apache |
Ce module permet de convertir une réponse en URL de type données + RFC2397. +
+ +Les URLs de type données peuvent être incluses en ligne dans les
+ pages web via le module mod_include par exemple,
+ afin d'éviter aux clients d'avoir à effectuer des connexions
+ séparées pour éventuellement extraire un grand nombre de petites
+ images. Les URLs de type données peuvent aussi être incluses dans
+ des pages générées par langages de scripting tels que PHP.
+ data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw
+ AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz
+ ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp
+ a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl
+ ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis
+ F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH
+ hhx4dbgYKAAA7
+
Le filtre n'accepte aucun paramètre, et peut être ajouté à la
+ pile des filtres via la directive SetOutputFilter, ou toute autre directive
+ supportée par le module mod_filter.
<Location "/data/images"> + SetOutputFilter DATA +</Location>+
Ce module ne fournit aucune directive.
+Serveur HTTP Apache Version 2.4
+| Description: | Fonctionnalité de création et gestion de versions de +documents via le web (WebDAV) |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | dav_module |
| Fichier Source: | mod_dav.c |
Ce module ajoute à Apache une fonctionnalité WebDAV de classes 1 et 2 + ('Web-based Distributed Authoring and Versioning' ou Création et + gestion de versions de documents via le web). Il s'agit d'une + extension du protocole HTTP qui permet de créer, déplacer, copier et + supprimer des ressources ou collections de ressources sur un serveur + web distant.
+Pour activer le module mod_dav, ajoutez la ligne
+ suivante à un conteneur de votre fichier httpd.conf
+ :
Dav On+ + +
Ceci active le fournisseur de système de fichier DAV implémenté par
+ le module mod_dav_fs. Ce dernier doit donc être
+ compilé dans le serveur ou chargé au démarrage à l'aide de la
+ directive LoadModule.
En outre, vous devez indiquer où se trouve la base de données des
+ verrous DAV via une directive DavLockDB dans la section globale de
+ votre fichier httpd.conf :
DavLockDB /usr/local/apache2/var/DavLock+ + +
Le répertoire contenant le fichier de la base de données des
+ verrous doit avoir des droits en écriture pour l'utilisateur et le
+ groupe sous lesquels Apache s'exécute et définis respectivement par
+ les directives User et
+ Group.
Si vous souhaitez limiter l'accès aux répertoires où DAV est
+ activé, vous pouvez ajouter une clause <Limit> dans la section <Location> considérée. Pour
+ définir la quantité maximale de données en octets qu'un client
+ DAV peut envoyer par requête, vous devez utiliser la directive
+ LimitXMLRequestBody, car La
+ directive LimitRequestBody
+ "habituelle" n'a aucune incidence sur les requêtes DAV.
DavLockDB "/usr/local/apache2/var/DavLock" + +<Directory "/usr/local/apache2/htdocs/foo"> + Require all granted + Dav On + + AuthType Basic + AuthName DAV + AuthUserFile "user.passwd" + + <LimitExcept GET POST OPTIONS> + Require user admin + </LimitExcept> +</Directory>+
Etant donné que les méthodes d'accès DAV permettent à des clients
+ distants de manipuler des fichiers sur le serveur, vous devez vous
+ assurer que votre serveur est bien sécurisé avant d'activer
+ mod_dav.
Tout répertoire du serveur où DAV est activé doit être protégé
+ par une procédure d'authentification. L'utilisation de
+ l'authentification HTTP de base n'est pas recommandée. Vous devez
+ utiliser au moins l'authentification HTTP à base de condensés
+ qu'implémente le module mod_auth_digest.
+ Pratiquement tous les clients WebDAV supportent cette méthode
+ d'authentification. Vous pouvez aussi utiliser l'authentification de
+ base sur une connexion où SSL est activé.
Pour que mod_dav puisse manipuler des fichiers,
+ il doit avoir des permissions en écriture sur les répertoires et les
+ fichiers qui sont sous son contrôle ; en d'autre termes, c'est
+ l'utilisateur et le groupe sous lesquels Apache s'exécute et définis
+ par les directives User et
+ Group qui doivent avoir
+ les droits en écriture sur ces fichiers et répertoires. Les fichiers
+ nouvellement créés appartiendront aussi à ces utilisateur et groupe.
+ Par conséquent, il est important de contrôler l'accès à ce compte.
+ Les répertoires DAV sont considérés comme privés du point de vue
+ d'Apache, et la modification des fichiers qu'ils contiennent
+ autrement que par l'intermédiaire d'Apache (par exemple par FTP ou
+ par des outils du niveau du système de fichiers) ne doit pas être
+ permise.
mod_dav peut faire l'objet de plusieurs sortes
+ d'attaques par déni de service. La directive LimitXMLRequestBody permet de limiter la
+ quantité de mémoire consommée pour interpréter des requêtes DAV de
+ grande taille. En outre, la directive DavDepthInfinity permet d'empêcher les
+ requêtes PROPFIND concernant un répertoire de très
+ grande taille de consommer de grandes quantités de mémoire. Un autre
+ type d'attaque par déni de service peut aussi être mené par un
+ client qui remplit simplement tout l'espace disque disponible avec
+ des fichiers de très grande taille. Etant donné qu'il n'existe aucun
+ moyen direct d'éviter ce genre d'attaque dans Apache, vous ne devez
+ accorder des accès DAV qu'à des utilisateurs de confiance.
Les requêtes ayant pour but de manipuler des fichiers dynamiques
+ (scripts PHP, scripts CGI, etc...) en utilisant
+ mod_dav sont courantes. Ce traitement n'est pas
+ évident car une requête
+ GET va toujours tenter d'exécuter le script, plutôt que
+ de télécharger son contenu. Pour éviter cet inconvénient, une
+ méthode possible consiste à faire correspondre deux URLs
+ différentes au même contenu, l'une d'entre elles servant à lancer le
+ script, alors que l'autre peut être utilisée pour le télécharger et
+ le manipuler avec DAV.
Alias "/phparea" "/home/gstein/php_files" +Alias "/php-source" "/home/gstein/php_files" +<Location "/php-source"> +Dav On +ForceType text/plain +</Location>+ + +
Avec cette configuration, on peut utiliser
+ http://example.com/phparea pour afficher le résultat de
+ l'exécution des scripts PHP, et
+ http://example.com/php-source pour les manipuler avec
+ DAV.
| Description: | Active les méthodes HTTP WebDAV |
|---|---|
| Syntaxe: | Dav On|Off|nom fournisseur |
| Défaut: | Dav Off |
| Contexte: | répertoire |
| Statut: | Extension |
| Module: | mod_dav |
La directive Dav permet d'activer les
+ méthodes HTTP WebDAV pour le conteneur condidéré :
<Location "/foo"> + Dav On +</Location>+ + +
La valeur On est en fait un alias vers le
+ fournisseur par défaut filesystem implémenté par le
+ module mod_dav_fs. Notez que lorsque DAV est activé
+ pour un conteneur, on ne peut pas le désactiver pour ses
+ sous-conteneurs. Pour un exemple de configuration complet,
+ reportez-vous à la section précédente.
| Description: | Autorise les requêtes PROPFIND avec en-tête Depth: +Infinity |
|---|---|
| Syntaxe: | DavDepthInfinity on|off |
| Défaut: | DavDepthInfinity off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_dav |
La directive DavDepthInfinity permet
+ d'autoriser le traitement des requêtes PROPFIND
+ contenant l'en-tête Depth: Infinity. Par défaut, ce type de requête
+ n'est pas autorisé, car il peut favoriser les attaques de type Déni
+ de service.
| Description: | Durée minimale pendant laquelle le serveur maintient un +verrou sur une ressource DAV |
|---|---|
| Syntaxe: | DavMinTimeout secondes |
| Défaut: | DavMinTimeout 0 |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_dav |
Lorsqu'un client demande le verrouillage d'une ressource DAV, il + peut aussi spécifier une durée au bout de laquelle le verrou sera + automatiquement supprimé par le serveur. Cette valeur ne constitue + qu'une demande, et le serveur peut l'ignorer ou informer le client + qu'il va utiliser une valeur arbitraire.
+ +La directive DavMinTimeout permet de
+ spécifier, en secondes, la durée minimale de verrouillage à renvoyer
+ au client. Les Répertoires Web de Microsoft présentent une durée par
+ défaut de 120 secondes ; la directive
+ DavMinTimeout permet de définir une valeur
+ supérieure (par exemple 600 secondes), afin de réduire les risques
+ de perte du verrou par le client suite à une surcharge du
+ réseau.
<Location "/MSWord"> + DavMinTimeout 600 +</Location>+
Serveur HTTP Apache Version 2.4
+| Description: | Implémente le fournisseur filesystem pour
+mod_dav |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | dav_fs_module |
| Fichier Source: | mod_dav_fs.c |
L'activation de ce module nécessite l'utilisation de
+ mod_dav. C'est un module de support pour mod_dav et à ce titre, il permet l'accès à des ressources
+ situées dans le système de fichiers du serveur. Le nom formel de ce
+ fournisseur est filesystem. Les fournisseurs supports
+ de mod_dav sont invoqués via la directive
+ Dav :
Dav filesystem+
Comme filesystem est le fournisseur par défaut de
+ mod_dav, vous pouvez vous contenter d'utiliser la
+ valeur On comme argument de Dav.
| Description: | Chemin de la base de données des verrous DAV |
|---|---|
| Syntaxe: | DavLockDB chemin fichier |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_dav_fs |
La directive DavLockDB permet de spécifier
+ le chemin complet de la base de données des verrous, sans extension.
+ Si le chemin n'est pas absolu, il sera considéré comme relatif au
+ répertoire défini par la directive ServerRoot. L'implémentation de
+ mod_dav_fs utilise une base de données SDBM pour
+ surveiller les verrous utilisateurs.
DavLockDB "var/DavLock"+
Les utilisateur et groupe sous lesquels Apache s'exécute et qui
+ sont respectivement définis par les directives User et Group doivent pouvoir écrire dans le
+ répertoire qui contient le fichier de la base de données des
+ verrous. Pour des raisons de sécurité, il est recommandé de créer un
+ répertoire dédié à la base de données des verrous, plutôt que de
+ modifier les permissions d'un répertoire existant. Dans l'exemple
+ ci-dessus, Apache va créer des fichiers dans le répertoire
+ var/, lui-même sous-répertoire du répertoire défini par
+ la directive ServerRoot, avec le nom de base
+ DavLock suivi d'une extension choisie par le
+ serveur.
Serveur HTTP Apache Version 2.4
+| Description: | Module de verrouillage générique pour
+mod_dav |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | dav_lock_module |
| Fichier Source: | mod_dav_lock.c |
| Compatibilité: | Disponible depuis la version 2.1 d'Apache |
ce module implémente une API de verrouillage générique que tout
+ fournisseur support de mod_dav peut utiliser. Son
+ activation nécessite l'utilisation de mod_dav. Mais
+ sans fournisseur support pour l'utiliser, il n'est d'aucun service
+ et ne doit pas être chargé dans le serveur. mod_dav_svn, le module qui
+ implémente le fournisseur subversion, est un exemple
+ de module de support qui utilise effectivement
+ mod_dav_lock.
Notez que mod_dav_fs n'a pas besoin de
+ ce module de verrouillage générique, car il utilise sa propre
+ version plus spécifique.
Pour que mod_dav_lock puisse fonctionner, il
+ vous suffit de spécifier le chemin de la base de données des verrous
+ à l'aide de la directive DavGenericLockDB décrite
+ ci-dessous.
Pour déterminer le pointeur de la fonction du fournisseur de
+ verrouillage, vous devez utiliser l'API
+ ap_lookup_provider avec les arguments
+ dav-lock, generic et 0.
| Description: | Chemin de la base de données des verrous DAV |
|---|---|
| Syntaxe: | DavGenericLockDB chemin fichier |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_dav_lock |
La directive DavLockDB permet de spécifier
+ le chemin complet de la base de données des verrous, sans extension.
+ Si le chemin n'est pas absolu, il sera considéré comme relatif au
+ répertoire défini par la directive ServerRoot. L'implémentation de
+ mod_dav_lock utilise une base de données SDBM pour
+ surveiller les verrous utilisateurs.
DavGenericLockDB var/DavLock+
Les utilisateur et groupe sous lesquels Apache s'exécute et qui
+ sont respectivement définis par les directives User et Group doivent pouvoir écrire dans le
+ répertoire qui contient le fichier de la base de données des
+ verrous. Pour des raisons de sécurité, il est recommandé de créer un
+ répertoire dédié à la base de données des verrous, plutôt que de
+ modifier les permissions d'un répertoire existant. Dans l'exemple
+ ci-dessus, Apache va créer des fichiers dans le répertoire
+ var/, lui-même sous-répertoire du répertoire défini par
+ la directive ServerRoot, avec le nom de base
+ DavLock suivi d'une extension choisie par le
+ serveur.
Serveur HTTP Apache Version 2.4
+| Description: | Gestion des connexions à une base de données SQL |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | dbd_module |
| Fichier Source: | mod_dbd.c |
| Compatibilité: | Versions 2.1 and supérieures |
Le module mod_dbd gère les connexions
+ à une base de données SQL via APR. Il permet
+ aux modules qui requièrent des fonctions liées aux bases de données
+ SQL de se connecter à une base de données à la demande, et s'efforce
+ de conférer aux bases de données une efficacité et une
+ évolutivité optimales pour les MPMs threadés ou non threadés. Pour
+ plus de détails, voir le site web APR,
+ ainsi que cette vue d'ensemble de l'environnement de
+ développement d'Apache DBD par son développeur initial.
+
Regroupement des connexions Connexion API DBD d'Apache Requêtes SQL préparées AVERTISSEMENT DE SECURITE DBDExptime DBDInitSQL DBDKeep DBDMax DBDMin DBDParams DBDPersist DBDPrepareSQL DBDriverCe module gère de manière optimisée en fonction de la plate-forme
+ les connexions aux bases de données. Sur les plates-formes non
+ threadées, il maintient une connexion persistente à la manière d'un
+ LAMP classique (Linux, Apache, Mysql, Perl/PHP/Python). Sur les
+ plates-formes threadées, il maintient un groupe de
+ connexions à la fois plus évolutif et plus efficace, comme
+ décrit dans cet
+ article d'ApacheTutor. Notez que mod_dbd
+ remplace les modules présentés dans cet article.
Pour vous connecter à votre base de données, vous devez spécifier un + pilote et des paramètres de connexion qui diffèrent selon le moteur de base + de données. Par exemple, pour vous connecter à mysql, spécifiez ce qui suit + :
+ +DBDriver mysql +DBDParams host=localhost,dbname=pony,user=shetland,pass=appaloosa+ + +
Vous pourrez alors utiliser cette connexion dans de nombreux autres
+ modules comme mod_rewrite, mod_authn_dbd
+ et mod_lua. Vous trouverez des exemples d'utilisation dans
+ la documentation de ces modules.
Voir la syntaxe de la directive DBDParams pour les
+ informations à fournir dans la chaîne de connexion en fonction des
+ différents pilotes de base de données supportés.
mod_dbd exporte cinq fonctions que d'autres
+ modules pourront utiliser. L'API se présente comme suit :
typedef struct {
+ apr_dbd_t *handle;
+ apr_dbd_driver_t *driver;
+ apr_hash_t *prepared;
+} ap_dbd_t;
+
+/* Fonctions exportées pour accéder à la base de données */
+
+/* ouvre une connexion qui DOIT avoir été explicitement fermée.
+ * Renvoie NULL en cas d'erreur
+ */
+AP_DECLARE(ap_dbd_t*) ap_dbd_open(apr_pool_t*, server_rec*);
+
+/* ferme une connexion ouverte avec ap_dbd_open */
+AP_DECLARE(void) ap_dbd_close(server_rec*, ap_dbd_t*);
+
+/* acquiert une connexion qui aura la durée de vie de la requête et qui
+ * NE DOIT PAS avoir été explicitement fermée. Renvoie NULL en cas
+ * d'erreur. C'est la fonction recommandée pour la plupart des
+ * applications.
+ */
+AP_DECLARE(ap_dbd_t*) ap_dbd_acquire(request_rec*);
+
+/* acquiert une connexion qui aura la durée de vie d'une connexion et
+ * qui NE DOIT PAS avoir été explicitement fermée. Renvoie NULL en cas
+ * d'erreur.
+ */
+AP_DECLARE(ap_dbd_t*) ap_dbd_cacquire(conn_rec*);
+
+/* Prépare une requête qu'un module client pourra utiliser */
+AP_DECLARE(void) ap_dbd_prepare(server_rec*, const char*, const char*);
+
+/* Exporte aussi ces fonctions à titre optionnel mour les modules qui
+ * péfèreraient les utiliser */
+APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_open, (apr_pool_t*, server_rec*));
+APR_DECLARE_OPTIONAL_FN(void, ap_dbd_close, (server_rec*, ap_dbd_t*));
+APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_acquire, (request_rec*));
+APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_cacquire, (conn_rec*));
+APR_DECLARE_OPTIONAL_FN(void, ap_dbd_prepare, (server_rec*, const char*, const char*));
+
+mod_dbd supporte les requêtes SQL préparées à
+ destination des modules qui pourraient les utiliser. Chaque requête
+ préparée doit posséder un nom (étiquette), et est stockée dans un
+ condensé (hash) : les condensés sont du type
+ apr_dbd_prepared_t et s'utilisent dans toute requête
+ SQL ou commande select préparée par apr_dbd.
Il est du ressort des modules utilisateurs de dbd d'utiliser les
+ requêtes préparées et de préciser quelles requêtes doivent être
+ spécifiées dans httpd.conf, ou de fournir leurs propres directives
+ et d'utiliser ap_dbd_prepare.
reconnect à 0 dans la chaîne de connexion, afin
+ d'éviter des erreurs provoquées par un client MySQL qui se
+ reconnecterait sans réinitialiser correctement les requêtes
+ préparées. Si reconnect est défini à 1, toute
+ connexion défectueuse sera sensée être réparée, mais comme
+ mod_dbd n'en est pas informé, les requêtes préparées seront
+ invalidées.
+ Toute application web impliquant une base de données doit se + protéger elle-même contre les attaques de type injection SQL. Dans + la plupart des cas Apache DBD est sûr, car les applications + utilisent des requêtes préparées, et les entrées non sures ne seront + utilisées qu'à titre de données. Bien entendu, si vous l'utilisez + via un module tiers, vous devez être au fait des précautions à + prendre.
+Cependant, le pilote FreeTDS est non + sûr de par sa nature-même. Comme la bibliothèque + sous-jacente ne supporte pas les requêtes préparées, le pilote en + effectue une émulation, et les entrées non sûres sont fusionnées + avec la requête SQL.
+Il peut être sécurisé en décontaminant toutes les + entrées : un processus inspiré de la recherche de contaminations + (taint mode) de + Perl. Chaque entrée est comparée à une expression rationnelle, et + seules les entrées qui correspondent sont utilisées, en accord avec + le langage Perl :
+ $untrusted =~ /([a-z]+)/;
+ $trusted = $1;Pour utiliser ceci, les expressions rationnelles de + décontamination doivent être incluses dans les requêtes préparées. + L'expression rationnelle doit se situer immédiatement après le + caractère % dans la requête préparée, et doit être entourée + d'accolades {}. Par exemple, si votre application attend une entrée + alphanumérique, vous pouvez utiliser :
+
+ "SELECT foo FROM bar WHERE input = %s"
+
avec d'autres pilotes, et ne risquer au pire qu'une requête + échouée. Mais avec FreeTDS, vous devez utiliser :
+
+ "SELECT foo FROM bar WHERE input = %{([A-Za-z0-9]+)}s"
+
tout ce qui ne correspond pas à l'expression rationnelle est + alors rejeté, et la requête est maintenant sûre.
+Alternativement, vous pouvez utiliser le pilote ODBC tiers, qui + offre la sécurité des requêtes préparées authentiques.
+| Description: | Durée de vie des connexions inactives |
|---|---|
| Syntaxe: | DBDExptime durée en secondes |
| Défaut: | DBDExptime 300 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_dbd |
Cette directive permet de définir la durée de vie des connexions + inactives lorsque le nombre de connexions spécifié par la directive + DBDKeep a été dépassé (plates-formes threadées uniquement).
+ +| Description: | Exécute une instruction SQL après connexion à une base de +données |
|---|---|
| Syntaxe: | DBDInitSQL "instruction SQL" |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_dbd |
Les modules qui le souhaitent peuvent exécuter une ou plusieurs + instructions SQL après connexion à une base de données. Par exemple + initialiser certaines valeurs, ou ajouter une entrée dans le journal + lors d'une nouvelle connexion à la base de données.
+ +| Description: | Nombre maximum de connexions maintenues |
|---|---|
| Syntaxe: | DBDKeep nombre |
| Défaut: | DBDKeep 2 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_dbd |
Cette directive permet de définir le nombre maximum de connexions + à maintenir par processus, en dehors de celles servant à gérer les + pics de demandes (plates-formes threadées uniquement).
+ +| Description: | Nombre maximum de connexions |
|---|---|
| Syntaxe: | DBDMax nombre |
| Défaut: | DBDMax 10 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_dbd |
Cette directive permet de définir le nombre maximum effectif de + connexions par processus (plates-formes threadées uniquement).
+ +| Description: | Nombre minimum de connexions |
|---|---|
| Syntaxe: | DBDMin nombre |
| Défaut: | DBDMin 1 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_dbd |
Cette directive permet de définir le nombre minimum de connexions + par processus (plates-formes threadées uniquement).
+ +| Description: | Paramètres de la connexion à la base de +données |
|---|---|
| Syntaxe: | DBDParams
+param1=valeur1[,param2=valeur2] |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_dbd |
Cette directive permet de spécifier des paramètres selon les + besoins du pilote concerné. En général, les paramètres à passer + concernent tout ce qui n'a pas de valeur par défaut comme le nom + d'utilisateur, le mot de passe, le nom de la base de données, le nom + d'hôte et le numéro de port de la connexion.
+Les paramètres de la chaîne de connexion en fonction des + différents pilotes comprennent :
+PQconnectdbpartie1:partie2 est utilisé dans
+ sqlite_open(partie1, atoi(partie2), NULL)sqlite3_open| Description: | Utiliser ou non des connexions persistentes |
|---|---|
| Syntaxe: | DBDPersist On|Off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_dbd |
Si cette directive est définie à Off, les connexions persistentes + et les connexions groupées sont désactivées. À la demande d'un + client, une nouvelle connexion à la base de données est ouverte, et + fermée immédiatement à l'issue du traitement. Cette configuration ne + doit être utilisée qu'à des fins de débogage, ou sur des serveurs à + charge faible.
+ +Par défaut, les groupes de connexions persistentes sont activés + (ou une seule connexion persistente du style LAMP pour les serveurs + non threadés), et c'est la configuration qui devrait être utilisée + dans la plupart des cas sur un serveur en production.
+ +Avant la version 2.2.2, cette directive n'acceptait que les
+ valeurs 0 et 1 au lieu de Off
+ et On, respectivement.
| Description: | Définit une requête SQL préparée |
|---|---|
| Syntaxe: | DBDPrepareSQL "requête SQL" étiquette |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_dbd |
Pour les modules tels que les modules d'authentification, qui + utilisent de manière répétée la même requête SQL, on peut optimiser + les performances en préparant la requête une fois pour toutes au + démarrage, plutôt qu'à chaque utilisation. Cette directive permet de + préparer une requête SQL et de lui assigner une étiquette.
+ +| Description: | Spécifie un pilote SQL |
|---|---|
| Syntaxe: | DBDriver nom |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_dbd |
Cette directive permet de spécifier un pilote apr_dbd par son
+ nom. Le pilote doit être installé sur votre système (sur la plupart
+ des systèmes, il s'agit d'un objet partagé ou d'une dll). Par
+ exemple, DBDriver mysql va sélectionner le pilote MySQL
+ dans la bibliothèque apr_dbd_mysql.so.
Serveur HTTP Apache Version 2.4
+| Description: | Comprime le contenu avant de le servir au +client |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | deflate_module |
| Fichier Source: | mod_deflate.c |
Le module mod_deflate implémente le filtre de
+ sortie DEFLATE qui permet de comprimer la sortie de
+ votre serveur avant de l'envoyer au client sur le réseau.
Codages supportés Exemples de configurations Activation de la compression Prise en compte des serveurs mandataires Servir du contenu précompressé DeflateBufferSize DeflateCompressionLevel DeflateFilterNote DeflateInflateLimitRequestBody DeflateInflateRatioBurst DeflateInflateRatioLimit DeflateMemLevel DeflateWindowSizeLe seul codage supporté est gzip afin d'assurer une complète
+ compatibilité avec les anciens navigateurs. Le codage deflate
+ n'est donc pas supporté ; voir à ce sujet la documentation de zlib
+ pour une explication détaillée.
+
Certaines applications web sont vulnérables aux attaques + visant le vol d'information lorsqu'une connexion TLS transmet + des données compressées par deflate. Pour plus de détails, + étudiez les attaques de la famille "BREACH".
+Voici une configuration simple qui comprime les contenus à base + de texte courants.
+ +AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript+
Certaines applications web sont vulnérables aux attaques pour + vol d'information lorsque la connexion TLS transmet des données + compressées par deflate. Pour plus d'informations, voir en + détails la famille d'attaques de type "BREACH".
+La compression est implémentée par le filtre DEFLATE. La
+ directive suivante active la compression des documents dans le
+ conteneur où elle est placée :
SetOutputFilter DEFLATE +SetEnvIfNoCase Request_URI "\.(?:gif|jpe?g|png)$" no-gzip+ + +
Si vous voulez limiter la compression à certains types MIME
+ particuliers, vous pouvez utiliser la directive AddOutputFilterByType. Voici un exemple
+ où la compression n'est activée que pour les fichiers html de la
+ documentation d'Apache :
<Directory "/your-server-root/manual"> + AddOutputFilterByType DEFLATE text/html +</Directory>+ + +
DEFLATE est toujours inséré après les
+ filtres RESOURCE comme PHP ou SSI. Il n'affecte jamais les
+ sous-requêtes internes.
+ force-gzip, définie à
+ l'aide de la directive SetEnv, permet d'ignorer la
+ configuration de votre navigateur quant aux codages acceptés, et
+ d'envoyer sans condition une sortie comprimée.
+ Le module mod_deflate fournit aussi un filtre
+ permettant de décomprimer un corps de réponse comprimé par gzip.
+ Pour activer cette fonctionnalité, vous devez insérer le filtre
+ INFLATE dans la chaîne de filtrage en sortie via la
+ directive SetOutputFilter ou
+ AddOutputFilter, comme
+ dans l'exemple suivant :
<Location "/dav-area"> + ProxyPass "http://example.com/" + SetOutputFilter INFLATE +</Location>+ + +
Dans cet exemple, les sorties comprimées par gzip en + provenance de example.com seront décomprimées afin de pouvoir + être éventuellement traitées par d'autres filtres. +
+ + +Le module mod_deflate fournit également un filtre
+ permettant de décomprimer un corps de requête comprimé par gzip.
+ Pour activer cette fonctionnalité, vous devez insérer le filtre
+ DEFLATE dans la chaîne de filtrage en entrée via la
+ directive SetInputFilter ou
+ AddInputFilter, comme
+ dans l'exemple suivant :
<Location "/dav-area"> + SetInputFilter DEFLATE +</Location>+ + +
Désormais, si une requête contient un en-tête
+ Content-Encoding: gzip, son corps sera
+ automatiquement décomprimé. Peu de navigateurs sont actuellement
+ en mesure de comprimer les corps de requêtes. Cependant,
+ certaines applications spécialisées supportent les requêtes
+ comprimées, comme par exemple certains clients WebDAV.
Content-LengthSi vous évaluez vous-même la taille du corps de requête,
+ ne faites pas confiance à l'en-tête
+ Content-Length! L'en-tête
+ Content-Length indique la longueur des données en provenance du
+ client, et non la quantité d'octets que représente le
+ flux de données décompressé.
Le module mod_deflate envoie un en-tête de
+ réponse HTTP Vary: Accept-Encoding pour avertir les
+ mandataires qu'une réponse enregistrée dans le cache ne doit être
+ envoyée qu'aux clients qui ont envoyé l'en-tête de requête
+ Accept-Encoding approprié. Ceci permet d'éviter l'envoi
+ d'un contenu comprimé à un client qui ne sera pas en mesure
+ de l'interpréter.
Si vous avez défini des exclusions spécifiques dépendant, par
+ exemple, de l'en-tête User-Agent, vous devez
+ ajouter manuellement des données à l'en-tête Vary afin
+ d'informer les mandataires des restrictions supplémentaires. Par
+ exemple, dans la configuration classique où l'addition du filtre
+ DEFLATE dépend du contenu de l'en-tête
+ User-Agent, vous devez spécifier :
Header append Vary User-Agent+ + +
Si votre décision de comprimer le contenu dépend d'autres
+ informations que celles contenues dans les en-têtes de la requête
+ (par exemple la version HTTP), vous devez attribuer à l'en-tête
+ Vary la valeur *, ce qui permet d'empêcher
+ les mandataires compatibles de tout mettre en cache.
Header set Vary *+
Comme mod_deflate recompresse le contenu demandé à
+ chaque requête, il est possible de gagner en performances en
+ précompressant ce contenu, et en forçant mod_deflate à servir ce
+ contenu précompressé sans avoir à le recompresser à chaque requête.
+ Pour ce faire, utilisez une configuration du style :
<IfModule mod_headers.c>
+ # Servir des fichiers CSS compressés avec gzip, s'ils existent, et
+ # si le client accepte gzip.
+ RewriteCond "%{HTTP:Accept-encoding}" "gzip"
+ RewriteCond "%{REQUEST_FILENAME}\.gz" "-s"
+ RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]
+
+ # Servir des fichiers JS compressés avec gzip, s'ils existent, et
+ # si le client accepte gzip.
+ RewriteCond "%{HTTP:Accept-encoding}" "gzip"
+ RewriteCond "%{REQUEST_FILENAME}\.gz" "-s"
+ RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]
+
+
+ # Servir des types de contenus corrects, et empêcher mod_deflate
+ # d'effectuer un double gzip.
+ RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
+ RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]
+
+
+ <FilesMatch "(\.js\.gz|\.css\.gz)$">
+ # Servir le type de codage correct.
+ Header append Content-Encoding gzip
+
+ # Force les mandataires à mettre en cache séparément les fichiers
+ # css/js gzippés & non gzippés.
+ Header append Vary Accept-Encoding
+ </FilesMatch>
+</IfModule>
+
+
+| Description: | Taille du fragment que zlib devra comprimer en une seule +fois |
|---|---|
| Syntaxe: | DeflateBufferSize valeur |
| Défaut: | DeflateBufferSize 8096 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_deflate |
La directive DeflateBufferSize permet de
+ spécifier la taille en octets du fragment que zlib devra comprimer
+ en une seule fois. Si la taille de la réponse compressée est supérieure à
+ celle spécifiée par cette directive, httpd passera à un mode d'encodage
+ fragmenté (l'en-tête HTTP Transfer-Encoding prend la valeur
+ Chunked), ceci ayant comme effet de bord de ne définir aucun
+ en-tête HTTP Content-Length. Il est important de connaître ce
+ comportement, particulièrement lorsque httpd travaille derrière des
+ mandataires inverses avec mise en cache, ou lorsque httpd est configuré pour
+ utiliser mod_cache et mod_cache_disk car
+ les réponses HTTP sans en-tête Content-Length peuvent ne pas
+ être mises en cache.
| Description: | Le niveau de compression que nous appliquons à la +sortie |
|---|---|
| Syntaxe: | DeflateCompressionLevel valeur |
| Défaut: | La valeur par défaut de zlib |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_deflate |
La directive DeflateCompressionLevel
+ permet de spécifier le niveau de compression à utiliser ; plus
+ grande est la valeur, meilleure sera la compression, mais plus grand
+ sera aussi le temps CPU nécessaire pour effectuer le
+ traitement.
La valeur doit être comprise entre 1 (compression minimale) et 9 + (compression maximale).
+ +| Description: | Enregistre le taux de compression sous la forme d'une note +à des fins de journalisation |
|---|---|
| Syntaxe: | DeflateFilterNote [type] nom de la note |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_deflate |
La directive DeflateFilterNote permet de
+ spécifier qu'une note à propos du taux de compression doit être
+ attachée à la requête. Le nom de la note est passé sous la forme
+ d'un argument de la directive. Vous pouvez utiliser cette note à des
+ fins statistiques en enregistrant sa valeur dans votre journal des accès.
DeflateFilterNote ratio
+
+ LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' deflate
+ CustomLog "logs/deflate_log" deflate
+Pour extraire des informations plus précises de vos journaux, + vous pouvez utiliser l'argument type pour spécifier le + type de données de la note enregistrée dans le journal. + type peut prendre une des valeurs suivantes :
+ +InputOutputRatiosortie/entrée *
+ 100) dans la note. Il s'agit de la valeur par défaut si
+ l'argument type est omis.Vous pouvez donc configurer votre journalisation de la manière + suivante :
+ +DeflateFilterNote Input instream
+DeflateFilterNote Output outstream
+DeflateFilterNote Ratio ratio
+
+LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
+CustomLog "logs/deflate_log" deflate
+| Description: | Taille maximale des corps de requête décompressés |
|---|---|
| Syntaxe: | DeflateInflateLimitRequestBodyvalue |
| Défaut: | Aucune limite, mais LimitRequestBody s'applique après la
+compression |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_deflate |
| Compatibilité: | Disponible à partir de la version 2.4.10 du serveur HTTP +Apache |
La directive
+ DeflateInflateLimitRequestBody permet de
+ spécifier la taille maximale d'un corps de requête décompressé. Si
+ elle n'est pas définie, c'est la valeur de la directive LimitRequestBody qui s'applique au corps
+ de requête décompressé.
| Description: | Nombre maximal de fois que le ratio de décompression d'un +corps de requête peut être dépassé |
|---|---|
| Syntaxe: | DeflateInflateRatioBurst value |
| Défaut: | 3 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_deflate |
| Compatibilité: | Disponible à partir de la version 2.4.10 du serveur HTTP +Apache |
La directive DeflateInflateRatioBurst
+ permet de spécifier le nombre maximal de fois que la valeur de la
+ directive DeflateInflateRatioLimit peut être
+ dépassé avant l'arrêt du traitement de la requête.
| Description: | Ratio de décompression maximum pour les corps de requêtes |
|---|---|
| Syntaxe: | DeflateInflateRatioLimit value |
| Défaut: | 200 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_deflate |
| Compatibilité: | Disponible à partir de la version 2.4.10 du serveur HTTP +Apache |
La directive DeflateInflateRatioLimit
+ permet de définir le ratio maximum entre la taille d'un corps de
+ requête compressé et sa taille décompressée. Ce ratio est vérifié au
+ fur et à mesure de
+ l'arrivée du corps de requête, et s'il est dépassé plus de
+ DeflateInflateRatioBurst fois, le traitement
+ de la requête est interrompu.
| Description: | La quantité de mémoire utilisable par zlib pour la +compression |
|---|---|
| Syntaxe: | DeflateMemLevel valeur |
| Défaut: | DeflateMemLevel 9 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_deflate |
La directive DeflateMemLevel permet de
+ spécifier la quantité de mémoire utilisable par zlib pour la
+ compression (une valeur comprise entre 1 et 9).
| Description: | Taille de la fenêtre de compression zlib |
|---|---|
| Syntaxe: | DeflateWindowSize valeur |
| Défaut: | DeflateWindowSize 15 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_deflate |
La directive DeflateWindowSize permet de
+ spécifier la fenêtre de compression zlib (une valeur comprise entre
+ 1 et 15). En général, plus grande sera la taille de la fenêtre, plus
+ grand sera le taux de compression auquel on pourra s'attendre.
Serveur HTTP Apache Version 2.4
+| Description: | Envoie le contenu statique avec une bande passante limitée +définie par les différents standards des anciens modems. |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | dialup_module |
| Fichier Source: | mod_dialup.c |
Il s'agit d'un module qui envoie le contenu statique avec une bande +passante limitée définie par les différents standards des anciens +modems. Ainsi, il est possible de naviguer sur votre site avec un modem +56k V.92 en positionnant une configuration de ce type :
+ +<Location "/mysite"> + ModemStandard "V.92" +</Location>+ + +
Auparavant, pour faire des modules de limitation de bande passante, +il fallait monopoliser un thread, pour chaque client, et insérer des +temporisations pour diminuer la bande passante. Grâce à cette nouvelle +fonctionnalité, un gestionnaire peut recevoir les réponses à ses +callbacks après N millisecondes, et il sera invoqué par le module MPM +Event dans un thread différent à la fin du délai indiqué. À partir de ce +moment, le gestionnaire peut continuer à envoyer des données au +client.
+| Description: | Standard de modem à simuler |
|---|---|
| Syntaxe: | ModemStandard V.21|V.26bis|V.32|V.34|V.92 |
| Contexte: | répertoire |
| Statut: | Expérimental |
| Module: | mod_dialup |
Cette directive permet de spécifier le standard de modem que vous +souhaitez simuler.
+ +<Location "/mysite"> + ModemStandard "V.26bis" +</Location>+ + + +
Serveur HTTP Apache Version 2.4
+| Description: | Permet la redirection des adresses se terminant par un +répertoire sans slash de fin et la mise à disposition des fichiers index +de répertoire |
|---|---|
| Statut: | Base |
| Identificateur de Module: | dir_module |
| Fichier Source: | mod_dir.c |
L'index d'un répertoire peut provenir de deux sources :
+ +index.html, peut être défini à l'aide de la
+ directive DirectoryIndex
+ fournie par le module mod_dir.mod_autoindex.Les deux fonctions sont bien distinctes, si bien que vous pouvez + supprimer (ou remplacer) la génération automatique d'index, si vous + le souhaitez.
+ +Une redirection "slash de fin" est effectuée lorsque le serveur
+ reçoit une requête pour une URL du style
+ http://nom-serveur/foo/nom-rep où nom-rep
+ est le nom d'un répertoire. Comme les répertoires nécessitent un slash de
+ fin, mod_dir effectue une redirection vers
+ http://nom-serveur/foo/nom-rep/.
DirectoryCheckHandler DirectoryIndex DirectoryIndexRedirect DirectorySlash FallbackResource| Description: | Définit la réponse de ce module lorsqu'un autre +gestionnaire est utilisé |
|---|---|
| Syntaxe: | DirectoryCheckHandler On|Off |
| Défaut: | DirectoryCheckHandler Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_dir |
| Compatibilité: | Disponible depuis la version 2.4.8 du serveur HTTP +Apache. Les versions antérieures à 2.4 se comportaient implicitement +comme si "DirectoryCheckHandler ON" avait été spécifié. |
La directive DirectoryCheckHandler permet
+ de faire en sorte que mod_dir recherche un index
+ de répertoire ou ajoute des slashes de fin lorsqu'un autre
+ gestionnaire à été défini pour l'URL considérée. Les gestionnaires
+ peuvent être définis à via des directives telles que
+ SetHandler ou par d'autres
+ modules tels que mod_rewrite au cours des
+ substitutions de niveau répertoire.
Dans les versions antérieures à 2.4, ce module ne modifiait pas son
+ comportement si un autre gestionnaire avait été défini pour l'URL
+ considérée. Ceci permettait de servir des index de répertoires même si une
+ directive SetHandler avait été définie pour un
+ répertoire entier, mais pouvait aussi être à l'origine de conflits avec
+ d'autres modules comme mod_rewrite.
| Description: | Liste des fichiers ressources à rechercher lorsque le +client envoie une requête pour un répertoire |
|---|---|
| Syntaxe: | DirectoryIndex
+ disabled | url locale [url locale] ... |
| Défaut: | DirectoryIndex index.html |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_dir |
La directive DirectoryIndex permet de
+ définir une liste de fichiers ressources à rechercher lorsqu'un
+ client envoie une requête pour l'index d'un répertoire, en ajoutant
+ un '/' à la fin du nom de ce dernier. url locale est
+ l'URL (codée avec caractères '%') d'un document du serveur, relative
+ au répertoire faisant l'objet de la requête ; il s'agit en général
+ du nom d'un fichier situé dans le répertoire. Si plusieurs URLs sont
+ fournies, le serveur renverra la première d'entre elles qui
+ correspond à une ressource existante. Si aucune ressource ne
+ correspond à la liste des URLs spécifiées, et si l'option
+ Indexes est définie, le serveur générera son propre
+ listing du répertoire.
DirectoryIndex index.html+
Avec cette configuration, une requête pour l'URL
+ http://example.com/docs/ renverrait au client la
+ ressource http://example.com/docs/index.html si elle
+ existe, ou provoquerait la génération du listing du répertoire si la
+ ressource n'existe pas.
Notez qu'il n'est pas nécessaire que les documents soient + relatifs au répertoire ;
+ +DirectoryIndex index.html index.txt /cgi-bin/index.pl+ + +
provoquerait l'exécution du script CGI
+ /cgi-bin/index.pl si aucun des fichiers
+ index.html ou index.txt n'existe dans le
+ répertoire considéré.
La spécification du seul argument "disabled" empêche
+ mod_dir de rechercher un index. Un argument
+ "disabled" sera interprété de manière littérale si d'autres
+ arguments sont présents avant ou après lui, même s'ils sont
+ eux-mêmes des arguments "disabled".
Note: Positionner plusieurs directives DirectoryIndex
+ au coeur du même context complète la liste des ressources et ne l'écrase pas :
+
# Exemple A: Positionner index.html en page d'index, puis ajouter index.php. +<Directory "/foo"> + DirectoryIndex index.html + DirectoryIndex index.php +</Directory> + +# Exemple B: La même chose que l'exemple A, mais réalisé au moyen d'une seule directive. +<Directory "/foo"> + DirectoryIndex index.html index.php +</Directory> + +# Exemple C: Pour remplacer la liste des ressources, il faut d'abord la vider : +# Ici, seul index.php restera référencé comme ressource d'index. +<Directory "/foo"> + DirectoryIndex index.html + DirectoryIndex disabled + DirectoryIndex index.php +</Directory>+ + + +
| Description: | Définit une redirection externe pour les index de +répertoires. + |
|---|---|
| Syntaxe: | DirectoryIndexRedirect on | off | permanent | temp | seeother |
+3xx-code
+ |
| Défaut: | DirectoryIndexRedirect off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_dir |
| Compatibilité: | Disponible depuis la version 2.3.14 |
Par défaut, c'est la page définie par la directive
+ DirectoryIndex qui est sélectionnée et
+ renvoyée de manière transparente au client. La directive
+ DirectoryIndexRedirect permet de rediriger le
+ client via une redirection de type 3xx.
Les arguments acceptés sont :
+on : envoie une redirection 302 vers l'index choisi.off : n'envoie aucune redirection. Il s'agit du comportement historique de mod_dir.permanent : envoie une redirection 301 (permanent) vers l'index choisi.temp : ceci est équivalent à onseeother : envoie une redirection 303 (également appelée "See Other") vers l'index choisi.DirectoryIndexRedirect on+
Une requête pour http://example.com/docs/ se
+ solderait par une redirection temporaire vers
+ http://example.com/docs/index.html si cette ressource
+ existe.
| Description: | Activation/Désactivation de la redirection "slash de +fin" |
|---|---|
| Syntaxe: | DirectorySlash On|Off |
| Défaut: | DirectorySlash On |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_dir |
La directive DirectorySlash permet de
+ déterminer si mod_dir doit corriger ou non les URLs
+ pointant vers un répertoire.
En général, si un utilisateur envoie une requête pour une
+ ressource sans slash de fin, cette ressource représentant un
+ répertoire, mod_dir le redirige vers la même
+ ressource, mais en ajoutant un slash de fin, et ceci pour
+ plusieurs bonnes raisons :
mod_autoindex fonctionnera correctement. Comme
+ il n'indique pas le chemin dans le lien, le chemin de l'URL serait
+ incorrect.DirectoryIndex n'est évaluée
+ que pour les répertoires se terminant par un slash.Si vous ne souhaitez pas voir ces effets, et si + les raisons évoquées ci-dessus ne s'appliquent pas à vous, vous + pouvez désactiver la redirection comme indiqué ci-dessous. + Gardez cependant à l'esprit que ceci peut avoir des répercutions en + matière de sécurité.
+ +# voir l'avertissement de sécurité ci-dessous ! +<Location "/some/path"> + DirectorySlash Off + SetHandler some-handler +</Location>+ + +
La désactivation de la redirection "slash de fin" peut entraîner
+ la divulgation d'informations. Considérons la situation où
+ mod_autoindex est actif (Options
+ +Indexes), où la directive DirectoryIndex a pour valeur une ressource valide (par
+ exemple index.html), et où aucun gestionnaire
+ particulier n'a été défini pour cette URL. Dans ce cas, une requête
+ avec slash de fin afficherait le contenu du fichier
+ index.html ; par contre, une requête sans slash
+ de fin afficherait un listing du contenu du
+ répertoire.
Notez aussi que certains navigateurs peuvent modifier par erreur + des requêtes POST en requêtes GET lors d'une redirection, les + données POST étant alors perdues.
+ +| Description: | Définit une URL par défaut pour les requêtes qui ne ciblent +aucun fichier |
|---|---|
| Syntaxe: | FallbackResource disabled | url-locale |
| Défaut: | disabled - httpd renvoie un code d'erreur 404 (Not Found) |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_dir |
| Compatibilité: | L'argument disabled est disponible à partir
+de la version 2.4.4 du serveur HTTP Apache. |
Cette directive permet de définir un traitement pour toute URL + qui ne correspond à aucune ressource de votre système de fichiers, + et qui provoquerait sans cela l'envoi d'un code d'erreur HTTP 404 + (Not Found). + Par exemple
+FallbackResource /not-404.php+ +
fait en sorte que les requêtes ne correspondant à aucun fichier
+ soient traitées par non-404.php, sans affecter les
+ requêtes pour des fichiers existants.
Il est souvent souhaitable qu'un seul fichier ou ressource traite + toutes les requêtes à destination d'un répertoire + particulier, sauf pour les requêtes qui correspondent à un fichier + ou script existant. On y fait souvent référence sous le terme + 'contrôleur frontal'.
+Dans les versions plus anciennes de httpd, cet effet nécessitait
+ en général mod_rewrite, et l'utilisation des tests
+ conditionnels -f et -d pour vérifier
+ l'existence des fichiers et répertoires. Maintenant, une seule ligne
+ de configuration est nécessaire.
FallbackResource /index.php+ +
Les fichiers existants comme des images, des fichiers css, etc... + seront traités normalement.
+L'argument disabled permet de désactiver cette
+ fonctionnalité dans le cas où l'héritage d'un répertoire parent
+ n'est pas souhaité.
Pour un URI intermédiaire tel que + http://example.com/blog/, cet URI intermédiaire doit être + spécifié en tant que url-locale :
+<Directory "/web/example.com/htdocs/blog"> + FallbackResource /blog/index.php +</Directory> +<Directory "/web/example.com/htdocs/blog/images"> + FallbackResource disabled +</Directory>+ + +
Serveur HTTP Apache Version 2.4
+| Description: | Enregistre toutes les entrées/sorties dans le journal des +erreurs de la manière souhaitée. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | dumpio_module |
| Fichier Source: | mod_dumpio.c |
mod_dumpio permet d'enregistrer toutes les entrées
+ reçues par Apache et/ou toutes les sorties envoyées par ce dernier
+ dans le fichier error.log.
+
L'enregistrement des données s'effectue juste après le décodage + SSL (pour les entrées), et juste avant le codage SSL (pour les + sorties). Comme on peut s'y attendre, tout ceci peut représenter un + volume important de données, et ne doit être utilisé qu'à des fins + de débogage.
+Pour activer le module, ce dernier doit être compilé et chargé
+ par l'intermédiaire de la configuration de votre instance d'Apache.
+ La journalisation peut ensuite être activée ou désactivée séparément
+ pour les entrées et sorties à l'aide des directives ci-dessous. En
+ outre, mod_dumpio doit être configuré à LogLevel trace7 :
LogLevel dumpio:trace7+ +
| Description: | Enregistre toutes les entrées dans le journal des +erreurs |
|---|---|
| Syntaxe: | DumpIOInput On|Off |
| Défaut: | DumpIOInput Off |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_dumpio |
| Compatibilité: | DumpIOInput est disponible depuis la version 2.1.3 +d'Apache. |
Active la journalisation de toutes les entrées.
+ +DumpIOInput On+
| Description: | Enregistre toutes les sorties dans le journal des +erreurs |
|---|---|
| Syntaxe: | DumpIOOutput On|Off |
| Défaut: | DumpIOOutput Off |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_dumpio |
| Compatibilité: | DumpIOOutput est disponible depuis la version 2.1.3 +d'Apache. |
Active la journalisation de toutes les sorties.
+ +DumpIOOutput On+
Serveur HTTP Apache Version 2.4
+| Description: | Un simple serveur d'écho pour illustrer les modules de +protocole |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | echo_module |
| Fichier Source: | mod_echo.c |
Ce module est un module de protocole exemple permettant d'en + illustrer le concept. Il fournit un simple serveur d'écho. Envoyez + lui une phrase par telnet, et il vous la renverra.
+| Description: | Active ou désactive le serveur d'écho |
|---|---|
| Syntaxe: | ProtocolEcho On|Off |
| Défaut: | ProtocolEcho Off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_echo |
La directive ProtocolEcho permet d'activer
+ ou de désactiver le serveur d'écho.
ProtocolEcho On+
Serveur HTTP Apache Version 2.4
+| Description: | Modifie l'environnement transmis aux scripts CGI et aux +pages SSI |
|---|---|
| Statut: | Base |
| Identificateur de Module: | env_module |
| Fichier Source: | mod_env.c |
Ce module permet de contrôler les variables d'environnement
+ internes utilisées par divers modules du serveur HTTP Apache. Ces
+ variables sont aussi accessibles aux scripts CGI en tant que
+ variables d'environnement système natives, et disponibles dans les
+ pages SSI. Les variables d'environnement peuvent
+ être transmises depuis le shell qui a lancé le processus
+ httpd. Elles peuvent également être définies ou
+ supprimées au cours du processus de configuration.
| Description: | Transmet des variables d'environnement depuis le +shell |
|---|---|
| Syntaxe: | PassEnv var-env [var-env]
+... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_env |
Cette directive permet de spécifier quelles variables
+ d'environnement système natives doivent être disponibles en tant que
+ variables d'environnement internes pour les modules du serveur HTTP
+ Apache, et propagées vers les scripts CGI et les pages SSI. Leurs
+ valeurs sont issues de l'environnement natif de l'OS associé au
+ shell qui a invoqué le processus httpd.
PassEnv LD_LIBRARY_PATH+
| Description: | Définit des variables d'environnement |
|---|---|
| Syntaxe: | SetEnv var-env [valeur] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_env |
Définit une variable d'environnement interne, cette dernière étant + ensuite disponible pour les modules du serveur HTTP Apache et + transmise aux scripts CGI et aux pages SSI.
+ +SetEnv SPECIAL_PATH /foo/bin+
Si l'argument valeur est absent, la variable est + définie à la valeur d'une chaîne vide.
+ +Les variables d'environnement internes définies par cette
+ directive le sont après l'exécution de la plupart des
+ directives du traitement initial des requêtes, comme les contrôles
+ d'accès et la mise en correspondance des URIs avec les noms de
+ fichiers. Si la variable d'environnement est sensée intervenir au
+ cours de cette phase initiale du traitement, par exemple pour la
+ directive RewriteRule,
+ vous devez plutôt utiliser la directive SetEnvIf pour définir cette
+ variable.
| Description: | Supprime des variables de l'environnement |
|---|---|
| Syntaxe: | UnsetEnv var-env [var-env]
+... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_env |
Supprime une ou plusieurs variables d'environnement internes parmi celles + qui sont transmises aux scripts CGI et aux pages SSI.
+ +UnsetEnv LD_LIBRARY_PATH+
Serveur HTTP Apache Version 2.4
+| Description: | Illustration de l'API des modules Apache |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | example_hooks_module |
| Fichier Source: | mod_example_hooks.c |
Certains fichiers situés dans le répertoire
+ modules/examples de l'arborescence de la
+ distribution d'Apache sont fournis à titre d'exemples pour ceux qui
+ souhaitent écrire des modules qui utilisent l'API d'Apache.
Le fichier principal est mod_example_hooks.c, qui
+ constitue une illustration exhaustive des différents mécanismes et
+ syntaxes d'appels. En aucun cas un module additionnel n'aura à
+ inclure des routines pour tous les appels - il n'en nécessitera au
+ contraire qu'un petit nombre !
Le module example_hooks fonctionne réellement. Si vous le chargez dans + votre serveur, activez le gestionnaire "example-hooks-handler" dans une + section location, et essayez d'accéder à la zone du site web + correspondante, vous verrez s'afficher certaines sorties que le + module example_hooks produit au cours des différents appels.
+Pour inclure le module example_hooks dans votre serveur, effectuez les + étapes suivantes :
+ +configure avec l'option
+ --enable-example-hooks.make").Pour ajouter votre propre module :
+ +cp modules/examples/mod_example_hooks.c
+ modules/nouveau_module/mod_monexemple.cmodules/nouveau_module/config.m4.
+ APACHE_MODPATH_INIT(nouveau_module).modules/examples/config.m4.configure --help.config.m4 des répertoires des autres modules pour
+ plus d'exemples.APACHE_MODPATH_FINISH.module/nouveau_module/Makefile.in.
+ Si la compilation de votre module ne nécessite pas d'instructions
+ particulières, ce fichier ne doit contenir que la ligne
+ include $(top_srcdir)/build/special.mk.mod_example_hooksPour activer le module example_hooks, ajoutez à votre fichier
+ httpd.conf un bloc du style :
<Location "/example-hooks-info"> + SetHandler example-hooks-handler +</Location>+ + +
Vous pouvez aussi ajouter ce qui suit dans un fichier .htaccess, puis
+ accéder au fichier "test.example" à partir du répertoire
+ correspondant :
AddHandler example-hooks-handler ".example"+ + +
Après avoir rechargé la configuration ou redémarré votre serveur, + vous devriez pouvoir accéder à ce fichier et voir s'afficher ce qui + a été décrit plus haut.
+| Description: | Directive de démonstration pour illustrer l'API des modules +Apache |
|---|---|
| Syntaxe: | Example |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Expérimental |
| Module: | mod_example_hooks |
La directive Example n'a pour fonction que
+ de définir un drapeau de démonstration que le gestionnaire de
+ contenu du module example_hooks va afficher. Elle ne possède aucun
+ argument. Si vous naviguez vers une URL à laquelle le gestionnaire
+ de contenu example_hooks s'applique, vous verrez s'afficher les routines
+ du module, ainsi que l'ordre dans lequel elles ont été appelées pour
+ servir le document demandé. On peut observer l'effet de cette
+ directive dans la phrase "Example
+ directive declared here: YES/NO".
Serveur HTTP Apache Version 2.4
+| Description: | Génération des en-têtes HTTP Expires et
+Cache-Control en fonction de critères spécifiés par
+l'utilisateur |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | expires_module |
| Fichier Source: | mod_expires.c |
Ce module permet de contrôler la définition de l'en-tête HTTP
+ Expires et la directive max-age de
+ l'en-tête HTTP Cache-Control dans les réponses du
+ serveur. La date d'expiration peut être définie soit par rapport à
+ la date de dernière modification du fichier source, soit
+ par rapport à l'heure d'accès du client.
Ces en-têtes HTTP permettent d'informer le client quant à la + validité et à la persistence du document. S'il est présent dans le + cache, et tant qu'il n'est pas arrivé à expiration, le document sera + servi à partir de ce dernier, plutôt qu'à partir du document source. + Après expiration, la copie du document dans le cache sera considérée + comme "expirée" et donc invalide, et une nouvelle copie devra être + obtenue à partir du document source.
+ +Pour modifier les directives de contrôle du cache autres
+ que max-age (voir la RFC
+ 2616 section 14.9), vous pouvez utiliser la directive Header.
Lorsque l'en-tête Expires est déjà présent dans la
+ réponse générée par le serveur, par exemple s'il a été créé par un
+ script CGI ou un serveur original via un serveur mandataire, ce
+ module n'ajoute aucun en-tête Expires ou
+ Cache-Control.
ExpiresActive ExpiresByType ExpiresDefaultPour une syntaxe plus lisible, on peut aussi utiliser les
+ directives ExpiresDefault et ExpiresByType comme suit :
ExpiresDefault "base [plus num type] [num type] ..." +ExpiresByType type/encoding "base [plus num type] [num type] ..."+ + +
où base peut être :
+ +accessnow (équivalent à
+ 'access')modificationLe mot-clé plus est optionnel. num doit
+ correspondre à une valeur entière [compatible avec
+ atoi()], et type peut être choisi parmi :
yearsmonthsweeksdayshoursminutessecondsPar exemple, pour faire expirer par défaut les documents 1 mois + après leur accès, on peut utiliser une des directives suivantes :
+ExpiresDefault "access plus 1 month" +ExpiresDefault "access plus 4 weeks" +ExpiresDefault "access plus 30 days"+ + + +
La date d'expiration peut être définie plus précisément en + ajoutant plusieurs clauses 'num type' :
+ +ExpiresByType text/html "access plus 1 month 15 days 2 hours" +ExpiresByType image/gif "modification plus 5 hours 3 minutes"+ + +
Notez que si vous utilisez une configuration basée sur la date de + modification, l'en-tête Expires ne sera pas ajouté à un contenu qui + ne provient pas directement d'un fichier sur disque ; et ceci tout + simplement parce que ce type de contenu ne possède pas de date de + modification.
+| Description: | Active la génération d'en-têtes
+Expires |
|---|---|
| Syntaxe: | ExpiresActive On|Off |
| Défaut: | ExpiresActive Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Extension |
| Module: | mod_expires |
Cette directive permet d'activer ou de désactiver la génération
+ des en-têtes Expires et Cache-Control pour
+ les documents concernés ; en d'autres termes, si cette directive se
+ trouve dans un fichier .htaccess, par exemple, elle ne
+ s'applique qu'aux documents générés à partir du répertoire
+ considéré. Si elle est définie à Off, les en-têtes ne
+ seront générés pour aucun document du domaine considéré (sauf
+ surcharge de la configuration à un niveau inférieur, comme un
+ fichier .htaccess qui l'emporterait sur le fichier de
+ configuration du serveur). Si elle est définie à On,
+ les en-têtes seront ajoutés aux documents servis en fonction des
+ critères définis par les directives ExpiresByType et ExpiresDefault (voir plus
+ loin).
Notez que cette directive ne permet pas de garantir qu'un en-tête
+ Expires ou Cache-Control sera généré. Si
+ les critères ne sont pas respectés, aucun en-tête ne sera généré, et
+ la directive produira le même effet que si elle n'avait pas été
+ définie.
| Description: | Définition de la valeur de l'en-tête Expires
+en fonction du type MIME |
|---|---|
| Syntaxe: | ExpiresByType type MIME
+<code>secondes |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Extension |
| Module: | mod_expires |
Cette directive permet de définir la valeur de l'en-tête
+ Expires et de la directive max-age de
+ l'en-tête Cache-Control générés pour les documents du
+ type MIME spécifié (par exemple, text/html). Le second
+ argument définit le nombre de secondes qui seront ajoutées à un
+ temps de base pour calculer la date d'expiration.
+ Cache-Control: max-age se calcule en soustrayant la
+ date de la requête de la date d'expiration et s'exprime en
+ secondes.
Le champ <code> permet de spécifier
+ quel temps doit être utilisé comme temps de base; M
+ signifie que c'est la date
+ de dernière modification du fichier qui doit être utilisée comme
+ temps de base, alors que A signifie que c'est le moment
+ où le client a accédé au document qui doit être utilisé comme temps
+ de base.
La différence d'effet est subtile. Si on utilise M,
+ toutes les copies existantes du document dans tous les caches
+ expireront au même moment, ce qui peut convenir par exemple pour une
+ notice hebdomadaire qui correspond toujours à la même URL. Si on
+ utilise A, la date d'expiration sera différente pour
+ chaque client, ce qui peut convenir pour des fichiers d'images qui
+ ne changent pas très souvent, et en particulier pour un ensemble de
+ documents en relation qui se réfèrent tous aux mêmes images (ces
+ images sont alors accédées de manière répétitive dans un intervalle
+ de temps assez court).
# active la génération des en-têtes Expires +ExpiresActive On +# les images GIF expirent au bout d'un mois dans le cache du +# client +ExpiresByType image/gif A2592000 +# les documents HTML restent valables une semaine après leur date +# de dernière modification +ExpiresByType text/html M604800+
Notez que cette directive ne produit d'effet que si
+ ExpiresActive On a été spécifié. Elle l'emporte, mais
+ seulement pour le type MIME spécifié, sur toute date
+ d'expiration définie par la directive ExpiresDefault.
Vous pouvez aussi définir le mode de calcul de la date + d'expiration en utilisant une syntaxe + alternative, comme décrit plus haut dans ce document.
+ +| Description: | Mode de calcul par défaut de la date +d'expiration |
|---|---|
| Syntaxe: | ExpiresDefault <code>secondes |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Extension |
| Module: | mod_expires |
Cette directive permet de définir le mode de calcul par défaut de
+ la date d'expiration pour tous les documents du domaine considéré.
+ Elle peut être annulée pour certains types de documents par la
+ directive ExpiresByType. Voir la description
+ de cette dernière directive pour plus de détails à propos de la
+ syntaxe de l'argument, ainsi que la description de la syntaxe alternative.
Serveur HTTP Apache Version 2.4
+| Description: | Fait traiter le corps de la réponse par un programme +externe avant de l'envoyer au client |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | ext_filter_module |
| Fichier Source: | mod_ext_filter.c |
mod_ext_filter représente un modèle de
+ programmation simple et bien connu pour les filtres. Avec ce module, tout programme
+ qui lit l'entrée standard stdin et écrit sur la sortie standard
+ stdout (autrement dit une commande filtre de style Unix) peut
+ servir de filtre pour Apache. Ce mécanisme de filtrage est beaucoup
+ plus lent qu'un filtre spécialement écrit pour
+ l'API d'Apache et faisant partie intégrante du processus du serveur
+ Apache, mais il présente les avantages suivants :
Même dans le cas où le niveau de performance est insuffisant pour
+ une utilisation en production, on peut utiliser
+ mod_ext_filter comme prototype d'environnement pour
+ les filtres.
# la directive de mod_ext_filter définissant un filtre +# permettant de mettre des fichiers text/c au format HTML en +# utilisant le programme externe /usr/bin/enscript, le type du +# fichier résultant étant défini à text/html +ExtFilterDefine c-to-html mode=output \ + intype=text/c outtype=text/html \ + cmd="/usr/bin/enscript --color -w html -Ec -o -" + +<Directory "/export/home/trawick/apacheinst/htdocs/c"> + # directive de base permettant de traiter la sortie avec le + # nouveau filtre + SetOutputFilter c-to-html + + # directive de mod_mime définissant le type des fichiers dont + # le nom possède l'extension .c à text/c + AddType text/c .c +</Directory>+ + + +
Note : cet exemple avec gzip n'est fourni qu'à titre
+ d'illustration. Veuillez vous reporter à la documentation de
+ mod_deflate pour un exemple d'implémentation plus
+ pratique.
# la directive de mod_ext_filter qui définit le filtre externe +ExtFilterDefine gzip mode=output cmd=/bin/gzip + +<Location "/gzipped"> + + # directive de base permettant de traiter la sortie avec le + # filtre gzip + SetOutputFilter gzip + + # la directive de mod_headers permettant d'ajouter le champ + # d'en-tête "Content-Encoding: gzip" + Header set Content-Encoding gzip +</Location>+ + + + +
# directive de mod_ext_filter définissant un filtre qui fait +# passer tous les flux en sortie par la commande cat ; cat ne +# modifie rien ; elle ne fait que compliquer le cheminement des +# flux et consommer des ressources supplémentaires + ExtFilterDefine slowdown mode=output cmd=/bin/cat \ +ExtFilterDefine slowdown mode=output cmd=/bin/cat \ + preservescontentlength + +<Location "/"> + # directive de base permettant de traiter plusieurs fois la + # sortie avec le filtre slowdown + # + SetOutputFilter slowdown;slowdown;slowdown +</Location>+ + + +
# directive de mod_ext_filter définissant un filtre qui +# remplace du texte dans la réponse +# +ExtFilterDefine fixtext mode=output intype=text/html \ + cmd="/bin/sed s/verdana/arial/g" + +<Location "/"> + # directive de base permettant de traiter la sortie avec le + # filtre fixtext + SetOutputFilter fixtext +</Location>+ + +
Vous pouvez aussi utiliser mod_substitute pour
+effectuer le même traitement sans avoir à invoquer un programme
+externe.
# Trace les données lues et écrites par mod_deflate pour un +# client particulier (IP 192.168.1.31) qui a des problèmes de +# compression. +# Ce premier filtre va tracer ce qui entre dans mod_deflate. +ExtFilterDefine tracebefore \ + cmd="/bin/tracefilter.pl /tmp/tracebefore" \ + EnableEnv=trace_this_client + +# Ce second filtre va tracer ce qui sort de mod_deflate. +# Notez que sans le paramètre ftype, le type de filtre par +# défaut AP_FTYPE_RESOURCE placerait le filtre *avant* +# mod_deflate dans la chaîne de filtrage. Le fait d'affecter +# à ce paramètre une valeur numérique sensiblement supérieure à +# AP_FTYPE_CONTENT_SET permet de s'assurer que le filtre sera +# placé après mod_deflate. +ExtFilterDefine traceafter \ + cmd="/bin/tracefilter.pl /tmp/traceafter" \ + EnableEnv=trace_this_client ftype=21 + +<Directory "/usr/local/docs"> + SetEnvIf Remote_Addr 192.168.1.31 trace_this_client + SetOutputFilter tracebefore;deflate;traceafter +</Directory>+ + +
#!/usr/local/bin/perl -w
+use strict;
+
+open(SAVE, ">$ARGV[0]")
+ or die "can't open $ARGV[0]: $?";
+
+while (<STDIN>) {
+ print SAVE $_;
+ print $_;
+}
+
+close(SAVE);
+| Description: | Définit un filtre externe |
|---|---|
| Syntaxe: | ExtFilterDefine nom_filtre paramètres |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ext_filter |
La directive ExtFilterDefine
+ définit les caractéristiques d'un filtre externe, et en particulier
+ le programme à exécuter ainsi que ses arguments.
nom_filtre spécifie le nom du filtre en cours de
+ définition. On peut ensuite utiliser ce nom pour référencer le
+ filtre dans les directives SetOutputFilter. Il doit être unique parmi les noms de
+ tous les filtres enregistrés. Pour le moment, aucune erreur
+ n'est signalée par l'API register-filter, si bien qu'un problème de
+ noms dupliqués ne sera pas porté à la connaissance de
+ l'utilisateur.
Viennent ensuite un ou plusieurs paramètres dans un ordre
+ indéfini, qui permettent de spécifier la commande externe à exécuter
+ et certaines autres caractéristiques. Le seul paramètre obligatoire
+ est cmd=. Voici la liste de ces paramètres :
cmd=ligne de commandecmd= spécifie la commande
+ externe à exécuter. Si la ligne de commande comporte des
+ arguments, elle doit être entourée de guillemets (par exemple
+ cmd="/bin/mypgm arg1
+ arg2"). Les guillemets habituels du shell ne
+ sont pas nécessaires car le programme est lancé directement, sans
+ passer par le shell. Les arguments du programme doivent être
+ séparés par des espaces. Si un argument contient des espaces, ces
+ derniers doivent être échappés par un antislash '\'. Si un
+ argument contient des antislashes '\', ces derniers doivent être
+ eux-mêmes échappés par un antislash '\'. Outre les variables
+ d'environnement CGI standards, les variables DOCUMENT_URI,
+ DOCUMENT_PATH_INFO, et QUERY_STRING_UNESCAPED seront également
+ définies pour le programme.mode=modemode=output (valeur par défaut) pour les
+ filtres qui traitent les réponses. Utilisez
+ mode=input pour les filtres qui traitent les
+ requêtes. mode=input est disponible depuis la version
+ 2.1 d'Apache.intype=type MIMEintype= ne sera filtré.outtype=type MIMEPreservesContentLengthPreservesContentLength indique que le
+ filtre doit conserver la taille du contenu. Ce n'est pas le
+ comportement par défaut, car la plupart des filtres modifient cette
+ taille. Ce mot-clé doit être spécifié si le filtre ne doit pas
+ modifier la taille du contenu.ftype=type de filtredisableenv=envenableenv=env| Description: | Configure les options de
+mod_ext_filter |
|---|---|
| Syntaxe: | ExtFilterOptions option [option] ... |
| Défaut: | ExtFilterOptions NoLogStderr |
| Contexte: | répertoire |
| Statut: | Extension |
| Module: | mod_ext_filter |
La directive ExtFilterOptions
+ spécifie des options de traitement particulières pour
+ mod_ext_filter. Les arguments option
+ peuvent contenir :
LogStderr | NoLogStderrLogStderr indique que les messages
+ envoyés par le programme de filtrage externe sur la sortie
+ d'erreurs standard doivent être enregistrés dans le journal des
+ erreurs d'Apache. NoLogStderr inverse ce
+ comportement.Onfail=[abort|remove]abort (la valeur par
+ défaut), le traitement de la requête sera abandonné. Avec remove, le
+ filtre est supprimé, et le traitement de la requête se poursuit
+ sans lui.ExtFilterOptions LogStderr+ + +
Les messages envoyés vers la sortie d'erreurs standard du filtre + seront enregistrés dans le journal des erreurs d'Apache.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Mise en cache mémoire d'une liste statique de +fichiers |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | file_cache_module |
| Fichier Source: | mod_file_cache.c |
mod_file_cache peut facilement conduire à la
+ création d'un site inopérant.
+ La mise en cache de fichiers souvent demandés mais rarement
+ modifiés est une technique permettant de réduire la charge du
+ serveur. mod_file_cache met en oeuvre deux
+ techniques de mise en cache de fichiers statiques
+ fréquemment demandés. Des directives de configuration vous
+ permettent d'indiquer à mod_file_cache soit
+ d'ouvrir et de charger une image en mémoire d'un fichier avec
+ mmap(), soit de préouvrir un fichier et de maintenir en
+ service le gestionnaire du fichier. Les deux techniques
+ permettent de réduire la charge du serveur lors du traitement des
+ requêtes concernant ces fichiers, en accomplissant une partie du
+ travail nécessaire à la mise à disposition de ces fichiers (en
+ particulier les opérations d'entrées/sorties sur les fichiers) au
+ démarrage du serveur, plutôt qu'au cours de chaque requête.
Note : ces techniques sont inutilisables pour accélérer des + programmes CGI ou d'autres fichiers servis par des gestionnaires de + contenu spéciaux. Elles ne peuvent être utilisées que pour des + fichiers standards, normalement servis par le gestionnaire de contenu + de base d'Apache.
+ +Ce module est une extension du module
+ d'Apache 1.3 mod_mmap_staticet s'en inspire
+ fortement .
mod_file_cache gère la mise en cache d'une liste
+ de fichiers définie de manière statique via une des directives
+ MMapFile ou
+ CacheFile au niveau
+ de la configuration du serveur principal.
Les deux directives ne sont pas supportées par toutes les
+ plates-formes. Par exemple, Apache pour Windows ne supporte pas
+ actuellement la directive MMapFile, alors que d'autres
+ plates-formes, comme AIX, supportent les deux. Vous recevrez un
+ message d'erreur dans le journal des erreurs du serveur si vous
+ essayez d'utiliser une directive non supportée. Si vous utilisez une
+ directive non supportée, le serveur démarrera, mais les fichiers ne
+ seront pas mis en cache. Sur les plates-formes qui supportent les
+ deux directives, vous devez faire des essais afin de déterminer
+ quelle directive vous convient le mieux.
La directive MMapFile du module
+ mod_file_cache permet de transférer en mémoire
+ une liste statique de fichiers à l'aide de l'appel système
+ mmap(). Cet appel système est disponible sur la
+ plupart des plates-formes de style Unix, mais pas sur toutes. Il
+ existe parfois des limites spécifiques au système quant à la
+ taille et au nombre de fichiers qui peuvent être
+ mmap()és, et l'expérimentation est probablement la
+ méthode la plus simple pour déterminer ces limites.
Ce mmap()age n'est effectué qu'une seul fois au
+ démarrage ou redémarrage du serveur. Ainsi, chaque fois qu'un des
+ fichiers chargés en mémoire est modifié au niveau du système de
+ fichiers, vous devez redémarrer le serveur (voir la
+ documentation sur l'Arrêt et redémarrage). Pour bien
+ insister sur ce point, si des fichiers sont modifiés sur
+ disque, et si vous ne redémarrez pas le serveur, vous allez
+ finir par servir des contenus complètement obsolètes. Vous devez
+ mettre à jour les fichiers en renommant l'ancienne version et en
+ enregistrant la nouvelle sur disque. Pour y parvenir, on peut
+ utiliser des outils comme rdist et mv.
+ La raison pour laquelle ce module ne prend pas en compte les
+ modifications de fichiers réside dans le fait que cette
+ vérification nécessiterait un appel à stat() à chaque
+ accès, et en fin de compte, l'augmentation de la consommation de
+ ressources finirait par aller contre le but initial de
+ réduire les entrées/sorties.
La directive CacheFile du module
+ mod_file_cache permet d'associer un
+ gestionnaire ou descripteur de fichier à chaque
+ fichier énuméré dans la directive de configuration et place ces
+ gestionnaires de fichiers ouverts dans le cache. Lorsqu'un des
+ fichier est demandé, le serveur sélectionne son gestionnaire dans
+ le cache et le transmet à l'API sendfile() (ou
+ TransmitFile() sous Windows).
Cette mise en cache des gestionnaire n'est effectuée qu'une
+ seule fois au démarrage ou redémarrage du système. Ainsi, chaque
+ fois qu'un des fichiers chargés en mémoire est modifié au niveau
+ du système de fichiers, vous devez redémarrer le serveur
+ (voir la documentation sur l'Arrêt et redémarrage).
+ Pour bien
+ insister sur ce point, si des fichiers sont modifiés sur
+ disque, et si vous ne redémarrez pas le serveur, vous allez
+ finir par servir des contenus complètement obsolètes. Vous devez
+ mettre à jour les fichiers en renommant l'ancienne version et en
+ enregistrant la nouvelle sur disque. Pour y parvenir, on peut
+ utiliser des outils comme rdist et
+ mv.
Ne cherchez pas à trouver de directive qui met tous les
+ fichiers d'un répertoire en cache, de manière récursive. Pour y
+ parvenir, vous pouvez vous reporter à la directive Include directive, et considérer cette
+ commande :
+ find /www/htdocs -type f -print \
+ | sed -e 's/.*/mmapfile &/' > /www/conf/mmap.conf
+
| Description: | Met en cache une liste de gestionnaires de fichiers au +démarrage |
|---|---|
| Syntaxe: | CacheFile chemin fichier [chemin fichier] ... |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_file_cache |
La directive CacheFile permet d'associer
+ des gestionnaires à un ou plusieurs fichiers (séparés par des
+ espaces), et de placer ceux-ci dans le cache au démarrage du
+ serveur. Les gestionnaires des fichiers mis en cache sont
+ automatiquement fermés à l'arrêt du serveur. Lorsqu'un ou plusieurs
+ fichiers ont été modifiés sur disque, le serveur doit être redémarré
+ afin que les modifications soient prises en compte par le cache.
Soyez prudent avec les arguments chemin fichier : ils
+ doivent correspondre exactement au chemin du système de fichier que
+ créent les gestionnaires de traduction URL-vers-nom-fichier
+ d'Apache. On ne peut pas comparer des inodes ou autres identifiants
+ pour mettre en correspondance des chemins à l'aide de liens
+ symboliques (etc...), car là encore, ceci nécessiterait un
+ appel à stat() supplémentaire, ce qui n'est pas acceptable.
+ Il n'est pas garanti que ce module fonctionne avec des noms de
+ fichiers réécrits par mod_alias ou
+ mod_rewrite.
CacheFile /usr/local/apache/htdocs/index.html+
| Description: | Charge au démarrage une liste de fichiers en mémoire |
|---|---|
| Syntaxe: | MMapFile chemin fichier [chemin fichier] ... |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_file_cache |
La directive MMapFile permet de charger un
+ ou plusieurs fichiers (séparés par des espaces) en mémoire au
+ démarrage du serveur. Ceux-ci sont automatiquement déchargés de la
+ mémoire à l'arrêt du serveur. Lorsqu'un ou plusieurs fichiers ont
+ été modifiés sur disque, on doit au minimum envoyer un signal
+ HUP ou USR1 au serveur afin de les
+ remmap()er.
Soyez prudent avec les arguments chemin fichier : ils
+ doivent correspondre exactement au chemin du système de fichier que
+ créent les gestionnaires de traduction URL-vers-nom-fichier
+ d'Apache. On ne peut pas comparer des inodes ou autres identifiants
+ pour mettre en correspondance des chemins à l'aide de liens
+ symboliques (etc...), car là encore, ceci nécessiterait un
+ appel à stat() supplémentaire, ce qui n'est pas
+ acceptable.
+ Il n'est pas garanti que ce module fonctionne avec des noms de
+ fichiers réécrits par mod_alias ou
+ mod_rewrite.
MMapFile /usr/local/apache/htdocs/index.html+
Serveur HTTP Apache Version 2.4
+| Description: | Module de configuration de filtre intelligent sensible au +contexte |
|---|---|
| Statut: | Base |
| Identificateur de Module: | filter_module |
| Fichier Source: | mod_filter.c |
| Compatibilité: | Versions 2.1 et supérieures |
Ce module permet une configuration intelligente et dépendant du + contexte des filtres de contenu en sortie. Par exemple, Apache peut + être configuré pour faire traiter différents types de contenus par + différents filtres, même lorsque le type de contenu n'est pas connu + à l'avance (par exemple dans un serveur mandataire).
+ +Le fonctionnement de mod_filter consiste à
+ introduire des branchements dans la chaîne de filtrage. Plutôt que
+ d'insérer directement des filtres dans la chaîne, on insère un
+ sélecteur de filtre qui va effectuer un branchement conditionnel
+ vers un fournisseur de filtre. mod_filter peut
+ utiliser tout filtre de contenu comme fournisseur ; aucune
+ modification des modules de filtrage existants n'est nécessaire
+ (bien qu'il soit tout de même possible de les simplifier).
Filtrage intelligent Déclarations de filtres, fournisseurs et
+chaînes Configuration de la chaîne de
+filtrage Filtrage et statut de la réponse Mise à jour depuis une configuration du
+serveur HTTP Apache 2.2 Exemples Gestion de protocole AddOutputFilterByType FilterChain FilterDeclare FilterProtocol FilterProvider FilterTraceDans le modèle de filtrage traditionnel, les filtres sont insérés
+ sans condition à l'aide de la directive AddOutputFilter et des directives
+ apparentées. Chaque filtre doit ensuite déterminer s'il doit
+ s'exécuter ou non, et les administrateurs du serveur disposent de
+ peu de souplesse pour faire en sorte que la chaîne soit traitée de
+ manière dynamique.
mod_filter, à l'opposé, fournit aux
+ administrateurs du serveur un grand degré de souplesse pour
+ configurer la chaîne de filtrage. Concrètement, la décision
+ d'insérer un filtre peut être prise en fonction d'une expression booléenne complexe. Ceci
+ généralise le fonctionnement relativement souple de la directive
+ AddOutputFilterByType.
+ ![[Cette image illustre le modèle de filtrage traditionnel]](../images/mod_filter_old.gif)
+ Figure 1: Le modèle de filtrage traditionnel
Dans le modèle traditionnel, les filtres en sortie constituent + une simple chaîne s'étendant depuis le générateur de contenu (ou + gestionnaire) jusqu'au client. Ce fonctionnement peut convenir s'il + permet d'atteindre le but recherché, mais pose + problème lorsque cette chaîne doit être configurée dynamiquement en + fonction de la sortie du gestionnaire.
+ +
+ ![[Cette image illustre le modèle de fonctionnement de mod_filter]](../images/mod_filter_new.gif)
+ Figure 2: Le modèle de fonctionnement de
+ mod_filter
Le fonctionnement de mod_filter consiste à
+ introduire des branchements dans la chaîne de filtrage. Plutôt que
+ d'insérer directement des filtres dans la chaîne, on insère un
+ sélecteur de filtre qui va effectuer un branchement conditionnel
+ vers un fournisseur de filtre. mod_filter peut
+ utiliser tout filtre de contenu comme fournisseur ; aucune
+ modification des modules de filtrage existants n'est nécessaire
+ (bien qu'il soit tout de même possible de les simplifier). Il peut y
+ avoir plusieurs fournisseurs pour un seul filtre, mais un seul
+ fournisseur sera choisi pour chaque requête.
Une chaîne de filtrage peut comporter autant d'instances du + sélecteur de filtre que l'on souhaite, chacune d'entre elles pouvant + disposer de plusieurs fournisseurs. Un sélecteur de filtre possédant + un seul fournisseur dont le choix est inconditionnel constitue un + cas particulier : cette situation est équivalente à l'insertion + directe du filtre dans la chaîne.
+Trois étapes sont nécessaires pour configurer une chaîne de
+ filtrage avec mod_filter. Voir ci-dessous la
+ description détaillée des directives.
FilterDeclare permet de déclarer un
+ filtre en lui assignant un nom et un type. Elle n'est obligatoire
+ que si le filtre n'est pas du type par défaut
+ AP_FTYPE_RESOURCE.FilterProvider permet d'associer un
+ fournisseur à un filtre. Le filtre a été éventuellement déclaré à
+ l'aide de la directive FilterDeclare ; si ce n'est pas le cas, FilterProvider
+ va le déclarer implicitement avec le type par défaut
+ AP_FTYPE_RESOURCE. Le fournisseur doit avoir été enregistré à
+ l'aide de ap_register_output_filter par un module
+ quelconque. Le dernier argument de la directive FilterProvider est une expression :
+ le fournisseur s'exécutera pour une requête si et seulement si
+ l'expression est évaluée vraie. L'expression peut évaluer une
+ requête HTTP ou les en-têtes de la réponse, des variables
+ d'environnement, ou le gestionnaire utilisé par cette requête. À la
+ différence des version précédentes, mod_filter supporte désormais
+ les expressions complexes associant des critères multiples au moyen
+ d'une logique AND / OR (&& / ||) et de parenthèses. Pour les
+ détails sur la syntaxe de l'expression, voir la documentation sur ap_expr.FilterChain élabore une chaîne de filtrage à
+ partir de filtres intelligents déclarés, permettant avec souplesse
+ d'insérer des filtres au début ou à la fin de la chaîne, de
+ supprimer un filtre ou même la chaîne complète.Normalement, mod_filter n'applique les filtres qu'aux réponses
+ possédant un statut HTTP 200 (OK). Pour pouvoir filtrer des
+ documents possédant un autre statut, vous devez définir la variable
+ d'environnement filter-errordocs, les réponses étant
+ alors filtrées sans se préoccuper de leur statut. Pour définir ce
+ comportement de manière plus fine, vous pouvez utiliser des
+ conditions dans la directive
+ FilterProvider.
La directive FilterProvider a été modifiée par
+ rapport à httpd 2.2 : les arguments match et
+ dispatch ont été remplacés par l'argument unique
+ expression plus polyvalent. En général, il est possible
+ de convertir une paire match/dispatch vers les deux côtés d'une
+ expression, de la manière suivante :
"dispatch = 'match'"
Les en-têtes de requête et de réponse et les variables + d'environnement sont maintenant interprétés selon les syntaxes + respectives %{req:foo}, %{resp:foo} et + %{env:foo}. Les variables %{HANDLER} et + %{CONTENT_TYPE} sont également supportées.
+Notez que l'évaluation de l'expression ne supporte plus les + comparaisons de sous-chaînes. Ces dernières peuvent + être remplacées par des comparaisons d'expressions rationnelles.
+AddOutputFilterByType
+ FilterDeclare SSI
+FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|"
+FilterChain SSI
+
+ FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'"
+FilterChain SSI
+
+ FilterDeclare gzip CONTENT_SET
+FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/"
+FilterChain gzip
+
+ FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'"
+FilterProvider unpack gif_unpack "%{CONTENT_TYPE} = 'image/gif'"
+FilterProvider unpack png_unpack "%{CONTENT_TYPE} = 'image/png'"
+
+FilterProvider downsample downsample_filter "%{CONTENT_TYPE} = m|^image/(jpeg|gif|png)|"
+FilterProtocol downsample "change=yes"
+
+FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
+FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'"
+FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'"
+<Location "/image-filter">
+ FilterChain unpack downsample repack
+</Location>
+
+ Historiquement, tout filtre doit s'assurer que toute modification + qu'il effectue est correctement représentée dans les en-têtes de la + réponse HTTP, et qu'il ne s'exécutera pas si cette exécution + résultait en une modification interdite. Ceci impose aux auteurs de + filtres la corvée de réimplémenter certaines fonctionnalités + communes dans chaque filtre :
+ +Cache-Control: no-transform éventuel.mod_filter a pour but de gérer de manière
+ générale ces détails de l'implémentation des filtres, réduisant par
+ là-même la complexité des modules de filtrage de contenu. Le
+ travail permettant d'atteindre ce but est cependant toujours en
+ cours ; la directive FilterProtocol
+ implémente certaines de ces fonctionnalités à des fins de
+ compatibilité ascendante avec les modules d'Apache 2.0. Pour les
+ versions 2.1 et supérieures de httpd, les API
+ ap_register_output_filter_protocol et
+ ap_filter_protocol permettent aux modules de filtrage
+ de définir leurs propres comportements.
Cependant, mod_filter ne doit pas interférer
+ avec un filtre qui gère déjà tous les aspects du protocole. Par
+ défaut (c'est à dire en l'absence de toute directive FilterProtocol),
+ mod_filter ne modifiera donc pas les en-têtes.
Au moment où ces lignes sont écrites, cette fonctionnalité a été + très peu testée, car les modules d'usage courant ont été conçus pour + fonctionner avec httpd 2.0. Les modules qui l'utilisent devront donc + l'expérimenter avec précautions.
+| Description: | assigne un filtre en sortie pour un type de média +particulier |
|---|---|
| Syntaxe: | AddOutputFilterByType filtre[;filtre...]
+type_de_média [type_de_média] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_filter |
| Compatibilité: | Présentait de sévères limitations avant d'être déplacé dans
+mod_filter dans la version 2.3.7 |
Cette directive active un filtre en sortie particulier pour une + requête en fonction du type de média de la réponse.
+ +L'exemple suivant active le filtre DEFLATE qui est
+ fourni par le module mod_deflate. Il va compresser
+ toute sortie dont le type MIME est text/html ou
+ text/plain avant de l'envoyer au client.
AddOutputFilterByType DEFLATE text/html text/plain+ + +
Si vous voulez assigner plusieurs filtres au contenu, leurs noms
+ doivent être séparés par des points-virgules. On peut aussi utiliser
+ une directive AddOutputFilterByType pour
+ chacun des filtres à assigner.
La configuration ci-dessous impose le traitement de toute sortie
+ de script dont le type MIME est text/html en premier
+ lieu par le filtre INCLUDES, puis par le filtre
+ DEFLATE.
<Location "/cgi-bin/"> + Options Includes + AddOutputFilterByType INCLUDES;DEFLATE text/html +</Location>+ + + +
| Description: | Configure la chaîne de filtrage |
|---|---|
| Syntaxe: | FilterChain [+=-@!]nom_filtre ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Options |
| Statut: | Base |
| Module: | mod_filter |
Cette directive permet de configurer une chaîne de filtrage
+ composée de filtres déclarés. FilterChain
+ accepte un nombre illimité d'arguments, chacun d'entre eux étant
+ précédé d'un caractère de contrôle unique qui détermine l'action à
+ entreprendre :
+nom filtre@nom filtre-nom filtre=nom filtre!nom filtre+nom filtre| Description: | Déclare un filtre intelligent |
|---|---|
| Syntaxe: | FilterDeclare nom_filtre [type] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Options |
| Statut: | Base |
| Module: | mod_filter |
Cette directive permet de déclarer un filtre en sortie associé à
+ un en-tête ou une variable d'environnement qui déterminera les
+ conditions de son exécution. Le premier argument est le nom du
+ filtre destiné à être utilisé dans les directives FilterProvider, FilterChain et FilterProtocol.
Le dernier argument (optionnel) est le type du filtre, et peut
+ prendre les valeurs de ap_filter_type, à savoir
+ RESOURCE (valeur par défaut), CONTENT_SET,
+ PROTOCOL, TRANSCODE,
+ CONNECTION ou NETWORK.
| Description: | Vérifie le respect du protocole HTTP |
|---|---|
| Syntaxe: | FilterProtocol nom_filtre [nom_fournisseur]
+ drapeaux_protocole |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Options |
| Statut: | Base |
| Module: | mod_filter |
Cette directive permet à mod_filter de s'assurer
+ qu'un filtre ne s'exécutera pas s'il ne doit pas le faire, et que
+ les en-têtes de la réponse HTTP sont définis correctement en tenant
+ compte des effets du filtre.
Cette directive se présente sous deux formes. Avec trois + arguments, elle s'applique de manière spécifique à un nom + filtre et un nom fournisseur pour ce filtre. Avec + deux arguments, elle s'applique à un nom filtre pour + tout fournisseur qu'il actionne.
+ +Les drapeaux spécifiés sont fusionnés avec les drapeaux que les
+ fournisseurs sous-jacents ont éventuellement enregistrés avec
+ mod_filter. Par exemple, un filtre peut avoir
+ spécifié en interne un drapeau équivalent à change=yes,
+ mais une configuration particulière du module peut le surcharger
+ en spécifiant change=no.
+
drapeaux_protocole peut contenir un ou plusieurs + drapeaux parmi les suivants :
+ +change=yes|nochange=1:1byteranges=noproxy=noproxy=transformCache-Control: no-transformcache=no| Description: | Enregistre un filtre de contenu |
|---|---|
| Syntaxe: | FilterProvider nom_filtre nom_fournisseur
+ expression |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Options |
| Statut: | Base |
| Module: | mod_filter |
Cette directive permet d'associer un fournisseur au + filtre intelligent. Le fournisseur sera invoqué si et seulement si + l'expression est évaluée vraie lorsque le sélecteur de + filtre est appelé pour la première fois.
+ +
+ nom fournisseur doit avoir été enregistré au cours du
+ chargement d'un module à l'aide de
+ ap_register_output_filter.
+
expression est une expression ap_expr.
+ + +mod_include| Description: | Obtention d'informations de débogage/diagnostique en
+provenance de mod_filter |
|---|---|
| Syntaxe: | FilterTrace nom_filtre niveau |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_filter |
Cette directive permet d'obtenir des informations de débogage en
+ provenance de mod_filter. Elle est conçue pour
+ aider à tester et déboguer les fournisseurs (ou modules de filtrage)
+ ; elle peut aussi apporter une aide à l'utilisation de
+ mod_filter lui-même.
La sortie de débogage dépend de la définition d'argument + level :
+0 (valeur par défaut)1mod_filter va enregistrer les ensembles de
+ conteneurs de données (buckets and brigades) qui traversent le
+ filtre dans le journal des erreurs, avant que le fournisseur ne les
+ traite. Ces informations sont similaires à celles générées par mod_diagnostics.
+ 2 (pas encore implémenté)Serveur HTTP Apache Version 2.4
+| Description: | Personnalisation des en-têtes de requêtes et de réponses +HTTP |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | headers_module |
| Fichier Source: | mod_headers.c |
Ce module fournit des directives permettant de contrôler et + modifier les en-têtes de requêtes et de réponses HTTP. Les en-têtes + peuvent être fusionnés, remplacés ou supprimés.
+Les directives fournies par mod_headers peuvent
+ s'insérer presque partout dans la configuration du serveur, et on
+ peut limiter leur portée en les plaçant dans des sections de configuration.
La chronologie du traitement est importante et est affectée par + l'ordre d'apparition des directives dans le fichier de configuration + et par leur placement dans les sections de configuration. Ainsi, + ces deux directives ont un effet différent si leur ordre est inversé + :
+ +RequestHeader append MirrorID "mirror 12" +RequestHeader unset MirrorID+ + +
Dans cet ordre, l'en-tête MirrorID n'est pas défini.
+ Si l'ordre des directives était inversé, l'en-tête
+ MirrorID serait défini à "mirror 12".
mod_headers peut agir soir précocement, soit
+ tardivement au niveau de la requête. Le mode normal est le mode
+ tardif, lorsque les en-têtes de requête sont définis, immédiatement
+ avant l'exécution du générateur de contenu, et pour les en-têtes de
+ réponse, juste au moment où la réponse est envoyée sur le réseau.
+ Utilisez toujours le mode tardif sur un serveur en production.
Le mode précoce a été conçu à des fins d'aide aux tests et au
+ débogage pour les développeurs. Les directives définies en utilisant
+ le mot-clé early sont censées agir au tout début du
+ traitement de la requête. Cela signifie que l'on peut les utiliser
+ pour simuler différentes requêtes et définir des situations de test,
+ tout en gardant à l'esprit que les en-têtes peuvent être modifiés à
+ tout moment par d'autres modules avant que le réponse ne soit
+ générée.
Comme les directives précoces sont traitées avant que le
+ chemin de la requête ne soit parcouru, les en-têtes
+ précoces ne peuvent être définis que dans un contexte de serveur
+ principal ou de serveur virtuel. Les directives précoces ne peuvent
+ pas dépendre d'un chemin de requête, si bien qu'elles échoueront
+ dans des contextes tels que <Directory> ou <Location>.
Header echo ^TS+ +
mon-en-tête, qui
+ contient un horodatage permettant de déterminer le moment où la
+ requête a été reçue, et le temps qui s'est écoulé jusqu'à ce que
+ la requête ait commencé à être servie. Cet en-tête peut être
+ utilisé par le client pour estimer la charge du serveur ou
+ isoler les goulets d'étranglement entre le client et le
+ serveur.
+
+ Header set mon-en-tête "%D %t"+ + +
le résultat est l'ajout à la réponse d'un en-tête du type :
+ +
+ mon-en-tête: D=3775428 t=991424704447256
+
+ Header set mon-en-tête "Bonjour Joe. Il a fallu %D microsecondes \
+ à Apache pour servir cette requête."
+
le résultat est l'ajout à la réponse d'un en-tête du type :
+ +Header set MyHeader "Bonjour Joe. Il a fallu D=3775428 microsecondes à Apache + pour servir cette requête."+ +
mon-en-tête à la réponse si et
+ seulement si l'en-tête mon-en-tête-requête est
+ présent dans la requête. Ceci peut s'avérer utile pour générer
+ des en-têtes de réponse "à la tête du client". Notez que cet
+ exemple nécessite les services du module
+ mod_setenvif.
+
+ SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader +Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader+ + +
Si l'en-tête mon-en-tête-requête: mavaleur est
+ présent dans la requête HTTP, la réponse contiendra un en-tête
+ du type :
+ mon-en-tête: D=3775428 t=991424704447256 montexte
+
RequestHeader edit Destination ^https: http: early+ +
CGI,
+ NO_CACHE et NO_STORE existent pour la
+ requête) :
+
+ Header merge Cache-Control no-cache env=CGI +Header merge Cache-Control no-cache env=NO_CACHE +Header merge Cache-Control no-store env=NO_STORE+ + +
alors, la réponse contiendra l'en-tête suivant :
+ +
+ Cache-Control: no-cache, no-store
+
Si append avait été utilisé à la place de
+ merge, la réponse aurait contenu l'en-tête suivant
+ :
+ Cache-Control: no-cache, no-cache, no-store
+
Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"
+
+ Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"
+
+ | Description: | Configure les en-têtes d'une réponse HTTP |
|---|---|
| Syntaxe: | Header [condition] add|append|echo|edit|edit*|merge|set|setifempty|unset|note
+en-tête [[expr=]valeur
+[remplacement]
+[early|env=[!]variable|expr=expression]]
+ |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_headers |
| Compatibilité: | SetIfEmpty est disponible depuis la version 2.4.7 du +serveur HTTP Apache ; le paramètre expr=valeur a été introduit avec la +version 2.4.10 |
Cette directive permet de remplacer, fusionner, ou + supprimer des en-têtes de réponse HTTP. L'en-tête est modifié juste + après que le gestionnaire de contenu et les filtres en sortie ne + s'exécutent, ce qui permet la modification des en-têtes + sortants.
+ +L'argument optionnel condition permet de déterminer
+ sur quelle table interne d'en-têtes de réponses cette directive va
+ opérer. En dépit du nom, la valeur par défaut de
+ onsuccess ne limite pas une action
+ aux réponses avec un code d'état de 2xx. Les en-têtes définis sous
+ cette condition sont encore utilisés quand par exemple une requête
+ est mandatée ou générée par un programme CGI avec succès,
+ et ceci même dans le cas où ils ont généré un code d'échec.
Lorsque votre action est une fonction agissant sur un en-tête
+ existant, vous pourrez être amené à spécifier une condition
+ always, en fonction de la table interne dans laquelle
+ l'en-tête original a été défini. La table qui correspond à
+ always est utilisée pour les réponses d'erreur générées
+ localement ainsi que pour les réponses qui ont abouti.
+ Notez aussi que la répétition
+ de cette directive avec les deux conditions peut être pertinente
+ dans certains scénarios, car always n'englobe pas
+ onsuccess en ce qui concerne les en-têtes existants :
always est utilisée dans la réponse
+ définitive.always et non dans la table par
+ défaut.onsuccess.Outre le paramètre condition décrit ci-dessus, vous + pouvez limiter une action en fonction de codes d'état HTTP, par + exemple pour les requêtes mandatées ou générées par un programme + CGI. Voir l'exemple qui utilise %{REQUEST_STATUS} dans la section + ci-dessus.
+ +L'action que cette directive provoque est déterminée par le + premier argument (ou par le second argument si une + condition est spécifiée). Il peut prendre + une des valeurs suivantes :
+ +addset, append ou merge.appendechoeditedit*edit n'effectuera une
+ recherche/remplacement qu'une seule fois dans la valeur de
+ l'en-tête, alors que la forme edit* en effectuera autant
+ que le nombre d'apparition de la chaîne à remplacer.mergesetsetifemptysetifempty est évalué. Dans ce cas, il est
+ préférable d'utiliser set comme dans l'exemple suivant :
+ Header set Content-Type "text/plain" "expr=-z %{CONTENT_TYPE}"
+
+ unsetnoteCet argument est suivi d'un nom d'en-tête qui peut se
+ terminer par un caractère ':', mais ce n'est pas obligatoire. La
+ casse est ignorée avec set, append,
+ merge, add, unset et
+ edit. Le nom d'en-tête est sensible à la
+ casse pour echo et peut être une expression rationnelle.
Avec set, append, merge et
+ add, une valeur est spécifiée comme
+ argument suivant. Si valeur contient des espaces, elle
+ doit être entourée de guillemets. valeur peut être une
+ chaîne de caractères, une chaîne contenant des spécificateurs de
+ format propres à mod_headers (et des caractères
+ littéraux), ou une expression ap_expr
+ préfixée par expr=.
valeur supporte les spécificateurs de format suivants :
+ +| Format | Description |
|---|---|
%% |
+ Le caractère pourcentage |
%t |
+ Le moment de réception de la requête en temps
+ universel coordonné depuis le temps epoch (Jan. 1, 1970) et
+ exprimé en microsecondes. La valeur est précédée de
+ t=. |
%D |
+ Le temps écoulé entre la réception de la requête et l'envoi
+ des en-têtes sur le réseau. Il s'agit de la durée de traitement
+ de la requête. La valeur est précédée de D=. La
+ valeur est exprimée en microsecondes. |
%l |
+ La charge moyenne courante du serveur proprement dit. Ce
+ sont les valeurs obtenues par getloadavg() qui
+ représentent la charge moyenne courante, sur 5 minutes et sur 15
+ minutes. Chaque valeur est précédée de l= et
+ séparée de la suivante par un /.+ Disponible depuis la version 2.4.4 du serveur HTTP Apache. + |
%i |
+ Le pourcentage courant de httpd au repos (de 0 à 100)
+ en se basant sur le nombre de processus et threads disponibles.
+ La valeur est précédée de i=.+ Disponible depuis la version 2.4.4 du serveur HTTP Apache. + |
%b |
+ Le pourcentage courant de httpd utilisé (de 0 à 100)
+ en se basant sur le nombre de processus et threads disponibles.
+ La valeur est précédée de b=.+ Disponible depuis la version 2.4.4 du serveur HTTP Apache. + |
%{NOM_VARIABLE}e |
+ Le contenu de la variable
+ d'environnement NOM_VARIABLE. |
%{NOM_VARIABLE}s |
+ Le contenu de la variable
+ d'environnement SSL NOM_VARIABLE, si
+ mod_ssl est activé. |
Le spécificateur de format %s est disponible
+ depuis la version 2.1 d'Apache ; il peut être utilisé à la place
+ de %e pour éviter de devoir spécifier
+ SSLOptions +StdEnvVars. Cependant, si
+ SSLOptions +StdEnvVars doit tout de même être
+ spécifié pour une raison quelconque, %e sera plus
+ efficace que %s.
Lorsque le paramètre valeur utilise l'interpréteur ap_expr, certaines syntaxes d'expressions + seront différentes des exemples qui évaluent des expressions + booléennes telles que <If> :
+Header set foo-checksum "expr=%{md5:foo}"
+
+ editnécessite les deux arguments
+ valeur, qui est une expression
+ rationnelle, et une chaîne additionnelle
+ remplacement. Depuis la version 2.4.7, la chaîne de
+ remplacement peut aussi
+ contenir des spécificateurs de format.
La directive Header peut être suivie d'un
+ argument additionnel qui peut prendre les valeurs suivantes :
earlyenv=[!]variablevariable existe. Un ! devant
+ variable inverse le test, et la directive ne
+ s'appliquera alors que si variable n'est pas définie.expr=expression # Cet exemple retarde l'évaluation de la clause de condition par
+ # rapport à <If>
+ Header always set CustomHeader my-value "expr=%{REQUEST_URI} =~ m#^/special_path.php$#"
+
+ Excepté le cas du mode précoce, les
+ directives Header sont traitées juste avant
+ l'envoi de la réponse sur le réseau. Cela signifie qu'il est
+ possible de définir et/ou modifier la plupart des en-têtes, à
+ l'exception de certains en-têtes qui sont ajoutés par le filtre
+ d'en-tête HTTP. Avant la version 2.2.12, il n'était pas
+ possible de modifier l'en-tête Content-Type avec cette directive.
| Description: | Configure les en-têtes d'une requête HTTP |
|---|---|
| Syntaxe: | RequestHeader add|append|edit|edit*|merge|set|setifempty|unset
+en-tête [[expr=]valeur
+[remplacement]
+[early|env=[!]variable|expr=expression]]
+ |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_headers |
| Compatibilité: | SetIfEmpty est disponible depuis la version 2.4.7 du +serveur HTTP Apache ; le paramètre expr=valeur a été introduit avec la +version 2.4.10 |
Cette directive permet de remplacer, fusionner, modifier ou + supprimer des en-têtes de requête HTTP. L'en-tête est modifié juste + avant que le gestionnaire de contenu ne s'exécute, ce qui permet la + modification des en-têtes entrants. L'action effectuée est + déterminée par le premier argument. Ce dernier accepte les valeurs + suivantes :
+ +addset, append ou merge.appendeditedit*edit, la chaîne de l'en-tête correspondant au modèle ne
+ sera recherchée et remplacée qu'une seule fois, alors qu'avec
+ edit*, elle le sera pour chacune de ses instances si
+ elle apparaît plusieurs fois.mergesetsetifemptyunsetCet argument est suivi d'un nom d'en-tête qui peut se terminer
+ par un caractère ':', mais ce n'est pas obligatoire. La casse est
+ ignorée. Avec set, append,
+ merge et add, une valeur est
+ fournie en troisième argument. Si une valeur contient des
+ espaces, elle doit être entourée de guillemets. Avec
+ unset, aucune valeur ne doit apparaître.
+ valeur peut être une chaîne de caractères, une chaîne
+ contenant des spécificateurs de format, ou une combinaison des deux.
+ Les spécificateurs de format supportés sont les mêmes que ceux de la
+ directive Header, à
+ laquelle vous pouvez vous reporter pour plus de détails. Avec
+ edit, les deux arguments valeur et
+ remplacement sont obligatoires, et correspondent
+ respectivement à une expression
+ rationnelle et à une chaîne de remplacement.
La directive RequestHeader peut être
+ suivie d'un argument supplémentaire, qui pourra prendre les valeurs
+ suivantes :
earlyenv=[!]variablevariable existe. Un ! devant
+ variable inverse le test, et la directive ne
+ s'appliquera alors que si variable n'est pas définie.expr=expressionExcepté le cas du mode précoce, la directive
+ RequestHeader est traitée juste avant la
+ prise en compte de la requête par son gestionnaire, au cours de la
+ phase de vérification. Ceci permet la modification des en-têtes
+ générés par le navigateur, ou par les filtres en entrée
+ d'Apache.
Serveur HTTP Apache Version 2.4
+| Description: | Envoie des messages d'état au mandataire frontal |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | heartbeat_module |
| Fichier Source: | mod_heartbeat |
| Compatibilité: | Disponible à partir de la version 2.3 +du serveur HTTP Apache |
mod_heartbeat envoie à un moniteur
+ mod_heartmonitor des messages multicast l'informant
+ du nombre de connexions courantes. En général,
+ mod_heartmonitor est chargé sur un serveur
+ mandataire où mod_lbmethod_heartbeat est chargé, ce
+ qui permet d'utiliser la lbmethod "heartbeat" au sein des
+ directives ProxyPass.
+ Le module mod_heartbeat est chargé sur le
+ serveur d'origine qui sert les requêtes via le
+ serveur mandataire.
+
mod_heartbeat,
+ mod_status et mod_watchdog
+ doivent être soit des modules statiques, soit des modules
+ dynamiques, et dans ce dernier cas, ils doivent être chargés
+ avant mod_heartbeat.
+ + Chaque seconde, ce module génère un paquet multicast UDP contenant + le nombre de threads/processus occupés et en attente. Le paquet + possède un format ASCII simple similaire aux paramètres de requête + GET en HTTP. +
+ +
+v=1&ready=75&busy=0
+
+ Les utilisateurs disposeront dans le futur de nouvelles variables en + plus de busy et ready, et toujours séparées par des '&'. +
+ +| Description: | Adresse multicast à laquelle envoyer les requêtes +heartbeat |
|---|---|
| Syntaxe: | HeartbeatAddress addr:port |
| Défaut: | disabled |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_heartbeat |
La directive HeartbeatAddress permet de
+ spécifier l'adresse multicast à laquelle mod_heartbeat va
+ envoyer ses informations. En général, cette adresse correspond à la
+ valeur définie par la directive HeartbeatListen sur le serveur
+ mandataire frontal.
HeartbeatAddress 239.0.0.1:27999+ + +
Serveur HTTP Apache Version 2.4
+| Description: | Moniteur centralisé pour les serveurs d'origine mod_heartbeat |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | heartmonitor_module |
| Fichier Source: | mod_heartmonitor.c |
| Compatibilité: | Disponible depuis la version 2.3 d'Apache |
+mod_heartmonitor interprète les messages d'état générés
+par les serveurs d'origine pour lesquels mod_heartbeat est activé et
+fournit ces informations à mod_lbmethod_heartbeat, ce
+qui permet d'utiliser la lbmethod "heartbeat" au sein des
+directives ProxyPass.
+
Ce module utilise les services de mod_slotmem_shm,
+lorsqu'il est disponible, au lieu d'un simple fichier texte. Aucune
+configuration supplémentaire n'est requise pour utiliser
+mod_slotmem_shm.
mod_heartmonitor,
+ mod_status et mod_watchdog
+ doivent être soit des modules statiques, soit des modules
+ dynamiques, et dans ce dernier cas, ils doivent être chargés
+ avant mod_heartmonitor.
+ | Description: | Adresse multicast d'écoute des requêtes entrantes heartbeat |
|---|---|
| Syntaxe: | HeartbeatListen addr:port |
| Défaut: | disabled |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_heartmonitor |
La directive HeartbeatListen permet de
+ spécifier l'adresse multicast sur laquelle le serveur va surveiller les
+ informations d'état en provenance de serveurs où
+ mod_heartbeat est activé. Cette adresse correspond
+ en général à la valeur de la directive HeartbeatAddress sur le serveur
+ d'origine.
+
HeartbeatListen 239.0.0.1:27999+ + +
Tant que cette directive n'est pas utilisée, le module est + désactivé.
+ +| Description: | Spécifie le nombre maximal de serveurs qui pourront envoyer +des requêtes heartbeat à ce serveur. |
|---|---|
| Syntaxe: | HeartbeatMaxServers nombre-de-serveurs |
| Défaut: | HeartbeatMaxServers 10 |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_heartmonitor |
La directive HeartbeatMaxServers
+ spécifie le nombre maximal de serveurs qui pourront envoyer des
+ requêtes heartbeat à ce serveur de monitoring. Elle permet ainsi de
+ contrôler la quantité de mémoire partagée allouée pour le stockage
+ des données heartbeat lorsqu'on utilise
+ mod_slotmem_shm.
| Description: | Chemin vers le stockage des données heartbeat |
|---|---|
| Syntaxe: | HeartbeatStorage chemin fichier |
| Défaut: | HeartbeatStorage logs/hb.dat |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_heartmonitor |
La directive HeartbeatStorage permet de
+ spécifier le chemin de stockage des données heartbeat. Ce fichier
+ texte n'est utilisé que si mod_slotmem_shm n'est
+ pas chargé.
Serveur HTTP Apache Version 2.4
+| Description: | Support de la couche transport HTTP/2 |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | http2_module |
| Fichier Source: | mod_http2.c |
| Compatibilité: | Disponible à partir de la version 2.4.17 du serveur + HTTP Apache |
Ce module ajoute le support de HTTP/2 (RFC 7540) au serveur HTTP + Apache.
+ +Il s'appuie sur la bibliothèque libnghttp2 pour implémenter le + moteur de base http/2.
+ +Pour mettre en oeuvre les fonctionnalités décrites dans ce
+ document, vous devez activer HTTP/2 en utilisant la directive
+ Protocols. HTTP/2 n'imposant
+ pas de chiffrement, deux protocoles sont disponibles :
+ h2 (HTTP/2 avec TLS) at h2c (HTTP/2 avec TCP).
Voici deux types de configuration courant :
+ +Protocols h2 http/1.1+ +
Permet une négociation HTTP/2 (h2) via TLS ALPN au sein d'un
+ <VirtualHost>
+ sécurisé. La vérification du préambule HTTP/2 (mode direct, voir
+ H2Direct) est désactivée par
+ défaut pour h2.
Protocols h2 h2c http/1.1+ +
Permet une négociation HTTP/2 (h2) via TLS ALPN au sein d'un
+ <VirtualHost>
+ sécurisé. Permet aussi une négociation HTTP/2 en texte pur (h2c) en
+ effectuant une mise à jour depuis une connexion initiale HTTP/1.1 ou via
+ une vérification du préambule HTTP/2 (mode direct, voir
+ H2Direct).
Si vous avez besoin d'informations supplémentaires à propos du + protocole, veuillez vous reporter à la HTTP/2 FAQ.
+ + + H2CopyFiles H2Direct H2EarlyHints H2MaxSessionStreams H2MaxWorkerIdleSeconds H2MaxWorkers H2MinWorkers H2ModernTLSOnly H2Push H2PushDiarySize H2PushPriority H2PushResource H2SerializeHeaders H2StreamMaxMemSize H2TLSCoolDownSecs H2TLSWarmUpSize H2Upgrade H2WindowSize+ Activer HTTP/2 sur votre serveur Apache a un impact sur la + consommation de ressources, et si votre site est très actif, il est + conseillé d'en prendre sérieusement en compte les implications. +
++ HTTP/2 attribue à chaque requête qu'il reçoit son propre thread + de travail pour son traitement, la collecte des résultats et + l'envoie de ces derniers au client. Pour y parvenir, il lui faut + lancer des threads supplémentaires, et ceci constituera le premier + effet notable de l'activation de HTTP/2. +
+
+ Dans l'implémentation actuelle, ces threads de travail font partie
+ d'un jeu de threads distinct de celui des threads de travail du MPM
+ avec lequel vous êtes familié. Il s'agit simplement du mode de
+ fonctionnement actuel, et il n'en sera pas obligatoirement toujours
+ ainsi (il est cependant probable que la situation restera inchangée
+ avec la version 2.4.x). De par ce mode de fonctionnement, les
+ threads de travail HTTP/2, ou plus simplement H2 ne seront pas
+ affichés par mod_status. De même, ils ne seront pas
+ pris en compte par les directives du style ThreadsPerChild. Par contre, ils
+ utilisent par défaut la valeur de ThreadsPerChild si vous n'avez pas
+ spécifié d'autres valeurs via H2MinWorkers et H2MaxWorkers.
+
+ Autre changement à surveiller : la consommation de mémoire. En
+ effet, comme HTTP/2 conserve plus d'informations sur le serveur pour
+ gérer toutes les requêtes en cours, leurs priorités et
+ interdépendances, il aura toujours besoin de plus de mémoire que
+ pour un traitement en HTTP/1.1. Trois directives permettent de
+ limiter l'empreinte mémoire d'une connexion HTTP/2 : H2MaxSessionStreams, H2WindowSize et H2StreamMaxMemSize.
+
+ La directive H2MaxSessionStreams permet de limiter
+ le nombre de requêtes simultanées qu'un client peut envoyer sur une
+ connexion HTTP/2. La valeur que vous allez définir dépend de votre
+ site. La valeur par défaut qui est de 100 est largement suffisante,
+ et à moins que vous ne soyez un peu juste en mémoire, je vous
+ conseille de ne pas la modifier. La plupart des requêtes qu'envoie
+ un client sont des requêtes de type GET sans corps qui n'utilisent
+ que très peu de mémoire en attendant le démarrage du traitement.
+
+
+ La directive H2WindowSize
+ permet de définir la taille maximale que peut avoir le corps d'une
+ requête que le client envoie avant d'attendre que le serveur
+ en demande d'avantage. En d'autres termes, il s'agit de la quantité
+ de données que le serveur peut stocker dans son tampon, valable pour
+ une requête.
+
+ En outre, la directive H2StreamMaxMemSize permet de définir
+ la quantité de données de la réponse qui doit être mise en tampon.
+ Chaque requête étant prise en charge par un thread H2Worker et
+ produisant des données que le serveur tente de transmettre au client
+ via une connexion HTTP/2, si le client n'est pas en mesure de lire
+ ces données assez rapidement, la connexion les mettra en tampon et
+ interrompra l'exécution du thread H2Worker correspondant.
+
+ De nombreux site utilisent le même certificat TLS pour plusieurs + serveurs virtuels. Ce certificat référence un nom de serveur + générique comme '*.example.org' ou plusieurs noms de serveur + différents. Les navigateurs qui utilisent HTTP/2 détectent ce + comportement et réutilisent une connexion déjà ouverte pour ces + serveurs. +
++ Ceci améliore considérablement les performances, mais il y a un prix + à payer : il faut accorder un soin tout particulier à la + configuration de tels serveurs virtuels. Le problème réside dans le + fait que plusieurs requêtes pour plusieurs serveurs virtuels vont se + partager la même connexion TLS, et ceci empêche toute renégociation + car le standard HTTP/2 l'interdit. +
++ Ainsi, lorsque plusieurs de vos serveurs virtuels utilisent le même + certificat et si vous souhaitez utiliser HTTP/2 pour y accéder, vous + devez vous assurer que tous vos serveurs virtuels possèdent + exactement la même configuration SSL. En particulier, ils doivent + utiliser les mêmes protocole, algorithme de chiffrement et + configuration pour la vérification du client. +
++ Dans le cas contraire, Apache httpd le détectera et renverra au + client un code de réponse spécial, 421 Misdirected Request. +
+ + +Ce module peut être configuré pour fournir des informations en
+ rapport avec HTTP/2 sous la forme de variables d'environnement
+ supplémentaires dans l'espace de nommage SSI et CGI, ainsi que dans les
+ configurations personnalisées de le journalisation (voir
+ %{VAR_NAME}e).
+
| Nom variable : | +Type : | +Description : | +
|---|---|---|
HTTPe | drapeau | HTTP/2 est utilisé. |
H2PUSH | drapeau | La + fonctionnalité HTTP/2 Server Push est activée pour cette requête et + supportée par le client. |
H2_PUSH | drapeau | autre nom pour H2PUSH |
H2_PUSHED | chaîne | vide ou
+ PUSHED pour une requête pushée par le serveur. |
H2_PUSHED_ON | nombre | numéro du + flux HTTP/2 qui a déclenché le push de cette requête. |
H2_STREAM_ID | nombre | numéro du + flux HTTP/2 de cette requête. |
H2_STREAM_TAG | chaîne | identifiant
+ de flux unique du processus HTTP/2 composé de l'identifiant de la
+ connexion et de l'identifiant du flux séparés par -. |
| Description: | Contrôle la gestion des fichiers dans les réponses |
|---|---|
| Syntaxe: | H2CopyFiles on|off |
| Défaut: | H2CopyFiles off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_http2 |
| Compatibilité: | Disponible à partir de la version 2.4.24 du serveur HTTP + Apache. |
+ Cette directive permet de définir la manière de gérer les
+ contenus de fichiers dans les réponses. Lorsqu'elle est à off
+ (sa valeur par défaut), les descripteurs de fichiers sont
+ transmis par le processus de traitement de la requête vers la
+ connexion principale en utilisant le système habituel de mise en
+ réserve d'Apache pour gérer le durée de vie du fichier.
+
+ Lorsqu'elle est à on, le contenu du fichier est
+ recopier pendant le traitement de la requête et ces données
+ mises en tampon sont transmises vers la connexion principale, ce
+ qui s'avère avantageux lorsqu'un module tiers injecte dans la
+ réponse des fichiers possédant des durées de vie différentes.
+
+ Un exemple de ces modules tiers : mod_wsgi qui peut
+ injecter des descripteurs de fichiers dans la réponse. Ces
+ fichiers sont fermés lorsque Python estime que le traitement est
+ terminé, alors que mod_http2 est probablement
+ encore loin d'en avoir fini avec eux.
+
| Description: | Activation du protocole H2 Direct |
|---|---|
| Syntaxe: | H2Direct on|off |
| Défaut: | H2Direct on pour h2c, off pour le protocole h2 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
+ Cette directive permet d'activer/désactiver
+ l'utilisation du mode HTTP/2 Direct. Elle doit être
+ située dans une section <VirtualHost> afin d'activer la
+ communication directe HTTP/2 pour le serveur virtuel
+ considéré.
+
+ La notion de communication directe signifie que si les + premiers octets reçus par le serveur correspondent à un + en-tête HTTP/2, le protocole HTTP/2 est utilisé sans + négociation supplémentaire. Ce mode est défini pour + les transmissions en clair (h2c) dans la RFC 7540. Son + utilisation avec les connexions TLS n'est pas + officiellement supportée. +
+
+ Lorsque le protocole h2 ou h2c n'est pas activé via la
+ directive Protocols, la recherche d'un en-tête HTTP/2 n'est
+ jamais effectuée au sein d'une connexion. La directive
+ H2Direct ne produit alors aucun effet. Ceci est
+ important pour les connexions qui utilisent un protocole
+ pour lequel une lecture initiale peut entraîner un
+ blocage définitif comme NNTP.
+
+ Pour un client qui sait qu'un serveur supporte h2c, la + communication directe HTTP/2 dispense le client d'une + mise à jour HTTP/1.1, ce qui entraîne une amélioration + des performances et évite les restrictions sur les corps + de requête suite à une mise à jour. +
++ Cette directive rend aussi h2c plus attractif pour les + communications de serveur à serveur lorsque la connexion + est sure ou peut être sécurisée d'une manière ou d'une + autre. +
+H2Direct on+
| Description: | Contrôle l'envoi de codes d'état 103 |
|---|---|
| Syntaxe: | H2EarlyHints on|off |
| Défaut: | H2EarlyHints off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
| Compatibilité: | Disponible à partir de la version 2.4.24 du serveur HTTP + Apache. |
+ Cette directive permet de définir si les réponses intermédiaires + contenant un code d'état HTTP 103 doivent être envoyées au + client ou non. Par défaut ce n'est actuellement pas le cas car + certains clients ont encore des problèmes avec les réponses + intermédiaires inattendues. +
+
+ Lorsque cette directive est définie à on, les
+ ressources PUSHées définie par la directive
+ H2PushResource déclenchent une réponse
+ intermédiaire 103 avant la réponse finale. Cette réponse 103
+ comporte des en-têtes Link qui provoquent le
+ préchargement des ressources considérées.
+
| Description: | Nombre maximal de flux actifs par session HTTP/2. |
|---|---|
| Syntaxe: | H2MaxSessionStreams n |
| Défaut: | H2MaxSessionStreams 100 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
+ Cette directive permet de définir le nombre maximal de flux
+ actifs par session (connexion) HTTP/2 accepté par le serveur.
+ Selon la RFC 7540, un flux est considéré comme actif s'il n'est
+ ni en attente ni fermé.
+
H2MaxSessionStreams 20+
| Description: | Nombre maximal de secondes pendant lequel une unité de + traitement h2 pourra rester inactive sans être arrêtée. |
|---|---|
| Syntaxe: | H2MaxWorkerIdleSeconds n |
| Défaut: | H2MaxWorkerIdleSeconds 600 |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_http2 |
+ Cette directive permet de définir le nombre maximal de secondes
+ pendant lequel une unité de traitement h2 pourra rester inactive
+ avant de s'arrêter elle-même. Cet arrêt ne peut cependant se
+ produire que si le nombre d'unités de traitement h2 dépasse
+ H2MinWorkers.
+
H2MaxWorkerIdleSeconds 20+
| Description: | Nombre maximal de threads à utiliser pour chaque processus + enfant. |
|---|---|
| Syntaxe: | H2MaxWorkers n |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_http2 |
+ Cette directive permet de définir le nombre maximal de threads à
+ lancer pour le traitement HTTP/2 de chaque processus enfant. Si
+ cette directive n'est pas définie, mod_http2
+ choisira une valeur appropriée en fonction du module mpm
+ utilisé.
+
+ This directive sets the maximum number of worker threads to spawn
+ per child process for HTTP/2 processing. If this directive is not used,
+ mod_http2 will chose a value suitable for the mpm
+ module loaded.
+
H2MaxWorkers 20+
| Description: | Nombre minimal de threads à utiliser pour chaque processus + enfant. |
|---|---|
| Syntaxe: | H2MinWorkers n |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_http2 |
+ Cette directive permet de définir le nombre minimal de threads à
+ lancer pour le traitement HTTP/2 de chaque processus enfant. Si
+ cette directive n'est pas définie, mod_http2
+ choisira une valeur appropriée en fonction du module mpm
+ utilisé.
+
H2MinWorkers 10+
| Description: | Impose les connexions HTTP/2 en mode "TLS moderne" + seulement |
|---|---|
| Syntaxe: | H2ModernTLSOnly on|off |
| Défaut: | H2ModernTLSOnly on |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
| Compatibilité: | Disponible à partir de la version 2.4.18 du serveur HTTP + Apache. |
+ Cette directive permet de définir si les vérifications de
+ sécurité sur les connexions HTTP/2 doivent être exclusivement en
+ mode TLS (https:). Elle peut être placée au niveau du serveur
+ principal ou dans une section <VirtualHost>.
+
+ Les vérifications de sécurité nécessitent TLSv1.2 au minimum et + l'absence de tout algorithme de chiffrement listé dans la RFC + 7540, Appendix A. Ces vérifications seront étendues lorsque de + nouveaux prérequis en matière de sécurité seront mis en place. +
++ Le nom provient des définitions Mozilla Security/Server + Side TLS où il est question de "modern compatibility". + Mozilla Firefox et d'autres navigateurs imposent la "modern + compatibility" pour les connexions HTTP/2. Comme toute chose en + matière de sécurité opérationnelle, c'est une cible mouvante + susceptible d'évoluer dans le futur. +
+
+ Un des buts de ces vérifications dans mod_http2 tend à imposer
+ ce niveau de sécurité pour toutes les connexions, et non
+ seulement celles en provenance des navigateurs web. Un autre but
+ est l'interdiction d'utiliser HTTP/2 en tant que protocole dans
+ les négociations si les prérequis ne sont pas respectés.
+
+ En fin de compte, la sécurité de la connexion TLS est déterminée
+ par les directives de configuration du serveur pour mod_ssl.
+
H2ModernTLSOnly off+
| Description: | Activation/désactivation du server push H2 |
|---|---|
| Syntaxe: | H2Push on|off |
| Défaut: | H2Push on |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
| Compatibilité: | Disponible à partir de la version 2.4.18 du serveur HTTP + Apache. |
+ Cette directive permet d'activer/désactiver + l'utilisation de la fonctionnalité server push du + protocole HTTP/2. +
++ Lorsqu'un client demande une ressource particulière, le + protocole HTTP/2 permet au serveur de lui fournir des + ressources supplémentaires. Ceci s'avère utile lorsque + ces ressources sont reliées entre elles, ce qui peut + laisser supposer que le client va probablement les + demander dans un délai plus ou moins long. Le mécanisme + de pushing permet alors au client d'économiser le temps + qu'il lui aurait fallu pour demander ces ressources + supplémentaires lui-même. Par contre, fournir au client + des ressources dont il n'a pas besoin ou qu'il possède + déjà constitue une perte de bande passante. +
+
+ Les server pushes sont détectés en inspectant les
+ en-têtes Link des réponses (voir
+ https://tools.ietf.org/html/rfc5988 pour la
+ spécification). Lorsqu'un lien spécifié de cette manière
+ possède l'attribut rel=preload, il est
+ considéré comme devant faire l'objet d'un push.
+
+ Les en-têtes link des réponses sont soit définis par
+ l'application, soit configurés via
+ mod_headers comme suit :
+
<Location /index.html> + Header add Link "</css/site.css>;rel=preload" + Header add Link "</images/logo.jpg>;rel=preload" +</Location>+
+ Comme le montre l'exemple, il est possible d'ajouter + autant d'en-têtes link que l'on souhaite à une réponse, ce qui déclenchera + autant de pushes. Cette fonctionnalité doit donc être + utilisée avec prudence car le module ne vérifie pas si + une ressource n'a pas déjà été "pushée" vers un client. +
++ Les server pushes HTTP/2 sont activés par défaut. Cette + directive permet de désactiver cette fonctionnalité pour + le serveur virtuel ou non considéré. +
+H2Push off+
+ Enfin, il est important de savoir que les pushes ne se + produisent que si le client en manifeste le désir ; la + plupart des navigateurs le font, mais certains, comme + Safari 9, ne le font pas. En outre, les pushes ne se produisent que + pour les ressources de la même autorité que celle de la + réponse originale. +
+ +| Description: | Taille du journal des Pushes H2 |
|---|---|
| Syntaxe: | H2PushDiarySize n |
| Défaut: | H2PushDiarySize 256 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
| Compatibilité: | Disponible à partir de la version 2.4.19 du serveur HTTP + Apache. |
+ Cette directive permet de définir le nombre maximum de pushes
+ qui seront enregistrés pour une connexion HTTP/2. Elle peut être
+ placée dans une section <VirtualHost> afin de définir le nombre
+ de pushes pour le serveur virtuel considéré.
+
+ Le journal des pushes enregistre un condensé (sous la forme d'un + nombre de 64 bits) des ressources préchargées (leurs URLs) afin + d'éviter les duplications de pushes pour une même connexion. + Cependant, ces données ne sont pas conservées, et les clients + qui ouvrent une nouvelle connexion se verront à nouveau affecter les + mêmes pushes. A ce titre, une étude est en cours pour permettre + au client de supprimer le condensé des ressources qu'il possède + déjà, et par là-même de réinitialiser le journal des pushes à + chaque nouvelle connexion. +
++ Si la taille maximale est atteinte, les nouvelles entrées + remplacent les plus anciennes. Une entrée du journal nécessitant + 8 octets, un journal de 256 entrées consomme 2 Ko de mémoire. +
++ Si cette directive est définie à 0, le journal des pushes est + désactivé. +
+ +| Description: | Priorité des pushes H2 |
|---|---|
| Syntaxe: | H2PushPriority mime-type [after|before|interleaved] [weight] |
| Défaut: | H2PushPriority * After 16 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
| Compatibilité: | Disponible à partir de la version 2.4.18 du serveur HTTP + Apache. Nécessite la bibliothèque nghttp2 version 1.5.0 ou supérieure. |
+ Cette directive permet de définir une gestion de priorité des + pushes en fonction du type de contenu de la réponse. Elle est en + général définie au niveau du serveur principal, mais peut aussi + l'être au niveau d'un serveur virtuel. +
++ Les pushes HTTP/2 sont toujours liés à une requête client. + Chaque paire requête/réponse de cette sorte, ou flux, + possède une dépendance et un poids qui définissent la + priorité du flux. +
++ Lorsqu'un flux dépend d'un autre, disons X dépend de Y, + alors Y reçoit toute la bande passante avant que X n'en reçoive + ne serait-ce qu'une partie. Notez que cela ne signifie en rien + que Y bloque X ; en effet, si Y n'a aucune donnée à envoyer, + toute la bande passante qui lui est allouée peut être utilisée + par X. +
++ Lorsque plusieurs flux dépendent d'un même autre flux, disons X1 + et X2 dépendent tous deux de Y, le poids détermine la + bande passante allouée. Ainsi, si X1 et X2 possèdent le même + poids, ils recevront tous deux la moitié de la bande passante + disponible. Si le poids de X1 est égal au double de celui de X2, + X1 recevra une bande passante double de celle de X2. + +
++ En fin de compte, tout flux dépend du flux racine qui + reçoit toute la bande passante disponible mais n'envoie jamais + de données. Cette bande passante est ainsi répartie entre les flux + enfants selon leur poids. Ces derniers l'utilisent alors pour + envoyer leurs données ou pour la répartir entre leurs propres + flux enfants, et ainsi de suite. Si aucun des flux enfants n'a + de données à envoyer, la bande passante est attribuée à d'autres + flux selon les mêmes règles. +
++ Ce système de priorités a été conçu de façon a toujours pouvoir + utiliser la bande passante disponible tout en définissant des + priorités et en attribuant des poids aux différents flux. Ainsi, + tous les flux sont en général initialisés par le client qui + lui-même définit les priorités. +
++ Seul le fait de savoir qu'un flux implique un PUSH permet au + serveur de décider quelle est la priorité initiale d'un + tel flux. Dans les exemples ci-dessous, X est le flux client. Il + dépend de Y et le serveur décide de "PUSHer" les flux P1 et P2 + sur X. +
++ La règle de priorité par défaut est : +
+H2PushPriority * After 16+
+ Elle peut se traduire par "Envoyer un flux PUSH avec tout type + de contenu et dépendant du flux client avec le poids 16". P1 et + P2 seront alors envoyés après X, et comme leurs poids sont + identiques, il se verront allouer la même quantité de bande + passante. +
+H2PushPriority text/css Interleaved 256+
+ Ce qui peut se traduire par "Envoyer toute ressource CSS dans la
+ même dépendance et avec le même poids que le flux client". Si le
+ type de contenu de P1 est "text/css", il dépendra de Y (comme X)
+ et son poids effectif sera calculé selon la formule : P1ew
+ = Xw * (P1w / 256). Si P1w est de 256, Le poids effectif
+ de P1 sera le même que celui de X. Si X et P1 ont des données à
+ envoyer, il se verront allouer la même quantité de bande
+ passante.
+
+ Avec un Pw de 512, un flux entrelacé et PUSHé aura un poids + double de celui de X. Avec un poids de 128, son poids ne sera + que la moitié de celui de X. Notez que les poids effectifs sont + toujours plafonnés à 256. + +
+H2PushPriority application/json Before+
+ Dans cet exemple, tout flux PUSHé dont le contenu est de type + 'application/json' sera envoyé avant X, ce qui rend P1 + dépendant de Y et X dépendant de P1. Ainsi, X sera mis en + attente aussi longtemps que P1 aura des données à envoyer. Le + poids effectif est hérité du flux client, et l'attribution d'un + poids spécifique n'est pas autorisée. +
++ Vous devez garder à l'esprit que les spécifications en matière + de priorités sont limitées par les ressources disponibles du + serveur. Si un serveur ne dispose d'aucun processus/thread de + travail pour les flux PUSHés, les données du flux considéré ne + seront envoyées que lorsque les autres flux auront terminé + l'envoi des leurs. +
++ Enfin et surtout, il convient de tenir compte de certaines + particularités de la syntaxe de cette directive : +
+H2PushPriority application/json 32 # une règle de priorité 'After' +H2PushPriority image/jpeg before # poid hérité +H2PushPriority text/css interleaved # poids de 256 par défaut+
| Description: | Déclare des ressources à proposer ("pusher") au client |
|---|---|
| Syntaxe: | H2PushResource [add] path [critical] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_http2 |
| Compatibilité: | Disponible à partir de la version 2.4.24 du serveur HTTP + Apache. |
+ Lorsqu'il sont activés pour un répertoire, les PUSHes HTTP/2 seront + tentés pour tous les chemins ajoutés via cette directive. Cette + dernière peut être utilisée plusieurs fois pour le même + répertoire. +
+
+ Cette directive propose des ressources beaucoup plus tôt que les
+ en-têtes Link de mod_headers.
+ mod_http2 présente ces ressources au client via
+ une réponse intermédiaire 103 Early Hints. Ceci
+ implique que les clients qui ne supportent pas PUSH recevront
+ quand-même rapidement des propositions de préchargement.
+
+ A la différence de la définition d'en-têtes de réponse
+ Link via mod_headers, cette
+ directive n'aura d'effet que pour les connexions HTTP/2.
+
+ En ajoutant l'option critical à une telle
+ ressource, le serveur la traitera prioritairement, et une fois
+ les données disponibles, ces dernières seront envoyées avant les
+ données de la requête principale.
+
| Description: | Active/désactive la sérialisation du traitement des + requêtes/réponses |
|---|---|
| Syntaxe: | H2SerializeHeaders on|off |
| Défaut: | H2SerializeHeaders off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
+ Cette directive permet de définir si les requêtes HTTP/2 doivent
+ être sérialisées au format HTTP/1.1 pour être traitées par le
+ noyau de httpd, ou si les données binaires reçues
+ doivent être passées directement aux request_recs.
+
+ La sérialisation dégrade les performances, mais garantit une + meilleure compatibilité ascendante lorsque des filtres ou + programmes accroche personnalisés en ont besoin. +
+H2SerializeHeaders on+
| Description: | Quantité maximale de données en sortie mises en tampon par + flux. |
|---|---|
| Syntaxe: | H2StreamMaxMemSize bytes |
| Défaut: | H2StreamMaxMemSize 65536 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
+ Cette directive permet de définir la quantité maximale de + données en sortie mises en tampon mémoire pour un flux actif. Ce + tampon mémoire n'est pas alloué pour chaque flux en tant que + tel. Les quantités de mémoire sont définies en fonction de + cette limite lorsqu'elles sont sur le point d'être allouées. Le + flux s'arrête lorsque la limite a été atteinte, et ne reprendra + que lorsque les données du tampon auront été transmises au + client. +
+H2StreamMaxMemSize 128000+
| Description: | |
|---|---|
| Syntaxe: | H2TLSCoolDownSecs seconds |
| Défaut: | H2TLSCoolDownSecs 1 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
| Compatibilité: | Disponible à partir de la version 2.4.18 du serveur HTTP + Apache. |
+ Cette directive permet de spécifier le nombre de secondes avant
+ lequel une connexion TLS inactive va diminuer
+ la taille des paquets de données à une valeur inférieure (~1300
+ octets). Elle peut être définie au niveau du serveur principal
+ ou pour un <serveur
+ virtuel> spécifique.
+
+ Voir la directive H2TLSWarmUpSize pour une description
+ du "préchauffage" de TLS. La directive H2TLSCoolDownSecs met en
+ lumière le fait que les connexions peuvent se détériorer au bout
+ d'un certain temps (et au fur et à mesure des corrections du
+ flux TCP), et cela même si elle sont inactives. Pour ne pas
+ détériorer les performances d'une manière générale, il est par
+ conséquent préférable de revenir à la phase de préchauffage
+ lorsqu'aucune donnée n'a été transmise pendant un certain nombre
+ de secondes.
+
+ Dans les situations où les connexions peuvent être considérées + comme fiables, ce délai peut être désactivé en définissant cette + directive à 0. +
++ Dans l'exemple suivant, la directive est définie à 0, ce qui + désactive tout retour à une phase de préchauffage des connexions + TLS. Les connexions TLS déjà préchauffées conservent donc toujours + leur taille de paquet de données maximale. +
+H2TLSCoolDownSecs 0+
| Description: | |
|---|---|
| Syntaxe: | H2TLSWarmUpSize amount |
| Défaut: | H2TLSWarmUpSize 1048576 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
| Compatibilité: | Disponible à partir de la version 2.4.18 du serveur HTTP + Apache. |
+ Cette directive permet de définir le nombre d'octets à envoyer
+ dans les petits enregistrements TLS (~1300 octets) avant
+ d'atteindre leur taille maximale de 16 ko pour les connexions
+ https: HTTP/2. Elle peut être définie au niveau du serveur
+ principal ou pour des <Serveurs virtuels> spécifiques.
+
+ Les mesures effectuées par les laboratoires de performances de + Google montrent que les meilleurs performances sont atteintes + pour les connexions TLS si la taille initiale des + enregistrements reste en deça du niveau du MTU afin de permettre + à la totatlité d'un enregistrement d'entrer dans un paquet IP. +
++ Comme TCP ajuste son contrôle de flux et sa taille de fenêtre, + des enregistrements TLS trop longs peuvent rester en file + d'attente ou même être perdus et devoir alors être réémis. Ceci + est bien entendu vrai pour tous les paquets ; cependant, TLS a + besoin de la totalité de l'enregistrement pour pouvoir le + déchiffrer. Tout octet manquant rendra impossible l'utilisation + de ceux qui ont été reçus. +
++ Lorqu'un nombre suffisant d'octets a été transmis avec succès, + la connexion TCP est stable, et la taille maximale (16 ko) des + enregistrements TLS peut être utilisée pour des performances + optimales. +
++ Dans les architectures où les serveurs sont atteints par des + machines locales ou pour les connexions de confiance seulement, + la valeur de cette directive peut être définie à 0, ce qui a + pour effet de désactiver la "phase de chauffage". +
++ Dans l'exemple suivant, la phase de chauffage est effectivement + désactivée en définissant la directive à 0. +
+H2TLSWarmUpSize 0+
| Description: | Activation/Désactivation du protocole de mise à jour H2 |
|---|---|
| Syntaxe: | H2Upgrade on|off |
| Défaut: | H2Upgrade on pour h2c, off pour h2 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
+ Cette directive permet d'activer/désactiver l'utilisation de la
+ méthode de mise à jour pour passer de HTTP/1.1 à HTTP/2. Elle
+ doit être placée dans une section <VirtualHost> afin d'activer la mise à
+ jour vers HTTP/2 pour le serveur virtuel considéré.
+
+ Cette méthode de changement de protocole est définie dans + HTTP/1.1 et utilise l'en-tête "Upgrade" (d'où son nom) pour + indiquer l'intention d'utiliser un autre protocole. Cet en-tête + peut être présent dans toute requête sur une connexion HTTP/1.1. +
++ Elle activée par défaut pour les transmissions en clair + (h2c), et désactivée avec TLS (h2), comme préconisé par la RFC + 7540. +
+
+ Sachez cependant que les mises à jour ne sont acceptées que pour
+ les requêtes qui ne possèdent pas de corps. Le requêtes de type
+ POST et PUT avec un contenu ne feront jamais l'objet d'une mise
+ à jour vers HTTP/2. Se référer à la documentation de la
+ directive H2Direct pour
+ envisager une alternative à Upgrade.
+
+ Cette directive n'a d'effet que si h2 ou h2c est activé via la
+ directive Protocols.
+
H2Upgrade on+
| Description: | Taille maximale des paquets de données pour les transmissions client + vers serveur. |
|---|---|
| Syntaxe: | H2WindowSize bytes |
| Défaut: | H2WindowSize 65535 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_http2 |
+ Cette directive permet de définir la taille maximale des paquets + de données envoyés par le client au serveur, et + limite la quantité de données que le serveur doit mettre en + tampon. Le client arrêtera d'envoyer des données sur un flux + lorsque cette limite sera atteinte jusqu'à ce que le serveur + indique qu'il dispose d'un espace suffisant (car il aura traité + une partie des données). +
+ Cette limite n'affecte que les corps de requêtes, non les + métadonnées comme les en-têtes. Par contre, elle n'affecte pas + les corps de réponses car la taille maximale de ces derniers est + gérée au niveau des clients. +
+H2WindowSize 128000+
Serveur HTTP Apache Version 2.4
+| Description: | Recherche d'identité conformément à la RFC +1413 |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | ident_module |
| Fichier Source: | mod_ident.c |
| Compatibilité: | Disponible depuis la version 2.2 d'Apache |
Ce module interroge un démon compatible RFC 1413 sur un + serveur distant afin de déterminer le propriétaire d'une + connexion.
+| Description: | Active la journalisation de l'identité RFC 1413 de +l'utilisateur distant |
|---|---|
| Syntaxe: | IdentityCheck On|Off |
| Défaut: | IdentityCheck Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_ident |
| Compatibilité: | Retiré du serveur de base depuis Apache +2.1 |
Cette directive permet d'activer la journalisation compatible RFC 1413 du nom de
+ l'utilisateur distant pour chaque connexion, si la machine du client
+ exécute identd ou un démon similaire. Cette information est
+ enregistrée dans le journal des accès en utilisant la chaîne de formatage
+ %...l.
Notez que de sérieux problèmes de délais peuvent survenir lors
+ des accès à votre serveur, car chaque requête nécessite l'exécution
+ d'un de ces processus de recherche. Lorsque des pare-feu ou des
+ serveurs mandataires sont impliqués, chaque recherche est
+ susceptible d'échouer et ajouter un temps de latence conformément
+ à la directive IdentityCheckTimeout. En général, ces
+ recherches ne se révèlent donc pas très utiles sur des serveurs
+ publics accessibles depuis l'Internet.
| Description: | Détermine le délai d'attente pour les requêtes +ident |
|---|---|
| Syntaxe: | IdentityCheckTimeout secondes |
| Défaut: | IdentityCheckTimeout 30 |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_ident |
Cette directive permet de spécifier le délai d'attente d'une + requête ident. Une valeur par défaut de 30 secondes est recommandée + par la RFC 1413, + principalement pour prévenir les problèmes qui pourraient être + induits par la charge du réseau. Vous pouvez cependant ajuster la + valeur de ce délai en fonction du débit de votre réseau local.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Traitement des cartes des zones interactives d'une image +(imagemaps) au niveau du serveur |
|---|---|
| Statut: | Base |
| Identificateur de Module: | imagemap_module |
| Fichier Source: | mod_imagemap.c |
Ce module traite les fichiers .map, et remplace
+ ainsi la fonctionnalité du programme CGI imagemap. Tout
+ répertoire ou type de document configuré pour utiliser le
+ gestionnaire imap-file (à l'aide des directives
+ AddHandler ou SetHandler), sera traité par ce
+ module.
La directive suivante confère aux fichiers possèdant l'extension
+ .map le statut de fichiers imagemap :
AddHandler imap-file map+ + +
Notez que la syntaxe suivante reste encore supportée :
+ +AddType application/x-httpd-imap map+ + +
Cependant, nous essayons d'abandonner progressivement les "types + MIME magiques", et cette syntaxe est sur le point de devenir + obsolète.
+ Nouvelles fonctionnalités Fichier imagemap Exemple de fichier imagemap Référencement de votre fichier
+imagemap ImapBase ImapDefault ImapMenuLe module imagemap propose quelques nouvelles fonctionnalités qui + n'étaient pas disponibles avec les programmes imagemap précédemment + distribués.
+ +<base> par défaut via la
+ nouvelle directive base.imagemap.conf non requis.Les lignes d'un fichier imagemap peuvent se présenter sous + plusieurs formats :
+ +
+ directive valeur [x,y ...]
+ directive valeur "Texte de menu" [x,y
+ ...]
+ directive valeur x,y ... "Texte de menu"
+
Les directives sont base, default,
+ poly, circle, rect, ou
+ point. valeur est une URL absolue ou relative, ou une
+ des valeurs spéciales énumérées ci-dessous. Les coordonnées sont des
+ paires x,y séparées par des
+ espaces. Le texte entre guillemets est le texte du lien si un menu
+ imagemap est généré. Les lignes commençant par '#' sont des
+ commentaires.
Les directives autorisées dans un fichier imagemap sont au + nombre de six. Elles peuvent se trouver à n'importe quelle + position dans le fichier, mais sont traitées dans l'ordre selon + lequel elles sont enregistrées dans le fichier imagemap.
+ +baseElle a le même effet que <base
+ href="valeur">. Les URLs non absolues du
+ fichier imagemap sont considérées comme relatives à cette valeur.
+ La directive base l'emporte sur une directive
+ ImapBase définie dans
+ un fichier .htaccess ou dans le fichier de
+ configuration du serveur. En l'absence de directive de
+ configuration ImapBase, la valeur par
+ défaut de base est
+ http://nom_serveur/.
base_uri est un synonyme de base.
+ Notez que la présence ou l'absence d'un slash de fin dans l'URL
+ est importante.
defaultpoly,
+ circle, ou rect, et si aucune directive
+ point n'est présente. En l'absence de définition
+ d'une directive de configuration ImapDefault, la valeur par défaut est
+ nocontent et provoque l'envoi d'un code de statut
+ 204 No Content. Le client verra toujours la même
+ page s'afficher.polycirclerectpointdefault ne sera pas suivie si une directive
+ point est présente et si des coordonnées valides sont
+ fournies.Les valeurs passées aux directives peuvent contenir :
+ +L'URL peut être absolue ou relative. Les URLs relatives
+ peuvent contenir '..' et seront considérées comme relatives à la
+ valeur de base.
base en lui-même, ne sera pas résolu en fonction
+ de la valeur courante. Cependant, une directive base
+ mailto: fonctionnera correctement.
mapImapMenu n'ait été définie à
+ none.menumap.refererhttp://nom_serveur/ si aucun en-tête
+ Referer: n'est présent.nocontent204 No Content,
+ indiquant au client qu'il doit continuer à afficher la même page.
+ Valide pour toutes les directives, sauf base.error500 Server
+ Error. Valide pour toutes les directives, sauf
+ base, mais n'a de sens qu'avec la directive
+ default.0,0 200,2000,0 a le même effet que
+ si aucune coordonnée n'a été sélectionnée."Texte du menu"Après la valeur ou les coordonnées, la ligne peut + éventuellement contenir un texte entre guillemets. Cette chaîne + constitue le texte du lien si un menu est généré :
+ +
+ <a href="http://example.com/">Texte de
+ menu</a>
+
Si aucun texte entre guillemets n'est présent, le texte sera + constitué du nom du lien :
+ +
+ <a href="http://example.com/">http://example.com</a>
+
Si vous voulez insérer des guillemets dans le texte, vous devez
+ les inscrire sous la forme ".
+ #Les commentaires sont affichés dans un menu 'formaté' ou
+ #'semi-formaté'.
+ #Et peuvent contenir des balises html. <hr>
+ base referer
+ poly map "Puis-je avoir un menu, s'il vous plait ?" 0,0 0,10 10,10 10,0
+ rect .. 0,0 77,27 "le répertoire du référant"
+ circle http://www.inetnebr.example.com/lincoln/feedback/ 195,0 305,27
+ rect autre_fichier "dans le même répertoire que le référant" 306,0 419,27
+ point http://www.zyzzyva.example.com/ 100,100
+ point http://www.tripod.example.com/ 200,200
+ rect mailto:nate@tripod.example.com 100,150 200,0 "Bogues?"
+
+ <a href="/maps/imagemap1.map">
+
+ <img ismap src="/images/imagemap1.gif">
+
+ </a>
+
+ <a href="/maps/imagemap1.map">
+
+ <img ismap="ismap" src="/images/imagemap1.gif" />
+
+ </a>
+
| Description: | Valeur par défaut de la directive base des
+fichiers imagemap |
|---|---|
| Syntaxe: | ImapBase map|referer|URL |
| Défaut: | ImapBase http://nom_serveur/ |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_imagemap |
La directive ImapBase permet de définir la
+ valeur par défaut de la directive base des fichiers
+ imagemap. Sa valeur est écrasée par la présence éventuelle d'une
+ directive base dans le fichier imagemap. Si cette
+ directive est absente, la valeur par défaut de la directive
+ base est
+ http://nom_serveur/.
| Description: | Action à entreprendre par défaut lorsqu'un fichier imagemap +est invoqué avec des coordonnées qui ne correspondent à aucune +cible |
|---|---|
| Syntaxe: | ImapDefault error|nocontent|map|referer|URL |
| Défaut: | ImapDefault nocontent |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_imagemap |
La directive ImapDefault permet de définir
+ la valeur par défaut de la directive default utilisée
+ dans les fichiers imagemap. Sa valeur est écrasée par la présence
+ éventuelle d'une directive default dans le fichier
+ imagemap. Si cette directive est absente, l'action associée à
+ default est nocontent, ce qui implique
+ l'envoi d'un code de statut 204 No Content au client.
+ Dans ce cas, le client doit continuer à afficher la même page.
| Description: | Action à entreprendre si aucune coordonnée n'est fournie +lorsqu'on invoque un fichier imagemap |
|---|---|
| Syntaxe: | ImapMenu none|formatted|semiformatted|unformatted |
| Défaut: | ImapMenu formatted |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Indexes |
| Statut: | Base |
| Module: | mod_imagemap |
La directive ImapMenu permet de spécifier
+ l'action à entreprendre lorsqu'un fichier imagemap est invoqué sans
+ coordonnées valides.
nonenone, aucun menu
+ n'est généré, et l'action default est effectuée.formattedformatted est le menu le plus simple. Les
+ commentaires du fichier imagemap sont ignorés. Un en-tête de
+ niveau un est affiché, puis un séparateur horizontal, puis chacun
+ des liens sur une ligne séparée. L'aspect du menu est similaire à
+ celui d'un listing de répertoire.semiformattedsemiformatted, les commentaires sont
+ affichés au moment où ils apparaissent dans le fichier imagemap.
+ Les lignes vides sont interprètées comme des lignes de séparation
+ HTML. Aucun en-tête ni séparateur horizontal n'est affiché. À part
+ ces différences, le menu semiformatted est identique
+ au menu formatted.unformattedServeur HTTP Apache Version 2.4
+| Description: | Documents html interprétés par le serveur (Server Side +Includes ou SSI) |
|---|---|
| Statut: | Base |
| Identificateur de Module: | include_module |
| Fichier Source: | mod_include.c |
Ce module fournit un filtre qui va traiter les fichiers avant + de les envoyer au client. Le traitement est contrôlé via des + commentaires SGML spécialement formatés, aussi nommés + éléments. Ces éléments permettent l'insertion + conditionnelle de texte, l'inclusion d'autres fichiers ou + programmes, ainsi que la définition et l'affichage de variables + d'environnement.
+ Activation des SSI PATH_INFO et SSI Eléments disponibles Variables include Substitution de variable Eléments de contrôle d'inclusion conditionnelle Syntaxe des expressions héritée SSIEndTag SSIErrorMsg SSIETag SSILastModified SSILegacyExprParser SSIStartTag SSITimeFormat SSIUndefinedEcho XBitHackLes SSI sont implémentés par le filtre INCLUDES. Si des
+ documents contenant des directives SSI possèdent une extension
+ .shtml, les directives suivantes indiqueront à Apache de les
+ interpréter et d'assigner le type MIME
+ text/html au document obtenu :
AddType text/html .shtml +AddOutputFilter INCLUDES .shtml+ + +
L'option suivante doit être définie pour les répertoires qui
+ contiennent les fichiers shtml (en général dans une section
+ <Directory>, mais
+ cette option peut également être définie dans un fichier
+ .htaccess si AllowOverride Options
Options +Includes+ + +
Pour des raisons de compatibilité ascendante, le gestionnaire server-parsed
+ peut aussi activer le filtre INCLUDES. Ainsi, Apache va activer le
+ filtre INCLUDES pour tout document de type MIME
+ text/x-server-parsed-html ou
+ text/x-server-parsed-html3 (et le document obtenu aura
+ pour type MIME text/html).
Pour plus d'informations, voyez notre Tutoriel SSI.
+Les fichiers traités dans le cadre des SSI n'acceptent plus par
+ défaut les requêtes avec PATH_INFO (les informations
+ relatives au chemin en fin de requête). La directive AcceptPathInfo permet de configurer le
+ serveur de façon à ce qu'il accepte ce genre de requête.
Le document est interprété comme un document HTML, avec des + commandes spéciales incluses sous forme de commentaires SGML. La + syntaxe d'une commande est la suivante :
+ +
+ <!--#élément attribut=valeur
+ attribut=valeur ... -->
+
Les valeurs sont souvent entourées de guillemets, mais on peut
+ aussi utiliser des apostrophes (') ou des apostrophes
+ inverses (`). De nombreuses commandes n'acceptent
+ qu'une seule paire attribut-valeur. Notez que le terminateur de
+ commentaire (-->) doit être précédé d'un espace afin
+ d'être sûr qu'il ne soit pas considéré comme un élément de commande
+ SSI. Notez aussi que le délimiteur de début <!--#
+ est un élément de commande et ne doit donc pas contenir
+ d'espace.
La table suivante contient la liste des éléments autorisés :
+ +| Elément | Description |
|---|---|
comment |
+ commentaire SSI |
config |
+ configure les formats de sortie |
echo |
+ affiche le contenu de variables |
exec |
+ exécute des programmes externes |
fsize |
+ affiche la taille d'un fichier |
flastmod |
+ affiche la date de dernière modification d'un fichier |
include |
+ inclut un fichier |
printenv |
+ affiche toutes les variables disponibles |
set |
+ définit la valeur d'une variable |
Les éléments SSI peuvent être définis par d'autres modules que
+ mod_include. À ce titre, l'élément exec est fourni par
+ mod_cgi, et ne sera disponible que si ce module est
+ chargé.
Cette commande n'affiche aucune information. Elle n'a pour but que + l'ajout de commentaires dans un fichier et ces commentaires ne sont pas + affichés.
+ +Cette syntaxe est disponible à partir de la version 2.4.21 du serveur + HTTP Apache.
+ +
+ <!--#comment Blah Blah Blah -->
+
Cette commande contrôle divers aspects de l'interprétation. Les + attributs valides sont :
+ +echomsg (Versions 2.1 et supérieures
+ d'Apache)La valeur est un message qui sera envoyé au client si
+ l'élément echo tente
+ d'afficher le contenu d'une variable non définie. Cet attribut
+ l'emporte sur toute directive SSIUndefinedEcho.
+ <!--#config echomsg="[Valeur non définie]" -->
+
errmsgLa valeur est un message qui sera envoyé au client si une
+ erreur survient lors de l'interprétation du document. Cet attribut
+ l'emporte sur toute directive SSIErrorMsg.
+ <!--#config errmsg="[Zut, quelque chose s'est mal passé.]" -->
+
sizefmtLa valeur définit l'unité employée lors de l'affichage de la
+ taille d'un fichier. Les valeurs possibles sont bytes
+ pour une taille en octets, ou abbrev pour une taille
+ en Ko ou Mo selon son importance ; par exemple, une taille de 1024
+ octets sera affichée sous la forme "1K".
+ <!--#config sizefmt="abbrev" -->
+
timefmtLa valeur est une chaîne que pourra utiliser la fonction de la
+ bibliothèque standard strftime(3) lors de l'affichage
+ des dates.
+ <!--#config timefmt=""%R, %B %d, %Y"" -->
+
Cette commande affiche le contenu d'une des variables include définies ci-dessous. Si
+ la variable n'est pas définie, le résultat est déterminé par la
+ valeur de la directive SSIUndefinedEcho. Le format d'affichage des dates est
+ défini par l'attribut timefmt de la commande
+ config.
Attributs:
+ +vardecodingSpécifie si Apache doit effectuer un décodage dans la
+ variable avant son traitement ultérieur. La valeur par défaut est
+ none, et dans ce cas, aucun décodage n'est effectué.
+ Si la valeur est url, un décodage de type URL sera
+ effectué (il s'agit du codage de type %-encoding utilisé dans les
+ URLs des liens, etc...). Si la valeur est urlencoded,
+ c'est un décodage des éléments de type
+ application/x-www-form-urlencode (que l'on trouve dans les chaînes
+ de paramètres) qui sera effectué. Si la valeur est
+ base64, un
+ decodage de type base64 sera effectué, et si elle est
+ entity, c'est un décodage des entités HTML qui sera
+ effectué. Ce décodage est effectué avant tout codage ultérieur de
+ la variable. Il est possible d'effectuer plusieurs décodages en
+ spécifiant plusieurs valeurs séparées par des virgules. Les
+ spécifications de décodages restent valables jusqu'au prochain
+ attribut de décodage, ou la fin de l'élément.
Pour être pris en compte, l'attribut de décodage
+ doit précéder l'attribut var correspondant.
encodingSpécifie la manière dont Apache va coder les caractères
+ spéciaux que la variable contient avant leur affichage. S'il est
+ défini à none, aucun codage ne sera effectué. S'il
+ est défini à url, un codage de type URL sera effectué
+ (aussi connu sous le nom de codage avec caractères % , il convient
+ pour les URLS des liens, etc...). S'il est défini à
+ urlencoded, c'est un codage compatible
+ application/x-www-form-urlencoded qui sera effectué (à utiliser
+ dans les chaînes de paramètres). S'il est défini à
+ base64, c'est un encodage de type base64 qui sera
+ effectué. Au début d'un élément
+ echo, la valeur par défaut est définie à
+ entity, ce qui correspond à un codage de type entité
+ (codage qui convient pour un élément HTML de type bloc, comme le
+ paragraphe d'un texte). Cette valeur par défaut peut être modifiée
+ en ajoutant un attribut encoding, qui fera effet
+ jusqu'à la définition d'un nouvel attribut encoding
+ ou la fin de l'élément echo.
Pour produire son effet, l'attribut encoding doit
+ précéder l'attribut var concerné.
+ <!--#echo encoding="entity" var="QUERY_STRING" -->
+
La commande exec exécute la commande shell ou le
+ script spécifié. Elle nécessite le chargement du module
+ mod_cgi. Si Options IncludesNOEXEC est
+ définie, cette commande est désactivée. Les attributs disponibles
+ sont :
cgiLa valeur spécifie un chemin URL vers le script CGI (encodé
+ avec caractères %). Si le chemin ne commence pas par un slash (/),
+ il est considéré comme relatif au document courant. Le document
+ référencé par ce chemin est invoqué en tant que script CGI, même
+ s'il n'est pas censé être reconnu comme tel par le serveur. Les
+ scripts CGI doivent cependant être activés dans le répertoire qui
+ contient les scripts (via la directive ScriptAlias ou l'Options ExecCGI).
Le PATH_INFO et la chaîne d'arguments
+ (QUERY_STRING) de la requête originale du client sont
+ fournis au script CGI ; ils ne peuvent pas être spécifiés
+ dans le chemin de l'URL. Le script disposera des variables include
+ en plus de l'environnement standard CGI.
+ <!--#exec cgi="/cgi-bin/exemple.cgi" -->
+
Si, à la place d'un flux de sortie, le script renvoie un
+ en-tête Location:, ce dernier sera traduit en ancrage
+ HTML.
L'élément include
+ virtual doit être préféré à exec cgi. En
+ particulier, si vous devez transmettre des arguments
+ supplémentaires à un programme CGI en utilisant la chaîne
+ d'arguments de la requête, c'est impossible avec exec
+ cgi, mais vous pouvez y parvenir avec include
+ virtual comme suit :
+ <!--#include virtual="/cgi-bin/exemple.cgi?argument=valeur" -->
+
cmdLe serveur va exécuter la commande fournie en utilisant
+ /bin/sh. La commande dispose des variables include, en plus du jeu habituel
+ de variables CGI.
Il est toujours préférable d'utiliser #include virtual à la place de
+ #exec cgi ou #exec cmd. #include
+ virtual utilise le mécanisme standard des sous-requêtes
+ d'Apache pour inclure des fichiers ou des scripts. Il a fait
+ l'objet de tests plus approfondis et sa maintenance est mieux
+ suivie.
De plus, sur certaines plate-formes, comme Win32, et sous unix,
+ si l'on utilise suexec, il est
+ impossible de transmettre des arguments à une commande dans une
+ directive exec, à moins d'insérer des espaces dans la
+ commande. Ainsi, alors que ce qui suit fonctionnera sous unix avec
+ une configuration sans suexec, l'effet produit ne sera pas celui
+ désiré sous Win32, ou dans le cas de l'utilisation de suexec
+ :
+ <!--#exec cmd="perl /chemin/vers/script_perl arg1 arg2" -->
+
Cette commande permet d'afficher la taille du fichier spécifié
+ en fonction des spécifications de format de sizefmt.
+ Attributs :
file
+ Ce fichier a une taille de <!--#fsize file="mod_include.html"
+ --> octets.
+
file ne peut pas faire référence à un
+ fichier situé à un niveau supérieur de l'arborescence du répertoire
+ courant ou en dehors de la racine des documents ; il ne peut donc
+ ni commencer par un slash, ni contenir la séquence de caractères
+ ../. Si c'est le cas, le message d'erreur The
+ given path was above the root path sera renvoyé.
+ virtual
+ Ce fichier a une taille de <!--#fsize
+ virtual="/docs/mod/mod_include.html" --> octets.
+
Notez que dans la plupart des cas, ces deux attributs sont
+ identiques. Cependant, l'attribut file ne respecte
+ pas les aliases URL-space.
Cette commande permet d'afficher la date de dernière
+ modification du fichier spécifié, en fonction des spécifications
+ de format de timefmt. Les attributs sont les mêmes
+ que ceux de la commande fsize.
Cette commande permet d'insérer le texte d'un autre document ou
+ fichier dans le fichier en cours d'interprétation. Tout fichier
+ inclus est soumis au contrôle d'accès habituel. Si Options IncludesNOEXEC
+ est défini pour le répertoire contenant le fichier
+ interprété, seuls les documents possèdant un
+ type MIME de type texte
+ (text/plain, text/html, etc...) seront
+ inclus. Les scripts CGI, quant à eux, sont invoqués de manière
+ habituelle en utilisant l'URL complète fournie avec la commande, y
+ compris toute chaîne d'arguments éventuelle.
Un attribut définit le chemin du document à inclure, et peut + apparaître plusieurs fois dans l'élément à inclure ; en retour, pour + chaque attribut fourni à la commande include, une inclusion est + effectuée. Les attributs disponibles sont :
+ +file../, ni être un chemin absolu. Ainsi, vous ne pouvez
+ pas inclure de fichiers situés en dehors de l'arborescence du
+ site web ou dans un niveau supérieur à celui du fichier courant
+ dans cette arborescence. Il est toujours préférable d'utiliser
+ l'attribut virtual.virtualLa valeur est un chemin URL (codé avec caractères %). L'URL + ne peut contenir qu'un chemin et une chaîne d'arguments + éventuelle, à l'exclusion de tout protocole ou nom d'hôte. S'il ne + commence pas par un slash (/), il est considéré comme relatif au + document courant.
+ +Une URL est construite à partir de l'attribut, et la sortie que + renverrait le serveur si l'URL était accédée par le client est + incluse dans la sortie interprétée. Les inclusions de fichiers + peuvent ainsi être imbriquées.
+ +Si l'URL spécifiée correspond à un programme CGI, le programme + sera exécuté, et son flux de sortie inséré à la place de la + directive dans le fichier interprété. Vous pouvez insérer une + chaîne d'arguments dans une URL correspond à un programme CGI + :
+ +
+ <!--#include virtual="/cgi-bin/exemple.cgi?argument=valeur" -->
+
include virtual doit être préféré à exec
+ cgi pour inclure le flux de sortie d'un programme CGI dans
+ un document HTML.
Si la directive KeptBodySize est correctement
+ définie et valide pour le fichier inclus, les tentatives de
+ requêtes POST vers le document HTML qui inclut des fichiers seront
+ transmises aux sous-requêtes en tant que requêtes POST
+ elles-mêmes. Sans cette directive, toutes les sous-requêtes sont
+ traitées en tant que requêtes GET.
onerrorLa valeur est un chemin-URL (codé-%) qui est affiché si une + tentative précédente d'inclure un fichier ou un attribut virtuel a + échoué. Pour produire son effet, cet attribut doit être spécifié + après le fichier ou les attributs virtuels concernés. Si la + tentative d'inclure le chemin onerror échoue, ou si onerror n'est + pas spécifié, c'est le message d'erreur par défaut qui sera + inclus.
+ +
+ # Exemple simple
+ <!--#include virtual="/not-exist.html" onerror="/error.html" -->
+
+ # Chemins onerror dédiés
+ <!--#include virtual="/path-a.html" onerror="/error-a.html" virtual="/path-b.html" onerror="/error-b.html" -->
+
Cette commande affiche la liste en mode texte de toutes les variables et de
+ leurs valeurs. Les caractères spéciaux sont encodés entity avant
+ d'être affichés (se reporter à l'élément echo pour plus de détails). Cette
+ commande ne comporte pas d'attributs.
+ <pre>
+ <!--#printenv -->
+ </pre>
+
Cette commande permet de définir la valeur d'une variable. Les + attributs sont :
+ +varvaluedecodingSpécifie si Apache doit effectuer un décodage dans la
+ variable avant son traitement ultérieur. La valeur par défaut est
+ none, et dans ce cas, aucun décodage n'est effectué.
+ Si la valeur est url, urlencoded,
+ base64 ou
+ entity, c'est un décodage de type URL,
+ application/x-www-form-urlencoded, base64 ou
+ entité HTML qui sera respectivement effectué. Il est possible
+ d'effectuer plusieurs décodages en
+ spécifiant plusieurs valeurs séparées par des virgules. Les
+ spécifications de décodages restent valables jusqu'au prochain
+ attribut de décodage, ou la fin de l'élément. Pour être pris en
+ compte, l'attribut de décodage
+ doit précéder l'attribut var correspondant.
encodingSpécifie la manière dont Apache va encoder les caractères
+ spéciaux que la variable contient avant leur affichage. S'il est
+ défini à none, aucun encodage ne sera effectué. Si la
+ valeur est url, urlencoding,
+ base64 ou
+ entity, c'est un encodage de type URL,
+ application/x-www-form-urlencoded, base64 ou
+ entité HTML qui sera respectivement effectué. Il est possible de
+ spécifier plusieurs types d'encodage en les séparant par des
+ virgules. La spécification du type d'encodage fera effet
+ jusqu'à la définition d'un nouvel attribut encoding
+ ou la fin de l'élément. Pour produire son effet, l'attribut encoding doit
+ précéder l'attribut var concerné. Les encodages sont
+ effectués après les opérations de décodage.
+ <!--#set var="category" value="help" -->
+
À l'instar des variables de l'environnement CGI standard, ces
+ variables sont mises à la disposition de la commande
+ echo, des opérateurs conditionnels if et
+ elif, et de tout programme invoqué par le document.
DATE_GMTDATE_LOCALDOCUMENT_ARGSinclude, QUERY_STRING contiendra la chaîne
+ de paramètres de la sous-requête et DOCUMENT_ARGS la chaîne
+ de paramètres du document SSI (disponible à partir de la version 2.4.19 du
+ serveur HTTP Apache).DOCUMENT_NAMEDOCUMENT_PATH_INFOAcceptPathInfo pour plus d'informations à
+ propos de PATH_INFO.DOCUMENT_URIalias ou directoryindex), c'est l'URL modifiée
+ que contiendra la variable.LAST_MODIFIEDQUERY_STRING_UNESCAPED&,etc...
+ sont précédés d'anti-slashes). Cette variable n'est pas définie si aucune
+ chaîne d'arguments n'est présente. Utilisez DOCUMENT_ARGS si
+ l'échappement des caractères du shell n'est pas souhaité.USER_NAMEUne substitution de variable à l'intérieur d'une chaîne entre
+ guillemets s'effectue dans la plupart des situations où cette
+ dernière peut raisonablement constituer un argument d'une directive
+ SSI. Sont concernées les directives config,
+ exec, flastmod, fsize,
+ include, echo, et set. Si la
+ directive SSILegacyExprParser est définie à
+ on, la substitution s'effectue aussi dans les arguments
+ des opérateurs conditionnels. Vous pouvez insérer
+ un signe dollar en tant que caractère littéral dans une chaîne en
+ utilisant un anti-slash :
+ <!--#set var="cur" value="\$test" -->
+
Si une référence de variable doit être substituée au beau milieu + d'une séquence de caractères qui pourrait être elle-même considérée + comme un identifiant valide, l'ambiguïté peut être levée en + entourant la référence d'accolades, à la manière du shell :
+ +
+ <!--#set var="Zed" value="${REMOTE_HOST}_${REQUEST_METHOD}" -->
+
Dans cet exemple, la variable Zed se verra affecter
+ la valeur "X_Y" si REMOTE_HOST et
+ REQUEST_METHOD contiennent respectivement
+ "X" et "Y".
Les éléments de base du contrôle d'inclusion conditionnelle sont + :
+ +
+ <!--#if expr="test_condition" -->
+ <!--#elif expr="test_condition" -->
+ <!--#else -->
+ <!--#endif -->
+
L'élément if fonctionne de la même manière que
+ la directive if d'un langage de programmation. La condition est
+ évaluée et si le résultat est vrai, le texte qui suit jusqu'au
+ prochain élément elif, else ou
+ endif sera inclus dans le flux de sortie.
Les éléments elif ou else permettent
+ d'insérer du texte dans le flux de sortie si
+ test_condition s'est révélé faux. Ces éléments sont
+ optionnels.
L'élément endif termine le bloc de traitement
+ conditionnel if et est obligatoire.
test_condition est une expression booléenne qui
+ emprunte la syntaxe ap_expr. La directive
+ SSILegacyExprParser
+ permet de modifier cette syntaxe pour la rendre compatible avec
+ Apache HTTPD 2.2.x.
Le jeu de variables SSI avec l'élément var sont
+ exportées vers l'environnement de la requête et sont accessibles via
+ la fonction reqenv. Pour faire simple, le nom de
+ fonction v est aussi disponible dans le module
+ mod_include.
Dans l'exemple suivant, "depuis le réseau local" sera affiché si + l'adresse IP du client appartient au sous-réseau 10.0.0.0/8.
+ +
+ <!--#if expr='-R "10.0.0.0/8"' -->
+
+ depuis le réseau local
+
+ <!--#else -->
+
+ depuis ailleurs
+
+ <!--#endif -->
+
Dans l'exemple suivant, "foo vaut bar" sera affiché si la variable
+ foo contient la valeur "bar".
+ <!--#if expr='v("foo") = "bar"' -->
+
+ foo vaut bar
+
+ <!--#endif -->
+
Voir aussi Les expressions dans le serveur
+ HTTP Apache pour une référence complète et des exemples. Les
+ fonctions restricted ne sont pas disponibles dans
+ mod_include.
Cette section décrit la syntaxe de l'élément #if
+ expr dans le cas où la directive SSILegacyExprParser est définie à
+ on.
chaîne-A stringvrai si l'URL que contient la chaîne est accessible du + point de vue de la configuration, faux sinon. Il + s'avère utile lorsqu'un lien vers une URL doit être caché aux + utilisateurs qui ne sont pas autorisés à voir cette URL. Notez que + le test porte sur l'autorisation d'accès à l'URL, et non sur son + existence.
+ +
+ <!--#if expr="-A /prive" -->
+
+ Cliquez <a href="/prive">ici</a> pour accéder aux
+ informations privées.
+
+ <!--#endif -->
+
chaîne1 = chaîne2
+ chaîne1 == chaîne2
+ chaîne1 != chaîne2Compare chaîne1 à chaîne2. Si
+ chaîne2 est de la forme
+ /chaîne2/, elle est traitée comme une
+ expression rationnelle. Les expressions rationnelles sont
+ implémentées par le moteur PCRE
+ et possèdent la même syntaxe que celles de perl 5. Notez que ==
+ n'est qu'un alias pour = et se comporte exactement de
+ la même manière que ce dernier.
Si vous faites une comparaison directe (= ou
+ ==), vous pouvez extraire des parties de l'expression
+ rationnelle. Les parties extraites sont stockées dans les
+ variables spéciales $1 .. $9. L'ensemble
+ de la chaîne correspondant à l'expression rationnelle est stocké
+ dans la variable spéciale $0.
+ <!--#if expr="$QUERY_STRING = /^sid=([a-zA-Z0-9]+)/" -->
+
+ <!--#set var="session" value="$1" -->
+
+ <!--#endif -->
+
chaîne1 < chaîne2
+ chaîne1 <= chaîne2
+ chaîne1 > chaîne2
+ chaîne1 >= chaîne2strcmp(3)). Ainsi, la chaîne "100" est inférieure à
+ "20".( test_condition )! test_conditiontest_condition1 &&
+ test_condition2test_condition1 ||
+ test_condition2"=" et "!=" ont une priorité supérieure
+ à "&&" et "||". "!" a
+ la priorité la plus haute. Ainsi, les deux directives suivantes sont
+ équivalentes :
+ <!--#if expr="$a = test1 && $b = test2" -->
+ <!--#if expr="($a = test1) && ($b = test2)" -->
+
Les opérateurs booléens && et
+ || ont la même priorité. Ainsi, si vous voulez
+ augmenter la priorité d'un de ces opérateurs, vous devez utiliser
+ des parenthèses.
Tout ce qui n'est pas reconnu comme variable ou opérateur est
+ traité comme une chaîne. Les chaînes peuvent aussi être entourées
+ d'apostrophes : 'chaîne'. Les chaînes sans apostrophe
+ ne peuvent pas contenir d'espaces (espaces ou tabulations) car
+ ceux-ci servent à séparer certains éléments comme les variables. Si
+ plusieurs chaînes se trouvent dans une ligne, elles sont concaténées
+ en utilisant des espaces. Ainsi,
chaîne1 chaîne2 devient chaîne1 chaîne2
+
+ et
+
+ 'chaîne1 chaîne2' devient chaîne1 chaîne2.
Si les expressions atteignent une complexité suffisante pour + ralentir les traitements de manière significative, vous pouvez + essayer de les optimiser en fonction des règles d'évaluation :
+&& et
+ ||) font l'objet d'une évaluation abrégée chaque fois
+ que cela est possible. En d'autres termes, et selon la règle
+ ci-dessus, mod_include évalue tout d'abord la
+ partie gauche de l'expression. Si le résultat de l'évaluation de
+ cette partie gauche suffit à déterminer le résultat final,
+ l'évaluation s'arrête ici. Dans le cas contraire, la partie droite
+ est évaluée, et le résultat final tient compte des résultats des
+ évaluations des parties gauche et droite.$1 .. $9).Si vous voulez déterminer la manière dont une expression est
+ traitée, vous pouvez recompiler mod_include en
+ utilisant l'option de compilation -DDEBUG_INCLUDE.
+ Ceci a pour effet d'insérer, pour chaque expression interprétée,
+ des informations étiquetées, l'arbre d'interprétation et la
+ manière dont elle est évaluée au sein du flux de sortie envoyé au
+ client.
Tous les caractères slashes qui ne sont pas des séparateurs dans + votre expression rationnelle doivent être échappés, et ceci sans + tenir compte de leur signification du point de vue du moteur + d'expressions rationnelles.
+Voir le document Les expressions dans le + serveur HTTP Apache, pour une référence complète et des exemples.
+| Description: | Chaîne qui termine l'élément include |
|---|---|
| Syntaxe: | SSIEndTag tag |
| Défaut: | SSIEndTag "-->" |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_include |
Cette directive permet de modifier la chaîne que
+ mod_include interprète comme la fin d'un élément
+ include.
SSIEndTag "%>"+ + + +
SSIStartTag| Description: | Message d'erreur affiché lorsqu'une erreur SSI +survient |
|---|---|
| Syntaxe: | SSIErrorMsg message |
| Défaut: | SSIErrorMsg "[an error occurred while processing this
+directive]" |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Base |
| Module: | mod_include |
La directive SSIErrorMsg permet de
+ modifier le message d'erreur affiché lorsqu'une erreur SSI survient.
+ Pour les serveurs en production, il est recommandé de modifier le
+ message d'erreur par défaut en "<!-- Error
+ -->", de façon à ce que le message ne soit pas
+ présenté à l'utilisateur.
Cette directive a le même effet que l'élément
+ <!--#config errmsg=message -->.
SSIErrorMsg "<!-- Error -->"+ + +
| Description: | Définit si des en-têtes ETags sont générés par le serveur. |
|---|---|
| Syntaxe: | SSIETag on|off |
| Défaut: | SSIETag off |
| Contexte: | répertoire, .htaccess |
| Statut: | Base |
| Module: | mod_include |
| Compatibilité: | Disponible à partir de la version 2.2.15 du serveur HTTP +Apache. |
Dans le cas général, un fichier filtré par
+ mod_include peut contenir des éléments soit
+ générés dynamiquement, soit éventuellement modifiés indépendemment
+ du fichier original. En conséquence, il est demandé par défaut au
+ serveur de ne pas générer d'en-tête ETag à la réponse
+ en ajoutant no-etag aux informations de requête.
Ce comportement peut être modifié via la directive
+ SSIETag qui permet au serveur de générer un
+ en-tête ETag. On peut aussi l'utiliser pour la mise
+ en cache de la sortie. Notez qu'un serveur d'arrière-plan ou un
+ générateur de contenu dynamique peut lui-même générer un en-tête
+ ETag, en ignorant l'information no-etag,
+ cet en-tête ETag étant transmis par
+ mod_include sans tenir compte de la définition de
+ la présente directive. La directive SSIETag
+ peut prendre une des valeurs suivantes :
offno-etag sera ajouté aux informations de
+ requête, et il sera demandé au serveur de ne pas générer
+ d'en-tête ETag. Lorsqu'un serveur ignore la valeur
+ de no-etag et génère tout de même un en-tête
+ ETag, ce dernier sera respecté.onETag existants seront respectés,
+ et ceux générés par le serveur seront ajoutés à la réponse.| Description: | Définit si des en-têtes Last-Modified sont
+générés par le serveur. |
|---|---|
| Syntaxe: | SSILastModified on|off |
| Défaut: | SSILastModified off |
| Contexte: | répertoire, .htaccess |
| Statut: | Base |
| Module: | mod_include |
| Compatibilité: | Disponible à partir de la version 2.2.15 du serveur HTTP +Apache. |
Dans le cas général, un fichier filtré par
+ mod_include peut contenir des éléments soit
+ générés dynamiquement, soit éventuellement modifiés indépendemment
+ du fichier original. En conséquence, l'en-tête
+ Last-Modified est supprimé par défaut de la réponse.
La directive SSILastModified permet de
+ modifier ce comportement en faisant en sorte que l'en-tête
+ Last-Modified soit respecté s'il est déjà présent, ou
+ défini dans le cas contraire. On peut aussi l'utiliser pour la mise
+ en cache de la sortie. La directive
+ SSILastModified peut prendre une des
+ valeurs suivantes :
offLast-Modified sera supprimé des
+ réponses, à moins que la directive XBitHack ne soit définie à
+ full comme décrit plus loin.onLast-Modified sera respecté s'il est
+ déjà présent, et ajouté à la réponse si cette dernière est un
+ fichier et si l'en-tête est manquant. La directive SSILastModified l'emporte sur
+ la directive XBitHack.| Description: | Active le mode de compatibilité pour les expressions +conditionnelles. |
|---|---|
| Syntaxe: | SSILegacyExprParser on|off |
| Défaut: | SSILegacyExprParser off |
| Contexte: | répertoire, .htaccess |
| Statut: | Base |
| Module: | mod_include |
| Compatibilité: | Disponible à partir de la version 2.3.13. |
Depuis la version 2.3.13, mod_include a adopté
+ la nouvelle syntaxe ap_expr pour ses
+ expressions conditionnelles dans les éléments de contrôle de flux
+ #if. Cette directive permet de réactiver l'ancienne syntaxe qui est compatible avec les
+ versions 2.2.x et antérieures d'Apache HTTPD.
+
| Description: | Chaîne qui marque le début d'un élément +include |
|---|---|
| Syntaxe: | SSIStartTag tag |
| Défaut: | SSIStartTag "<!--#" |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_include |
Cette directive permet de modifier la chaîne que
+ mod_include interprète comme le début d'un élément
+ include.
Cette option peut vous être utile si vous avez deux serveurs qui + interprètent un fichier avec des commandes différentes (et + éventuellement à des moments différents).
+ +SSIStartTag "<%" +SSIEndTag "%>"+ + +
Avec l'exemple ci-dessus, qui définit aussi une directive
+ SSIEndTag, vous pourrez
+ inscrire des directives SSI comme dans l'exemple suivant :
+ <%printenv %>
+
SSIEndTag| Description: | Configuration du format d'affichage des dates |
|---|---|
| Syntaxe: | SSITimeFormat chaîne de formatage |
| Défaut: | SSITimeFormat "%A, %d-%b-%Y %H:%M:%S %Z" |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Base |
| Module: | mod_include |
Cette directive permet de modifier le format d'affichage des
+variables d'environnement DATE. La chaîne de
+formatage est identique à celle de la fonction
+strftime(3) de la bibliothèque C standard.
Cette directive a le même effet que l'élément
+ <!--#config timefmt=chaîne de formatage
+ -->.
SSITimeFormat "%R, %B %d, %Y"+ + +
Avec l'exemple ci-dessus, les dates seront affichées dans le + style "22:26, June 14, 2002".
+ +| Description: | Chaîne à afficher lorsqu'on tente d'extraire le contenu +d'une variable non définie |
|---|---|
| Syntaxe: | SSIUndefinedEcho chaîne |
| Défaut: | SSIUndefinedEcho "(none)" |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Base |
| Module: | mod_include |
Cette directive permet de modifier la chaîne affichée par
+ mod_include lorsqu'on tente d'extraire le contenu
+ d'une variable non définie.
SSIUndefinedEcho "<!-- nondef -->"+ + +
| Description: | Interprète les directives SSI dans les fichiers dont le bit +d'exécution est positionné |
|---|---|
| Syntaxe: | XBitHack on|off|full |
| Défaut: | XBitHack off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Options |
| Statut: | Base |
| Module: | mod_include |
La directive XBitHack permet de contrôler
+ l'interprétation des documents html standards. Elle n'affecte que
+ les fichiers dont le type MIME est
+ text/html. XBitHack peut prendre
+ les valeurs suivantes :
offontext/html dont le bit d'exécution
+ est positionné pour le propriétaire sera traité en tant que
+ document html interprété par le serveur.fullon, avec test du bit d'exécution pour
+ le groupe. Si ce dernier est positionné, la date de dernière
+ modification du fichier renvoyé est définie à la date de
+ dernière modification du fichier. Dans le cas contraire, aucune
+ date de dernière modification n'est renvoyée. Le positionnement de
+ ce bit permet aux clients et aux mandataires de gérer la mise en
+ cache du résultat de la requête.
+
+ Il est recommandé de n'utiliser l'option full que dans le cas
+ où vous êtes certain que le bit d'exécution du groupe est non
+ positionné pour les scripts SSI qui pourraient effectuer l'#include d'un programme CGI ou bien produire des sorties
+ différentes à chaque accès (ou seraient susceptibles d'être
+ modifiées au cours des requêtes ultérieures).
Lorsqu'elle est définie à on, la directive
+ SSILastModified
+ l'emporte sur la directive XBitHack.
Serveur HTTP Apache Version 2.4
+| Description: | Affiche une présentation complète de la configuration du +serveur |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | info_module |
| Fichier Source: | mod_info.c |
Pour activer mod_info, ajoutez les lignes
+ suivantes à votre fichier httpd.conf.
<Location "/server-info"> + SetHandler server-info +</Location>+ + +
Il est recommandé d'utiliser mod_authz_host à
+ l'intérieur de la section <Location> afin de restreindre l'accès aux
+ informations de configuration de votre serveur :
<Location "/server-info"> + SetHandler server-info + Require host example.com +</Location>+ + +
Une fois cette configuration effectuée, les informations du
+ serveur sont disponibles à l'adresse
+ http://votre-serveur.com/infos-serveur.
Problèmes liés à la sécurité Filtrage des informations affichées Affichage de la configuration au démarrage Limitations connues AddModuleInfoUne fois mod_info chargé dans le serveur, sa
+ fonctionnalité de gestionnaire est disponible dans tous les
+ fichiers de configuration, y compris les fichiers de configuration
+ des répertoires (par exemple .htaccess). Ceci peut
+ avoir des répercutions en matière de sécurité pour votre site.
En particulier, l'utilisation de ce module peut conduire à la + divulgation d'informations sensibles à partir des directives de + configuration d'autres modules Apache comme des chemins systèmes, + des couples nom d'utilisateur/mot de passe, des noms de bases de + données, etc... C'est pourquoi ce module ne doit être utilisé + que dans un environnement sous contrôle et toujours + avec les plus grandes précautions.
+ +Il est recommandé d'utiliser mod_authz_host pour
+ restreindre l'accès aux informations de configuration de votre
+ serveur.
<Location "/server-info"> + SetHandler server-info + # Autorisation d'accès depuis le serveur lui-même + Require ip 127.0.0.1 + + # Autorisation d'accès depuis une station de travail du réseau +# local + Require ip 192.168.1.17 +</Location>+
Par défaut, les informations affichées comprennent une liste de + tous les modules activés, et pour chaque module, une description des + directives qu'il accepte, les branchements (hooks) qu'il + implémente, ainsi que les directives concernées dans la + configuration courante.
+ +Il est possible d'afficher d'autres vues de la configuration en
+ ajoutant un argument à la requête infos-serveur. Par
+ exemple, http://votre-serveur.com/infos-serveur?config
+ affichera toutes les directives de configuration.
?<module-name>?config?hooks?list?server?providersSi la directive de configuration define
+ -DDUMP_CONFIG est utilisée, mod_info va
+ envoyer la configuration préinterprétée vers stdout au
+ cours du démarrage du serveur.
httpd -DDUMP_CONFIG -k start+ + +
"Préinterprétée" signifie que
+ les directives telles que <IfDefine> et <IfModule> sont évaluées et les variables
+ d'environnement remplacées par leurs valeurs. Cela ne représente
+ cependant pas la configuration définitive. En particulier, les
+ fusions ou écrasementsde définitions en cas de directives multiples ne sont pas
+ représentés.
Le résultat est équivalent à celui de la requête
+ ?config.
mod_info tire ses informations de
+ la configuration interprétée, et non du fichier de configuration
+ original. La manière dont l'arbre de configuration interprété est
+ créé induit quelques limitations :
ServerRoot, LoadModule et LoadFile.Include,
+ <IfModule> et
+ <IfDefine> ne
+ sont pas prises en compte, mais les directives de configuration
+ incluses le sont..htaccess ne sont pas prises en compte (car elles ne
+ font pas partie de la configuration permanente du serveur).<Directory> sont affichées
+ normalement, mais mod_info est incapable de
+ déterminer le numéro de ligne de la balise fermante
+ </Directory>.| Description: | Ajoute des données supplémentaires aux informations de +module affichées par le gestionnaire server-info |
|---|---|
| Syntaxe: | AddModuleInfo nom-module chaîne |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_info |
Cette directive permet d'afficher le contenu de chaîne + en tant qu'Information supplémentaire interprétée + en HTML pour le module nom-module. Exemple :
+ +AddModuleInfo mod_deflate.c 'See <a \ + href="http://httpd.apache.org/docs/2.4/mod/mod_deflate.html">\ + http://httpd.apache.org/docs/2.4/mod/mod_deflate.html</a>'+ + +
Serveur HTTP Apache Version 2.4
+| Description: | Extensions ISAPI dans Apache pour Windows |
|---|---|
| Statut: | Base |
| Identificateur de Module: | isapi_module |
| Fichier Source: | mod_isapi.c |
| Compatibilité: | Win32 only |
Ce module implémente l'API des extensions du Serveur Internet. Il + permet à Apache pour Windows de servir les extensions du Serveur + Internet (par exemple les modules .dll ISAPI), compte tenu des + restrictions spécifiées.
+ +Les modules d'extension ISAPI (fichiers .dll) sont des modules + tiers. Leur auteur n'est pas le Groupe Apache, et nous n'assurons + donc pas leur support. Veuillez contacter directement l'auteur + d'ISAPI si vous rencontrez des problèmes à l'exécution d'une + extension ISAPI. Merci de ne pas soumettre ce genre + de problème dans les listes d'Apache ou dans les pages de rapports + de bogues.
+ ISAPIAppendLogToErrors ISAPIAppendLogToQuery ISAPICacheFile ISAPIFakeAsync ISAPILogNotSupported ISAPIReadAheadBufferDans le fichier de configuration du serveur, utilisez la
+ directive AddHandler pour
+ associer les fichiers ISAPI au gestionnaire
+ isapi-handler à l'aide de l'extension de leur nom de
+ fichier. Pour faire en sorte que tout fichier .dll soit traité en
+ tant qu'extension ISAPI, éditez le fichier httpd.conf et ajoutez les
+ lignes suivantes :
AddHandler isapi-handler .dll+ + +
isapi-isa au lieu de
+ isapi-handler. Depuis les versions de développement 2.3
+ du serveur Apache, isapi-isa n'est plus valide, et vous
+ devrez éventuellement modifier votre configuration pour utiliser
+ isapi-handler à la place.Le serveur Apache ne propose aucun moyen de conserver en mémoire + un module chargé. Vous pouvez cependant précharger et garder un + module spécifique en mémoire en utilisant la syntaxe suivante dans + votre httpd.conf :
+ISAPICacheFile c:/WebWork/Scripts/ISAPI/mytest.dll+ + +
Que vous ayez ou non préchargé une extension ISAPI, ces dernières
+ sont toutes soumises au mêmes restrictions et possèdent les mêmes
+ permissions que les scripts CGI. En d'autres termes, Options ExecCGI doit être
+ défini pour le répertoire qui contient le fichier .dll ISAPI.
Reportez-vous aux Notes additionnelles et au
+ Journal du programmeur pour plus de détails
+ et une clarification à propos du support spécifique ISAPI fourni par
+ le module mod_isapi.
L'implémentation ISAPI d'Apache se conforme à toutes les
+ spécifications ISAPI 2.0, à l'exception de certaines extensions
+ "spécifiques Microsoft" utilisant des entrées/sorties asynchrones.
+ Le modèle des entrées/sorties d'Apache ne permet pas l'écriture et
+ la lecture asynchrone de la manière dont ISAPI pourrait le faire. Si
+ une extension tente d'utiliser des fonctionnalités non supportées,
+ comme les entrées/sorties asynchrones, un message est enregistré
+ dans le journal des erreurs afin d'aider au débogage. Comme ces
+ messages peuvent devenir envahissants, la directive
+ ISAPILogNotSupported Off permet de filter ce bruit de
+ fond.
Si aucune option de configuration particulière n'est spécifiée,
+ certains serveurs, comme Microsoft IIS, chargent l'extension ISAPI
+ dans le serveur et la conservent en mémoire jusqu'à ce que
+ l'utilisation de cette dernière devienne trop élevée. Apache, par
+ contre, charge et décharge réellement l'extension ISAPI chaque fois
+ qu'elle est invoquée, si la directive ISAPICacheFile n'a pas été spécifiée.
+ Ce n'est pas très performant, mais le modèle de mémoire d'Apache
+ fait que cette méthode est la plus efficace. De nombreux modules
+ ISAPI présentent des incompatibilités subtiles avec le serveur
+ Apache, et le déchargement de ces modules permet d'assurer la
+ stabilité du serveur.
En outre, gardez à l'esprit que si Apache supporte les extensions + ISAPI, il ne supporte pas les filtres ISAPI. Le + support des filtres sera peut-être ajouté dans le futur, mais n'a + pas encore été planifié.
+Si vous écrivez des modules mod_isapi Apache
+ 2.0, vous devez limiter vos appels à
+ ServerSupportFunction aux directives suivantes :
HSE_REQ_SEND_URL_REDIRECT_RESPhttp://serveur/chemin).HSE_REQ_SEND_URL/chemin).Dans sa documentation récente, Microsoft semble avoir
+ abandonné la distinction entre les deux fonctions
+ HSE_REQ_SEND_URL. Apache, quant à lui, continue de
+ les traiter comme deux fonctions distinctes avec des contraintes
+ et des comportements spécifiques.
HSE_REQ_SEND_RESPONSE_HEADERHSE_REQ_DONE_WITH_SESSIONHSE_REQ_MAP_URL_TO_PATHHSE_APPEND_LOG_PARAMETER\"%{isapi-parameter}n\"
+ d'une directive CustomLog%q avec la directive
+ ISAPIAppendLogToQuery
+ OnISAPIAppendLogToErrors
+ OnLa première option, le composant
+ %{isapi-parameter}n, est préférable et toujours
+ disponible.
HSE_REQ_IS_KEEP_CONNHSE_REQ_SEND_RESPONSE_HEADER_EXfKeepConn soit ignoré.HSE_REQ_IS_CONNECTEDApache renvoie FALSE pour tout appel non supporté à
+ ServerSupportFunction, et GetLastError
+ renverra la valeur ERROR_INVALID_PARAMETER.
ReadClient extrait la partie du corps de la requête
+ qui dépasse le tampon initial (défini par la directive ISAPIReadAheadBuffer). En fonction de
+ la définition de la directive
+ ISAPIReadAheadBuffer (nombre d'octets à
+ mettre dans le tampon avant d'appeler le gestionnaire ISAPI), les
+ requêtes courtes sont envoyées en entier à l'extension lorsque
+ celle-ci est invoquée. Si la taille de la requête est trop
+ importante, l'extension ISAPI doit faire appel à
+ ReadClient pour extraire la totalité du corps de la
+ requête.
WriteClient est supporté, mais seulement avec le
+ drapeau HSE_IO_SYNC ou le drapeau "aucune option"
+ (valeur 0). Toute autre requête
+ WriteClient sera rejetée avec une valeur de retour
+ FALSE, et GetLastError renverra la valeur
+ ERROR_INVALID_PARAMETER
GetServerVariable est supporté, bien que les
+ variables étendues de serveur n'existent pas (comme défini par
+ d'autres serveurs). Toutes les variables d'environnement CGI
+ usuelles d'Apache sont disponibles à partir de
+ GetServerVariable, ainsi que les valeurs
+ ALL_HTTP et ALL_RAW.
Depuis httpd 2.0, mod_isapi propose des
+ fonctionnalités supplémentaires introduites dans les versions
+ actualisées de la spécification ISAPI, ainsi qu'une émulation
+ limitée des entrées/sorties asynchrones et la sémantique
+ TransmitFile. Apache httpd supporte aussi le préchargement
+ des .dlls ISAPI à des fins de performances.
| Description: | Enregistrement des requêtes
+HSE_APPEND_LOG_PARAMETER de la part des extensions ISAPI
+dans le journal des erreurs |
|---|---|
| Syntaxe: | ISAPIAppendLogToErrors on|off |
| Défaut: | ISAPIAppendLogToErrors off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_isapi |
Cette directive permet d'enregistrer les requêtes
+ HSE_APPEND_LOG_PARAMETER de la part des extensions
+ ISAPI dans le journal des erreurs.
| Description: | Enregistre les requêtes
+HSE_APPEND_LOG_PARAMETER de la part des extensions ISAPI
+dans la partie arguments de la requête |
|---|---|
| Syntaxe: | ISAPIAppendLogToQuery on|off |
| Défaut: | ISAPIAppendLogToQuery on |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_isapi |
Cette directive permet d'enregistrer les requêtes
+ HSE_APPEND_LOG_PARAMETER de la part des extensions
+ ISAPI dans la partie arguments de la requête (ajouté au composant
+ %q de la directive CustomLog).
| Description: | Fichiers .dll ISAPI devant être chargés au +démarrage |
|---|---|
| Syntaxe: | ISAPICacheFile chemin-fichier
+[chemin-fichier]
+... |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_isapi |
Cette directive permet de spécifier une liste, séparés par des
+ espaces, de noms de fichiers devant être chargés au démarrage
+ du serveur Apache, et rester en mémoire jusqu'à l'arrêt du serveur.
+ Cette directive peut être répétée pour chaque fichier .dll ISAPI
+ souhaité. Le chemin complet du fichier doit être spécifié. Si le
+ chemin n'est pas absolu, il sera considéré comme relatif au
+ répertoire défini par la directive ServerRoot.
| Description: | Emulation du support des entrées/sorties asynchrones pour +les appels ISAPI |
|---|---|
| Syntaxe: | ISAPIFakeAsync on|off |
| Défaut: | ISAPIFakeAsync off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_isapi |
Lorsquelle est définie à "on", cette directive permet d'émuler le + support des entrées/sorties asynchrones pour les appels ISAPI.
+ +| Description: | Journalisation des demandes de fonctionnalités non +supportées de la part des extensions ISAPI |
|---|---|
| Syntaxe: | ISAPILogNotSupported on|off |
| Défaut: | ISAPILogNotSupported off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_isapi |
Cette directive permet d'enregistrer dans le journal des erreurs + toutes les demandes de fonctionnalités non supportées de la part des + extensions ISAPI. Ceci peut aider les administrateurs à décortiquer + certains problèmes. Lorsqu'elle a été définie à "on" et si tous les + modules ISAPI fonctionnent, elle peut être redéfinie à "off".
+ +| Description: | Taille du tampon de lecture anticipée envoyé aux extensions +ISAPI |
|---|---|
| Syntaxe: | ISAPIReadAheadBuffer taille |
| Défaut: | ISAPIReadAheadBuffer 49152 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_isapi |
Cette directive permet de définir la taille maximale du tampon de
+ lecture anticipée envoyé aux extensions ISAPI lorsqu'elles sont
+ initialement invoquées. Toute donnée restante doit être extraite en
+ faisant appel à ReadClient ; certaines extensions ISAPI
+ peuvent ne pas supporter la fonction ReadClient.
+ Pour plus de détails, veuillez vous adresser à l'auteur de
+ l'extension ISAPI.
Serveur HTTP Apache Version 2.4
+| Description: | Algorithme de planification avec répartition de charge de
+l'attribution des requêtes en attente pour le module
+mod_proxy_balancer |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | lbmethod_bybusyness_module |
| Fichier Source: | mod_lbmethod_bybusyness.c |
| Compatibilité: | Dissocié de mod_proxy_balancer depuis la
+version 2.3 |
Ce module ne fournit pas lui-même de directive de configuration. Il
+nécessite les services de mod_proxy_balancer, et
+fournit la méthode de répartition de charge bybusyness.
Ce module ne fournit aucune directive.
+Activé via lbmethod=bybusyness, ce planificateur
+ surveille le nombre de requêtes assignées à chaque processus worker
+ à l'instant présent. Une nouvelle requête est automatiquement
+ assignée au processus worker auquel est assigné le plus petit nombre de
+ requêtes. Ceci s'avère utile dans le cas où les
+ processus worker mettent en file d'attente les requêtes entrantes
+ indépendamment d'Apache, et permet de s'assurer que la longueur des
+ files reste raisonnable, et qu'une requête est toujours assignée au
+ processus worker qui sera à même de la servir le plus
+ rapidement et avec une latence réduite.
Si plusieurs processus worker s'avèrent les moins chargés, le
+ choix d'un de ces derniers est effectué à partir des statistiques
+ (et des estimations de charges) qu'utilise la méthode de décompte
+ des requêtes. Au fil du temps, la distribution des tâches finit par
+ ressembler à celle de byrequests (tel qu'implémenté par
+ mod_lbmethod_byrequests).
Serveur HTTP Apache Version 2.4
+| Description: | Algorithme de planification avec répartition de charge du
+traitement des requêtes pour le module
+mod_proxy_balancer |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | lbmethod_byrequests_module |
| Fichier Source: | mod_lbmethod_byrequests.c |
| Compatibilité: | Dissocié de mod_proxy_balancer dans la
+version 2.3 |
Ce module ne fournit pas lui-même de directive de configuration. Il
+nécessite les services de mod_proxy_balancer, et
+fournit la méthode de répartition de charge byrequests.
Ce module ne fournit aucune directive.
+Activé via lbmethod=byrequests, ce planificateur a
+ été conçu dans le but de distribuer les requêtes à tous les
+ processus worker afin qu'ils traitent tous le nombre de requêtes
+ pour lequel ils ont été configurés. Il fonctionne de la manière
+ suivante :
lbfactor correspond à la quantité de travail que + nous attendons de ce processus worker, ou en d'autres termes + son quota de travail. C'est une valeur normalisée + représentant leur part du travail à accomplir.
+ +lbstatus représente combien il est urgent que + ce processus worker travaille pour remplir son quota de + travail.
+ +Le worker est un membre du dispositif de répartition + de charge, en général un serveur distant traitant un des protocoles + supportés.
+ +On distribue à chaque processus worker son quota de travail, puis + on regarde celui qui a le plus besoin de travailler + (le plus grand lbstatus). Ce processus est alors sélectionné pour + travailler, et son lbstatus diminué de l'ensemble des quotas de + travail que nous avons distribués à tous les processus. La somme de + tous les lbstatus n'est ainsi pas modifiée, et nous pouvons + distribuer les requêtes selon nos souhaits.
+ +Si certains processus workers sont désactivés, les autres feront + l'objet d'une planification normale.
+ +for each worker in workers
+ worker lbstatus += worker lbfactor
+ total factor += worker lbfactor
+ if worker lbstatus > candidate lbstatus
+ candidate = worker
+
+candidate lbstatus -= total factorSi un répartiteur de charge est configuré comme suit :
+ +| worker | +a | +b | +c | +d |
|---|---|---|---|---|
| lbfactor | +25 | +25 | +25 | +25 |
| lbstatus | +0 | +0 | +0 | +0 |
Et si b est désactivé, la planification suivante est + mise en oeuvre :
+ +| worker | +a | +b | +c | +d |
|---|---|---|---|---|
| lbstatus | +-50 | +0 | +25 | +25 |
| lbstatus | +-25 | +0 | +-25 | +50 |
| lbstatus | +0 | +0 | +0 | +0 |
| (repeat) | ||||
C'est à dire la chronologie suivante : a c + d + a c d a c + d ... Veuillez noter que :
+ +| worker | +a | +b | +c | +d |
|---|---|---|---|---|
| lbfactor | +25 | +25 | +25 | +25 |
A le même effet que :
+ +| worker | +a | +b | +c | +d |
|---|---|---|---|---|
| lbfactor | +1 | +1 | +1 | +1 |
Ceci est dû au fait que toutes les valeurs de lbfactor + sont normalisées et évaluées en fonction des autres. Avec :
+ +| worker | +a | +b | +c |
|---|---|---|---|
| lbfactor | +1 | +4 | +1 |
le processus b va, en moyenne, se voir assigner 4 fois + plus de requêtes que a et c.
+ +La configuration suivante, asymétrique, fonctionne comme on peut + s'y attendre :
+ +| worker | +a | +b |
|---|---|---|
| lbfactor | +70 | +30 |
| lbstatus | +-30 | +30 |
| lbstatus | +40 | +-40 |
| lbstatus | +10 | +-10 |
| lbstatus | +-20 | +20 |
| lbstatus | +-50 | +50 |
| lbstatus | +20 | +-20 |
| lbstatus | +-10 | +10 |
| lbstatus | +-40 | +40 |
| lbstatus | +30 | +-30 |
| lbstatus | +0 | +0 |
| (repeat) | ||
Après 10 distributions, la planification se répète et 7 + a sont sélectionnés avec 3 b intercalés.
+Serveur HTTP Apache Version 2.4
+| Description: | Algorithme de planification avec répartition de charge en
+fonction d'un niveau de trafic pour le module
+mod_proxy_balancer |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | lbmethod_bytraffic_module |
| Fichier Source: | mod_lbmethod_bytraffic.c |
| Compatibilité: | Dissocié de mod_proxy_balancer depuis la
+version 2.3 |
Ce module ne fournit pas lui-même de directive de configuration. Il
+nécessite les services de mod_proxy_balancer, et
+fournit la méthode de répartition de charge bytraffic.
Ce module ne fournit aucune directive.
+Activé via lbmethod=bytraffic, l'idée directrice de
+ ce planificateur est similaire à celle de la méthode reposant sur le
+ nombre de requêtes, avec les différences suivantes :
lbfactor représente la quantité de trafic, en + octets, que nous voulons voir traitée par le processus. Il + s'agit là aussi d'une valeur normalisée représentant la part de + travail à effectuer par le processus, mais au lieu de se baser sur + un nombre de requêtes, on prend en compte la quantité de trafic que + ce processus a traité.
+ +Si un répartiteur est configuré comme suit :
+ +| worker | +a | +b | +c |
|---|---|---|---|
| lbfactor | +1 | +2 | +1 |
Cela signifie que nous souhaitons que b traite 2 fois + plus d'octets que a ou c. Cela n'entraîne pas + nécessairement que b va traiter deux fois plus de + requêtes, mais qu'il va traiter deux fois plus de trafic en termes + d'entrées/sorties. A cet effet, les tailles de la requête et de sa + réponse assocciée sont prises en compte par l'algorithme de + sélection et d'évaluation du trafic.
+ +Note : les octets en entrée sont évalués avec la même pondération + que les octets en sortie.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Algorithme d'ordonnancement de répartition de charge pour
+mod_proxy_balancer basé sur le comptage de trafic Heartbeat |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | lbmethod_heartbeat_module |
| Fichier Source: | mod_lbmethod_heartbeat.c |
| Compatibilité: | Disponible depuis la version 2.3 d'Apache |
lbmethod=heartbeat utilise les services du module
+ mod_heartmonitor pour répartir la charge entre les
+ serveurs d'origine qui fournissent des données heartbeat via le
+ module mod_heartbeat.
Son algorithme de répartition de charge favorise les serveurs dont la +capacité de traitement moyenne répartie dans le temps est la plus +importante, mais il ne sélectionne pas forcément le serveur qui présente +la disponibilité instantanée la plus importante. Les serveurs qui ne +possèdent aucun client actif sont pénalisés, car ils sont considérés +comme non entièrement initialisés.
+| Description: | Indique le chemin permettant de lire les données +heartbeat |
|---|---|
| Syntaxe: | HeartbeatStorage chemin-fichier |
| Défaut: | HeartbeatStorage logs/hb.dat |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_lbmethod_heartbeat |
La directive HeartbeatStorage permet de
+ spécifier le chemin d'accès aux données heartbeat. Ce fichier texte
+ n'est utilisé que si le module mod_slotmem_shm
+ n'est pas chargé.
Serveur HTTP Apache Version 2.4
+| Description: | Conservation des connexions LDAP et services de mise en +cache du résultat à destination des autres modules LDAP |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | ldap_module |
| Fichier Source: | util_ldap.c |
Ce module a été conçu dans le but d'améliorer les performances + des sites web s'appuyant sur des connexions en arrière-plan vers des + serveurs LDAP. Il ajoute aux fonctions fournies par les + bibliothèques standards LDAP la conservation des connexions LDAP + ainsi qu'un cache LDAP partagé en mémoire.
+ +Pour activer ce module, le support LDAP doit être compilé dans
+ apr-util. Pour ce faire, on ajoute l'option --with-ldap
+ au script configure lorsqu'on construit
+ Apache.
Le support SSL/TLS est conditionné par le kit de développement + LDAP qui a été lié à APR. Au moment où ces + lignes sont écrites, APR-util supporte OpenLDAP SDK (version 2.x ou + supérieure), Novell LDAP + SDK, + Mozilla LDAP SDK, le SDK LDAP Solaris natif (basé sur Mozilla) + ou le SDK LDAP Microsoft natif. Voir le site web APR pour plus de détails.
+ + Exemple de configuration Conservation des connexions LDAP Cache LDAP Utiliser SSL/TLS Certificats SSL/TLS LDAPCacheEntries LDAPCacheTTL LDAPConnectionPoolTTL LDAPConnectionTimeout LDAPLibraryDebug LDAPOpCacheEntries LDAPOpCacheTTL LDAPReferralHopLimit LDAPReferrals LDAPRetries LDAPRetryDelay LDAPSharedCacheFile LDAPSharedCacheSize LDAPTimeout LDAPTrustedClientCert LDAPTrustedGlobalCert LDAPTrustedMode LDAPVerifyServerCertCe qui suit est un exemple de configuration qui utilise
+ mod_ldap pour améliorer les performances de
+ l'authentification HTTP de base fournie par
+ mod_authnz_ldap.
# Active la conservation des connexions LDAP et le cache partagé en +# mémoire. Active le gestionnaire de statut du cache LDAP. +# Nécessite le chargement de mod_ldap et de mod_authnz_ldap. +# Remplacez "votre-domaine.example.com" par le nom de votre +# domaine. + +LDAPSharedCacheSize 500000 +LDAPCacheEntries 1024 +LDAPCacheTTL 600 +LDAPOpCacheEntries 1024 +LDAPOpCacheTTL 600 + +<Location "/ldap-status"> + SetHandler ldap-status + + Require host yourdomain.example.com + + Satisfy any + AuthType Basic + AuthName "LDAP Protected" + AuthBasicProvider ldap + AuthLDAPURL "ldap://127.0.0.1/dc=example,dc=com?uid?one" + Require valid-user +</Location>+ +
Les connexions LDAP sont conservées de requête en requête. Ceci + permet de rester connecté et identifié au serveur LDAP, ce dernier + étant ainsi prêt pour la prochaine requête, sans avoir à se + déconnecter, reconnecter et réidentifier. Le gain en performances + est similaire à celui des connexions persistantes (keepalives) + HTTP.
+ +Sur un serveur très sollicité, il est possible que de nombreuses + requêtes tentent d'accéder simultanément à la même connexion au + serveur LDAP. Lorsqu'une connexion LDAP est utilisée, Apache en crée + une deuxième en parallèle à la première, ce qui permet d'éviter que + le système de conservation des connexions ne devienne un goulot + d'étranglement.
+ +Il n'est pas nécessaire d'activer explicitement la conservation + des connexions dans la configuration d'Apache. Tout module utilisant + le module ldap pour accéder aux services LDAP partagera le jeu de + connexions.
+ +Les connexions LDAP peuvent garder la trace des données
+ d'identification du client ldap utilisées pour l'identification
+ auprès du serveur LDAP. Ces données peuvent être fournies aux
+ serveurs LDAP qui ne permettent pas les connexions anonymes au cours
+ lors des tentatives de sauts vers des serveurs alternatifs. Pour
+ contrôler cette fonctionnalité, voir les directives LDAPReferrals et LDAPReferralHopLimit. Cette
+ fonctionnalité est activée par défaut.
Pour améliorer les performances, mod_ldap met en
+ oeuvre une stratégie de mise en cache agressive visant à minimiser
+ le nombre de fois que le serveur LDAP doit être contacté. La mise en
+ cache peut facilement doubler et même tripler le débit d'Apache
+ lorsqu'il sert des pages protégées par mod_authnz_ldap. De plus, le
+ serveur LDAP verra lui-même sa charge sensiblement diminuée.
mod_ldap supporte deux types de mise en cache
+ LDAP : un cache recherche/identification durant la phase
+ de recherche/identification et deux caches d'opérations
+ durant la phase de comparaison. Chaque URL LDAP utilisée par le
+ serveur a son propre jeu d'instances dans ces trois caches.
Les processus de recherche et d'identification sont les + opérations LDAP les plus consommatrices en temps, en particulier + si l'annuaire est de grande taille. Le cache de + recherche/identification met en cache toutes les recherches qui + ont abouti à une identification positive. Les résultats négatifs + (c'est à dire les recherches sans succès, ou les recherches qui + n'ont pas abouti à une identification positive) ne sont pas mis en + cache. La raison de cette décision réside dans le fait que les + connexions avec des données d'identification invalides ne + représentent qu'un faible pourcentage du nombre total de + connexions, et ainsi, le fait de ne pas mettre en cache les + données d'identification invalides réduira d'autant la taille du + cache.
+ +mod_ldap met en cache le nom d'utilisateur, le
+ DN extrait, le mot de passe utilisé pour l'identification, ainsi
+ que l'heure de l'identification. Chaque fois qu'une nouvelle
+ connexion est initialisée avec le même nom d'utilisateur,
+ mod_ldap compare le mot de passe de la nouvelle
+ connexion avec le mot de passe enregistré dans le cache. Si les
+ mots de passe correspondent, et si l'entrée du cache n'est pas
+ trop ancienne, mod_ldap court-circuite la phase
+ de recherche/identification.
Le cache de recherche/identification est contrôlé par les
+ directives LDAPCacheEntries et LDAPCacheTTL.
Au cours des opérations de comparaison d'attributs et de noms
+ distinctifs (DN), mod_ldap utilise deux caches
+ d'opérations pour mettre en cache les opérations de comparaison.
+ Le premier cache de comparaison sert à mettre en cache les
+ résultats de comparaisons effectuées pour vérifier l'appartenance
+ à un groupe LDAP. Le second cache de comparaison sert à mettre en
+ cache les résultats de comparaisons entre DNs.
Notez que, lorsque l'appartenance à un groupe est vérifiée, + toute comparaison de sous-groupes est mise en cache afin + d'accélérer les comparaisons de sous-groupes ultérieures.
+ +Le comportement de ces deux caches est contrôlé par les
+ directives LDAPOpCacheEntries et LDAPOpCacheTTL.
mod_ldap possède un gestionnaire de contenu
+ qui permet aux administrateurs de superviser les performances du
+ cache. Le nom du gestionnaire de contenu est
+ ldap-status, et on peut utiliser les directives
+ suivantes pour accéder aux informations du cache de
+ mod_ldap :
<Location "/server/cache-info"> + SetHandler ldap-status +</Location>+ + +
En se connectant à l'URL
+ http://nom-serveur/infos-cache, l'administrateur peut
+ obtenir un rapport sur le statut de chaque cache qu'utilise
+ mod_ldap. Notez que si Apache ne supporte pas la
+ mémoire partagée, chaque instance de httpd
+ possèdera son propre cache, et chaque fois que l'URL sera
+ rechargée, un résultat différent pourra être affiché, en fonction
+ de l'instance de httpd qui traitera la
+ requête.
La possibilité de créer des connexions SSL et TLS avec un serveur
+ LDAP est définie par les directives
+ LDAPTrustedGlobalCert,
+ LDAPTrustedClientCert et
+ LDAPTrustedMode. Ces directives permettent de spécifier
+ l'autorité de certification (CA), les certificats clients éventuels,
+ ainsi que le type de chiffrement à utiliser pour la connexion (none,
+ SSL ou TLS/STARTTLS).
# Etablissement d'une connexion SSL LDAP sur le port 636. +# Nécessite le chargement de mod_ldap et mod_authnz_ldap. +# Remplacez "votre-domaine.example.com" par le nom de votre +# domaine. + +LDAPTrustedGlobalCert CA_DER "/certs/certfile.der" + +<Location "/ldap-status"> + SetHandler ldap-status + + Require host yourdomain.example.com + + Satisfy any + AuthType Basic + AuthName "LDAP Protected" + AuthBasicProvider ldap + AuthLDAPURL "ldaps://127.0.0.1/dc=example,dc=com?uid?one" + Require valid-user +</Location>+ + +
# Etablissement d'une connexion TLS LDAP sur le port 389. +# Nécessite le chargement de mod_ldap et mod_authnz_ldap. +# Remplacez "votre-domaine.example.com" par le nom de votre +# domaine. + +LDAPTrustedGlobalCert CA_DER "/certs/certfile.der" + +<Location "/ldap-status"> + SetHandler ldap-status + + Require host yourdomain.example.com + + Satisfy any + AuthType Basic + AuthName "LDAP Protected" + AuthBasicProvider ldap + AuthLDAPURL "ldap://127.0.0.1/dc=example,dc=com?uid?one" TLS + Require valid-user +</Location>+ + +
Les différents SDKs LDAP disposent de nombreuses méthodes pour + définir et gérer les certificats des clients et des autorités de + certification (CA).
+ +Si vous avez l'intention d'utiliser SSL ou TLS, lisez cette + section ATTENTIVEMENT de façon à bien comprendre les différences de + configurations entre les différents SDKs LDAP supportés.
+ +Les certificat de CA sont enregistrés dans un fichier nommé + cert7.db. Le SDK ne dialoguera avec aucun serveur LDAP dont le + certificat n'a pas été signé par une CA spécifiée dans ce + fichier. Si des certificats clients sont requis, un fichier + key3.db ainsi qu'un mot de passe optionnels peuvent être + spécifiés. On peut aussi spécifier le fichier secmod si + nécessaire. Ces fichiers sont du même format que celui utilisé + par les navigateurs web Netscape Communicator ou Mozilla. Le + moyen le plus simple pour obtenir ces fichiers consiste à les + extraire de l'installation de votre navigateur.
+ +Les certificats clients sont spécifiés pour chaque connexion + en utilisant la directive LDAPTrustedClientCert et en se + référant au certificat "nickname". On peut éventuellement + spécifier un mot de passe pour déverrouiller la clé privée du + certificat.
+ +Le SDK supporte seulement SSL. Toute tentative d'utilisation + de STARTTLS engendrera une erreur lors des tentatives de + contacter le serveur LDAP pendant l'exécution.
+ +# Spécifie un fichier de certificats de CA Netscape +LDAPTrustedGlobalCert CA_CERT7_DB "/certs/cert7.db" +# Spécifie un fichier key3db optionnel pour le support des +# certificats clients +LDAPTrustedGlobalCert CERT_KEY3_DB "/certs/key3.db" +# Spécifie le fichier secmod si nécessaire +LDAPTrustedGlobalCert CA_SECMOD "/certs/secmod" +<Location "/ldap-status"> + SetHandler ldap-status + + Require host yourdomain.example.com + + Satisfy any + AuthType Basic + AuthName "LDAP Protected" + AuthBasicProvider ldap + LDAPTrustedClientCert CERT_NICKNAME <nickname> [password] + AuthLDAPURL "ldaps://127.0.0.1/dc=example,dc=com?uid?one" + Require valid-user +</Location>+ + + + +
Un ou plusieurs certificats de CA doivent être spécifiés pour + que le SDK Novell fonctionne correctement. Ces certificats + peuvent être spécifiés sous forme de fichiers au format binaire + DER ou codés en Base64 (PEM).
+ +Note: Les certificats clients sont spécifiés globalement + plutôt qu'à chaque connexion, et doivent être spécifiés à l'aide + de la directive LDAPTrustedGlobalCert comme ci-dessous. Définir + des certificats clients via la directive LDAPTrustedClientCert + engendrera une erreur qui sera journalisée, au moment de la + tentative de connexion avec le serveur LDAP.
+ +Le SDK supporte SSL et STARTTLS, le choix étant défini par le + paramètre de la directive LDAPTrustedMode. Si une URL de type + ldaps:// est spécifiée, le mode SSL est forcé, et l'emporte sur + cette directive.
+ +# Spécifie deux fichiers contenant des certificats de CA +LDAPTrustedGlobalCert CA_DER "/certs/cacert1.der" +LDAPTrustedGlobalCert CA_BASE64 "/certs/cacert2.pem" +# Spécifie un fichier contenant des certificats clients +# ainsi qu'une clé +LDAPTrustedGlobalCert CERT_BASE64 "/certs/cert1.pem" +LDAPTrustedGlobalCert KEY_BASE64 "/certs/key1.pem" [password] +# N'utilisez pas cette directive, sous peine de provoquer +# une erreur +#LDAPTrustedClientCert CERT_BASE64 "/certs/cert1.pem"+ + + + +
Un ou plusieurs certificats de CA doivent être spécifiés pour + que le SDK OpenLDAP fonctionne correctement. Ces certificats + peuvent être spécifiés sous forme de fichiers au format binaire + DER ou codés en Base64 (PEM).
+ +Les certificats clients sont spécifiés pour chaque connexion + à l'aide de la directive LDAPTrustedClientCert.
+ +La documentation du SDK prétend que SSL et STARTTLS sont + supportés ; cependant, STARTTLS semble ne pas fonctionner avec + toutes les versions du SDK. Le mode SSL/TLS peut être défini en + utilisant le paramètre de la directive LDAPTrustedMode. Si une + URL de type + ldaps:// est spécifiée, le mode SSL est forcé. La documentation + OpenLDAP indique que le support SSL (ldaps://) tend à être + remplacé par TLS, bien que le mode SSL fonctionne toujours.
+ +# Spécifie deux fichiers contenant des certificats de CA +LDAPTrustedGlobalCert CA_DER "/certs/cacert1.der" +LDAPTrustedGlobalCert CA_BASE64 "/certs/cacert2.pem" +<Location /ldap-status> + SetHandler ldap-status + + Require host yourdomain.example.com + + LDAPTrustedClientCert CERT_BASE64 "/certs/cert1.pem" + LDAPTrustedClientCert KEY_BASE64 "/certs/key1.pem" + # CA certs respecified due to per-directory client certs + LDAPTrustedClientCert CA_DER "/certs/cacert1.der" + LDAPTrustedClientCert CA_BASE64 "/certs/cacert2.pem" + Satisfy any + AuthType Basic + AuthName "LDAP Protected" + AuthBasicProvider ldap + AuthLDAPURL "ldaps://127.0.0.1/dc=example,dc=com?uid?one" + Require valid-user +</Location>+ + + + +
SSL/TLS pour les bibliothèques LDAP propres à Solaris n'est + pas encore supporté. Si nécessaire, installez et utilisez plutôt + les bibliothèques OpenLDAP.
+ + + +La configuration des certificats SSL/TLS pour les + bibliothèques LDAP propres à Microsoft s'effectue à l'intérieur + du registre système, et aucune directive de configuration n'est + requise.
+ +SSL et TLS sont tous deux supportés en utilisant des URLs de + type ldaps://, ou en définissant la directive LDAPTrustedMode à + cet effet.
+ +Note: L'état du support des certificats clients n'est pas + encore connu pour ce SDK.
+ + + +| Description: | Nombre maximum d'entrées dans le cache LDAP +primaire |
|---|---|
| Syntaxe: | LDAPCacheEntries nombre |
| Défaut: | LDAPCacheEntries 1024 |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
Cette directive permet de spécifier la taille maximale du cache + LDAP primaire. Ce cache contient les résultats de + recherche/identification positifs. Définissez-la à 0 pour désactiver + la mise en cache des résultats de recherche/identification positifs. + La taille par défaut est de 1024 recherches en cache.
+ +| Description: | Durée pendant laquelle les entrées du cache restent +valides. |
|---|---|
| Syntaxe: | LDAPCacheTTL secondes |
| Défaut: | LDAPCacheTTL 600 |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
Cette directive permet de spécifier la durée (en secondes) + pendant laquelle une entrée du cache de recherche/identification + reste valide. La valeur par défaut est de 600 secondes (10 + minutes).
+ +| Description: | Désactive les connexions d'arrière-plan qui sont restées +inactives trop longtemps au sein du jeu de connexions. |
|---|---|
| Syntaxe: | LDAPConnectionPoolTTL n |
| Défaut: | LDAPConnectionPoolTTL -1 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ldap |
| Compatibilité: | Disponible à partir de la version 2.3.12 du serveur HTTP +Apache |
Cette directive permet de spécifier la durée maximale, en + secondes, pendant laquelle une connexion LDAP du jeu de connexions + peut demeurer inactive, mais rester quand-même disponible pour une + utilisation éventuelle. Le jeu de connexions est nettoyé au fur et à + mesure des besoins, de manière non asynchrone.
+ +Si cette directive est définie à 0, les connexions ne sont jamais + sauvegardées dans le jeu de connexions d'arrière-plan. Avec la + valeur par défaut -1, ou toute autre valeur négative, les connexions + peuvent être réutilisées sans limite de durée.
+ +Dans le but d'améliorer les performances, le temps de référence + qu'utilise cette directive correspond au moment où la connexion LDAP + est enregistrée ou remise dans le jeu de connexions, et non au + moment du dernier échange réussi avec le serveur LDAP.
+ +La version 2.4.10 a introduit de nouvelles mesures permettant + d'éviter une augmentation excessive du temps de référence due à des + correspondances positives dans le cache ou des requêtes lentes. A + cet effet, le temps de référence n'est pas réactualisé si aucune + connexion LDAP d'arrière-plan n'est requise ; d'autre part, le temps + de référence se base sur le moment où la requête HTTP est reçue, et + non sur le moment où la requête a été traitée.
+ +Cette durée de vie s'exprime par défaut en secondes, mais + il est possible d'utiliser d'autres unités en ajoutant un suffixe : + millisecondes (ms), minutes (min), ou heures (h). +
| Description: | Spécifie le délai d'attente en secondes de la socket de +connexion |
|---|---|
| Syntaxe: | LDAPConnectionTimeout secondes |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
Cette directive configure l'option LDAP_OPT_NETWORK_TIMEOUT (ou + LDAP_OPT_CONNECT_TIMEOUT) dans la bibliothèque client LDAP + sous-jacente, si elle est disponible. Cette valeur représente la + durée pendant laquelle la bibliothèque client LDAP va attendre que + le processus de connexion TCP au serveur LDAP soit achevé.
+ +Si la connexion n'a pas réussi avant ce délai, une erreur sera
+ renvoyée, ou la bibliothèque client LDAP tentera de se connecter à
+ un second serveur LDAP, s'il en a été défini un (via une liste de
+ noms d'hôtes séparés par des espaces dans la directive AuthLDAPURL).
La valeur par défaut est 10 secondes, si la bibliothèque client + LDAP liée avec le serveur supporte l'option + LDAP_OPT_NETWORK_TIMEOUT.
+ +| Description: | Active le débogage dans le SDK LDAP |
|---|---|
| Syntaxe: | LDAPLibraryDebug 7 |
| Défaut: | disabled |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
Active les options de débogage LDAP spécifiques au SDK, qui + entraînent en général une journalisation d'informations verbeuses du + SDK LDAP dans le journal principal des erreurs d'Apache. Les + messages de traces en provenance du SDK LDAP fournissent des + informations très détaillées qui peuvent s'avérer utiles lors du + débogage des problèmes de connexion avec des serveurs LDAP + d'arrière-plan.
+ +Cette option n'est configurable que lorsque le serveur HTTP
+ Apache est lié avec un SDK LDAP qui implémente
+ LDAP_OPT_DEBUG ou LDAP_OPT_DEBUG_LEVEL,
+ comme OpenLDAP (une valeur de 7 est verbeuse) ou Tivoli Directory
+ Server (une valeur de 65535 est verbeuse).
Les informations journalisées peuvent contenir des données + d'authentification en clair utilisées ou validées lors de + l'authentification LDAP ; vous devez donc prendre soin de protéger + et de purger le journal des erreurs lorsque cette directive est + utilisée.
+| Description: | Nombre d'entrées utilisées pour mettre en cache les +opérations de comparaison LDAP |
|---|---|
| Syntaxe: | LDAPOpCacheEntries nombre |
| Défaut: | LDAPOpCacheEntries 1024 |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
Cette directive permet de spécifier le nombre d'entrées que
+ mod_ldap va utiliser pour mettre en cache les
+ opérations de comparaison LDAP. La valeur par défaut est de 1024
+ entrées. Si elle est définie à 0, la mise en cache des opérations de
+ comparaison LDAP est désactivée.
| Description: | Durée pendant laquelle les entrées du cache d'opérations +restent valides |
|---|---|
| Syntaxe: | LDAPOpCacheTTL secondes |
| Défaut: | LDAPOpCacheTTL 600 |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
Cette directive permet de spécifier la durée (en secondes) + pendant laquelle les entrées du cache d'opérations restent valides. + La valeur par défaut est de 600 secondes.
+ +| Description: | Le nombre maximum de redirections vers des serveurs +alternatifs (referrals) avant l'abandon de la requête +LDAP. |
|---|---|
| Syntaxe: | LDAPReferralHopLimit nombre |
| Défaut: | Dépend du SDK, en général entre 5 et 10 |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_ldap |
Si elle est activée par la directive LDAPReferrals,
+ cette directive permet de définir le nombre maximum de sauts vers
+ des serveurs alternatifs (referrals) avant l'abandon de la requête
+ LDAP.
L'ajustement de ce paramètre n'est pas commun à tous les SDKs LDAP.
+| Description: | Active la redirection vers des serveurs alternatifs au +cours des requêtes vers le serveur LDAP. |
|---|---|
| Syntaxe: | LDAPReferrals On|Off|default |
| Défaut: | LDAPReferrals On |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_ldap |
| Compatibilité: | Le paramètre default est disponible depuis la +version 2.4.7 du serveur HTTP Apache. |
Certains serveurs LDAP partagent leur annuaire en plusieurs + domaines et utilisent le système des redirections (referrals) pour + aiguiller un client lorsque les limites d'un domaine doivent être + franchies. Ce processus est similaire à une redirection HTTP. Les + bibliothèques client LDAP ne respectent pas forcément ces + redirections par défaut. Cette directive permet de configurer + explicitement les redirections LDAP dans le SDK sous-jacent.
+ +La directive LDAPReferrals accepte les
+ valeurs suivantes :
Avec la valeur "on", la prise en compte des redirections
+ LDAP par le SDK sous-jacent est activée, la directive
+ LDAPReferralHopLimit permet de surcharger la
+ "hop limit" du SDK, et un "LDAP rebind callback" est enregistré.
Avec la valeur "off", la prise en compte des redirections + LDAP par le SDK sous-jacent est complètement désactivée.
Avec la valeur "default", la prise en compte des redirections
+ LDAP par le SDK sous-jacent n'est pas modifiée, la directive
+ LDAPReferralHopLimit ne permet pas de surcharger la
+ "hop limit" du SDK, et aucun "LDAP rebind callback" n'est enregistré.
La directive LDAPReferralHopLimit travaille en
+ conjonction avec cette directive pour limiter le nombre de
+ redirections à suivre pour achever le traitement de la requête LDAP.
+ Lorsque le processus de redirection est activé par la valeur "On",
+ les données d'authentification du client sont transmises via un
+ "rebind callback" à tout serveur LDAP qui en fait la demande.
| Description: | Définit le nombre maximum de tentatives de connexions au +serveur LDAP. |
|---|---|
| Syntaxe: | LDAPRetries nombre d'essais |
| Défaut: | LDAPRetries 3 |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
Suite à des échecs de connexion au serveur LDAP, le serveur
+ tentera de se connecter autant de fois qu'indiqué par la directive
+ LDAPRetries. Si cette directive est définie à
+ 0, le serveur ne tentera pas d'autre connexion après un échec.
Il est possible d'effectuer une autre tentative de connexion en + cas d'erreurs LDAP du type délai dépassé ou connexion refusée.
+ +| Description: | Définit le temps d'attente avant un autre essai de connexion au +serveur LDAP. |
|---|---|
| Syntaxe: | LDAPRetryDelay secondes |
| Défaut: | LDAPRetryDelay 0 |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
Si la directive LDAPRetryDelay est définie
+ à une valeur différente de 0, le serveur attendra pendant la durée
+ spécifiée pour envoyer à nouveau sa requête LDAP. Une valeur de 0
+ implique une absence de délai pour les essais successifs.
Il est possible d'effectuer une autre tentative de connexion en + cas d'erreurs LDAP du type délai dépassé ou connexion refusée.
+ +| Description: | Définit le fichier du cache en mémoire +partagée |
|---|---|
| Syntaxe: | LDAPSharedCacheFile chemin/fichier |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
Cette directive permet de spécifier le chemin du + fichier du cache en mémoire partagée. Si elle n'est pas définie, la + mémoire partagée anonyme sera utilisée si la plate-forme la + supporte.
+ + +| Description: | Taille en octets du cache en mémoire partagée |
|---|---|
| Syntaxe: | LDAPSharedCacheSize octets |
| Défaut: | LDAPSharedCacheSize 500000 |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
Cette directive permet de spécifier le nombre d'octets à allouer + pour le cache en mémoire partagée. La valeur par + défaut est 500kb. + Si elle est définie à 0, le cache en mémoire partagée ne sera pas + utilisé et chaque processus HTTPD va créer son propre cache.
+ +| Description: | Spécifie le délai d'attente pour les opérations de +recherche et d'identification LDAP en secondes |
|---|---|
| Syntaxe: | LDAPTimeout secondes |
| Défaut: | LDAPTimeout 60 |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
| Compatibilité: | Disponible à partir de la version 2.3.5 du serveur HTTP +Apache |
Cette directive permet de spécifier le délai d'attente pour les + opérations de recherche et d'identification, ainsi que l'option + LDAP_OPT_TIMEOUT dans la bibliothèque LDAP client sous-jacente, + lorsqu'elle est disponible.
+ +Lorsque le délai est atteint, httpd va refaire un essai dans le + cas où une connexion existante a été silencieusement fermée par un + pare-feu. Les performances seront cependant bien meilleures si le + pare-feu est configuré pour envoyer des paquets TCP RST au lieu de + rejeter silencieusement les paquets.
+ +Les délais pour les opérations de comparaison LDAP nécessitent un + SDK avec LDAP_OPT_TIMEOUT, comme OpenLDAP >= 2.4.4.
+| Description: | Définit le nom de fichier contenant un certificat client ou +un alias renvoyant vers un certificat client spécifique à une connexion. +Tous les SDK LDAP ne supportent pas les certificats clients par +connexion. |
|---|---|
| Syntaxe: | LDAPTrustedClientCert type
+chemin/nom-fichier/alias [mot de passe] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_ldap |
Cette directive permet de spécifier le chemin et le nom de + fichier ou l'alias d'un certificat client par connexion utilisé lors + de l'établissement d'une connexion SSL ou TLS avec un serveur LDAP. + Les sections directory ou location peuvent posséder leurs propres + configurations de certificats clients. Certains SDK LDAP (en + particulier Novell) ne supportent pas les certificats clients par + connexion, et renvoient une erreur lors de la connexion au serveur + LDAP si vous tenter d'utiliser cette directive (Utilisez à la place + la directive LDAPTrustedGlobalCert pour les certificats clients sous + Novell - Voir plus haut le guide des certificats SSL/TLS pour plus + de détails). Le paramètre type spécifie le type du certificat en + cours de définition, en fonction du SDK LDAP utilisé. Les types + supportés sont :
+| Description: | Définit le nom de fichier ou la base de données contenant +les Autorités de Certification de confiance globales ou les certificats +clients globaux |
|---|---|
| Syntaxe: | LDAPTrustedGlobalCert type
+chemin/nom-fichier [mot de passe] |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
Cette directive permet de spécifier le chemin et le nom du
+ fichier contenant les certificats des CA de confiance et/ou les
+ certificats clients du système global que mod_ldap
+ utilisera pour établir une connexion SSL ou TLS avec un serveur
+ LDAP. Notez que toute information relative aux certificats spécifiée
+ en utilisant cette directive s'applique globalement à l'ensemble de
+ l'installation du serveur. Certains SDK LDAP (en particulier Novell)
+ nécessitent la définition globale de tous les certificats clients en
+ utilisant cette directive. La plupart des autres SDK nécessitent la
+ définition des certificats clients dans une section Directory ou
+ Location en utilisant la directive LDAPTrustedClientCert. Si vous ne
+ définissez pas ces directives correctement, une erreur sera générée
+ lors des tentatives de contact avec un serveur LDAP, ou la connexion
+ échouera silencieusement (Voir plus haut le guide des certificats
+ SSL/TLS pour plus de détails). Le paramètre type spécifie le type de
+ certificat en cours de définition, en fonction du SDK LDAP utilisé.
+ Les types supportés sont :
| Description: | Spécifie le mode (SSL ou TLS) à utiliser lors de la +connexion à un serveur LDAP. |
|---|---|
| Syntaxe: | LDAPTrustedMode type |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ldap |
Les modes suivants sont supportés :
+Les modes ci-dessus ne sont pas supportés par tous les SDK LDAP. + Un message d'erreur sera généré à l'exécution si un mode n'est pas + supporté, et la connexion au serveur LDAP échouera. +
+ +Si une URL de type ldaps:// est spécifiée, le mode est forcé à + SSL et la définition de LDAPTrustedMode est ignorée.
+ +| Description: | Force la vérification du certificat du +serveur |
|---|---|
| Syntaxe: | LDAPVerifyServerCert On|Off |
| Défaut: | LDAPVerifyServerCert On |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ldap |
Cette directive permet de spécifier s'il faut forcer la + vérification d'un certificat de serveur lors de l'établissement + d'une connexion SSL avec un serveur LDAP.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Journalisation des requêtes envoyées au +serveur |
|---|---|
| Statut: | Base |
| Identificateur de Module: | log_config_module |
| Fichier Source: | mod_log_config.c |
Ce module apporte une grande souplesse dans la journalisation des + requêtes des clients. Les journaux sont écrits sous un format + personnalisable, et peuvent être enregistrés directement dans un + fichier, ou redirigés vers un programme externe. La journalisation + conditionnelle est supportée, si bien que des requêtes individuelles + peuvent être incluses ou exclues des journaux en fonction de leur + caractéristiques.
+ +Ce module fournit trois directives : TransferLog crée un fichier
+ journal, LogFormat
+ définit un format personnalisé, et CustomLog définit un fichier journal et un format en
+ une seule étape. Pour journaliser les requêtes dans plusieurs
+ fichiers, vous pouvez utiliser plusieurs fois les directives
+ TransferLog et
+ CustomLog dans chaque serveur.
BufferedLogs CustomLog GlobalLog LogFormat TransferLogL'argument format des directives LogFormat et CustomLog est une chaîne de
+ caractères. Cette chaîne définit le format de la journalisation des
+ requêtes dans le fichier journal. Elle peut contenir des caractères
+ littéraux qui seront reproduits dans le fichier journal, et les
+ caractères de contrôle de style C "\n" et "\t" représentant
+ respectivement une nouvelle ligne et une tabulation. Les guillemets
+ et les anti-slashes littéraux doivent être échappés à l'aide
+ d'anti-slashes.
Les caractéristiques de la requête en elle-même sont journalisées
+ en insérant des directives "%" dans la chaîne de
+ format, celles-ci étant remplacées dans le fichier journal par
+ certaines valeurs comme suit :
| Chaîne de format | +Description | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
%% |
+ Le signe "pourcentage" | ||||||||||
%a |
+ L'adresse IP distante (voir le module
+ mod_remoteip). | ||||||||||
%{c}a |
+ Adresse IP distante de la connexion(voir le module
+ mod_remoteip) | ||||||||||
%A |
+ L'adresse IP locale | ||||||||||
%B |
+ La taille de la réponse en octets, en excluant les en-têtes + HTTP. | ||||||||||
%b |
+ La taille de la réponse en octets, en excluant les en-têtes
+ HTTP. Au format CLF , c'est à dire un '-' à la
+ place d'un 0 lorsqu'aucun octet n'est renvoyé. | ||||||||||
%{NOMVAR}C |
+ Le contenu du cookie NOMVAR dans la requête + envoyée au serveur. Seuls les cookies version 0 sont pleinement + supportés. | ||||||||||
%D |
+ Le temps mis à servir la requête, en + microsecondes. | ||||||||||
%{NOMVAR}e |
+ Le contenu de la variable d'environnement + NOMVAR | ||||||||||
%f |
+ Nom de fichier | ||||||||||
%h |
+ Serveur distant. Contiendra l'adresse IP si la directive
+ HostnameLookups est définie
+ à Off, ce qui est sa valeur par défaut. Si cette
+ adresse IP n'est enregistrée que pour certains serveurs, vous
+ avez probablement défini des directives de contrôle d'accès qui
+ mentionnent ces derniers par leurs noms. Voir la documentation de Require
+ host. | ||||||||||
%H |
+ Le protocole de la requête | ||||||||||
%{NOMVAR}i |
+ Le contenu des lignes d'en-tête
+ NOMVAR: dans la requête envoyée au
+ serveur. Ces en-têtes sont ajoutés par d'autres modules (par
+ exemple mod_headers). Si vous êtes intéressé
+ par ce qu'était l'en-tête de la requête avant d'être modifié
+ par la plupart des modules, utilisez
+ mod_setenvif pour copier l'en-tête dans une
+ variable d'environnement interne et journaliser sa valeur via
+ le champ %{VARNAME}e décrit plus haut.
+
+ | ||||||||||
%k |
+ Nombre de requêtes persistantes en cours pour cette
+ connexion. Interessant si la directive KeepAlive est utilisée ; par exemple,
+ '1' signifie la première requête après la requête initiale, '2'
+ la seconde, etc... ; autrement, il s'agit toujours de 0
+ (indiquant la requête initiale). | ||||||||||
%l |
+ Le nom de connexion distant (en provenance d'identd, si
+ disponible). Affiche un tiret, sauf si
+ mod_ident est présent et si IdentityCheck est à
+ On. | ||||||||||
%L |
+ L'identifiant du message de journalisation de la requête + dans le journal des erreurs (ou '-' si aucun message n'a + été enregistré dans le journal des erreurs pour cette requête) | ||||||||||
%m |
+ La méthode de la requête | ||||||||||
%{NOMVAR}n |
+ Le contenu de la note NOMVAR en provenance d'un + autre module. | ||||||||||
%{NOMVAR}o |
+ Le contenu de la ligne d'en-tête
+ NOMVAR: de la réponse. | ||||||||||
%p |
+ Le port canonique du serveur servant la requête | ||||||||||
%{format}p |
+ Le port canonique du serveur servant la requête ou le
+ véritable port du serveur ou le véritable port du client. les
+ formats valides sont canonical, local,
+ ou remote.
+ | ||||||||||
%P |
+ Le numéro de processus du processus enfant qui a servi la + requête. | ||||||||||
%{format}P |
+ Le numéro de processus ou le numéro de thread du processus
+ enfant qui a servi la requête. Les formats valides sont
+ pid, tid, et hextid.
+ hextid nécessite APR version 1.2.0 ou supérieure.
+ | ||||||||||
%q |
+ La chaîne d'arguments (préfixée par un ? si une
+ chaîne d'arguments existe, sinon une chaîne vide) | ||||||||||
%r |
+ La première ligne de la requête | ||||||||||
%R |
+ Le gestionnaire qui génère la réponse (s'il y en a un). | ||||||||||
%s |
+ Statut. Pour les requêtes redirigées en interne, il s'agit
+ du statut de la requête *originale* --- %>s pour
+ la dernière. | ||||||||||
%t |
+ Date à laquelle la requête a été reçue (au format anglais + standard) | ||||||||||
%{format}t |
+ La date, sous la forme spécifiée par format, qui devrait
+ être au format étendu strftime(3) (éventuellement
+ localisé). Si le format commence par begin: (valeur
+ par défaut), la date est extraite au début du traitement de la
+ requête ; s'il commence par end:, la date
+ correspond au moment où l'entrée du journal est inscrite, par
+ conséquent vers la fin du traitement de la requête. Hormis les
+ formats supportés par strftime(3), les formats
+ suivants sont aussi disponibles :
+
strftime(3) dans la même chaîne de
+ format. Par contre, vous pouvez utiliser plusieurs symboles
+ %{format}t. | ||||||||||
%T |
+ Le temps mis pour servir la requête, en secondes. | ||||||||||
%{UNIT}T |
+ Le temps mis pour traiter la requête dans une unité définie
+ par UNIT. Les valeurs d'unité valides sont
+ ms pour millisecondes, us pour
+ microsecondes et s pour secondes. Si
+ UNIT est omis, la valeur de l'unité par défaut est
+ la seconde ; spécifier la valeur d'unité us revient
+ à utiliser le format %D. La possibilité de
+ spécifier une valeur d'unité avec le format %T est
+ disponible depuis la version 2.4.13 du serveur HTTP Apache. | ||||||||||
%u |
+ L'utilisateur distant (en provenance d'auth ; peut être faux
+ si le statut de retour (%s) est 401). | ||||||||||
%U |
+ Le chemin de la requête, à l'exclusion de toute chaîne + d'arguments. | ||||||||||
%v |
+ Le nom canonique du serveur qui a servi la requête, défini
+ par la directive ServerName. | ||||||||||
%V |
+ La nom du serveur en tenant compte de la définition de la
+ directive UseCanonicalName. | ||||||||||
%X |
+ Statut de la connexion lorsque la réponse a été renvoyée
+ :
+
+
| ||||||||||
%I |
+ Le nombre d'octets reçus, en comptant la requête et les
+ en-têtes, ne peut être nul. Nécessite l'activation de
+ mod_logio. | ||||||||||
%O |
+ Nombre d'octets envoyés, y compris les en-têtes. Peut être
+ nul dans les rares cas où une requête est avortée avant que la
+ réponse ne soit envoyée. Nécessite l'activation de
+ mod_logio. | ||||||||||
%S |
+ Nombre d'octets transmis (en émission et réception), y
+ compris corps et en-têtes de requête. Ce nombre ne peut pas être
+ nul, et il correspond à la combinaison des formats %I et %O.
+ mod_logio doit être chargé pour pouvoir
+ utiliser ce format. | ||||||||||
%{VARNAME}^ti |
+ Le contenu de VARNAME: dans les
+ paramètres de la requête envoyée au serveur. | ||||||||||
%{VARNAME}^to |
+ Le contenu de VARNAME: dans les
+ paramètres de la réponse envoyée par le serveur. |
Il est possible de restreindre l'enregistrement de certains
+ éléments
+ en fonction du code de statut de la réponse, en insérant une liste
+ de codes de statut séparés par des virgules immédiatement après le
+ caractère "%". Par exemple, "%400,501{User-agent}i"
+ n'enregistrera l'en-tête User-agent que dans le cas
+ d'une erreur 400 ou 501. Avec les autres codes de statut, c'est la
+ chaîne littérale "-" qui sera enregistrée. La liste
+ de codes peut être précédée d'un "!" pour inverser la
+ condition : "%!200,304,302{Referer}i" enregistre
+ l'en-tête Referer pour toutes les requêtes qui
+ ne renvoient pas un des trois codes spécifiés.
Les modificateurs "<" et ">" peuvent être utilisés pour
+ les requêtes qui ont été redirigées en interne afin de choisir si
+ c'est respectivement la requête originale ou finale qui doit être
+ consultée. Par défaut, les directives %s, %U, %T, %D,
+ et %r consultent la requête originale, alors que
+ toutes les autres consultent la requête finale. Ainsi, par
+ exemple, on peut utiliser %>s pour enregistrer le
+ statut final de la requête, et %<u pour
+ enregistrer l'utilisateur authentifié à l'origine pour une requête
+ redirigée en interne vers une ressource sans authentification.
Pour des raisons de sécurité, à partir de la version 2.0.46,
+ les caractères non imprimables et autres caractères spéciaux dans
+ les directives %r, %i et %o
+ doivent être échappés à l'aide des séquences
+ \xhh,
+ où hh est le code hexadécimal du caractère spécial.
+ Comme exceptions à cette règle, les caractères " et
+ \ doivent être échappés par un anti-slash, et tous
+ les "blancs" doivent être écrits selon leur notation de style C
+ (\n, \t, etc...). Avant la version
+ 2.0.46, aucun échappement n'était effectué sur ces chaînes, et il
+ fallait être très prudent lors de l'exploitation des journaux
+ bruts.
A la différence de la version 1.3, depuis httpd 2.0, les chaînes
+ de format %b et %B ne représentent pas
+ le nombre d'octets envoyés au client, mais simplement la taille en
+ octets de la réponse HTTP (les deux étant différents, par exemple,
+ si la connexion est abandonnée, ou si SSL est utilisé). Le format
+ %O fourni par mod_logio,
+ enregistrera le nombre réel d'octets envoyés sur le réseau.
Note : mod_cache est implémenté en tant que
+ gestionnaire basique et non en tant que gestionnaire standard.
+ C'est pourquoi la chaîne de format %R ne renverra pas
+ d'information à propos du gestionnaire lorsqu'une mise en cache de
+ contenu entre en jeu.
Quelques chaînes de format couramment utilisées :
+ +"%h %l %u %t \"%r\" %>s %b""%v %h %l %u %t \"%r\" %>s %b""%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
+ \"%{User-agent}i\"""%{Referer}i -> %U""%{User-agent}i"Vous pouvez utiliser plusieurs fois la directive
+ %{format}t pour construire un format de temps
+ utilisant les symboles de format étendus tels que
+ msec_frac :
"%{%d/%b/%Y %T}t.%{msec_frac}t %{%z}t"Voir le document conseils à matière de + sécurité pour plus de détails sur les raisons pour lesquelles + votre sécurité pourrait être compromise, si le répertoire où sont + stockés les fichiers journaux sont inscriptibles par tout autre + utilisateur que celui qui démarre le serveur.
+| Description: | Enregistre les entrées du journal dans un tampon en mémoire +avant de les écrire sur disque |
|---|---|
| Syntaxe: | BufferedLogs On|Off |
| Défaut: | BufferedLogs Off |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_log_config |
Lorsque la directive BufferedLogs est à
+ "on", mod_log_config stocke de nombreuses entrées
+ du journal en mémoire, et les écrit d'un seul bloc sur disque,
+ plutôt que de les écrire après chaque requête. Sur certains
+ systèmes, ceci peut améliorer l'efficacité des accès disque, et par
+ conséquent les performances. La directive ne peut être définie
+ qu'une seule fois pour l'ensemble du serveur ; elle ne peut pas être
+ définie au niveau d'un serveur virtuel.
| Description: | Définit le nom et le format du fichier +journal |
|---|---|
| Syntaxe: | CustomLog fichier|pipe
+format|alias
+[env=[!]variable-environnement|
+expr=expression] |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_log_config |
La directive CustomLog permet de contrôler
+ la journalisation des requêtes destinées au serveur. Un format de
+ journal est spécifié, et la journalisation peut s'effectuer de
+ manière conditionnelle en fonction des caractéristiques de la
+ requête en utilisant des variables d'environnement.
Le premier argument, qui spécifie l'emplacement où les journaux + seront écrits, accepte deux types de valeurs :
+ +ServerRoot.|", suivi du chemin vers un
+ programme qui recevra les informations de la journalisation sur
+ son entrée standard. Voir les notes à propos de la journalisation redirigée pour plus
+ d'informations.
+
+ Si les journaux sont redirigés vers un programme, ce dernier
+ s'exécutera sous l'utilisateur qui a démarré
+ httpd. Ce sera l'utilisateur root si le serveur
+ a été démarré par root ; vérifiez que le programme est
+ sécurisé.
Lors de la spécification d'un chemin de fichier sur les + plate-formes non-Unix, il faut prendre soin de ne pas oublier + que seuls les slashes directs doivent être utilisés, même si la + plate-forme autorise l'emploi d'anti-slashes. D'une manière + générale, c'est une bonne idée que de n'utiliser que des slashes + directs dans les fichiers de configuration.
+Le second argument permet de définir ce qui va être écrit dans le
+ fichier journal. Il peut contenir soit un alias prédéfini
+ par une directive LogFormat, soit une chaîne de
+ format explicite comme décrit dans la section formats de journaux.
Par exemple, les deux blocs de directives suivants produisent le + même effet :
+ +# Journal personnalisé avec alias de format +LogFormat "%h %l %u %t \"%r\" %>s %b" common +CustomLog "logs/access_log" common + +# Journal personnalisé avec chaîne de format explicite +CustomLog "logs/access_log" "%h %l %u %t \"%r\" %>s %b"+ + +
Le troisième argument est optionnel et permet de contrôler si une
+ requête doit être ou non journalisée. Dans le cas d'une clause
+ 'env=!nom', la condition peut être la
+ présence ou l'absence d'une variable particulière dans
+ l'environnement du serveur. Dans le cas
+ d'une clause 'expr=expression', la condition consiste
+ en une expression booléenne
+ quelconque. Si la condition n'est pas vérifiée, la requête ne sera
+ pas journalisée. D'éventuelles références à des en-têtes HTTP dans
+ l'expression rationnelle n'entraîneront pas l'ajout des noms
+ d'en-tête correspondants à l'en-tête Vary.
Les variables d'environnement peuvent être définies au niveau de
+ chaque requête en utilisant les modules
+ mod_setenvif et/ou mod_rewrite.
+ Par exemple, si vous voulez enregistrer les requêtes pour toutes les
+ images GIF sur votre serveur dans un fichier journal séparé, et pas
+ dans votre journal principal, vous pouvez utiliser :
SetEnvIf Request_URI \.gif$ gif-image +CustomLog "gif-requests.log" common env=gif-image +CustomLog "nongif-requests.log" common env=!gif-image+ + +
Ou, pour reproduire le comportement de l'ancienne directive + RefererIgnore, vous pouvez utiliser :
+ +SetEnvIf Referer example\.com localreferer +CustomLog "referer.log" referer env=!localreferer+ + +
| Description: | Définit le nom et le format du fichier journal |
|---|---|
| Syntaxe: | GlobalLogfile|pipe
+format|nickname
+[env=[!]environment-variable|
+expr=expression] |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_log_config |
| Compatibilité: | Disponible à partir de la version 2.4.19 du serveur HTTP Apache |
La directive GlobalLog permet de spécifier un
+ journal partagé entre le serveur principal et tous les serveurs virtuels
+ définis.
Elle est identique à la directive CustomLog à ces
+ différences près :
CustomLog
+ définie globalement, elle est prise en compte par les serveurs virtuels
+ qui définissent leur propre directive CustomLog.| Description: | Décrit un format utilisable dans un fichier +journal |
|---|---|
| Syntaxe: | LogFormat format|alias
+[alias] |
| Défaut: | LogFormat "%h %l %u %t \"%r\" %>s %b" |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_log_config |
Cette directive permet de spécifier le format du fichier journal + des accès.
+ +La directive LogFormat se présente sous
+ deux formes. Sous la première forme, qui ne possède qu'un seul
+ argument, la directive définit le format qui sera utilisé dans les
+ journaux spécifiés par les directives
+ TransferLog ultérieures. L'argument unique
+ peut contenir un format explicite comme décrit dans la
+ section formats de journaux personnalisés
+ ci-dessus. Il peut aussi contenir un alias faisant
+ référence à un format de journal prédéfini par une directive
+ LogFormat comme décrit plus loin.
Sous sa seconde forme, la directive
+ LogFormat associe un format
+ explicite à un alias. Cet alias peut
+ ensuite s'utiliser dans les directives
+ LogFormat ou CustomLog ultérieures, ce qui
+ évite d'avoir à répéter l'ensemble de la chaîne de format. Une
+ directive LogFormat qui définit un alias
+ ne fait rien d'autre -- c'est à dire qu'elle ne
+ fait que définir l'alias, elle n'applique pas le format et n'en
+ fait pas le format par défaut. Par conséquent, elle n'affecte pas
+ les directives TransferLog ultérieures. En
+ outre, la directive LogFormat ne peut pas
+ utiliser un alias pour en définir un autre. Notez que l'alias ne
+ doit pas contenir de caractère pourcent (%).
LogFormat "%v %h %l %u %t \"%r\" %>s %b" serveur_virtuel_commun+
| Description: | Spécifie l'emplacement d'un fichier journal |
|---|---|
| Syntaxe: | TransferLog fichier|pipe |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_log_config |
Cette directive possède exactement les mêmes arguments et produit
+ les mêmes effets que la directive CustomLog, à l'exception qu'elle
+ ne permet pas de spécifier un format de journal explicite ou la
+ journalisation conditionnelle des requêtes. En l'occurrence, le
+ format de journal est déterminé par la dernière définition d'une
+ directive LogFormat
+ qui ne définit pas d'alias. Si aucun format particulier n'a été
+ spécifié, c'est le Common Log Format qui sera utilisé.
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
+TransferLog logs/access_log
+Serveur HTTP Apache Version 2.4
+| Description: | Journalisation supplémentaire à des fins de débogage |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | log_debug_module |
| Fichier Source: | mod_log_debug.c |
| Compatibilité: | Disponible depuis la version 2.3.14 d'Apache |
<Location "/foo/"> + LogMessage "/foo/ has been requested" +</Location>+ +
<Location "/foo/">
+ LogMessage "subrequest to /foo/" hook=type_checker "expr=-T %{IS_SUBREQ}"
+</Location>
+
+
+ Le branchement (hook) par défaut log_transaction n'est pas
+ exécuté pour les sous-requêtes ; nous devons donc en utiliser un
+ autre.
+ LogMessage "IPv6 timeout from %{REMOTE_ADDR}" "expr=-T %{IPV6} && %{REQUEST_STATUS} = 408"
+
+ Notez l'emplacement des guillemets pour l'argument
+ expr=.
+ <Location "/">
+ LogMessage "%{reqenv:X-Foo}" hook=all
+</Location>
+
+ En association avec les repères de temps en microsecondes du journal des erreurs,
+ hook=all permet aussi de déterminer la durée d'exécution des
+ différentes phases du traitement de la requête.
+ | Description: | Enregistre des messages personnalisés dans le journal des +erreurs |
|---|---|
| Syntaxe: | LogMessage message
+[hook=hook] [expr=expression]
+ |
| Défaut: | Non défini |
| Contexte: | répertoire |
| Statut: | Expérimental |
| Module: | mod_log_debug |
Cette directive permet d'enregistrer un message personnalisé dans + le journal des erreurs. Ce message peut utiliser des variables et + des fonctions dans la syntaxe ap_expr. + D'éventuelles références à des en-têtes HTTP dans l'expression + rationnelle n'entraîneront pas l'ajout des noms d'en-tête + correspondants à l'en-tête Vary. + Les messages sont enregistrés au loglevel info.
+ +Le branchement (hook) précise la phase du traitement de la + requête avant laquelle le message sera enregistré. Les branchements + suivants sont supportés :
+ +| Nom |
|---|
translate_name |
type_checker |
quick_handler |
map_to_storage |
check_access |
check_access_ex |
insert_filter |
check_authn |
check_authz |
fixups |
handler |
log_transaction |
Le branchement par défaut est log_transaction. La
+ valeur spéciale all est également supportée ; dans ce cas,
+ le message sera enregistré à chaque phase. Tous les branchements ne
+ sont pas exécutés pour chaque requête.
L'expression optionnelle permet de restreindre l'enregistrement + du message en fonction d'une certaine condition. La syntaxe de + l'expression est décrite dans la documentation ap_expr. D'éventuelles + références à des en-têtes HTTP dans l'expression + rationnelle n'entraîneront pas l'ajout des noms d'en-tête + correspondants à l'en-tête Vary.
+ + +Serveur HTTP Apache Version 2.4
+| Description: | Journalisation légale des requêtes envoyées au +serveur |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | log_forensic_module |
| Fichier Source: | mod_log_forensic.c |
| Compatibilité: | mod_unique_id n'est plus obligatoire
+depuis la version 2.1 |
Ce module permet la journalisation légale des requêtes client. La + journalisation s'effectuant avant et après le traitement de la + requête, le journal légal contient deux lignes pour chaque requête. + Le processus de journalisation légale est très strict, à savoir + :
+ +CoreDumpDirectory).Pour interpréter les données du journal légal, vous pouvez vous
+ aider du script check_forensic qui se trouve dans le
+ répertoire support de la distribution.
Chaque requête fait l'objet d'une double journalisation. La + requête est journalisée une première fois avant son traitement + (c'est à dire après la réception des en-têtes). La deuxième entrée + du journal est écrite après le traitement de la requête, en + fait au moment de la journalisation habituelle.
+ +Un identifiant unique est attribué à chaque requête afin de
+ pouvoir l'identifier. Cette identifiant légal peut faire l'objet
+ d'un enregistrement dans le journal standard en utilisant l'élément
+ de chaîne de format %{forensic-id}n. Si vous utilisez
+ mod_unique_id, c'est l'identifiant qu'il génère qui
+ sera utilisé.
La première partie de la journalisation de la requête enregistre
+ l'identifiant légal, la ligne de la requête et tous les en-têtes
+ reçus séparés par des caractères pipe (|). Voici à
+ titre d'exemple à quoi pourrait ressembler une telle entrée (tout
+ étant rassemblé sur une seule ligne) :
+ +yQtJf8CoAB4AAFNXBIEAAAAA|GET /manual/de/images/down.gif
+ HTTP/1.1|Host:localhost%3a8080|User-Agent:Mozilla/5.0 (X11;
+ U; Linux i686; en-US; rv%3a1.6) Gecko/20040216
+ Firefox/0.8|Accept:image/png, etc...
+
Le caractère plus ('+') de début indique qu'il s'agit de la + première entrée de journal pour cette requête. La seconde entrée ne + contiendra qu'un caractère moins ('-') suivi de l'identifiant :
+ +
+ -yQtJf8CoAB4AAFNXBIEAAAAA
+
Le script check_forensic prend comme argument le nom
+ du fichier journal. Il recherche ces paires d'identifiants
+ +/- et affiche un message d'erreur si la
+ journalisation d'une requête n'est pas complète.
Voir le document conseils en matière de + sécurité pour des détails sur les raisons pour lesquelles votre + sécurité pourrait être compromise si le répertoire dans lequel les + fichiers journaux sont stockés sont inscriptibles par tout autre + utilisateur que celui qui démarre le serveur.
+Les fichiers journaux peuvent contenir des données sensibles
+ comme le contenu des en-têtes Authorization: (qui
+ peuvent contenir des mots de passe) ; ils ne doivent donc être
+ lisibles que par l'utilisateur qui démarre le serveur.
| Description: | Définit le nom de fichier du journal légal |
|---|---|
| Syntaxe: | ForensicLog nom-fichier|pipe |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_log_forensic |
La directive ForensicLog permet de
+ contrôler la journalisation des requêtes à des fins d'analyse
+ légale. Chaque entrée du journal se voit assigner un identifiant
+ unique qui peut être associé à la requête en utilisant la directive
+ CustomLog habituelle.
+ mod_log_forensic crée un élément nommé
+ forensic-id, qui peut être ajouté au journal standard
+ en utilisant l'élément de format %{forensic-id}n.
L'argument, qui permet de spécifier l'emplacement vers lequel le + journal légal sera écrit, peut contenir les deux types de valeurs + suivants :
+ +ServerRoot.|", suivi du chemin vers un
+ programme qui recevra les informations de la journalisation sur
+ son entrée standard. Le nom du programme peut être relatif au
+ répertoire défini par la directive ServerRoot.
+
+ Si les journaux sont redirigés vers un programme, ce dernier
+ s'exécutera sous l'utilisateur qui a démarré
+ httpd. Ce sera l'utilisateur root si le serveur
+ a été démarré par root ; vérifiez que le programme est
+ sécurisé ou passe sous le contrôle d'un utilisateur possédant des
+ droits restreints.
Lors de la spécification d'un chemin de fichier sur les + plate-formes non-Unix, il faut prendre soin de ne pas oublier + que seuls les slashes directs doivent être utilisés, même si la + plate-forme autorise l'emploi d'anti-slashes. D'une manière + générale, c'est une bonne idée que de n'utiliser que des slashes + directs dans les fichiers de configuration.
+Serveur HTTP Apache Version 2.4
+| Description: | Journalisation des octets en entrée et en sortie pour +chaque requête |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | logio_module |
| Fichier Source: | mod_logio.c |
Ce module permet d'enregistrer le nombre d'octets reçus et + envoyés pour chaque requête. Ce nombre reflète le nombre réel + d'octets transmis sur le réseau, et prend en compte les en-têtes et + corps des requêtes et des réponses. Le décompte est effectué avant + SSL/TLS en entrée et après SSL/TLS en sortie, si bien que le + résultat reflètera toute modification introduite par le + chiffrement.
+ +Pour fonctionner, ce module requiert le chargement du module
+ mod_log_config.
Ce module introduit trois nouvelles directives de journalisation.
+ Les caractéristiques de la requête en elle-même sont journalisées en
+ insérant des directives "%" dans la chaîne de format,
+ qui seront remplacées comme suit dans le fichier journal :
| Chaîne de Format | +Description |
|---|---|
%I |
+ Octets reçus, en-têtes et corps de requête inclus ; ne peut + pas être nul. |
%O |
+ Octets envoyés, en-têtes inclus ; ne peut + pas être nul. |
%S |
+ Nombre d'octets transmis (en émission et réception), y
+ compris corps et en-têtes de requête. Ce nombre ne peut pas être
+ nul, et il correspond à la combinaison des formats %I et %O. + Disponible depuis la version 2.4.7 du serveur HTTP Apache. |
%^FB |
+ Délai en microsecondes entre l'arrivée de la requête et
+ l'écriture du premier octet des en-têtes de la réponse.
+ Disponible uniquement si la directive
+ LogIOTrackTTFB a été définie à ON.+ Disponible à partir de la version 2.4.13 du serveur HTTP Apache + |
En général, cette fonctionnalité s'utilise comme suit :
+ +"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
+ \"%{User-agent}i\" %I %O"| Description: | Permet d'enregistrer le délai avant le premier octet (time +to first byte - TTFB) |
|---|---|
| Syntaxe: | LogIOTrackTTFB ON|OFF |
| Défaut: | LogIOTrackTTFB OFF |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_logio |
| Compatibilité: | Disponible à partir de la version 2.4.13 du serveur HTTP +Apache |
Cette directive permet de définir si ce module mesure le délai
+ entre la lecture de la requête et l'écriture du premier octet des
+ en-têtes de la réponse. La valeur obtenue peut être enregistrée dans
+ le journal via le format %^FB.
Serveur HTTP Apache Version 2.4
+| Description: | Fournit des points d'entrée Lua dans différentes parties du +traitement des requêtes httpd |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | lua_module |
| Fichier Source: | mod_lua.c |
| Compatibilité: | versions 2.3 et supérieures |
Ce module permet d'ajouter au serveur des extensions sous forme de
+scripts écrits dans le langage de programmation Lua.
+mod_lua fournit de nombreuses extensions
+(hooks) disponibles avec les modules natifs du serveur HTTP Apache,
+comme les associations de requêtes à des fichiers, la génération de
+réponses dynamiques, le contrôle d'accès, l'authentification et
+l'autorisation.
Vous trouverez davantage d'informations à propos du langage de +programmation Lua sur le site web de +Lua.
+ +mod_lua est encore au stade expérimental. Son mode
+d'utilisation et son comportement pourront changer à tout moment jusqu'à
+ce qu'il passe au stade stable, et ce même entre deux versions stables
+2.4.x. N'oublez pas de consulter le fichier CHANGES avant toute mise à
+jour.Ce module possède une grande capacité d'action sur le fonctrionnement +de httpd, ce qui lui confère une grande puissance, mais peut aussi +induire un risque de sécurité. Il est déconseillé d'utiliser ce module +sur un serveur partagé avec des utilisateurs auxquels vous ne pouvez pas +accorder une confiance absolue, car il peut permettre de modifier le +fonctionnement interne de httpd.
+ Configuration de base Ecrire des gestionnaires Ecriture de fournisseurs d'autorisation Ecriture de fonctions d'accroche
+(hooks) Structures de données Méthodes de l'objet request_rec Fonctions de journalisation Paquet apache2 Modification de contenu avec les filtres lua Connectivité aux bases de données LuaAuthzProvider LuaCodeCache LuaHookAccessChecker LuaHookAuthChecker LuaHookCheckUserID LuaHookFixups LuaHookInsertFilter LuaHookLog LuaHookMapToStorage LuaHookTranslateName LuaHookTypeChecker LuaInherit LuaInputFilter LuaMapHandler LuaOutputFilter LuaPackageCPath LuaPackagePath LuaQuickHandler LuaRoot LuaScopeLa directive de base pour le chargement du module est
+ +LoadModule lua_module modules/mod_lua.so+ + +
+mod_lua fournit un gestionnaire nommé
+lua-script qui peut être utilisé avec une directive
+AddHandler ou SetHandler :
<Files "*.lua"> + SetHandler lua-script +</Files>+ + +
+Ceci aura pour effet de faire traiter les requêtes pour les fichiers
+dont l'extension est .lua par mod_lua en
+invoquant cette fonction de gestion de fichier.
+
Pour plus de détails, voir la directive
+LuaMapHandler.
+
Dans l'API du serveur HTTP Apache, un gestionnaire est une sorte de
+point d'accroche (hook) spécifique responsable de la génération de la
+réponse. mod_proxy, mod_cgi et
+mod_status sont des exemples de modules comportant un
+gestionnaire.
mod_lua cherche toujours à invoquer une fonction Lua pour le
+gestionnaire, plutôt que de simplement évaluer le corps d'un script dans
+le style de CGI. Une fonction de gestionnaire se présente comme suit :
+example.lua+ + +
+-- exemple de gestionnaire + +require "string" + +--[[ + Il s'agit du nom de méthode par défaut pour les gestionnaires Lua ; + voir les noms de fonctions optionnels dans la directive + LuaMapHandler pour choisir un point d'entrée différent. +--]] +function handle(r) + r.content_type = "text/plain" + + if r.method == 'GET' then + r:puts("Hello Lua World!\n") + for k, v in pairs( r:parseargs() ) do + r:puts( string.format("%s: %s\n", k, v) ) + end + elseif r.method == 'POST' then + r:puts("Hello Lua World!\n") + for k, v in pairs( r:parsebody() ) do + r:puts( string.format("%s: %s\n", k, v) ) + end + else + elseif r.method == 'PUT' then +-- message d'erreur personnalisé + r:puts("Unsupported HTTP method " .. r.method) + r.status = 405 + return apache2.OK + else +-- message d'erreur ErrorDocument + return 501 + end + return apache2.OK +end
+Ce gestionnaire se contente d'afficher les arguments codés d'un uri ou +d'un formulaire dans un page au format texte. +
+ ++Cela signifie que vous pouvez (et êtes encouragé à) avoir plusieurs +gestionnaires (ou points d'entrée, ou filtres) dans le même script. +
+ +mod_authz_core fournit une interface d'autorisation
+de haut niveau bien plus facile à utiliser que dans les hooks
+correspondants. Le premier argument de la directive Require permet de spécifier le
+fournisseur d'autorisation à utiliser. Pour chaque directive Require,
+mod_authz_core appellera le fournisseur d'autorisation
+spécifié, le reste de la ligne constituant les paramètres. Le
+fournisseur considéré va alors vérifier les autorisations et fournir le
+résultat dans une valeur de retour.
En général, le fournisseur authz est appelé avant l'authentification.
+S'il doit connaître le nom d'utilisateur authentifié (ou si
+l'utilisateur est appelé à être authentifié), le fournisseur doit
+renvoyer apache2.AUTHZ_DENIED_NO_USER, ce qui va
+déclancher le processus d'authentification et un deuxième appel du
+fournisseur authz.
La fonction du fournisseur authz ci-dessous accepte deux arguments, +une adresse IP et un nom d'utilisateur. Elle autorise l'accès dans le +cas où la requête provient de l'adresse IP spécifiée, ou si +l'utilisateur authentifié correspond au second argument :
+ ++authz_provider.lua+ + +
+ +require 'apache2' + +function authz_check_foo(r, ip, user) + if r.useragent_ip == ip then + return apache2.AUTHZ_GRANTED + elseif r.user == nil then + return apache2.AUTHZ_DENIED_NO_USER + elseif r.user == user then + return apache2.AUTHZ_GRANTED + else + return apache2.AUTHZ_DENIED + end +end
La configuration suivante enregistre cette fonction en tant que
+fournisseur foo, et la configure por l'URL / :
LuaAuthzProvider foo authz_provider.lua authz_check_foo +<Location "/"> + Require foo 10.1.2.3 john_doe +</Location>+ + +
Les fonctions d'accroche déterminent la manière dont les modules (et +les scripts Lua) participent au traitement des requêtes. Chaque type +d'accroche proposé par le serveur a un rôle spécifique, comme +l'association de requêtes au système de fichiers, le contrôle d'accès, +ou la définition de types MIME :
+ +| Phase d'accroche | +Directive mod_lua | +Description | +
|---|---|---|
| Gestionnaire rapide | +LuaQuickHandler |
+ Il s'agit de la première accroche appelée lorsqu'une requête + a été associée à un serveur ou un serveur virtuel. | +
| Phase de traduction | +LuaHookTranslateName |
+ Cette phase traduit l'URI de la requête en nom de fichier
+ sur le système. Ce sont des modules comme
+ mod_alias et mod_rewrite qui
+ interviennent au cours de cette phase. |
+
| Choix du lieu de stockage de la ressource | +LuaHookMapToStorage |
+ Cette phase définit le lieu de stockage de la ressource : + physique, en cache ou externe/mandaté. Elle est assurée par les + modules de mandat ou de mise en cache. | +
| Autorisation d'accès | +LuaHookAccessChecker |
+ Cette phase vérifie si un client a l'autorisation d'accès à + la ressource. Elle s'exécute avant l'authentification de + l'utisateur ; il faut donc être prudent. + | +
| Vérification de l'identifiant utilisateur | +LuaHookCheckUserID |
+ Cette phase vérifie l'identifiant de l'utilisateur ayant + fait l'objet d'une négociation. | +
| Vérification de l'autorisation d'accès | +LuaHookAuthChecker
+ ou
+ LuaAuthzProvider |
+ Cette phase vérifie l'autorisation d'accès d'un utilisateur + en fonction des ses paramètres de connexion, comme + l'identifiant, le certificat, etc... + | +
| Vérification du type de la ressource | +LuaHookTypeChecker |
+ Cette phase assigne un type de contenu et un gestionnaire à + la ressource. | +
| Derniers réglages | +LuaHookFixups |
+ C'est la dernière phase avant l'activation des gestionnaires + de contenu. Toute modification de dernière minute à la requête + doit être effectuée ici. | +
| Gestionnaire de contenu | +fichiers fx. .lua ou directive LuaMapHandler |
+ C'est durant cette phase que le contenu est traité. Les + fichiers sont lus, interprétés, certains sont exécutés, et le + résultat obtenu est envoyé au client. | +
| Journalisation | +LuaHookLog |
+ Lorsqu'une requête a été traitée, plusieurs phases de + journalisation interviennent, et enregistrent leurs résultats + dans les fichiers d'erreur ou d'accès. Mod_lua peut + s'intercaler au départ de ce processus et ainsi contrôler la + journalisation. | +
Les fonctions d'accroche reçoivent l'objet de la requête comme seul
+argument (sauf LuaAuthzProvider qui reçoit aussi des arguments en
+provenance de la directive Require). Elles peuvent renvoyer une valeur,
+selon la fonction, mais il s'agit en général d'un
+code d'état HTTP ou des valeurs OK, DONE, ou DECLINED,
+que vous pouvez écrire dans Lua sous la forme apache2.OK,
+apache2.DONE, ou apache2.DECLINED.
+translate_name.lua+ + + +
+-- exemple d'accroche qui réécrit un URI en chemin du système de fichiers. + +require 'apache2' + +function translate_name(r) + if r.uri == "/translate-name" then + r.filename = r.document_root .. "/find_me.txt" + return apache2.OK + end + -- on ne gère pas cette URL et on donne sa chance à un autre module + return apache2.DECLINED +end
+translate_name2.lua+ +
+--[[ exemple d'accroche qui réécrit un URI vers un autre URI. Il renvoie + un apache2.DECLINED pour permettre à un autre interpréteur d'URL de + travailler sur la substitution, y compris l'accroche translate_name + de base dont les tables de correspondances se basent sur DocumentRoot. + + Note: utilisez le drapeau early/late de la directive pour + l'exécuter avant ou après mod_alias. +--]] + +require 'apache2' + +function translate_name(r) + if r.uri == "/translate-name" then + r.uri = "/find_me.txt" + return apache2.DECLINED + end + return apache2.DECLINED +end
request_rec est considérée en tant que donnée utilisateur. + Elle possède une métatable qui vous permet d'accomplir des + choses intéressantes. Pour la plus grande partie, elle possède + les mêmes champs que la structure request_rec, la + plupart d'entre eux étant accessibles en lecture et écriture (le + contenu des champs de la table peut être modifié, mais les + champs eux-mêmes ne peuvent pas être établis en tant que tables + distinctes).
+ +| Nom | +Type Lua | +Modifiable | +Description | +
|---|---|---|---|
allowoverrides |
+ string | +non | +L'option AllowOverride s'applique à la requête courante. | +
ap_auth_type |
+ string | +non | +Ce champ contient le type d'authentification effectuée
+ (par exemple basic) |
+
args |
+ string | +oui | +La chaîne de paramètres de la requête (par exemple
+ foo=bar&name=johnsmith) |
+
assbackwards |
+ boolean | +non | +contient true s'il s'agit d'une requête de style HTTP/0.9
+ (par exemple GET /foo (sans champs d'en-tête) ) |
+
auth_name |
+ string | +non | +La chaîne d'identification utilisée pour la vérification + de l'autorisation d'accès (si elle est disponible). | +
banner |
+ string | +non | +La bannière du serveur, par exemple Apache HTTP
+ Server/2.4.3 openssl/0.9.8c |
+
basic_auth_pw |
+ string | +non | +Le mot de passe pour l'authentification de base envoyé + avec la requête, s'il existe | +
canonical_filename |
+ string | +non | +Le nom de fichier canonique de la requête | +
content_encoding |
+ string | +non | +Le type de codage du contenu de la requête courante | +
content_type |
+ string | +oui | +Le type de contenu de la requête courante, tel qu'il a été
+ déterminé au cours de la phase type_check (par exemple
+ image/gif ou text/html) |
+
context_prefix |
+ string | +non | ++ |
context_document_root |
+ string | +non | ++ |
document_root |
+ string | +non | +La racine des documents du serveur | +
err_headers_out |
+ table | +non | +L'en-tête MIME de l'environnement pour la réponse, écrit + même en cas d'erreur et conservé pendant les redirections + internes | +
filename |
+ string | +oui | +Le nom de fichier correspondant à la requête, par exemple + /www/example.com/foo.txt. Il peut être modifié au cours des + phases translate-name ou map-to-storage du traitement de la + requête pour permettre au gestionnaire par défaut (ou aux + gestionnaires de script) de servir une version du fichier + autre que celle demandée. | +
handler |
+ string | +oui | +Le nom du gestionnaire qui
+ doit traiter la requête, par exemple lua-script
+ si elle doit être traitée par mod_lua. Cette valeur est en
+ général définie via les directives AddHandler ou SetHandler, mais peut aussi l'être
+ via mod_lua pour permettre à un autre gestionnaire de traiter
+ une requête spécifique qui ne serait pas traitée par défaut
+ par ce dernier.
+ |
+
headers_in |
+ table | +oui | +Les en-têtes MIME de l'environnement de la requête. Il
+ s'agit des en-têtes comme Host, User-Agent,
+ Referer, etc... |
+
headers_out |
+ table | +oui | +Les en-têtes MIME de l'environnement de la réponse. | +
hostname |
+ string | +non | +Le nom d'hôte, tel que défini par l'en-tête
+ Host: ou par un URI complet. |
+
is_https |
+ boolean | +non | +Indique si la requête à été faite via HTTPS | +
is_initial_req |
+ boolean | +non | +Indique si la requête courante est la requête initiale ou + une sous-requête. | +
limit_req_body |
+ number | +non | +La taille maximale du corps de la requête, ou 0 si aucune + limite. | +
log_id |
+ string | +non | +L'identifiant de la requête dans les journaux d'accès ou + d'erreur. | +
method |
+ string | +non | +La méthode de la requête, par exemple GET ou
+ POST. |
+
notes |
+ table | +oui | +Une liste de notes qui peuvent être transmises d'un module + à l'autre. | +
options |
+ string | +non | +La valeur de la directive Options pour la requête + courante. | +
path_info |
+ string | +non | +La valeur de PATH_INFO extraite de la requête. | +
port |
+ number | +non | +Le port du serveur utilisé par la requête. | +
protocol |
+ string | +non | +Le protocole utilisé, par exemple HTTP/1.1 |
+
proxyreq |
+ string | +oui | +Indique s'il s'agit d'une requête mandatée ou non. Cette + valeur est en général définie au cours de la phase + post_read_request/translate_name du traitement de la requête. | +
range |
+ string | +non | +Le contenu de l'en-tête Range:. |
+
remaining |
+ number | +non | +Le nombre d'octets du corps de la requête restant à lire. | +
server_built |
+ string | +non | +La date de compilation du serveur. | +
server_name |
+ string | +non | +Le nom du serveur pour cette requête. | +
some_auth_required |
+ boolean | +non | +Indique si une autorisation est/était requise pour cette + requête. | +
subprocess_env |
+ table | +oui | +Le jeu de variables d'environnement pour cette requête. | +
started |
+ number | +non | +Le moment où le serveur a été (re)démarré, en secondes + depuis epoch (1er janvier 1970) | +
status |
+ number | +oui | +Le code de retour (courant) pour cette requête, par
+ exemple 200 ou 404. |
+
the_request |
+ string | +non | +La chaîne de la requête telle qu'elle a été envoyée par le
+ client, par exemple GET /foo/bar HTTP/1.1. |
+
unparsed_uri |
+ string | +non | +La partie URI non interprétée de la requête | +
uri |
+ string | +oui | +L'URI après interprétation par httpd | +
user |
+ string | +oui | +Si une authentification a été effectuée, nom de + l'utilisateur authentifié. | +
useragent_ip |
+ string | +non | +L'adresse IP de l'agent qui a envoyé la requête | +
L'objet request_rec possède (au minimum) les méthodes suivantes :
+ +r:flush() -- vide le tampon de sortie
+ -- Renvoie true si le vidage a été effectué avec succès,
+ -- false dans le cas contraire.
+
+while nous_avons_des_données_à_envoyer do
+ r:puts("Bla bla bla\n") -- envoi des données à envoyer vers le tampon
+ r:flush() -- vidage du tampon (envoi au client)
+ r.usleep(500000) -- mise en attente pendant 0.5 secondes et bouclage
+end
+
+
+r:add_output_filter(filter_name) -- ajoute un filtre en sortie
+
+r:add_output_filter("fooFilter") -- insère le filtre fooFilter dans le flux de sortie
+
+
+r:sendfile(filename) -- envoie un fichier entier au client en utilisant sendfile s'il est
+ -- supporté par la plateforme :
+
+if use_sendfile_thing then
+ r:sendfile("/var/www/large_file.img")
+end
+
+
+r:parseargs() -- renvoie deux tables : une table standard de couples
+ -- clé/valeur pour les données GET simples,
+ -- et une autre pour les données
+ -- multivaluées (par exemple foo=1&foo=2&foo=3) :
+
+local GET, GETMULTI = r:parseargs()
+r:puts("Votre nom est : " .. GET['name'] or "Unknown")
+
+
+
+r:parsebody()([sizeLimit]) -- interprète le corps de la
+ -- requête en tant que POST et renvoie
+ -- deux tables lua, comme r:parseargs(). Un
+ -- nombre optionnel peut être fourni
+ -- pour spécifier le nombre maximal
+ -- d'octets à interpréter. La
+ -- valeur par défaut est 8192.
+
+local POST, POSTMULTI = r:parsebody(1024*1024)
+r:puts("Votre nom est : " .. POST['name'] or "Unknown")
+
+
+
+r:puts("bonjour", " le monde", "!") -- affichage dans le corps de la réponse
+
+
+r:write("une simple chaîne") -- affichage dans le corps de la réponse
+
+
+r:escape_html("<html>test</html>") -- Echappe le code HTML et renvoie le résultat
+
+
+r:base64_encode(string) -- Encode une chaîne à l'aide du standard de codage Base64.
+
+local encoded = r:base64_encode("This is a test") -- returns VGhpcyBpcyBhIHRlc3Q=
+
+
+r:base64_decode(string) -- Décode une chaîne codée en Base64.
+
+local decoded = r:base64_decode("VGhpcyBpcyBhIHRlc3Q=") -- returns 'This is a test'
+
+
+r:md5(string) -- Calcule et renvoie le condensé MD5 d'une chaîne en mode binaire (binary safe).
+
+local hash = r:md5("This is a test") -- returns ce114e4501d2f4e2dcea3e17b546f339
+
+
+r:sha1(string) -- Calcule et renvoie le condensé SHA1 d'une chaîne en mode binaire (binary safe).
+
+local hash = r:sha1("This is a test") -- returns a54d88e06612d820bc3be72877c74f257b561b19
+
+
+r:escape(string) -- Echappe une chaîne de type URL. + +local url = "http://foo.bar/1 2 3 & 4 + 5" +local escaped = r:escape(url) -- renvoie 'http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5'+ + +
r:unescape(string) -- Déséchappe une chaîne de type URL. + +local url = "http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5" +local unescaped = r:unescape(url) -- renvoie 'http://foo.bar/1 2 3 & 4 + 5'+ + +
r:construct_url(string) -- Construit une URL à partir d'un URI + +local url = r:construct_url(r.uri)+ + +
r.mpm_query(number) -- Interroge le serveur à propos de son module MPM via la requête ap_mpm_query.
+
+local mpm = r.mpm_query(14)
+if mpm == 1 then
+ r:puts("Ce serveur utilise le MPM Event")
+end
+
+
+r:expr(string) -- Evalue une chaîne de type expr. + +if r:expr("%{HTTP_HOST} =~ /^www/") then + r:puts("Ce nom d'hôte commence par www") +end+ + +
r:scoreboard_process(a) -- Interroge le serveur à propos du
+ -- processus à la position a.
+
+local process = r:scoreboard_process(1)
+r:puts("Le serveur 1 a comme PID " .. process.pid)
+
+
+r:scoreboard_worker(a, b) -- Interroge le serveur à propos du + -- thread+ + +b, dans le processusa. + +local thread = r:scoreboard_worker(1, 1) +r:puts("L'ID du thread 1 du serveur 1 est " .. thread.tid .. " et son +état est " .. thread.status)
r:clock() -- Renvoie l'heure courante avec une précision d'une microseconde.+ + +
r:requestbody(filename) -- Lit et renvoie le corps d'une requête.
+ -- Si 'filename' est spécifié, le
+ -- corps de requête n'est pas
+ -- renvoyé, mais sauvegardé dans
+ -- le fichier correspondant.
+
+local input = r:requestbody()
+r:puts("Vous m'avez envoyé le corps de requête suivant :\n")
+r:puts(input)
+
+
+r:add_input_filter(filter_name) -- Ajoute le filtre en entrée 'filter_name'.+ + +
r:module_info(module_name) -- Interroge le serveur à propos d'un module.
+
+local mod = r.module_info("mod_lua.c")
+if mod then
+ for k, v in pairs(mod.commands) do
+ r:puts( ("%s: %s\n"):format(k,v)) -- affiche toutes les directives
+ -- implémentées par ce module.
+ end
+end
+
+
+r:loaded_modules() -- Renvoie une liste des modules chargés par httpd.
+
+for k, module in pairs(r:loaded_modules()) do
+ r:puts("J'ai chargé le module " .. module .. "\n")
+end
+
+
+r:runtime_dir_relative(filename) -- Génère le nom d'un fichier run-time + -- (par exemple la mémoire partagée + -- "file") relativement au répertoire de run-time.+ + +
r:server_info() -- Renvoie une table contenant des informations à + -- propos du serveur, comme le nom de + -- l'exécutable httpd, le module mpm utilisé, etc...+ + +
r:set_document_root(file_path) -- Définit la racine des documents + -- pour la requête à file_path.+ + +
r:add_version_component(component_string) -- Ajoute un élément à + -- la bannière du serveur.+ + +
r:set_context_info(prefix, docroot) -- Définit le préfixe et la + -- racine des documents du contexte pour une requête.+ + +
r:os_escape_path(file_path) -- Convertit un chemin du système de + -- fichiers en URL indépendamment du système d'exploitation.+ + +
r:escape_logitem(string) -- Echappe une chaîne pour journalisation.+ + +
r.strcmp_match(string, pattern) -- Vérifie si 'string' correspond à
+ -- 'pattern' via la fonction strcmp_match (GLOBs). Par exemple, est-ce que
+ -- 'www.example.com' correspond à '*.example.com' ?
+
+local match = r.strcmp_match("foobar.com", "foo*.com")
+if match then
+ r:puts("foobar.com matches foo*.com")
+end
+
+
+r:set_keepalive() -- Définit l'état de persistance d'une requête. + -- Renvoie true dans la mesure du possible, false dans le cas contraire.+ + +
r:make_etag() -- Génère et renvoie le etag pour la requête courante.+ + +
r:send_interim_response(clear) -- Renvoie une réponse d'intérim (1xx) au + -- client. Si 'clear' est vrai, les en-têtes disponibles + -- seront envoyés et effacés.+ + +
r:custom_response(status_code, string) -- Génère et définit une réponse + -- personnalisée pour un code d'état particulier. + -- Le fonctionnement est très proche de celui de la directive ErrorDocument. + +r:custom_response(404, "Baleted!")+ + +
r.exists_config_define(string) -- Vérifie si une définition de configuration existe.
+
+if r.exists_config_define("FOO") then
+ r:puts("httpd a probablement été lancé avec l'option -DFOO, ou FOO a
+ été défini dans la configuration")
+end
+
+
+r:state_query(string) -- Interroge le serveur à propos de son état.+ + +
r:stat(filename [,wanted]) -- Exécute stat() sur un fichier, et renvoie une table contenant
+ -- des informations à propos de ce fichier.
+
+local info = r:stat("/var/www/foo.txt")
+if info then
+ r:puts("Ce fichier existe et a été modifié pour la dernière fois à : " .. info.modified)
+end
+
+
+r:regex(string, pattern [,flags]) -- Exécute une recherche à base d'expression rationnelle
+ -- sur une chaîne, et renvoie les éventuelles correspondances trouvées.
+
+local matches = r:regex("foo bar baz", [[foo (\w+) (\S*)]])
+if matches then
+ r:puts("L'expression rationnelle correspond et le dernier mot
+ capturé ($2) est : " .. matches[2])
+end
+
+-- Exemple avec insensibilité à la casse :
+local matches = r:regex("FOO bar BAz", [[(foo) bar]], 1)
+
+-- les drapeaux peuvent être une combibaison bit à bit de :
+-- 0x01: insensibilité à la casse
+-- 0x02: recherche multiligne
+
+
+r.usleep(microsecondes) -- Interrompt l'exécution du script pendant le nombre de microsecondes spécifié.+ + +
r:dbacquire(dbType[, dbParams]) -- Acquiert une connexion à une base de données et renvoie une classe database. + -- Voir 'Connectivité aux bases de données' + -- pour plus de détails.+ + +
r:ivm_set("key", value) -- Défini une variable Inter-VM avec une valeur spécifique.
+ -- Ces valeurs sont conservées même si la VM est
+ -- arrêtée ou non utilisée, et ne doivent donc être
+ -- utilisées que si MaxConnectionsPerChild > 0.
+ -- Les valeurs peuvent être de type number, string
+ -- ou boolean et sont stockées séparément pour
+ -- chaque processus (elles ne seront donc pas d'une
+ -- grande utilité si l'on utilise le mpm prefork).
+
+r:ivm_get("key") -- Lit le contenu d'une variable définie via ivm_set. Renvoie
+ -- le contenu de la variable si elle existe, ou nil
+ -- dans le cas contraire.
+
+-- Voici un exemple de lecture/écriture qui sauvegarde une variable
+-- globale en dehors de la VM :
+function handle(r)
+ -- La première VM qui effectue l'appel suivant n'obtiendra aucune
+ -- valeur, et devra la créer
+ local foo = r:ivm_get("cached_data")
+ if not foo then
+ foo = do_some_calcs() -- simulation de valeurs de retour
+ r:ivm_set("cached_data", foo) -- définition globale de la variable
+ end
+ r:puts("La donnée en cache est : ", foo)
+end
+
+r:htpassword(string [,algorithm [,cost]]) -- Génère un hash de mot de passe à partir d'une chaîne. + -- algorithm: 0 = APMD5 (défaut), 1 = SHA, 2 = BCRYPT, 3 = CRYPT. + -- cost: ne s'utilise qu'avec l'algorythme BCRYPT (défaut = 5).+ + +
r:mkdir(dir [,mode]) -- Crée un répertoire et définit son mode via le paramètre optionnel mode.+ + +
r:mkrdir(dir [,mode]) -- Crée des répertoires de manière récursive et définit + -- leur mode via le paramètre optionnel mode.+ + +
r:rmdir(dir) -- Supprime un répertoire.+ + +
r:touch(file [,mtime]) -- Définit la date de modification d'un fichier à la date courante ou à + -- la valeur optionnelle mtime en msec.+ + +
r:get_direntries(dir) -- Renvoie une table contenant toutes les entrées de répertoires.
+
+-- Renvoie un chemin sous forme éclatée en chemin, fichier, extension
+function handle(r)
+ local dir = r.context_document_root
+ for _, f in ipairs(r:get_direntries(dir)) do
+ local info = r:stat(dir .. "/" .. f)
+ if info then
+ local mtime = os.date(fmt, info.mtime / 1000000)
+ local ftype = (info.filetype == 2) and "[dir] " or "[file]"
+ r:puts( ("%s %s %10i %s\n"):format(ftype, mtime, info.size, f) )
+ end
+ end
+end
+
+
+r.date_parse_rfc(string) -- Interprète une chaîne date/heure et renvoie l'équivalent en secondes depuis epoche.+ + +
r:getcookie(key) -- Obtient un cookie HTTP+ + +
r:setcookie(key, value, secure, expires) -- Définit un cookie HTTP, par exemple :
+r:setcookie("foo", "bar and stuff", false, os.time() + 86400)
+
+
+r:wsupgrade() -- Met à jour une connexion vers les WebSockets si possible (et si demandé) :
+if r:wsupgrade() then -- si la mise à jour est possible :
+ r:wswrite("Bienvenue dans les websockets!") -- écrit quelque chose à l'intention du client
+ r:wsclose() -- Au revoir !
+end
+
+
+r:wsread() -- Lit un cadre de websocket depuis une connexion vers websocket mise à jour (voir ci-dessus) :
+
+local line, isFinal = r:wsread() -- isFinal indique s'il s'agit du cadre final.
+ -- dans le cas contraire, on peut lire les cadres suivants
+r:wswrite("Vous avez écrit : " .. line)
+
+
+r:wswrite(line) -- écrit un cadre vers un client WebSocket :
+r:wswrite("Bonjour le Monde !")
+
+
+r:wsclose() -- ferme une requête WebSocket et l'achève pour httpd :
+
+if r:wsupgrade() then
+ r:wswrite("Ecrire quelque chose : ")
+ local line = r:wsread() or "nothing"
+ r:wswrite("Vous avez écrit : " .. line);
+ r:wswrite("Au revoir !")
+ r:wsclose()
+end
+
+ -- exemples de messages de journalisation
+ r:trace1("Ceci est un message de journalisation de niveau
+ trace") -- les niveaux valides vont de trace1 à trace8
+ r:debug("Ceci est un message de journalisation de niveau debug")
+ r:info("Ceci est un message de journalisation de niveau info")
+ r:notice("Ceci est un message de journalisation de niveau notice")
+ r:warn("Ceci est un message de journalisation de niveau warn")
+ r:err("Ceci est un message de journalisation de niveau err")
+ r:alert("Ceci est un message de journalisation de niveau alert")
+ r:crit("Ceci est un message de journalisation de niveau crit")
+ r:emerg("Ceci est un message de journalisation de niveau emerg")
+
+
+Le paquet nommé apache2 est fourni avec (au minimum) le
+contenu suivant :
mod_proxymod_authz_coreLes autres codes d'état HTTP ne sont pas encore implémentés.
+
+ Les fonctions de filtrage implémentées via les directives LuaInputFilter ou LuaOutputFilter sont conçues comme des
+ fonctions de 3ème phase non blocantes utilisant des sous-routines
+ pour suspendre et reprendre l'exécution d'une fonction lorsque des
+ paquets de données sont envoyés à la chaîne de filtrage. La
+ structure de base d'une telle fonction est :
+
function filter(r)
+ -- Nous indiquons tout d'abord que nous sommes prêts à recevoir des
+ -- blocs de données.
+ -- Avant ceci, nous pouvons définir notre environnement, tester
+ -- certaines conditions, et, si nous le jugeons nécessaire, refuser le
+ -- filtrage d'une requête :
+ if something_bad then
+ return -- Le filtrage est sauté
+ end
+ -- Sans se préoccuper des données que nous devons éventuellement ajouter, un arrêt est réalisé ici.
+ -- Noter que les filtres de sortie sont les seuls capables d'ajouter des éléments au début des données.
+ -- Les filtres en entrée peuvent ajouter des éléments à la fin des données au stade final.
+
+ coroutine.yield([optional header to be prepended to the content])
+
+ -- Après cet arrêt, nous allons recevoir d'autres blocs de données, un par un ;
+ -- nous pouvons les traiter comme il nous plaît et procéder à la réponse.
+ -- Ces blocs sont conservés dans la variable globale 'bucket', nous réalisons donc
+ -- une boucle pour vérifier que 'bucket' n'est pas vide :
+ while bucket ~= nil do
+ local output = mangle(bucket) -- Do some stuff to the content
+ coroutine.yield(output) -- Return our new content to the filter chain
+ end
+
+ -- Une fois les blocs de données épuisés, 'bucket' est positionné à une valeur vide ('nil'),
+ -- ce qui va nous faire sortir de cette boucle et nous amener à l'étape suivante.
+ -- On peut ajouter ce qu'on veut à la fin des données à cette étape, qui constitue le dernier
+ -- arrêt. Les filtres d'entrée comme de sortie peuvent servir à ajouter des éléments à la fin
+ -- des données à cette étape.
+ coroutine.yield([optional footer to be appended to the content])
+end
+
+Mod_lua implémente une fonctionnalité basique de connexion aux +bases de données permettant d'envoyer des requêtes ou d'exécuter des +commandes auprès des moteurs de base de données les plus courants +(mySQL, PostgreSQL, FreeTDS, ODBC, SQLite, Oracle), ainsi que mod_dbd. +
+L'exemple suivant montre comment se connecter à une base de +données et extraire des informations d'une table :
+function handle(r)
+ -- connexion à la base de données
+ local database, err = r:dbacquire("mysql", "server=localhost,user=someuser,pass=somepass,dbname=mydb")
+ if not err then
+ -- Sélection de certaines informations
+ local results, err = database:select(r, "SELECT `name`, `age` FROM `people` WHERE 1")
+ if not err then
+ local rows = results(0) -- extrait tous les enregistrements en mode synchrone
+ for k, row in pairs(rows) do
+ r:puts( string.format("Name: %s, Age: %s<br/>", row[1], row[2]) )
+ end
+ else
+ r:puts("Database query error: " .. err)
+ end
+ database:close()
+ else
+ r:puts("Connexion à la base de données impossible : " .. err)
+ end
+end
+
+
+ Pour utiliser mod_dbd, spécifiez
+mod_dbd comme type de base de données, ou laissez le champ
+vide :
+
local database = r:dbacquire("mod_dbd")
+
+ L'objet database renvoyé par dbacquire possède
+les méthodes suivantes :
Sélection normale et requête vers une base de données +:
+-- Exécution d'une requête et renvoie du nombre d'enregistrements +affectés : +local affected, errmsg = database:query(r, "DELETE FROM `tbl` WHERE 1") + +-- Exécution d'une requête et renvoie du résultat qui peut être utilisé +en mode synchrone ou asynchrone : +local result, errmsg = database:select(r, "SELECT * FROM `people` WHERE 1")+ +
Utilisation de requêtes préparées (recommandé) :
+-- Création et exécution d'une requête préparée :
+local statement, errmsg = database:prepare(r, "DELETE FROM `tbl` WHERE `age` > %u")
+if not errmsg then
+ local result, errmsg = statement:query(20) -- exécute la requête pour age > 20
+end
+
+-- Extrait une requête préparée depuis une directive DBDPrepareSQL :
+local statement, errmsg = database:prepared(r, "someTag")
+if not errmsg then
+ local result, errmsg = statement:select("John Doe", 123) -- injecte les valeurs "John Doe" et 123 dans la requête
+end
+
+ Echappement de valeurs, fermeture de la base données, +etc...
+-- Echappe une valeur pour pouvoir l'utiliser dans une requête : +local escaped = database:escape(r, [["'|blabla]]) + +-- Ferme une base de données et libère les liens vers cette dernière : +database:close() + +-- Vérifie si une connexion à une base de données est en service et +opérationnelle : +local connected = database:active()+ + +
Les jeux d'enregistrements renvoyés par db:select ou par des
+requêtes préparées créées par db:prepare permettent de
+sélectionner des enregistrements en mode synchrone ou
+asynchrone, selon le nombre d'enregistrements spécifié :
+ result(0) sélectionne tous les enregistrements en mode
+synchrone en renvoyant une table d'enregistrements.
+ result(-1) sélectionne le prochain enregistrement disponible en
+mode asynchrone.
+ result(N) sélectionne l'enregistrement numéro
+N en mode asynchrone.
+
-- extrait un jeu d'enregistrements via une requête régulière : +local result, err = db:select(r, "SELECT * FROM `tbl` WHERE 1") + +local rows = result(0) -- sélectionne tous les enregistrements en mode synchrone +local row = result(-1) -- sélectionne le prochain enregistrement disponible en mode asynchrone +local row = result(1234) -- sélectionne l'enregistrement 1234 en mode asynchrone +local row = result(-1, true) -- Lit l'enregistrement suivant en utilisant les noms d'enregistrements comme index.+ +
Il est possible de construire une fonction qui renvoie une +fonction itérative permettant de traiter tous les enregistrement en mode +synchrone ou asynchrone selon la valeur de l'argument async : +
+function rows(resultset, async) + local a = 0 + local function getnext() + a = a + 1 + local row = resultset(-1) + return row and a or nil, row + end + if not async then + return pairs(resultset(0)) + else + return getnext, self + end +end + +local statement, err = db:prepare(r, "SELECT * FROM `tbl` WHERE `age` > %u") +if not err then + -- sélectionne des enregistrements en mode asynchrone : + local result, err = statement:select(20) + if not err then + for index, row in rows(result, true) do + .... + end + end + + -- sélectionne des enregistrements en mode synchrone : + local result, err = statement:select(20) + if not err then + for index, row in rows(result, false) do + .... + end + end +end+ + +
Lorsqu'elles ne sont plus utilisées, les connexions aux bases de
+données doivent être fermées avec database:close(). Si vous
+ne les fermez pas manuellement, mod_lua les fermera peut-être en tant
+que résidus collectés, mais si ce n'est pas le cas, vous pouvez finir
+pas avoir trop de connexions vers la base de données inutilisées. Les
+deux mesures suivantes sont pratiquement identiques :
+
-- Méthode 1 : fermeture manuelle de la connexion
+local database = r:dbacquire("mod_dbd")
+database:close() -- c'est tout
+
+-- Méthode 2 : on laisse le collecteur de résidus la fermer
+local database = r:dbacquire("mod_dbd")
+database = nil -- on coupe le lien
+collectgarbage() -- fermeture de la connexion par le collecteur de résidus
+
+
+ Bien que les fonctions query et run
+soient toujours disponibles, il est recommandé d'utiliser des requêtes
+préparées chaque fois que possible, afin d'une part d'optimiser les
+performances (si votre connexion reste longtemps en vie), et d'autre part
+minimiser le risque d'attaques par injection SQL. Les fonctions
+run et query ne doivent être utilisées que
+lorsque la requête ne contient pas de variables (requête statique). Dans
+le cas des requêtes dynamiques, utilisez db:prepare ou
+db:prepared.
+
| Description: | Branche une fonction fournisseur d'autorisation dans mod_authz_core
+ |
|---|---|
| Syntaxe: | LuaAuthzProvider provider_name /path/to/lua/script.lua function_name |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_lua |
| Compatibilité: | Disponible depuis la version 2.4.3 du serveur HTTP Apache |
Lorsqu'une fonction lua a été enregistrée en tant que fournisseur
+d'autorisation, elle peut être appelée via la directive Require :
LuaRoot "/usr/local/apache2/lua" +LuaAuthzProvider foo authz.lua authz_check_foo +<Location "/"> + Require foo johndoe +</Location>+ +
require "apache2" +function authz_check_foo(r, who) + if r.user ~= who then return apache2.AUTHZ_DENIED + return apache2.AUTHZ_GRANTED +end+ + + +
| Description: | Configure le cache de code compilé. |
|---|---|
| Syntaxe: | LuaCodeCache stat|forever|never |
| Défaut: | LuaCodeCache stat |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
+ Cette directive permet de définir le comportement du cache de code + en mémoire. La valeur par défaut est stat ; dans ce cas, le script + du niveau le plus haut (et pas les scripts inclus) est vérifié à + chaque fois que ce fichier est nécessaire, et est rechargé si la + date de modification est plus récente que celle du script déjà + chargé. Les autres valeurs permettent respectivement de garder le + fichier en cache perpétuellement (forever - jamais vérifié ni + remplacé), ou de ne jamais le mettre en cache (never).
+ +En général, les valeurs stat et forever sont utilisées pour un + serveur en production, et les valeurs stat ou never pour un serveur + en développement.
+ +LuaCodeCache stat +LuaCodeCache forever +LuaCodeCache never+
| Description: | Fournit un point d'entrée pour la phase access_checker du +traitement de la requête |
|---|---|
| Syntaxe: | LuaHookAccessChecker /chemin/vers/lua/script.lua hook_function_name [early|late] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
| Compatibilité: | Le troisième argument optionnel est disponible depuis la +version 2.3.15 du serveur HTTP Apache. |
Ajoute votre fonction d'accroche à la phase access_checker. Une +fonction d'accroche access checker renvoie en général OK, DECLINED, ou +HTTP_FORBIDDEN.
+Les arguments optionnels + "early" ou "late" permettent de contrôler le moment auquel ce script + s'exécute par rapport aux autres modules.
| Description: | Fournit un point d'entrée pour la phase auth_checker du +traitement de la requête |
|---|---|
| Syntaxe: | LuaHookAuthChecker /chemin/vers/lua/script.lua hook_function_name [early|late] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
| Compatibilité: | Le troisième argument optionnel est disponible depuis la +version 2.3.15 du serveur HTTP Apache. |
Invoque une fonction lua au cours de la phase auth_checker du +traitement de la requête. Cette directive peut s'utiliser pour +implémenter une vérification arbitraire de l'authentification et de +l'autorisation. Voici un exemple très simple : +
+require 'apache2'
+
+-- fonction d'accroche authcheck fictive
+-- Si la requête ne contient aucune donnée d'authentification, l'en-tête
+-- de la réponse est défini et un code 401 est renvoyé afin de demander au
+-- navigateur d'effectuer une authentification basique. Si la requête
+-- comporte des données d'authentification, elles ne sont pas vraiment
+-- consultées, mais on admet la prise en compte de l'utilisateur 'foo' et
+-- on la valide. On vérifie ensuite si l'utilisateur est bien 'foo' et on
+-- accepte la requête.
+function authcheck_hook(r)
+
+ -- recherche des informations d'authentification
+ auth = r.headers_in['Authorization']
+ if auth ~= nil then
+ -- définition d'un utilisateur par défaut
+ r.user = 'foo'
+ end
+
+ if r.user == nil then
+ r:debug("authcheck: user is nil, returning 401")
+ r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"'
+ return 401
+ elseif r.user == "foo" then
+ r:debug('user foo: OK')
+ else
+ r:debug("authcheck: user='" .. r.user .. "'")
+ r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"'
+ return 401
+ end
+ return apache2.OK
+end
+
+Les arguments optionnels + "early" ou "late" permettent de contrôler le moment auquel ce script + s'exécute par rapport aux autres modules.
| Description: | Fournit un point d'entrée pour la phase check_user_id du +traitement de la requête |
|---|---|
| Syntaxe: | LuaHookCheckUserID /chemin/vers/lua/script.lua hook_function_name [early|late] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
| Compatibilité: | Le troisième argument optionnel est disponible depuis la +version 2.3.15 du serveur HTTP Apache. |
...
+Les arguments optionnels + "early" ou "late" permettent de contrôler le moment auquel ce script + s'exécute par rapport aux autres modules.
| Description: | Fournit un point d'entrée pour la phase de correction du +traitement de la requête |
|---|---|
| Syntaxe: | LuaHookFixups /chemin/vers/lua/script.lua hook_function_name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
+ Idem LuaHookTranslateName, mais s'exécute durant la phase de + correction. +
+ +| Description: | Fournit un point d'entrée pour la phase insert_filter du +traitement de la requête |
|---|---|
| Syntaxe: | LuaHookInsertFilter /chemin/vers/lua/script.lua hook_function_name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
Non encore implémenté
+| Description: | Permet une insertion dans la phase de journalisation du +traitement d'une requête |
|---|---|
| Syntaxe: | LuaHookLog /path/to/lua/script.lua log_function_name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
+ Ce dispositif d'insertion simple permet d'exécuter une fonction
+ lorsque httpd entre dans la phase de journalisation du traitement
+ d'une requête. Vous pouvez ainsi ajouter des données à vos propres
+ entrées de journalisation, manipuler les entrées du journal standard
+ avant leur enregistrement ou empêcher l'enregistrement d'une entrée
+ dans le journal. Pour empêcher l'enregistrement normal des entrées
+ du journal, renvoyez simplement apache2.DONE dans votre
+ gestionnaire de journalisation, ou au contraire, renvoyez
+ apache2.OK pour que httpd effectue une journalisation
+ normale.
+
Exemple :
+LuaHookLog "/path/to/script.lua" logger+ +
-- /path/to/script.lua --
+function logger(r)
+ -- on joue à pile ou face :
+ -- Si on obtient 1, on écrit dans notre propre journal Lua et on dit
+ -- à httpd de ne pas enregistrer d'entrée dans le journal standard..
+ -- Si on obtient 2, on nettoie un peu les données avant que httpd ne
+ -- les enregistre dans le journal standard.
+
+ if math.random(1,2) == 1 then
+ -- On effectue notre propre journalisation et le journal
+ -- standard n'est pas alimenté
+ local f = io.open("/foo/secret.log", "a")
+ if f then
+ f:write("Quelque chose de secret est arrivé à " .. r.uri .. "\n")
+ f:close()
+ end
+ return apache2.DONE -- On dit à httpd de ne rien enregistrer
+ --dans le journal standard
+ else
+ r.uri = r.uri:gsub("somesecretstuff", "") -- nettoie les données
+ return apache2.OK -- et httpd doit alors les enregistrer.
+ end
+end
+
+
+| Description: | Fournit un point d'entrée pour la phase map_to_storage du +traitement de la requête |
|---|---|
| Syntaxe: | LuaHookMapToStorage /chemin/vers/lua/script.lua hook_function_name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
Identique à la directive
+ LuaHookTranslateName, mais s'exécute à la
+ phase map-to-storage du traitement de la requête. Les modules comme
+ mod_cache agissent pendant cette phase, ce qui permet de présenter
+ un exemple intéressant de ce que l'on peut faire ici :
LuaHookMapToStorage "/path/to/lua/script.lua" check_cache+ +
require"apache2"
+cached_files = {}
+
+function read_file(filename)
+ local input = io.open(filename, "r")
+ if input then
+ local data = input:read("*a")
+ cached_files[filename] = data
+ file = cached_files[filename]
+ input:close()
+ end
+ return cached_files[filename]
+end
+
+function check_cache(r)
+ if r.filename:match("%.png$") then -- Ne concerne que les fichiers PNG
+ local file = cached_files[r.filename] -- Vérifie les entrées du cache
+ if not file then
+ file = read_file(r.filename) -- Lit le fichier vers le cache
+ end
+ if file then -- Si le fichier existe, on l'envoie
+ r.status = 200
+ r:write(file)
+ r:info(("%s a été envoyé au client depuis le cache"):format(r.filename))
+ return apache2.DONE -- cout-circuite le gestionnaire par défaut des fichiers PNG
+ end
+ end
+ return apache2.DECLINED -- Si nous n'avons rien eu à faire, nous laissons les autres s'en charger
+end
+
+
+
+| Description: | Fournit un point d'entrée à la phase du nom de +traduction du traitement de la requête |
|---|---|
| Syntaxe: | LuaHookTranslateName /chemin/vers/lua/script.lua nom_fonction_hook [early|late] |
| Contexte: | configuration globale, serveur virtuel |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
| Compatibilité: | Le troisième argument optionnel est disponible depuis la +version 2.3.15 du serveur HTTP Apache. |
+ Cette directive permet d'ajouter un point d'entrée (à + APR_HOOK_MIDDLE) à la phase du nom de traduction du traitement de la + requête. La fonction hook accepte un seul argument, le request_rec, + et doit renvoyer un code d'état qui est soit un code d'erreur HTTP, + ou une constante définie dans le module apache2 : apache2.OK, + apache2.DECLINED, ou apache2.DONE.
+ +Pour ceux qui ne sont pas familiers avec les points d'entrée + (hook), en gros, chaque hook sera invoqué jusqu'à ce que l'un + d'entre eux renvoie apache2.OK. Si un hook n'effectuer pas la + traduction, il doit juste renvoyer apache2.DECLINED. Si le + traitement de la requête doit être interrompu, la valeur renvoyée + doit être apache2.DONE.
+ +Exemple :
+ +# httpd.conf +LuaHookTranslateName "/scripts/conf/hooks.lua" silly_mapper+ + +
-- /scripts/conf/hooks.lua -- +require "apache2" +function silly_mapper(r) + if r.uri == "/" then + r.filename = "/var/www/home.lua" + return apache2.OK + else + return apache2.DECLINED + end +end+ + +
Cette directive ne peut être
+ utilisée ni à l'intérieur d'une section <Directory> ou <Files>, ni dans un fichier htaccess.
Les arguments optionnels + "early" ou "late" permettent de contrôler le moment auquel ce script + s'exécute par rapport aux autres modules.
| Description: | Fournit un point d'entrée pour la phase type_checker du +traitement de la requête |
|---|---|
| Syntaxe: | LuaHookTypeChecker /chemin/vers/lua/script.lua hook_function_name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
+ Cette directive fournit un point d'entrée pour la phase + type_checker du traitement de la requête. Cette phase + correspond au moment où la requête se voit assigner un type et un + gestionnaire de contenu, et peut donc être utilisée pour modifier le + type et le gestionnaire en fonction de l'entrée : +
+LuaHookTypeChecker "/path/to/lua/script.lua" type_checker+ +
function type_checker(r)
+ if r.uri:match("%.to_gif$") then -- foo.png.to_gif convient
+ r.content_type = "image/gif" -- affectation du type image/gif
+ r.handler = "gifWizard" -- force le traitement de la requête par le module gifWizard
+ r.filename = r.uri:gsub("%.to_gif$", "") -- corrige le nom du fichier demandé
+ return apache2.OK
+ end
+
+ return apache2.DECLINED
+ end
+
+
+| Description: | Contrôle la manière dont les sections de configuration +parentes sont fusionnées dans les enfants |
|---|---|
| Syntaxe: | LuaInherit none|parent-first|parent-last |
| Défaut: | LuaInherit parent-first |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
| Compatibilité: | Versions 2.4.0 et supérieures |
Par défaut, si des directives LuaHook* se trouvent dans + des sections de configuration Directory ou Location qui se + chevauchent, les scripts + définis dans les sections les plus spécifiques s'exécutent + après ceux définis dans les sections plus génériques + (LuaInherit parent-first). Vous pouvez inverser cet ordre, ou faire + en sorte que le contexte parent ne s'applique pas du tout.
+ +Jusqu'aux versions 2.3.x, le comportement par défaut consistait à + ignorer les directives LuaHook* situées dans les sections de + configuration parentes.
+| Description: | Fournit une fonction Lua pour le filtrage en entrée |
|---|---|
| Syntaxe: | LuaInputFilter filter_name /path/to/lua/script.lua function_name |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_lua |
| Compatibilité: | Disponible depuis la version 2.4.5 du serveur HTTP +Apache |
Cette directive permet d'ajouter un filtre en entrée sous la forme
+d'une fonction Lua. A l'instar des filtres en sorties, les filtres en
+entrée fonctionnent comme des sous-routines, intervenant dans un premier
+temps avant l'envoi du contenu des tampons, puis chaque fois qu'un
+paquet de données doit être transmis à la chaîne, et éventuellement
+produisant toute donnée à ajouter aux données en entrée. La variable
+globale bucket contient les paquets de données tels qu'ils
+sont transmis au script Lua :
+
LuaInputFilter myInputFilter "/www/filter.lua" input_filter +<Files "*.lua"> + SetInputFilter myInputFilter +</Files>+ +
--[[
+ Exemple de filtre en entrée qui convertit toutes les données POST en
+ majuscules.
+]]--
+function input_filter(r)
+ print("luaInputFilter called") -- pour débogage
+ coroutine.yield() -- attend des paquets de données
+ while bucket do -- Pour chaque paquet, faire ...
+ local output = string.upper(bucket) -- Convertit toutes les données POST en majuscules
+ coroutine.yield(output) -- Envoie les données traitées à la chaîne de filtrage
+ end
+ -- plus aucune donnée à traiter.
+ coroutine.yield("&filterSignature=1234") -- Ajoute une signature à la fin
+end
+
++Le filtre en entrée peut interdire ou sauter un filtre s'il est +considéré comme indésirable : +
+function input_filter(r) + if not good then + return -- Empêche tout simplement le filtrage et transmet le contenu original + end + coroutine.yield() -- attend des paquets de données + ... -- insert les filtres ici +end+ +
+Voir "Modification de contenu avec les +filtres Lua" pour plus de détails. +
+ +| Description: | Met en correspondance un chemin avec un gestionnaire lua |
|---|---|
| Syntaxe: | LuaMapHandler modele-uri /chemin/vers/lua/script.lua
+[nom-fonction] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
Cette directive permet de faire correspondre un modèle d'uri avec + une fonction de gestionnaire située dans un fichier spécifique. Elle + utilise les expressions rationnelles PCRE pour mettre en + correspondance l'uri, et supporte les groupes de correspondance + d'interpolation dans le chemin du fichier et le nom de la fonction. + Prenez garde aux problèmes de sécurité en écrivant vos expressions + rationnelles.
+LuaMapHandler "/(\w+)/(\w+)" "/scripts/$1.lua" "handle_$2"+
Cette directive va faire correspondre des uri comme + /photos/show?id=9 au fichier /scripts/photos.lua, et invoquera la + fonction de gestionnaire handle_show au niveau de la vm lua + après chargement de ce fichier.
+ +LuaMapHandler "/bingo" "/scripts/wombat.lua"+ +
Cette directive invoquera la fonction "handle" qui est la + valeur par défaut si aucun nom de fonction spécifique n'est + spécifié.
+ +| Description: | Fournit une fonction Lua pour le filtrage de contenu en +sortie |
|---|---|
| Syntaxe: | LuaOutputFilter filter_name /path/to/lua/script.lua function_name |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_lua |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP +Apache |
>Cette directive permet d'ajouter un filtre en sortie sous la forme
+d'une fonction Lua. A l'instar des filtres en sorties, les filtres en
+entrée fonctionnent comme des sous-routines, intervenant dans un premier
+temps avant l'envoi du contenu des tampons, puis chaque fois qu'un
+paquet de données doit être transmis à la chaîne, et éventuellement
+produisant toute donnée à ajouter aux données en sortie. La variable
+globale bucket contient les paquets de données tels qu'ils
+sont transmis au script Lua :
+
LuaOutputFilter myOutputFilter "/www/filter.lua" output_filter +<Files "*.lua"> + SetOutputFilter myOutputFilter +</Files>+ +
--[[
+ Exemple de filtre en sortie qui échappe toutes les entités HTML en
+ sortie
+]]--
+function output_filter(r)
+ coroutine.yield("(Handled by myOutputFilter)<br/>\n") -- Ajoute des données au début de la sortie,
+ -- puis attend des paquets de données à traiter
+ while bucket do -- Pour chaque paquet, faire ...
+ local output = r:escape_html(bucket) -- Echappe les données en sortie
+ coroutine.yield(output) -- Envoie les données traitées à la chaîne
+ end
+ -- plus aucune donnée à traiter.
+end
+
++Comme les filres en entrée, le filtre en sortie peut interdire ou sauter un filtre s'il est +considéré comme indésirable : +
+function output_filter(r)
+ if not r.content_type:match("text/html") then
+ return -- Empêche tout simplement le filtrage et transmet le contenu original
+ end
+ coroutine.yield() -- attend des paquets de données
+ ... -- insert les filtres ici
+end
+
+mod_filterLorsqu'on utilise un filtre Lua comme fournisseur sous-jacent via la
+directive FilterProvider, le
+filtrage ne fonctionnera que si filter-name est identique à
+provider-name.
+
+Voir "Modification de contenu avec les +filtres Lua" pour plus de détails. +
+ + +| Description: | Ajoute un répertoire au package.cpath de lua |
|---|---|
| Syntaxe: | LuaPackageCPath /chemin/vers/include/?.soa |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
Cette directive permet d'ajouter un chemin à la liste des chemins + de recherche des bibliothèques partagées de lua. Ceci modifie le + package.cpath dans les vms lua.
+ + +| Description: | Ajoute un répertoire au package.path de lua |
|---|---|
| Syntaxe: | LuaPackagePath /chemin/vers/include/?.lua |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
Cette directive permet d'ajouter un chemin à la liste des + chemins de recherche du module lua. Elle suit les mêmes conventions + que lua. Ceci modifie le package.path dans les vms lua.
+ +LuaPackagePath "/scripts/lib/?.lua" +LuaPackagePath "/scripts/lib/?/init.lua"+
| Description: | Fournit un point d'entrée pour la gestion rapide du +traitement de la requête |
|---|---|
| Syntaxe: | LuaQuickHandler /path/to/script.lua hook_function_name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
Cette phase s'exécute juste après l'attribution de la requête à
+ un serveur virtuel, et permet d'effectuer certains traitements avant
+ le déroulement des autres phases, ou de servir une requête sans
+ avoir à la traduire, l'associer à un espace de stockage, etc...
+ Comme cette phase s'exécute avant toute autre, les directives telles
+ que <Location> ou
+ <Directory> ne
+ sont pas encore prises en compte, car Les URI n'ont pas encore été
+ entièrement interprétés.
+
Cette directive ne peut être
+ utilisée ni à l'intérieur d'une section <Directory> ou <Files>, ni dans un fichier htaccess.
| Description: | Spécifie le chemin de base pour la résolution des chemins +relatifs dans les directives de mod_lua |
|---|---|
| Syntaxe: | LuaRoot /chemin/vers/un/répertoire |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
Cette directive permet de spécifier le chemin de base qui sera + utilisé pour évaluer tous les chemins relatifs dans mod_lua. En + l'absence de cette directive, les chemins relatifs sont résolus par + rapport au répertoire de travail courant, ce qui ne sera pas + toujours approprié pour un serveur.
+ +| Description: | Une valeur parmi once, request, conn, thread -- la valeur par défaut est once |
|---|---|
| Syntaxe: | LuaScope once|request|conn|thread|server [min] [max] |
| Défaut: | LuaScope once |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Expérimental |
| Module: | mod_lua |
Cette directive permet de spécifier la durée de vie de + l'interpréteur Lua qui sera utilisé dans ce "répertoire". La valeur + par défaut est "once".
+ +min et max permettent
+ de spécifier les nombres minimaux et maximaux d'états lua à stocker
+ dans la liste.En général, les portées thread et server
+ sont 2 à 3 fois plus rapides que les autres, car elles n'ont pas besoin
+ de régénérer de nouveaux états Lua à chaque requête (comme c'est le
+ cas avec le MPM event, où même les connexions persistantes utilisent un
+ nouveau thread pour chaque requête). Si vous pensez que vos scripts
+ n'auront pas de problème s'il réutilisent un état, alors les portées
+ thread ou server doivent être utilisées car
+ elles présenteront de meilleures performances. Alors que la portée
+ thread fournira les réponses les plus rapides, la portée
+ server utilisera moins de mémoire car les états sont
+ rassemblés dans des jeux, permettant par exemple à 1000 threads de
+ partager 100 états Lua, ne nécessitant ainsi que 10% de la mémoire
+ requise par la portée thread.
+
Serveur HTTP Apache Version 2.4
+| Description: | Ce module permet d'utiliser des macros dans les fichiers +de configuration Apache. |
|---|---|
| Statut: | Base |
| Identificateur de Module: | macro_module |
| Fichier Source: | mod_macro.c |
Ce module permet d'utiliser des macros dans les fichiers de + configuration à l'exécution du serveur HTTP Apache afin de faciliter + la création de nombreux blocs de configuration similaires. Quand le + serveur démarre, les macros sont exécutées avec les paramètres + fournis, et le résultat obtenu est traité au même titre que le reste + du fichier de configuration.
+ + Utilisation Conseils Exemples <Macro> UndefMacro UseOn définit une macro à l'aide des blocs <Macro> qui contiennent la portion de votre
+configuration qui intervient de manière répétitive, y compris les
+variables pour les parties qui devront être substituées.
Par exemple, vous pouvez utiliser une macro pour définir un bloc
+<VirtualHost>, afin de pouvoir
+définir de nombreux serveurs virtuels similaires :
<Macro VHost $name $domain> +<VirtualHost *:80> + ServerName $domain + ServerAlias www.$domain + + DocumentRoot "/var/www/vhosts/$name" + ErrorLog "/var/log/httpd/$name.error_log" + CustomLog "/var/log/httpd/$name.access_log" combined +</VirtualHost> +</Macro>+ + +
Comme les directives de configuration httpd, les noms des macros sont +insensibles à la casse, à la différence des variables qui y sont, elles, +sensibles.
+ +Vous pouvez alors invoquer cette macro autant de fois que vous le +voulez pour créer des serveurs virtuels
+ +Use VHost example example.com +Use VHost myhost hostname.org +Use VHost apache apache.org + +UndefMacro VHost+ + +
Au démarrage du serveur, chacune de ces invocations
+Use sera remplacée par une définition de serveur
+virtuel complète, comme décrit dans la définition de la
+<Macro>.
La directive UndefMacro permet d'éviter les
+conflits de définitions qui pourraient provenir de l'utilisation
+ultérieure de macros contenant les mêmes noms de variables.
Vous trouverez une version plus élaborée de cet exemple plus loin +dans la section Exemples.
+ +Les noms de paramètres doivent commencer par un sigil tel que
+$, %, ou @, de façon à ce qu'ils
+soient clairement identifiables, mais aussi afin de faciliter les
+interactions avec les autres directives, comme la directive de base
+Define. Dans le cas contraire, vous
+recevrez un avertissement. En tout état de cause, il est conseillé
+d'avoir une bonne connaissance globale de la configuration du serveur,
+afin d'éviter la réutilisation des mêmes variables à différents niveaux,
+ce qui peut être à l'origine de confusions.
Les paramètres préfixés par $ ou % ne sont
+pas échappés. Les paramètres préfixés par @ sont échappés
+entre guillemets.
Evitez de préfixer un paramètre par le nom d'un autre paramètre (par
+exemple, présence simultanée des paramètres $win et
+$winter), car ceci peut introduire de la confusion lors de
+l'évaluation des expressions. Si cela se produit, c'est le nom de
+paramètre le plus long possible qui sera utilisé.
Si vous désirez insérer une valeur dans une chaîne, il est conseillé +de l'entourer d'accolades afin d'éviter toute confusion :
+ +<Macro DocRoot ${docroot}>
+ DocumentRoot "/var/www/${docroot}/htdocs"
+</Macro>
+
+
+Un exemple typique d'utilisation de mod_macro est la
+création dynamique de serveurs virtuels.
## Définition d'une macro VHost pour les configurations répétitives + +<Macro VHost $host $port $dir> + Listen $port + <VirtualHost *:$port> + + ServerName $host + DocumentRoot "$dir" + + # Racine des documents publique + <Directory "$dir"> + Require all granted + </Directory> + + # restriction d'accès au sous-répertoire intranet. + <Directory "$dir/intranet"> + Require ip 10.0.0.0/8 + </Directory> + </VirtualHost> +</Macro> + +## Utilisation de la macro VHost avec différents arguments. + +Use VHost www.apache.org 80 /vhosts/apache/htdocs +Use VHost example.org 8080 /vhosts/example/htdocs +Use VHost www.example.fr 1234 /vhosts/example.fr/htdocs+ + + +
Il est recommandé de supprimer la définition d'une macro après +l'avoir utilisée. Ceci permet d'éviter les confusions au sein d'un +fichier de configuration complexe où des conflits entre noms de +variables peuvent survenir.
+ +<Macro DirGroup $dir $group> + <Directory "$dir"> + Require group $group + </Directory> +</Macro> + +Use DirGroup /www/apache/private private +Use DirGroup /www/apache/server admin + +UndefMacro DirGroup+ + + + +
| Description: | Définition d'une macro dans un fichier de configuration |
|---|---|
| Syntaxe: |
+<Macro nom [par1 .. parN]>
+... </Macro> |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_macro |
La directive <Macro> permet de définir une macro
+ dans un fichier de configuration Apache. Le premier argument est le nom
+ de la macro, et les arguments suivants sont les paramètres. Il
+ est de bon aloi de préfixer les noms des paramètres d'une macro
+ avec un caractère parmi '$%@', et d'éviter d'en faire
+ de même avec les noms de macros.
+
<Macro LocalAccessPolicy> + Require ip 10.2.16.0/24 +</Macro> + +<Macro RestrictedAccessPolicy $ipnumbers> + Require ip $ipnumbers +</Macro>+ + +
| Description: | Supprime une macro |
|---|---|
| Syntaxe: | UndefMacro nom |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_macro |
La directive UndefMacro annule la définition
+ d'une macro qui doit avoir été définie auparavant.
UndefMacro LocalAccessPolicy +UndefMacro RestrictedAccessPolicy+ + +
| Description: | Utilisation d'une macro |
|---|---|
| Syntaxe: | Use nom [valeur1 ... valeurN]
+ |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_macro |
La directive Use permet d'utiliser une macro.
+ La macro considérée est expansée. Son nombre d'arguments doit être égal au
+ nombre de paramètres précisés dans sa définition. Les valeurs passées en
+ argument sont attribuées aux paramètres correspondants et
+ substituées avant l'interprétation du texte de la macro.
Use LocalAccessPolicy +... +Use RestrictedAccessPolicy "192.54.172.0/24 192.54.148.0/24"+ + +
est équivalent, avec les macros définies ci-dessus à :
+ +Require ip 10.2.16.0/24 +... +Require ip 192.54.172.0/24 192.54.148.0/24+ + +
Serveur HTTP Apache Version 2.4
+| Description: | Associe les extensions des fichiers demandés avec l'action +déclenchée par ces fichiers et avec leur contenu (type MIME, langue, +jeu de caractère et codage) |
|---|---|
| Statut: | Base |
| Identificateur de Module: | mime_module |
| Fichier Source: | mod_mime.c |
Ce module permet d'assigner des métadonnées aux contenus
+ sélectionnés pour une réponse HTTP, en associant des modèles d'URI
+ ou de noms de fichiers aux valeurs des métadonnées. Par exemple, les
+ extensions de noms de fichiers définissent souvent le type de médium
+ Internet, la langue, le jeu de caractères et le codage du contenu.
+ Ces informations sont relayées par les messages HTTP véhiculant ces
+ contenus, et utilisées au cours de la négociation de contenu lors de
+ la sélection des différentes possibilités, de manière à ce que les
+ préférences des utilisateurs soient respectées lors du choix d'un
+ contenu à servir parmi plusieurs autres contenus. Voir
+ mod_negotiation pour plus d'informations à propos
+ de la négociation de
+ contenu.
Les directives AddCharset, AddEncoding, AddLanguage et AddType permettent d'associer des
+ extensions de fichiers aux métadonnées de ces fichiers. Elles
+ définissent respectivement le jeu de caractères, le codage du
+ contenu, la langue du contenu et le type de
+ médium (content-type) des documents. La directive
+ TypesConfig permet de
+ spécifier un fichier qui contient lui-même des associations entre
+ extensions et types de media.
De plus, mod_mime peut définir le gestionnaire et les filtres qui sont à l'origine du contenu et
+ le traitent. Les directives AddHandler, AddOutputFilter, et AddInputFilter permettent de contrôler
+ les modules ou les scripts qui vont servir le document. La directive
+ MultiviewsMatch permet à
+ mod_negotiation de déterminer les extensions de
+ fichiers à inclure lors des tests de correspondances multivues.
Alors que mod_mime associe des métadonnées avec
+ des extensions de fichiers, le serveur de base core
+ fournit des directives permettant d'associer tous les fichiers d'un
+ conteneur donné (par exemple <Location>, <Directory>, ou <Files>) avec des métadonnées particulières.
+ Parmi ces directives, on trouve ForceType, SetHandler, SetInputFilter, et SetOutputFilter. Les directives du serveur
+ de base l'emportent sur toute directive d'association d'extensions
+ de noms de fichiers définie par mod_mime.
Notez que la modification des métadonnées d'un fichier ne modifie
+ pas la valeur de l'en-tête Last-Modified. Ainsi,
+ certaines copies de documents préalablement mises en cache peuvent
+ encore être utilisées par un client ou un mandataire avec les
+ anciens en-têtes. Si vous modifiez les métadonnées (langue, type de
+ contenu, jeu de caractère ou codage), vous devez donc enregistrer
+ une modification du fichier concerné (afin de mettre à jour sa date
+ de dernière modification), pour être sûr que tous les visiteurs
+ recevront le documents avec les en-têtes corrects.
AddCharset AddEncoding AddHandler AddInputFilter AddLanguage AddOutputFilter AddType DefaultLanguage ModMimeUsePathInfo MultiviewsMatch RemoveCharset RemoveEncoding RemoveHandler RemoveInputFilter RemoveLanguage RemoveOutputFilter RemoveType TypesConfigLes fichiers peuvent posséder plusieurs extensions dont l'ordre
+ est normalement sans importance. Par exemple, si
+ le fichier welcome.html.fr est associé au type de
+ contenu text/html et à la langue française, le fichier
+ welcome.fr.html possèdera exactement les même
+ métadonnées. Si le fichier possède plusieurs extensions associées
+ au même type de métadonnée, c'est celle de ces extensions la plus à
+ droite qui sera utilisée, excepté pour ce qui concerne les langues
+ et les codages de contenu. Par exemple, si .gif est
+ associé au type de médium
+ image/gif, et .html au type de médium
+ text/html, le fichier welcome.gif.html
+ sera associé au type de médium text/html.
Les Languages et les codages de contenu sont traités de
+ manière cumulative, car il est possible d'assigner plusieurs
+ langues ou codages à une ressource particulière. Par exemple, le
+ fichier welcome.html.en.de sera servi avec les en-têtes
+ Content-Language: en, de et Content-Type:
+ text/html.
Des précautions doivent être prises lorsqu'un fichier avec
+ extensions multiples est associé à la fois à un type de
+ médium et à un gestionnaire. En général, cela impliquera
+ la gestion de la requête par le module associé au gestionnaire. Par
+ exemple, si l'extension .imap est associée au
+ gestionnaire imap-file (du module
+ mod_imagemap), et si l'extension .html
+ est associée au type de médium text/html, le fichier
+ world.imap.html sera à la fois associé au gestionnaire
+ imap-file et au type de médium text/html.
+ Pour son traitement, c'est le gestionnaire imap-file
+ qui sera utilisé, et il sera donc traité en tant que fichier
+ imagemap.
Si vous préférez que seule la dernière partie d'un nom de fichier
+ séparée du reste du nom par un point soit associée à une métadonnée
+ particulière, n'utilisez pas les directives Add*. Par
+ exemple, si vous souhaitez que le fichier foo.html.cgi
+ soit traité en tant que script CGI, mais pas le fichier
+ bar.cgi.html, alors, au lieu d'utiliser
+ AddHandler cgi-script .cgi, utilisez plutôt :
<FilesMatch "[^.]+\.cgi$"> + SetHandler cgi-script +</FilesMatch>+
Un fichier d'un type de médium particulier
+ peut être également codé d'une certaine manière pour simplifier sa
+ transmission sur Internet. Alors que cela concerne en général la
+ compression, comme gzip, il peut aussi s'agir de
+ chiffrement, comme pgp ou d'un codage comme UUencoding,
+ qui est conçu pour transmettre un fichier binaire sous un format
+ ASCII (texte).
La RFC + HTTP/1.1, section 14.11 stipule à ce titre :
+ +++ +Le champ d'en-tête Content-Encoding de l'entité est utilisé en + tant que modificateur du type de médium. Lorsqu'il est présent, sa + valeur indique quels codages de contenu additionnels ont été + appliqués au corps de l'entité, et ainsi quels mécanismes de + décodage doivent être appliqués afin de retrouver le type de + médium référencé par le champ d'en-tête Content-Type. Le codage de + contenu est principalement utilisé pour permettre la compression + d'un document sans perdre l'information concernant le type de + médium sous-jacent.
+
En utilisant plusieurs extensions (voir la section ci-dessus à propos des extensions de + fichiers multiples), vous pouvez indiquer qu'un fichier est d'un + type, particulier, et possède aussi un codage + particulier.
+ +Considérons par exemple un fichier contenant un document
+ Microsoft Word et compressé par pkzip pour réduire sa taille. Si
+ l'extension .doc est associée au type de fichier
+ Microsoft Word, et si l'extension .zip est associée au
+ codage de fichier pkzip, alors le fichier
+ Resume.doc.zip sera identifié comme document Word
+ compressé par pkzip.
Apache joint un en-tête Content-encoding à la
+ ressource afin d'informer le navigateur client à propos de la
+ méthode de codage.
Content-encoding: pkzip+ +
En plus du type de fichier et du codage, un autre élément + important d'information est la langue dans laquelle le document est + écrit, et avec quel jeu de caractères le contenu du fichier doit + être affiché. Par exemple, un document peut être écrit en alphabet + vietnamien ou cyrillique, et doit être affiché en conséquence. Cette + information est également transmise via des en-têtes HTTP.
+ +Les jeu de caractères, langue, codage et type MIME sont tous
+ utilisés au cours du processus de négociation de contenu (voir
+ mod_negotiation) afin de déterminer quel document
+ servir au client, lorsque plusieurs choix sont possibles en fonction
+ du jeu de caractères, de la langue, du codage ou du type MIME. Toutes
+ les associations d'extensions de noms de fichiers créées via les
+ directives AddCharset,
+ AddEncoding, AddLanguage et AddType (ainsi que les associations
+ d'extensions listées dans le fichier défini par la directive
+ MimeMagicFile),
+ participent à ce processus de sélection. Les extensions de noms de
+ fichiers qui n'ont été associés que par des directives AddHandler, AddInputFilter ou AddOutputFilter, peuvent être incluses
+ ou exclues du processus de sélection en utilisant la directive
+ MultiviewsMatch.
Pour transmettre cette information supplémentaire, Apache peut
+ ajouter un en-tête Content-Language, afin de
+ spécifier la langue dans laquelle le document est écrit, et peut
+ ajouter des informations additionnelles à l'en-tête
+ Content-Type pour indiquer le jeu de caractères
+ particulier qui doit être utilisé pour restituer correctement le
+ document.
+ Content-Language: en, fr
+Content-Type: text/plain; charset=ISO-8859-1
+
La langue est spécifiée via son abréviation en deux lettres. Le
+ jeu de caractères est le nom du jeu de caractères
+ particulier qui doit être utilisé.
| Description: | Associe les extensions de noms de fichiers spécifiées au +jeu de caractères spécifié |
|---|---|
| Syntaxe: | AddCharset jeu-car extension
+[extension] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive AddCharset permet d'associer
+ les extensions de noms de fichiers spécifiées au jeu de caractères
+ spécifié (le nom enregistré sur l'Internet d'un codage de caractères
+ donné). jeu-car est le paramètre jeu
+ de caractères du type de médium pour les ressources dont le nom
+ de fichier contient extension. Cette association est
+ ajoutée à toutes les autres déjà en vigueur, et écrase toute
+ association préexistante pour la même extension.
AddLanguage ja .ja +AddCharset EUC-JP .euc +AddCharset ISO-2022-JP .jis +AddCharset SHIFT_JIS .sjis+
Avec cet exemple, le document xxxx.ja.jis sera
+ traité en tant que document japonais dont le jeu de caractère est
+ ISO-2022-JP (idem pour le document
+ xxxx.jis.ja). La directive
+ AddCharset sert à la fois à informer le
+ client sur le codage des caractères du document afin que ce dernier
+ puisse être interprété et affiché correctement, et à la négociation de contenu, au
+ cours de laquelle le serveur décide lequel parmi plusieurs
+ documents possibles il renvoie au client en fonction des préférences
+ de ce dernier en matière de jeu de caractères.
L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial. Les noms de fichiers + peuvent posséder plusieurs extensions, et + l'argument extension sera comparé à chacune d'entre + elles.
+ + +| Description: | Associe les extensions de noms de fichiers données au type +de codage spécifié |
|---|---|
| Syntaxe: | AddEncoding codage extension
+[extension] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive AddEncoding permet d'associer
+ les extensions de noms de fichiers données au codage de contenu HTTP
+ spécifié. codage est le codage de contenu HTTP à ajouter
+ à la valeur du champ d'en-tête Content-Encoding pour les documents
+ possédant l'extension spécifiée. Cette association est
+ ajoutée à toutes les autres déjà en vigueur, et écrase toute
+ association préexistante pour la même extension.
AddEncoding x-gzip .gz +AddEncoding x-compress .Z+
Avec cet exemple, les noms de fichiers possédant l'extension
+ .gz seront marqués comme codés à l'aide du codage
+ x-gzip, et les noms de fichiers possédant l'extension
+ .Z comme codés avec x-compress.
Les clients anciens n'acceptent que x-gzip et
+ x-compress, bien que les standards stipulent qu'ils
+ sont respectivement équivalents à gzip et
+ compress. Apache effectue ses comparaisons de codages
+ de contenu en ignorant tout préfixe x-. Lorsqu'il
+ répond avec un codage, Apache utilise l'une ou l'autre forme (c'est
+ à dire x-foo ou foo) selon les besoins du
+ client. Si le client n'a pas besoin d'une forme particulière, Apache
+ utilisera la forme employée par la directive
+ AddEncoding. Pour résumer, vous devez toujours utiliser
+ x-gzip et x-compress pour ces deux
+ codages spécifiques. Certains codages plus récents, comme
+ deflate, doivent être spécifiés sans le préfixe
+ x-.
L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial. Les noms de fichiers + peuvent posséder plusieurs extensions, et + l'argument extension sera comparé à chacune d'entre + elles.
+ +| Description: | Associe les extensions de noms de fichiers données au +gestionnaire spécifié |
|---|---|
| Syntaxe: | AddHandler nom-gestionnaire extension
+[extension] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
Les fichiers dont le nom a pour extension extension
+ seront servis par le nom-gestionnaire spécifié. Cette
+ association est ajoutée à toutes les autres déjà en vigueur, et
+ écrase toute association préexistante pour la même
+ extension. Par exemple, pour associer les scripts CGI
+ avec l'extension de fichier .cgi, vous pouvez utiliser
+ :
AddHandler cgi-script .cgi+ + +
Une fois cette ligne insérée dans votre fichier httpd.conf, tout
+ fichier possédant l'extension .cgi sera traité en tant
+ que programme CGI.
L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial. Les noms de fichiers + peuvent posséder plusieurs extensions, et + l'argument extension sera comparé à chacune d'entre + elles.
+ +SetHandler| Description: | Associe les extensions de noms de fichiers aux +filtres spécifiés qui traiteront les requêtes clients |
|---|---|
| Syntaxe: | AddInputFilter filtre[;filtre...]
+extension [extension] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive AddInputFilter permet
+ d'associer l'extension de nom de fichier extension aux filtres spécifiés qui traiteront les
+ requêtes clients et les entrées POST à leur réception par le
+ serveur. Ceci s'ajoute à toute définition de filtre préexistante, y
+ compris la directive SetInputFilter. Cette
+ association est ajoutée à toutes les autres déjà en vigueur, et
+ écrase toute association préexistante pour la même
+ extension.
Si plusieurs filtres sont spécifiés, ils doivent être + séparés par des points-virgules et inscrits dans l'ordre selon + lequel ils devront traiter le contenu. L'argument filtre + est insensible à la casse.
+ +L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial. Les noms de fichiers + peuvent posséder plusieurs extensions, et + l'argument extension sera comparé à chacune d'entre + elles.
+ + +| Description: | Associe l'extension de nom de fichier donnée à la langue +spécifié |
|---|---|
| Syntaxe: | AddLanguage symbole-langue extension
+[extension] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive AddLanguage permet d'associer
+ l'extension de nom de fichier donnée à la langue spécifiée. Les
+ fichiers dont l'extension correspond à la valeur
+ de l'argument extension se voient attribuer la valeur de
+ l'argument symbole-langue comme en-tête HTTP
+ Content-Language en accord avec les identifiants de langues définis
+ par la RFC 3066. Cette directive l'emporte sur toute association
+ préexistante pour la même extension.
AddEncoding x-compress .Z +AddLanguage en .en +AddLanguage fr .fr+
Avec cet exemple, le document xxxx.en.Z sera traité
+ en tant que document compressé de langue anglaise (idem pour le
+ document xxxx.Z.en). Bien que la langue soit fournie au
+ client, le navigateur n'utilise habituellement pas cette
+ information. La directive AddLanguage est
+ principalement utilisée au cours de la négociation de contenu, où le
+ serveur choisit d'envoyer un document parmi plusieurs documents
+ possibles en fonction de la préférence du client en matière de
+ langue.
Si une extension fait l'objet de plusieurs associations de + langues, c'est la dernière qui sera utilisée. Ainsi, dans le cas + suivant,
+ +AddLanguage en .en +AddLanguage en-gb .en +AddLanguage en-us .en+ + +
les documents possédant l'extension .en seront
+ traités en tant que documents de langue en-us.
L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial. Les noms de fichiers + peuvent posséder plusieurs extensions, et + l'argument extension sera comparé à chacune d'entre + elles.
+ +| Description: | Associe les extensions de noms de fichiers aux +filtres spécifiés qui traiteront les réponses en provenance du +serveur |
|---|---|
| Syntaxe: | AddOutputFilter filtre[;filtre...]
+extension [extension] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive AddOutputFilter permet
+ d'associer l'extension de nom de fichier définie par l'argument
+ extension aux filtres qui traiteront les réponses en
+ provenance du serveur avant de les envoyer au client. Ces filtres
+ s'ajoutent à tout filtre défini par d'autres directives comme
+ SetOutputFilter et AddOutputFilterByType. Cette association
+ est fusionnée avec toute autre association en vigueur, et l'emporte
+ sur toute association préexistante pour la même
+ extension.
Avec l'exemple suivant, tous les fichiers .shtml
+ seront traités en tant qu'inclusions côté serveur (SSI), et la
+ sortie sera compressée à l'aide du module
+ mod_deflate.
AddOutputFilter INCLUDES;DEFLATE shtml+ + +
Si plusieurs filtres sont spécifiés, ils doivent être + séparés par des points-virgules et inscrits dans l'ordre selon + lequel il devront traiter le contenu. L'argument filtre + est insensible à la casse.
+ +L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial. Les noms de fichiers + peuvent posséder plusieurs extensions, et + l'argument extension sera comparé à chacune d'entre + elles.
+ +Notez que toute définition de filtres via la directive AddOutputFilter remplace toutes les
+ définitions précédentes effectuées via cette même directive.
# Filtre spécifié "DEFLATE" +AddOutputFilter DEFLATE shtml +<Location "/foo"> + # Filtre spécifié "INCLUDES", remplace "DEFLATE" + AddOutputFilter INCLUDES shtml +</Location> +<Location "/bar"> + # Filtre spécifié "INCLUDES;DEFLATE", remplace "DEFLATE" + AddOutputFilter INCLUDES;DEFLATE shtml +</Location> +<Location "/bar/baz"> + # Filtre spécifié "BUFFER", remplace "INCLUDES;DEFLATE" + AddOutputFilter BUFFER shtml +</Location> +<Location "/bar/baz/buz"> + # Pas de filtre spécifié, suppression de "BUFFER" + RemoveOutputFilter shtml +</Location>+ + +
| Description: | Associe les extensions de noms de fichiers au type de +contenu spécifié |
|---|---|
| Syntaxe: | AddType type-médium extension
+[extension] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive AddType permet d'associer les
+ extensions de noms de fichiers données au type de contenu spécifié.
+ type-médium est le Type
+ MIME à utiliser pour les fichiers dont le nom possède
+ l'extension extension. Cette association s'ajoute à toute
+ autre association en vigueur, et l'emporte sur toute association
+ préexistante pour la même extension.
TypesConfig, il est recommandé
+ d'utiliser la directive AddType pour
+ ajouter de nouveaux types de médias.
+ AddType image/gif .gif+
Ou, pour spécifier plusieurs extensions dans une seule directive + :
+ +AddType image/jpeg jpeg jpg jpe+
L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial. Les noms de fichiers + peuvent posséder plusieurs extensions, et + l'argument extension sera comparé à chacune d'entre + elles.
+ +Il est possible d'obtenir un effet similaire à celui de la
+ directive LanguagePriority du module
+ mod_negotiation en qualifiant un type de
+ média avec qs :
AddType application/rss+xml;qs=0.8 .xml+
Ceci peut s'avérer utile dans certaines situations, par exemple
+ lorsqu'un client qui a ajouté un en-tête Accept: */* à
+ sa requête n'est pas en mesure de traiter le contenu renvoyé par le
+ serveur.
À la base, cette directive configure le type de contenu généré + pour les fichiers statiques servis à partir du système de fichiers. + Dans le cas des ressources autres que les fichiers statiques pour + lesquelles le générateur de la réponse spécifie en général un + Content-Type, cette directive n'a aucun effet.
+ +Si aucun gestionnaire n'est explicitement défini pour une + requête, le type de contenu spécifié sera aussi utilisé comme nom du + gestionnaire.
+ +Lorsqu'aucune directive comme SetHandler ou
+ AddHandler ne s'applique à
+ une requête, le nom de gestionnaire interne normalement défini
+ par une de ces directives est en fait défini par le type de contenu
+ spécifié par la présente directive.
+ Pour des raisons historiques, certains modules tiers comme mod_php + peuvent adopter ce type de comportement pour prendre en compte la + requête concernée. +
+Il est conseillé d'éviter les configurations qui reposent sur de
+ tels types "synthétiques". En outre, les configurations qui
+ limitent l'accès aux directives SetHandler ou AddHandler doivent aussi limiter
+ l'accès à la directive AddType.
| Description: | Définit un symbole de langue par défaut à affecter au champ +d'en-tête Content-Language pour toutes les ressources dans le contexte +courant auxquelles aucun symbole de langue n'a été +associé. |
|---|---|
| Syntaxe: | DefaultLanguage symbole-langue |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive DefaultLanguage permet
+ d'indiquer à Apache que toutes les ressources du contexte courant
+ (par exemple, toutes les ressources concernées par le conteneur
+ <Directory>
+ courant) qui ne possèdent pas d'extension de langue explicite
+ (comme .fr ou .de tel que défini par la
+ directive AddLanguage),
+ verront leur en-tête HTTP Content-Language affecté de la langue
+ symbole-langue. Ceci permet de marquer des arborescences
+ de répertoires entières comme contenant des documents en français,
+ par exemple, sans avoir à renommer chaque fichier. Notez qu'à la
+ différence de l'utilisation des extensions pour spécifier des
+ langues, DefaultLanguage ne permet de
+ spécifier qu'une seule langue.
Si aucune directive DefaultLanguage n'est
+ en vigueur, et si un fichier ne possède pas d'extension configurée
+ par la directive AddLanguage, aucun champ d'en-tête
+ Content-Language ne sera généré.
DefaultLanguage en+
| Description: | Indique à mod_mime de traiter les éléments
+de path_info en tant que parties du nom de
+fichier |
|---|---|
| Syntaxe: | ModMimeUsePathInfo On|Off |
| Défaut: | ModMimeUsePathInfo Off |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_mime |
La directive ModMimeUsePathInfo permet de
+ combiner le nom de fichier avec la partie path_info de
+ l'URL pour appliquer les directives mod_mime à la
+ requête. La valeur par défaut est Off - situation dans
+ laquelle l'élément path_info est ignoré.
L'utilisation de cette directive est conseillée si vous utilisez + un système de fichiers virtuel.
+ +ModMimeUsePathInfo On+
Considérons une requête pour /index.php/foo.shtml,
+ mod_mime ne traitera pas la requête entrante comme
+ /index.php/foo.shtml et les directives comme
+ AddOutputFilter INCLUDES .shtml ajouteront le filtre
+ INCLUDES à la requête. Si la directive
+ ModMimeUsePathInfo n'est pas définie, le
+ filtre INCLUDES ne sera pas ajouté. Le fonctionnement
+ sera identique dans le cas des chemins virtuels, tels que ceux
+ définis par la directive <Location>
| Description: | Les types de fichiers qui seront inclus lors d'une +recherche de correspondance de fichier avec les vues multiples +(MultiViews) |
|---|---|
| Syntaxe: | MultiviewsMatch Any|NegotiatedOnly|Filters|Handlers
+[Handlers|Filters] |
| Défaut: | MultiviewsMatch NegotiatedOnly |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive MultiviewsMatch permet trois
+ comportements différents pour la fonctionnalité Multiviews du module
+ mod_negotiation. Les vues
+ multiples permettent d'associer une requête pour un fichier, par
+ exemple index.html, à toute extension négociée
+ s'ajoutant à la requête de base, par exemple
+ index.html.en, index.html.fr, ou
+ index.html.gz.
L'option NegotiatedOnly implique que toute extension
+ s'ajoutant au nom de base doit correspondre à une extension de
+ mod_mime reconnue pour la négociation de contenu,
+ par exemple Charset, Content-Type, Language, ou Encoding. C'est la
+ valeur d'option par défaut, et la contrainte la plus stricte
+ dont les effets de bord inattendus sont les moins nombreux.
Pour inclure des extensions associées avec des gestionnaires
+ et/ou des filtres, définissez la directive
+ MultiviewsMatch avec les mots-clés
+ Handlers, Filters, ou les deux. Si tous
+ les autres facteurs sont égaux, c'est le fichier de plus petite
+ taille qui sera servi ; par exemple, si le choix doit s'opérer entre
+ index.html.cgi de 500 octets et
+ index.html.pl de 1000 octets, c'est le fichier
+ .cgi qui l'emportera dans cet exemple. Les utilisateurs
+ de fichiers .asis auront avantage à utiliser l'option
+ Handler, si les fichiers .asis sont associés au
+ gestionnaire asis-handler.
Vous pouvez enfin autoriser l'association de toute extension avec
+ l'option Any, même si mod_mime ne
+ reconnaît pas l'extension. Ceci
+ peut conduire à des résultats imprévisibles, comme l'envoi de
+ fichiers .old ou .bak contrairement aux souhaits du webmaster.
Par exemple, la configuration suivante va permettre l'inclusion + des extensions associées aux gestionnaires et aux filtres dans les + vues multiples, tout en excluant les fichiers de type inconnu :
+ +MultiviewsMatch Handlers Filters+ + +
L'utilisation de la directive
+ MultiviewsMatch dans une section <Location> ou <LocationMatch> n'est pas
+ permise.
| Description: | Supprime toute association de jeu de caractères pour un +ensemble d'extensions de noms de fichiers |
|---|---|
| Syntaxe: | RemoveCharset extension [extension]
+... |
| Contexte: | serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive RemoveCharset permet de
+ supprimer toute association de jeu de caractères pour les fichiers
+ dont les noms possèdent les extensions spécifiées. Ceci permet, au
+ sein des fichiers .htaccess, d'annuler toute
+ association héritée du répertoire parent ou de la configuration du
+ serveur pour un répertoire particulier.
L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial.
+ +RemoveCharset .html .shtml+
| Description: | Supprime toute association de codage de contenu pour un +ensemble d'extensions de noms de fichiers |
|---|---|
| Syntaxe: | RemoveEncoding extension [extension]
+... |
| Contexte: | serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive RemoveEncoding permet de
+ supprimer toute association de codage pour les fichiers dont les
+ noms possèdent les extensions spécifiées. Ceci permet, au
+ sein des fichiers .htaccess, d'annuler toute
+ association héritée du répertoire parent ou de la configuration du
+ serveur pour un répertoire particulier. Voici un exemple
+ d'utilisation de cette directive :
AddEncoding x-gzip .gz +AddType text/plain .asc +<Files "*.gz.asc"> + RemoveEncoding .gz +</Files>+
Avec cette configuration, le fichier foo.gz sera
+ marqué comme codé avec gzip, mais foo.gz.asc sera
+ marqué comme fichier texte non codé.
Les directives RemoveEncoding étant
+ traitées après toute directive AddEncoding, il est possible
+ qu'elles annulent les effets de ces dernières si les deux
+ apparaissent dans la configuration du même répertoire.
L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial.
+ +| Description: | Supprime toute association de gestionnaire à un ensemble +d'extensions de noms de fichiers |
|---|---|
| Syntaxe: | RemoveHandler extension [extension]
+... |
| Contexte: | serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive RemoveHandler permet de
+ supprimer toute association de gestionnaire à des fichiers dont le
+ nom possède l'extension donnée. Ceci permet, au
+ sein des fichiers .htaccess, d'annuler toute
+ association héritée du répertoire parent ou de la configuration du
+ serveur pour un répertoire particulier. Voici un exemple
+ d'utilisation de cette directive :
AddHandler server-parsed .html+
RemoveHandler .html+
Avec cette dernière ligne, les fichiers .html du
+ répertoire /foo/bar seront traités en tant que fichiers
+ normaux, au lieu d'être traités en tant que candidats à
+ l'interprétation (voir le module mod_include
+ module).
L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial.
+ +| Description: | Supprime toute association de filtre en entrée à un +ensemble d'extensions de noms de fichiers |
|---|---|
| Syntaxe: | RemoveInputFilter extension [extension]
+... |
| Contexte: | serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive RemoveInputFilter permet de
+ supprimer toute association de filtre
+ en entrée à des fichiers dont le nom possède l'extension donnée.
+ Ceci permet, au
+ sein des fichiers .htaccess, d'annuler toute
+ association héritée du répertoire parent ou de la configuration du
+ serveur pour un répertoire particulier.
L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial.
+ +| Description: | Supprime toute association de langue à un ensemble +d'extensions de noms de fichiers |
|---|---|
| Syntaxe: | RemoveLanguage extension [extension]
+... |
| Contexte: | serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive RemoveLanguage permet de
+ supprimer toute association de langue à des fichiers dont le nom
+ possède l'extension donnée. Ceci permet, au
+ sein des fichiers .htaccess, d'annuler toute
+ association héritée du répertoire parent ou de la configuration du
+ serveur pour un répertoire particulier.
L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial.
+ +| Description: | Supprime toute association de filtre en sortie à un +ensemble d'extensions de noms de fichiers |
|---|---|
| Syntaxe: | RemoveOutputFilter extension [extension]
+... |
| Contexte: | serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive RemoveOutputFilter permet de
+ supprimer toute association de filtre
+ en sortie à des fichiers dont le nom possède l'extension donnée. Ceci permet, au
+ sein des fichiers .htaccess, d'annuler toute
+ association héritée du répertoire parent ou de la configuration du
+ serveur pour un répertoire particulier.
L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial.
+ +RemoveOutputFilter shtml+
| Description: | Supprime toute association de type de contenu à un ensemble +d'extensions de noms de fichiers |
|---|---|
| Syntaxe: | RemoveType extension [extension]
+... |
| Contexte: | serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_mime |
La directive RemoveType permet de
+ supprimer toute association de type de
+ médium à des fichiers dont le nom possède l'extension
+ donnée. Ceci permet, au
+ sein des fichiers .htaccess, d'annuler toute
+ association héritée du répertoire parent ou de la configuration du
+ serveur pour un répertoire particulier. Voici un exemple
+ d'utilisation de cette directive :
RemoveType .cgi+
Cette ligne aura pour effet de supprimer tout traitement
+ spécifique des fichiers .cgi dans le répertoire
+ /foo/ et ses sous-répertoires, et les réponses
+ contenant ce type de fichier ne possèderont pas de champ d'en-tête
+ HTTP Content-Type.
Les directives RemoveType sont traitées
+ après toutes les directives AddType, et il est possible que les
+ effets de ces dernières soient annulés si les deux types de
+ directives sont présents au sein de la configuration du même
+ répertoire.
L'argument extension est insensible à la casse et peut + être spécifié avec ou sans le point initial.
+ +| Description: | Le chemin du fichier mime.types |
|---|---|
| Syntaxe: | TypesConfig chemin-fichier |
| Défaut: | TypesConfig conf/mime.types |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_mime |
La directive TypesConfig permet de définir
+ le chemin du fichier de configuration des types de média. L'argument
+ chemin-fichier est un chemin relatif au répertoire défini
+ par la directive ServerRoot. Ce
+ fichier contient la liste des associations par défaut des extensions
+ de noms de fichiers aux types de contenus. La plupart des
+ administrateurs utilisent le fichier mime.types fourni
+ par leur système d'exploitation,
+ qui associe les extensions de noms de fichiers courantes à la liste
+ officielle des types de média enregistrés par l'IANA et maintenue à
+ http://www.iana.org/assignments/media-types/index.html, ainsi
+ qu'un grand nombre de types non officiels. Ce fichier permet de
+ simplifier le fichier httpd.conf en fournissant la
+ majorité des définitions de types de média, et ses définitions
+ peuvent être écrasées par des directives AddType, selon les besoins. Il est
+ déconseillé de modifier le contenu du fichier
+ mime.types car il peut être remplacé lors d'une mise à
+ jour du serveur.
Le fichier contient des lignes dont le format est identique à
+ celui des arguments d'une directive AddType :
+ type-médium [extension] ...
+
Les extensions sont insensibles à la casse. Les lignes vides et
+ les lignes commençant par un dièse (#) sont
+ ignorées. Les lignes vides servent à compléter le fichier
+ mime.types. Apache httpd peut encore déterminer ces types via le
+ module mod_mime_magic.
mime.types fourni, sauf si :
+ 1) le type de médium est déjà enregistré à l'IANA
+ 2) et si l'extension est largement acceptée et ne provoque pas de
+ conflits d'extensions entre les différentes plate-formes. Les
+ requêtes du type catégorie/x-sous-type seront
+ systématiquement rejetées, ainsi que toute nouvelle extension de
+ deux lettres, car elle ont de fortes chances d'entrer en conflit
+ par la suite avec les inombrables langues préexistantes et les
+ espaces de nommage des jeux de caractères.
+ Serveur HTTP Apache Version 2.4
+| Description: | Détermine le type MIME d'un fichier à partir de quelques +octets de son contenu |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | mime_magic_module |
| Fichier Source: | mod_mime_magic.c |
Ce module permet de déterminer le type
+ MIME des fichiers de la même manière que la commande Unix
+ file(1), à savoir en se basant sur les premiers octets
+ du fichier. Il est conçu comme une "seconde ligne de défense" pour
+ les cas où mod_mime ne parvient pas à déterminer le
+ type du fichier.
Ce module est dérivé d'une version libre de la commande Unix
+ file(1) qui utilise des "nombres magiques" et autres
+ marques distinctives issus du contenu du fichier pour essayer de
+ déterminer le type de contenu. Ce module n'est activé que si le
+ fichier magique est spécifié par la directive MimeMagicFile.
Le fichier contient du texte ASCII sur 4 à 5 colonnes. Les lignes
+ vides sont autorisées mais ignorées. Toute ligne commençant par un
+ dièse (#) est un commentaire. Les autres lignes sont
+ interprétées en colonnes comme suit :
| Colonne | Description | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | +numéro de l'octet à partir duquel la vérification débute + " >" indique une dépendance par rapport à la
+ dernière ligne non-">" | ||||||||||||||||||||||
| 2 | +type de donnée à rechercher +
| ||||||||||||||||||||||
| 3 | +contenu des données à rechercher | ||||||||||||||||||||||
| 4 | +type MIME si correspondance | ||||||||||||||||||||||
| 5 | +codage MIME si correspondance (optionnel) |
Par exemple, les lignes du fichier magique suivantes + permettraient de reconnaître certains formats audio :
+ +# Sun/NeXT audio data +0 string .snd +>12 belong 1 audio/basic +>12 belong 2 audio/basic +>12 belong 3 audio/basic +>12 belong 4 audio/basic +>12 belong 5 audio/basic +>12 belong 6 audio/basic +>12 belong 7 audio/basic +>12 belong 23 audio/x-adpcm
Et celles-ci permettraient de reconnaître la différence entre les
+ fichiers *.doc qui contiennent des documents Microsoft
+ Word et les documents FrameMaker (ce sont des formats de fichiers
+ incompatibles qui possèdent le même suffixe).
# Frame +0 string \<MakerFile application/x-frame +0 string \<MIFFile application/x-frame +0 string \<MakerDictionary application/x-frame +0 string \<MakerScreenFon application/x-frame +0 string \<MML application/x-frame +0 string \<Book application/x-frame +0 string \<Maker application/x-frame + +# MS-Word +0 string \376\067\0\043 application/msword +0 string \320\317\021\340\241\261 application/msword +0 string \333\245-\0\0\0 application/msword
Un champ optionnel codage MIME peut être ajouté dans la cinquième + colonne. Par exemple, cette ligne permet de reconnaître les fichiers + compressés par gzip et définissent le type de codage.
+ +# gzip (GNU zip, à ne pas confondre avec +# l'archiveur zip [Info-ZIP/PKWARE]) + +0 string \037\213 application/octet-stream x-gzip
Ce module n'est pas fait pour tous les systèmes. Si votre système + parvient à peine à supporter sa charge, ou si vous testez les + performances d'un serveur web, il est déconseillé d'utiliser ce + module car son fonctionnement a un prix en matière de ressources + consommées.
+ +Des efforts ont cependant été fournis pour améliorer les
+ performances du code original de la commande file(1) en
+ l'adaptant pour fonctionner sur un serveur web à forte charge. Il a
+ été conçu pour un serveur sur lequel des milliers d'utilisateurs
+ publient leurs propres documents, ce qui est probablement très
+ courant sur un intranet. Il s'avère souvent bénéfique qu'un serveur
+ puisse prendre des décisions plus pertinentes à propos du contenu
+ d'un fichier que celles se basant sur le nom du fichier seul, ne
+ serait-ce que pour diminuer le nombre d'appels du type "pourquoi ma
+ page ne s'affiche-t-elle pas ?" survenant lorsque les utilisateurs
+ nomment leurs fichiers incorrectement. Vous devez déterminer si la
+ charge supplémentaire convient à votre environnement.
Les notes suivantes s'appliquent au module
+ mod_mime_magic et sont incluses ici pour
+ conformité avec les restrictions de copyright des contributeurs
+ qui requièrent de les accepter.
Note de traduction : ces informations de type légal ne sont pas traductibles
+ +mod_mime_magic: MIME type lookup via file magic numbers
+ Copyright (c) 1996-1997 Cisco Systems, Inc.
This software was submitted by Cisco Systems to the Apache Group + in July 1997. Future revisions and derivatives of this source code + must acknowledge Cisco Systems as the original contributor of this + module. All other licensing and usage conditions are those of the + Apache Group.
+ +Some of this code is derived from the free version of the file + command originally posted to comp.sources.unix. Copyright info for + that program is included below as required.
+- Copyright (c) Ian F. Darwin, 1987. Written by Ian F. Darwin.
+ +This software is not subject to any license of the American + Telephone and Telegraph Company or of the Regents of the University + of California.
+ +Permission is granted to anyone to use this software for any + purpose on any computer system, and to alter it and redistribute it + freely, subject to the following restrictions:
+ +For compliance with Mr Darwin's terms: this has been very + significantly modified from the free "file" command.
+ +realloc().| Description: | Active la détermination du type MIME en se basant sur le +contenu du fichier et en utilisant le fichier magique +spécifié |
|---|---|
| Syntaxe: | MimeMagicFile chemin-fichier |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_mime_magic |
La directive MimeMagicFile permet
+ d'activer ce module, le fichier par défaut fourni étant
+ conf/magic. Les chemins sans slash '/' de début sont
+ relatifs au répertoire défini par la directive ServerRoot. Les serveurs virtuels
+ utilisent le même fichier que le serveur principal sauf si un
+ fichier spécifique a été défini pour ce serveur virtuel, auquel cas
+ c'est ce dernier fichier qui sera utilisé.
MimeMagicFile conf/magic+
Serveur HTTP Apache Version 2.4
+| Description: | Effectue la négociation de +contenu |
|---|---|
| Statut: | Base |
| Identificateur de Module: | negotiation_module |
| Fichier Source: | mod_negotiation.c |
La négociation de contenu, ou plus précisément la sélection de + contenu, est la sélection parmi plusieurs documents disponibles, du + document qui "colle" au plus près des possibilités du client. Pour y + parvenir, deux méthodes sont employées.
+ +type-map) qui contient une liste
+ explicite des fichiers contenant les différentes variantes.Options Multiviews), où le
+ serveur effectue une recherche de correspondance de modèle de nom
+ de fichier implicite, et fait son choix parmi les résultats.Une table de correspondances de types possède un format similaire + à celui des en-têtes de messagerie RFC822. Elle contient des + descriptions de documents séparées par des lignes vides, toute ligne + commençant par un dièse ('#') étant considérée comme un + commentaire. Une description de document comporte plusieurs + enregistrements d'en-têtes ; chaque enregistrement peut être réparti + sur plusieurs lignes à condition que les lignes supplémentaires + commencent par un ou plusieurs espaces. Lors du traitement, les + espaces de début de ligne seront supprimés et les lignes + concaténées. L'enregistrement d'un en-tête comprend un mot-clé qui + se termine toujours par un caractère "deux-points" ':', suivi d'une + valeur. Les espaces sont autorisés entre le nom d'en-tête et sa + valeur, ainsi qu'entre les différents éléments de la valeur. Les + en-têtes autorisés sont :
+ +Content-Encoding:AddEncoding. Sont normalement inclus
+ les codages x-compress pour les fichiers compressés
+ avec compress, et x-gzip pour les fichiers compressés
+ avec gzip. Le préfixe x- est ignoré lors des
+ comparaisons de codages.Content-Language:en correspond à l'anglais. Si la variante
+ contient plusieurs langages, ils sont séparés par des
+ virgules.Content-Length:Content-Type:nom=valeur. Les paramètres
+ courants sont :
+
+ leveltext/html, la valeur par défaut est 2, sinon
+ 0.qsqs sont donc spécifiques à une certaine
+ ressource.
+ Content-Type: image/jpeg; qs=0.8
+
URI:Body:
+ Body:----xyz----
+ <html>
+ <body>
+ <p>Contenu de la page.</p>
+ </body>
+ </html>
+ ----xyz----
+
Considérons une ressource, document.html, disponible
+ en anglais, en français et en allemand. Les fichiers correspondants
+ se nomment respectivement document.html.en,
+ document.html.fr, et document.html.de. Le
+ fichier de correspondances de types se nommera
+ document.html.var et contiendra ce qui suit :
+ URI: document.html
+
+ Content-language: en
+ Content-type: text/html
+ URI: document.html.en
+
+ Content-language: fr
+ Content-type: text/html
+ URI: document.html.fr
+
+ Content-language: de
+ Content-type: text/html
+ URI: document.html.de
+
+
+
Ces quatre fichiers doivent se trouver dans le même répertoire,
+ et le fichier .var doit être associé au gestionnaire
+ type-map via une directive AddHandler :
AddHandler type-map .var+ + +
A l'arrivée d'une requête pour la ressource
+ document.html.var, la variante de
+ document.html qui correspond le mieux à la préference
+ de langage spécifiée dans l'en-tête de la requête de l'utilisateur
+ Accept-Language sera choisie.
Si Multiviews est activée, et si MultiviewsMatch est définie à
+ "handlers" ou "any", une requête pour document.html va
+ rechercher document.html.var, et continuer la
+ négociation avec le gestionnaire explicite type-map.
D'autres directives de configuration, comme Alias, peuvent être utilisées pour
+ associer document.html avec
+ document.html.var.
Une recherche Multivues est activée par l'Options Multiviews. Si le
+ serveur reçoit une requête pour /un/répertoire/foo, et
+ si /un/répertoire/foo n'existe pas, le serveur parcourt
+ le répertoire à la recherche de tous les fichiers de nom
+ foo.*, et simule véritablement une correspondance de
+ type qui nomme tous ces fichiers en leur assignant les mêmes type
+ de média et codage de contenu qu'ils auraient eus si le client avait
+ requis l'un d'entre eux avec son nom complet. Il choisit ensuite le
+ fichier qui correspond le mieux au profile du client, puis renvoie
+ le document.
La directive MultiviewsMatch définit si Apache doit
+ prendre en compte les fichiers qui ne comportent pas de métadonnées
+ de négociation de contenu lors du choix du fichier à servir.
| Description: | Permet la mise en cache au niveau des serveurs mandataires +des documents dont le contenu a été négocié |
|---|---|
| Syntaxe: | CacheNegotiatedDocs On|Off |
| Défaut: | CacheNegotiatedDocs Off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_negotiation |
Si elle est définie à "on", cette directive permet la mise en + cache au niveau des serveurs mandataires des documents dont le + contenu a été négocié. Le processus de mise en cache sera alors plus + efficace, mais des clients se trouvant derrière le mandataire + seront alors susceptibles de se voir servir des versions de + documents qui ne correspondent pas forcément à leurs attentes.
+ +Cette directive ne s'applique qu'aux requêtes en provenance de + navigateurs HTTP/1.0. HTTP/1.1 fournit un bien meilleur contrôle de + la mise en cache des documents au contenu négocié, et cette + directive n'a aucun effet sur les réponses aux requêtes + HTTP/1.1.
+ + +| Description: | Action à entreprendre si un document acceptable unique +n'est pas trouvé |
|---|---|
| Syntaxe: | ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback] |
| Défaut: | ForceLanguagePriority Prefer |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_negotiation |
La directive ForceLanguagePriority utilise
+ le langage défini par la directive LanguagePriority pour terminer
+ la négociation lorsque le serveur n'est pas en mesure de trouver une
+ solution satisfaisante unique.
ForceLanguagePriority Prefer utilise la directive
+ LanguagePriority pour servir le résultat d'un choix
+ unique, au lieu de renvoyer un résultat HTTP 300 (MULTIPLE CHOICES),
+ lorsque que plusieurs choix équivalents sont disponibles. Par
+ exemple, avec les deux directives ci-dessous, si l'en-tête
+ Accept-Language de l'utilisateur assigne à
+ en et de une qualité de .500
+ (les deux langages sont également acceptables), alors c'est la
+ première variante acceptable de langue en qui sera
+ servie.
LanguagePriority en fr de +ForceLanguagePriority Prefer+ + +
ForceLanguagePriority Fallback utilise la directive
+ LanguagePriority
+ pour servir un résultat valide, au lieu de renvoyer un résultat HTTP
+ 406 (NOT ACCEPTABLE). Avec les deux directives ci-dessous, si
+ l'en-tête Accept-Language de l'utilisateur ne mentionne
+ que les réponses de langage es, et si aucune variante
+ dans cette langue n'est trouvée, c'est la première variante de la
+ liste définie par la directive LanguagePriority qui sera servie.
LanguagePriority en fr de +ForceLanguagePriority Fallback+ + +
Les deux options, Prefer et Fallback,
+ peuvent être spécifiées, de façon à ce que la variante servie soit
+ la première variante qui convient définie par la directive
+ LanguagePriority si
+ plusieurs variantes sont également acceptables, ou le premier
+ document disponible si aucune variante ne convient à la liste de
+ langages acceptables fournie par le client.
AddLanguage| Description: | L'ordre de priorité des variantes de langages pour les +cas où le client n'a pas formulé de préférences |
|---|---|
| Syntaxe: | LanguagePriority langage-MIME [langage-MIME]
+... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_negotiation |
La directive LanguagePriority permet de
+ définir, au cours du traitement d'une requête Multivues, l'ordre de
+ priorité des variantes de langages pour les cas
+ où le client n'a pas formulé de préférences. La liste énumère les
+ langages-MIME dans un ordre de préférences
+ décroissantes.
LanguagePriority en fr de+ + +
Dans le cas d'une requête pour foo.html, si
+ foo.html.fr et foo.html.de existent, et si
+ le client n'a pas formulé de préférences, c'est le fichier
+ foo.html.fr qui sera renvoyé.
Notez que cette directive n'a d'effet que si le 'meilleur'
+ langage n'a pas pu être déterminé d'une autre manière ou si la
+ valeur de la directive ForceLanguagePriority est
+ différente de None. En général, c'est le client qui
+ détermine le langage préféré, non le serveur.
AddLanguageServeur HTTP Apache Version 2.4
+| Description: | Active le chiffrement SSL pour Netware |
|---|---|
| Statut: | Base |
| Identificateur de Module: | nwssl_module |
| Fichier Source: | mod_nw_ssl.c |
| Compatibilité: | NetWare seulement |
Ce module active le chiffrement SSL sur un port spécifique. Il + s'appuie sur la fonctionnalité de chiffrement SSL intégrée au + système d'exploitation Netware.
+| Description: | Liste de certificats clients supplémentaires |
|---|---|
| Syntaxe: | NWSSLTrustedCerts nom-fichier
+[nom-fichier] ... |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_nw_ssl |
Cette directive permet de spécifier une liste de fichiers (au
+ format DER) contenant des certificats clients utilisés lors de
+ l'établissement d'une connexion SSL mandatée. Chaque certificat
+ client utilisé par un serveur doit être enregistré séparément dans
+ son propre fichier .der.
| Description: | Permet de promouvoir une connexion non SSL au statut de +connexion SSL à la demande |
|---|---|
| Syntaxe: | NWSSLUpgradeable [adresse-IP:]num-port |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_nw_ssl |
Cette directive permet de promouvoir une connexion établie sur
+ l'adresse IP et/ou le port spécifiés au statut de connexion SSL à la
+ demande du client. L'adresse et/ou le port doivent avoir été définis
+ au préalable par une directive Listen.
| Description: | Active le chiffrement SSL pour le port +spécifié |
|---|---|
| Syntaxe: | SecureListen [adresse-IP:]num-port
+nom-certificat [MUTUAL] |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_nw_ssl |
Cette directive permet de spécifier le port et le nom de + certificat de style eDirectory qui seront utilisés pour activer le + chiffrement SSL. En outre, un troisième paramètre optionnel permet + d'activer l'authentification mutuelle.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Support des privilèges de Solaris et de l'exécution des +serveurs virtuels sous différents identifiants +utilisateurs. |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | privileges_module |
| Fichier Source: | mod_privileges.c |
| Compatibilité: | Disponible depuis la version 2.3 d'Apache sur les +plates-formes Solaris 10 et OpenSolaris |
Ce module permet l'exécution de différents serveurs virtuels sous +différents identifiants Unix User et Group, +et avec différents Privilèges +Solaris. En particulier, il apporte au problème de +séparation des privilèges entre les différents serveurs virtuels la +solution que devait apporter le module MPM abandonné perchild. Il +apporte aussi d'autres améliorations en matière de sécurité.
+ +À la différence de perchild, mod_privileges n'est
+pas un module MPM. Il travaille au sein d'un modèle de
+traitement pour définir les privilèges et les User/Group pour chaque
+requête dans un même processus. Il n'est donc pas compatible avec
+les MPM threadés, et refusera de s'exécuter en cas d'utilisation d'un de
+ces derniers.
mod_privileges traite des problèmes de sécurité
+similaires à ceux de suexec ; mais à la
+différence de ce dernier, il ne s'applique pas seulement aux programmes
+CGI, mais à l'ensemble du cycle de traitement d'une requête, y compris
+les applications in-process et les sous-processus. Il convient
+particulièrement à l'exécution des applications PHP sous
+mod_php, qui est lui-même incompatible avec les modules
+MPM threadés. Il est également bien adapté aux autres applications de type
+script in-process comme mod_perl,
+mod_python, et mod_ruby, ainsi qu'aux
+applications en langage C telles que les modules Apache pour lesquels la
+séparation des privilèges constitue un problème.
DTracePrivileges PrivilegesMode VHostCGIMode VHostCGIPrivs VHostGroup VHostPrivs VHostSecure VHostUsermod_privileges introduit de nouveaux problèmes de
+sécurité dans les situations où du code non sûr peut
+s'exécuter à l'intérieur du processus du serveur web.
+Ceci s'applique aux modules non sûrs, et aux scripts s'exécutant sous
+des modules comme mod_php ou mod_perl. Les scripts s'exécutant en
+externe (comme par exemple les scripts CGI ou ceux s'exécutant sur un
+serveur d'applications derrière mod_proxy ou mod_jk) ne sont pas
+concernés.
Les principaux problèmes de sécurité que l'on rencontre avec +mod_privileges sont :
+ + +La directive PrivilegesMode vous permet de
+sélectionner soit le mode FAST, soit le mode
+SECURE. Vous pouvez panacher les modes en utilisant par
+exemple le mode FAST pour les utilisateurs de confiance et
+les chemins contenant du code entièrement audité, tout en imposant le
+mode SECURE où un utilisateur non sûr a la possibilité
+d'introduire du code.
Avant de décrire les modes, il nous faut présenter les cas +d'utilisation de la cible : "Benign" ou "Hostile". Dans une situation +"Benign", vous voulez séparer les utilisateurs pour leur confort, et les +protéger, ainsi que le serveur, contre les risques induits par les +erreurs involontaires. Dans une situation "Hostile" - par exemple +l'hébergement d'un site commercial - il se peut que des utilisateurs +attaquent délibérément le serveur ou s'attaquent entre eux.
+Vous pouvez sélectionner différents
+PrivilegesModes pour chaque serveur virtuel, et
+même dans un contexte de répertoire à l'intérieur d'un serveur virtuel.
+Le mode FAST convient lorsque les utilisateurs sont sûrs
+et/ou n'ont pas le privilège de charger du code "in-process". Le mode
+SECURE convient dans les cas où du code non sûr peut
+s'exécuter "in-process". Cependant, même en mode SECURE, il
+n'y a pas de protection contre un utilisateur malveillant qui a la
+possibilité d'introduire du code supportant les privilèges avant le
+début du cycle de traitement de la requête.
| Description: | Détermine si les privilèges requis par dtrace sont +activés. |
|---|---|
| Syntaxe: | DTracePrivileges On|Off |
| Défaut: | DTracePrivileges Off |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | >Disponible sous Solaris 10 et OpenSolaris avec les
+modules MPM non-threadés (prefork ou MPM
+personnalisé). |
Cette directive qui s'applique à l'ensemble du serveur permet de + déterminer si Apache s'exécutera avec les privilèges requis pour exécuter dtrace. + Notez que la définition DTracePrivileges On n'activera + pas à elle-seule DTrace, mais que DTracePrivileges Off + l'empêchera de fonctionner.
+ +| Description: | Fait un compromis entre d'une part l'efficacité et la +vitesse de traitement et d'autre part la sécurité à l'encontre des codes +malicieux supportant les privilèges. |
|---|---|
| Syntaxe: | PrivilegesMode FAST|SECURE|SELECTIVE |
| Défaut: | PrivilegesMode FAST |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec des
+modules MPMs non threadés (comme prefork ou un module
+personnalisé). |
Cette directive permet de faire un compromis entre les +performances et la sécurité à l'encontre des codes malicieux supportant +les privilèges. En mode SECURE, chaque requête est traitée +dans un sous-processus sécurisé, ce qui induit une dégradation sensible +des performances. En mode FAST, le serveur n'est pas protégé +contre l'augmentation de privilège comme décrit plus haut.
+Cette directive est sensiblement différente selon qu'elle se trouve
+dans une section <Directory> (ou Location/Files/If)
+ou au niveau global ou dans un <VirtualHost>.
Au niveau global, elle définit un comportement par défaut dont
+hériteront les serveurs virtuels. Dans un serveur virtuel, les modes
+FAST ou SECURE agissent sur l'ensemble de la requête HTTP, et toute
+définition de ces modes dans une section <Directory>
+sera ignorée. Le pseudo-mode SELECTIVE confie le choix
+du mode FAST ou SECURE aux directives contenues dans une
+section<Directory>.
Dans une section <Directory>, elle ne s'applique
+que lorsque le mode SELECTIVE a été défini pour le serveur virtuel.
+Seuls FAST ou SECURE peuvent être définis dans ce contexte (SELECTIVE
+n'aurait pas de sens).
<Directory> qui
+ s'applique à la requête. Ceci peut donner à un attaquant
+ l'opportunité d'introduire du code via une directive RewriteMap s'exécutant au
+ niveau global ou d'un serveur virtuel avant que les
+ privilèges n'aient été supprimés et l'uid/gid défini.
+| Description: | Détermine si le serveur virtuel peut exécuter des +sous-processus, et définit les privilèges disponibles pour ces +dernier. |
|---|---|
| Syntaxe: | VHostCGIMode On|Off|Secure |
| Défaut: | VHostCGIMode On |
| Contexte: | serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec les
+modules MPM non-threadés (prefork ou MPM
+personnalisé). |
Détermine si le serveur virtuel est autorisé à exécuter fork et
+ exec, et définit les privilèges requis pour exécuter des sous-processus. Si cette
+ directive est définie à Off le serveur virtuel ne
+ disposera d'aucun privilège et ne pourra exécuter ni des programmes
+ ou scripts CGI classiques via le module traditionnel
+ mod_cgi, ni des programmes externes similaires tels
+ que ceux créés via le module mod_ext_filter ou les
+ programmes de réécriture externes utilisés par la directive
+ RewriteMap. Notez que
+ ceci n'empêche pas l'exécution de programmes CGI via d'autres
+ processus et sous d'autres modèles de sécurité comme mod_fcgid, ce qui est la
+ solution recommandée sous Solaris.
Si cette directive est définie à On ou
+ Secure, le serveur virtuel pourra exécuter les scripts et
+ programmes externes cités ci-dessus. Définir la directive
+ VHostCGIMode à Secure a pour effet
+ supplémentaire de n'accorder aucun privilège aux sous-processus,
+ comme décrit dans la directive
+ VHostSecure.
| Description: | Assigne des privilèges au choix aux sous-processus créés +par un serveur virtuel. |
|---|---|
| Syntaxe: | VHostPrivs [+-]?nom-privilège [[+-]?nom-privilège] ... |
| Défaut: | Aucun |
| Contexte: | serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec les
+modules MPM non-threadés (prefork ou MPM
+personnalisé) et lorsque mod_privileges est construit
+avec l'option de compilation
+BIG_SECURITY_HOLE. |
La directive VHostCGIPrivs permet
+ d'assigner des privilèges au choix aux sous-processus créés par un serveur
+ virtuel, comme décrit dans la directive
+ VHostCGIMode. Chaque
+ nom-privilège correspond à un privilège Solaris tel que
+ file_setid ou sys_nfs.
nom-privilège peut être éventuellement préfixé par + + ou -, ce qui va respectivement accorder ou refuser le privilège. Si + nom-privilège est spécifié sans + ni -, tous les autres + privilèges préalablement assignés au serveur virtuel seront refusés. + Cette directive permet de construire aisément votre propre jeu de + privilèges en annulant tout réglage par défaut.
+ +L'utilisation de cette directive peut ouvrir d'immenses trous de + sécurité dans les sous-processus Apache, jusqu'à leur exécution avec les + droits de root. Ne l'utilisez que si vous êtes absolument sûr de + comprendre ce que vous faites !
| Description: | Définit l'identifiant du groupe sous lequel s'exécute un +serveur virtuel. |
|---|---|
| Syntaxe: | VHostGroup identifiant-groupe-unix |
| Défaut: | Hérite de l'identifiant du groupe spécifié par la directive
+ |
| Contexte: | serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec les
+modules MPM non-threadés (prefork ou MPM
+personnalisé). |
La directive VHostGroup permet de définir
+ l'identifiant du groupe unix sous lequel le serveur va traiter les
+ requêtes par l'intermédiaire d'un serveur virtuel. L'identifiant
+ du groupe est défini avant le traitement de la requête, puis
+ restauré à sa valeur de départ via les Privilèges
+ Solaris. Comme la définition
+ s'applique au processus, cette directive est incompatible
+ avec les modules MPM threadés.
Unix-group peut être :
+# suivi d'un numéro de groupe.Cette directive ne peut pas être utilisée pour exécuter Apache en + tant que root ! Elle est tout de même susceptible de poser des + problèmes de sécurité similaires à ceux décrits dans la + documentation de suexec.
GroupSuexecUserGroup| Description: | Assigne des privilèges à un serveur virtuel. |
|---|---|
| Syntaxe: | VHostPrivs [+-]?nom-privilège [[+-]?nom-privilège] ... |
| Défaut: | Aucun |
| Contexte: | serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec les
+modules MPM non-threadés (prefork ou MPM
+personnalisé) et lorsque mod_privileges est construit
+avec l'option de compilation
+BIG_SECURITY_HOLE. |
La directive VHostPrivs permet d'assigner
+ des privilèges au choix à un serveur virtuel. Chaque
+ nom-privilège correspond à un privilège Solaris tel que
+ file_setid ou sys_nfs.
nom-privilège peut être éventuellement préfixé par + + ou -, ce qui va respectivement accorder ou refuser le privilège. Si + nom-privilège est spécifié sans + ni -, tous les autres + privilèges préalablement assignés au serveur virtuel seront refusés. + Cette directive permet de construire aisément votre propre jeu de + privilèges en annulant tout réglage par défaut.
+ +L'utilisation de cette directive peut ouvrir d'immenses trous de + sécurité dans Apache, jusqu'au traitement de requêtes avec les + droits de root. Ne l'utilisez que si vous êtes absolument sûr de + comprendre ce que vous faites !
| Description: | Détermine si le serveur s'exécute avec une sécurité avancée +pour les serveurs virtuels. |
|---|---|
| Syntaxe: | VHostSecure On|Off |
| Défaut: | VHostSecure On |
| Contexte: | serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec les
+modules MPM non-threadés (prefork ou MPM
+personnalisé). |
Détermine si les serveurs virtuels traitent les requêtes avec une + sécurité avancée en supprimant les Privilèges rarement requis par un serveur web, mais disponibles + par défaut pour un utilisateur Unix standard, et donc susceptibles + d'être demandés par des modules et des applications. Il est + recommandé de conserver la définition par défaut (On), sauf si elle + empêche une application de fonctionner. Comme la définition + s'applique au processus, cette directive est incompatible + avec les modules MPM threadés.
+Le fait que la directive VHostSecure
+ empêche une application de fonctionner peut constituer un signal
+ d'avertissement indiquant que la sécurité de l'application doit être
+ revue.
| Description: | Définit l'identifiant utilisateur sous lequel s'exécute un +serveur virtuel. |
|---|---|
| Syntaxe: | VHostUser identifiant-utilisateur-unix |
| Défaut: | Hérite de l'identifiant utilisateur spécifié par la directive
+ |
| Contexte: | serveur virtuel |
| Statut: | Expérimental |
| Module: | mod_privileges |
| Compatibilité: | Disponible sous Solaris 10 et OpenSolaris avec les
+modules MPM non-threadés (prefork ou MPM
+personnalisé). |
La directive VHostUser permet de définir
+ l'identifiant utilisateur unix sous lequel le serveur va traiter les
+ requêtes par l'intermédiaire d'un serveur virtuel. L'identifiant
+ utilisateur est défini avant le traitement de la requête, puis
+ restauré à sa valeur de départ via les Privilèges
+ Solaris. Comme la définition
+ s'applique au processus, cette directive est incompatible
+ avec les modules MPM threadés.
identifiant-utilisateur-unix peut être :
+# suivi d'un numéro d'utilisateur.Cette directive ne peut pas être utilisée pour exécuter Apache en + tant que root ! Elle est tout de même susceptible de poser des + problèmes de sécurité similaires à ceux décrits dans la + documentation de suexec.
UserSuexecUserGroupServeur HTTP Apache Version 2.4
+| Description: | Serveur mandataire/passerelle multi-protocole |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_module |
| Fichier Source: | mod_proxy.c |
N'activez pas la fonctionnalité de mandataire avec la directive
+ ProxyRequests avant
+ d'avoir sécurisé votre serveur. Les serveurs
+ mandataires ouverts sont dangereux pour votre réseau,
+ mais aussi pour l'Internet au sens large.
mod_proxy et ses modules associés implémentent
+ un mandataire/passerelle pour le serveur HTTP Apache, et supportent
+ de nombreux protocoles courants, ainsi que plusieurs algorithmes de
+ répartition de charge. Le support de protocoles et d'algorithmes de
+ répartition de charge supplémentaires peut être assuré par des
+ modules tiers.
Un jeu de modules chargés dans le serveur permet de fournir les
+ fonctionnalités souhaitées. Ces modules peuvent être inclus
+ statiquement à la compilation, ou dynamiquement via la directive
+ LoadModule. Ce jeu de module
+ doit comporter :
mod_proxy, qui fournit les fonctionnalités de
+ base d'un mandatairemod_proxy_balancer et un ou plusieurs modules
+ de répartition, si la répartition de charge doit être mise en
+ oeuvre (Voir la documentation de
+ mod_proxy_balancer pour plus de détails).| Protocole | Module |
|---|---|
| AJP13 (Protocole Apache JServe version + 1.3) | mod_proxy_ajp |
| CONNECT (pour + SSL) | mod_proxy_connect |
| FastCGI | mod_proxy_fcgi |
| ftp | mod_proxy_ftp |
| HTTP/0.9, HTTP/1.0, et + HTTP/1.1 | mod_proxy_http |
| SCGI | mod_proxy_scgi |
| WS and WSS (Web-sockets) | mod_proxy_wstunnel |
En outre, d'autres modules fournissent des fonctionnalités
+ étendues. mod_cache et ses modules associés
+ fournissent la mise en cache. Les directives SSLProxy*
+ du module mod_ssl permettent de contacter des
+ serveurs distants en utilisant le protocole SSL/TLS. Ces modules
+ additionnels devront être chargés et configurés pour pouvoir
+ disposer de ces fonctionnalités.
Mandataires directs et
+ mandataires/passerelles inverses Exemples simples Accès via un gestionnaire Workers Contrôler l'accès à votre
+ mandataire Ralentissement au démarrage Mandataire en Intranet Ajustements relatifs au
+ protocole Corps de requêtes En-têtes de requête du mandataire
+ inverse BalancerGrowth BalancerInherit BalancerMember BalancerPersist NoProxy <Proxy> ProxyAddHeaders ProxyBadHeader ProxyBlock ProxyDomain ProxyErrorOverride ProxyIOBufferSize <ProxyMatch> ProxyMaxForwards ProxyPass ProxyPassInherit ProxyPassInterpolateEnv ProxyPassMatch ProxyPassReverse ProxyPassReverseCookieDomain ProxyPassReverseCookiePath ProxyPreserveHost ProxyReceiveBufferSize ProxyRemote ProxyRemoteMatch ProxyRequests ProxySet ProxySourceAddress ProxyStatus ProxyTimeout ProxyViaLe serveur HTTP Apache peut être configuré dans les deux modes mandataire + direct et mandataire inverse (aussi nommé + mode passerelle).
+ +Un mandataire direct standard est un serveur + intermédiaire qui s'intercale entre le client et le serveur + demandé. Pour obtenir un contenu hébergé par + le serveur demandé, le client envoie une requête au + mandataire en nommant le serveur demandé comme + cible. Le mandataire extrait alors le contenu depuis le + serveur demandé et le renvoie enfin au client. Le client doit être + configuré de manière appropriée pour pouvoir utiliser le mandataire + direct afin d'accéder à d'autres sites.
+ +L'accès à Internet depuis des clients situés derrière un
+ pare-feu est une utilisation typique du mandataire direct. Le
+ mandataire direct peut aussi utiliser la mise en cache (fournie
+ par mod_cache) pour réduire la charge du
+ réseau.
La fonctionnalité de mandataire direct est activée via la
+ directive ProxyRequests.
+ Comme les mandataires directs permettent aux clients d'accéder à
+ des sites quelconques via votre serveur et de dissimuler leur
+ véritable origine, il est indispensable de sécuriser votre serveur de façon à ce que seuls
+ les clients autorisés puissent accéder à votre serveur avant
+ d'activer la fonctionnalité de mandataire direct.
Un mandataire inverse (ou passerelle), + quant à lui, apparaît au client comme un serveur web standard. + Aucune configuration particulière du client n'est nécessaire. Le + client adresse ses demandes de contenus ordinaires dans l'espace + de nommage du mandataire inverse. Ce dernier décide alors où + envoyer ces requêtes, et renvoie le contenu au client comme s'il + l'hébergeait lui-même.
+ +L'accès d'utilisateurs depuis Internet vers un serveur situé + derrière un pare-feu est une utilisation typique du mandataire + inverse. On peut aussi utiliser les mandataires inverses pour + mettre en oeuvre une répartition de charge entre plusieurs + serveurs en arrière-plan, ou fournir un cache pour un serveur + d'arrière-plan plus lent. Les mandataires inverses peuvent aussi + tout simplement servir à rassembler plusieurs serveurs dans le + même espace de nommage d'URLs.
+ +La fonctionnalité de mandataire inverse est activée via la
+ directive ProxyPass ou
+ le drapeau [P] de la directive RewriteRule. Il n'est
+ pas nécessaire de définir ProxyRequests pour configurer
+ un mandataire inverse.
Les exemples ci-dessous illustrent de manière très basique la + mise en oeuvre de la fonctionnalité de mandataire et ne sont là que + pour vous aider à démarrer. Reportez-vous à la documentation de + chaque directive.
+ +Si en outre, vous désirez activer la mise en cache, consultez la
+ documentation de mod_cache.
ProxyPass "/foo" "http://foo.example.com/bar" +ProxyPassReverse "/foo" "http://foo.example.com/bar"+
ProxyRequests On +ProxyVia On + +<Proxy "*"> + Require host internal.example.com +</Proxy>+
Vous pouvez aussi forcer le traitement d'une requête en tant que + requête de mandataire inverse en créant un gestionnaire de transfert + approprié. Dans l'exemple suivant, toutes les requêtes pour + des scripts PHP seront transmises au serveur FastCGI + spécifié via un mandat inverse : +
+ +<FilesMatch "\.php$"> + # Les sockets Unix nécessitent une version 2.4.7 ou supérieure du + # serveur HTTP Apache + SetHandler "proxy:unix:/path/to/app.sock|fcgi://localhost/" +</FilesMatch>+
Cette fonctionnalité est disponible à partir de la version + 2.4.10 du serveur HTTP Apache.
+ +Le mandataire gère la configuration et les paramètres de + communication des serveurs originaux au sein d'objets nommés + workers. Deux types de worker sont fournis : le worker + par défaut du mandataire direct et le worker par défaut du + mandataire inverse. Il est aussi possible de définir explicitement + des workers supplémentaires.
+ +Les deux workers par défaut possèdent une configuration figée + et seront utilisés si aucun autre worker ne correspond à la + requête. Ils ne réutilisent pas les connexions et n'utilisent pas les + connexions HTTP persistantes (Keep-Alive). En effet, les + connexions TCP vers le serveur original sont fermées et ouvertes + pour chaque requête.
+ +Les workers définis explicitement sont identifiés par leur URL.
+ Ils sont en général définis via les directives ProxyPass ou ProxyPassMatch lorsqu'on les
+ utilise dans le cadre d'un mandataire inverse :
ProxyPass "/example" "http://backend.example.com" connectiontimeout=5 timeout=30+
Cette directive va créer un worker associé à l'URL du serveur
+ original http://backend.example.com qui utilisera les
+ valeurs de timeout données. Lorsqu'ils sont utilisés dans le cadre
+ d'un mandataire direct, les workers sont en général définis via la
+ directive ProxySet,
ProxySet "http://backend.example.com" connectiontimeout=5 timeout=30+
ou encore via les directives Proxy et ProxySet :
<Proxy "http://backend.example.com"> + ProxySet connectiontimeout=5 timeout=30 +</Proxy>+ + +
L'utilisation de workers définis explicitement dans le mode
+ mandataire direct n'est pas très courante, car les mandataires
+ directs communiquent en général avec de nombreux serveurs
+ originaux. La création explicite de workers pour certains serveurs
+ originaux peut cependant s'avérer utile si ces serveurs sont
+ très souvent sollicités. A leur niveau, les workers explicitement
+ définis ne possèdent aucune notion de mandataire direct ou
+ inverse. Ils encapsulent un concept de communication commun avec
+ les serveurs originaux. Un worker créé via la directive ProxyPass pour être utilisé dans le
+ cadre d'un mandataire inverse sera aussi utilisé dans le cadre
+ d'un mandataire directe chaque fois que l'URL vers le serveur
+ original correspondra à l'URL du worker, et vice versa.
L'URL qui identifie un worker correspond à l'URL de son serveur + original, y compris un éventuel chemin donné :
+ +ProxyPass "/examples" "http://backend.example.com/examples" +ProxyPass "/docs" "http://backend.example.com/docs"+ + +
Dans cet exemple, deux workers différents sont définis, chacun + d'eux utilisant des configurations et jeux de connexions + séparés.
+ +Le partage de workers intervient lorsque les URLs des workers + s'entrecoupent, ce qui arrive lorsque l'URL d'un worker + correspond au début de l'URL d'un autre worker défini plus loin + dans le fichier de configuration. Dans l'exemple suivant,
+ +ProxyPass "/apps" "http://backend.example.com/" timeout=60 +ProxyPass "/examples" "http://backend.example.com/examples" timeout=10+ + +
le second worker n'est pas vraiment créé. C'est le premier
+ worker qui est en fait utilisé. L'avantage de ceci réside dans
+ le fait qu'il n'existe qu'un seul jeu de connexions, ces
+ dernières étant donc réutilisées plus souvent. Notez que tous
+ les attributs de configuration définis explicitement pour le
+ deuxième worker seront ignorés, ce qui sera journalisé en tant
+ qu'avertissement. Ainsi, dans l'exemple ci-dessus, la valeur de
+ timeout retenue pour l'URL /exemples sera
+ 60, et non 10 !
Si vous voulez empêcher le partage de workers, classez vos
+ définitions de workers selon la longueur des URLs, de la plus
+ longue à la plus courte. Si au contraire vous voulez favoriser
+ ce partage, utilisez l'ordre de classement inverse. Voir aussi
+ l'avertissement à propos de l'ordre de classement des directives
+ ProxyPass.
Les workers définis explicitement sont de deux sortes :
+ workers directs et workers de répartition (de
+ charge). Ils supportent de nombreux attributs de
+ configuration importants décrits dans la directive ProxyPass. Ces mêmes attributs
+ peuvent aussi être définis via la directive ProxySet.
Le jeu d'options disponibles pour un worker direct dépend du
+ protocole spécifié dans l'URL du serveur original. Les protocoles
+ disponibles comprennent ajp, fcgi,
+ ftp, http et scgi.
Les workers de répartition sont des workers virtuels qui + utilisent les workers directs, connus comme faisant partie de leurs + membres, pour le traitement effectif des requêtes. Chaque + répartiteur peut comporter plusieurs membres. Lorsqu'il traite une + requête, il choisit un de ses membres en fonction de l'algorithme + de répartition de charge défini.
+ +Un worker de répartition est créé si son URL de worker comporte
+ balancer comme indicateur de protocole. L'URL du
+ répartiteur permet d'identifier de manière unique le worker de
+ répartition. La directive BalancerMember permet d'ajouter des
+ membres au répartiteur.
La résolution DNS s'effectue lorsque le socket vers le
+ domaine original est créé pour la première fois. Lorsque la réutilisation
+ des connexions est activée, chaque domaine d'arrière-plan n'est résolu qu'une
+ seule fois pour chaque processus enfant, et cette résolution est mise en
+ cache pour toutes les connexions ultérieures jusqu'à ce que le processus enfant
+ soit recyclé. Ce comportement doit être pris en considération lorsqu'on
+ planifie des tâches de maintenance du DNS impactant les domaines
+ d'arrière-plan. Veuillez aussi vous reporter aux paramètres de la
+ directive ProxyPass pour plus de
+ détails à propos de la réutilisation des connexions.
Vous pouvez restreindre l'accès à votre mandataire via le bloc
+ de contrôle <Proxy> comme dans
+ l'exemple suivant :
<Proxy "*"> + Require ip 192.168.0 +</Proxy>+ + +
Pour plus de détails sur les directives de contrôle d'accès,
+ voir la documentation du module
+ mod_authz_host.
Restreindre l'accès de manière stricte est essentiel si vous
+ mettez en oeuvre un mandataire direct (en définissant la directive
+ ProxyRequests à "on").
+ Dans le cas contraire, votre serveur pourrait être utilisé par
+ n'importe quel client pour accéder à des serveurs quelconques,
+ tout en masquant sa véritable identité. Ceci représente un danger
+ non seulement pour votre réseau, mais aussi pour l'Internet au
+ sens large. Dans le cas de la mise en oeuvre d'un mandataire
+ inverse (en utilisant la directive ProxyPass avec ProxyRequests Off), le contrôle
+ d'accès est moins critique car les clients ne peuvent contacter
+ que les serveurs que vous avez spécifiés.
Voir aussi la variable d'environnement Proxy-Chain-Auth.
+ +Si vous utilisez la directive ProxyBlock, les noms d'hôtes sont résolus en adresses
+ IP puis ces dernières mises en cache au cours du démarrage
+ à des fins de tests de comparaisons ultérieurs. Ce processus peut
+ durer plusieurs secondes (ou d'avantage) en fonction de la vitesse
+ à laquelle s'effectue la résolution des noms d'hôtes.
Un serveur mandataire Apache httpd situé à l'intérieur d'un Intranet
+ doit faire suivre les requêtes destinées à un serveur externe à
+ travers le pare-feu de l'entreprise (pour ce faire, définissez la
+ directive ProxyRemote de
+ façon à ce qu'elle fasse suivre le protocole concerné
+ vers le mandataire du pare-feu). Cependant, lorsqu'il doit accéder
+ à des ressources situées dans l'Intranet, il peut se passer du
+ pare-feu pour accéder aux serveurs. A cet effet, la directive
+ NoProxy permet de
+ spécifier quels hôtes appartiennent à l'Intranet et peuvent donc
+ être accédés directement.
Les utilisateurs d'un Intranet ont tendance à oublier le nom du
+ domaine local dans leurs requêtes WWW, et demandent par exemple
+ "http://un-serveur/" au lieu de
+ http://un-serveur.example.com/. Certains serveurs
+ mandataires commerciaux acceptent ce genre de requête et les
+ traitent simplement en utilisant un nom de domaine local
+ implicite. Lorsque la directive ProxyDomain est utilisée et si le
+ serveur est configuré comme
+ mandataire, Apache httpd peut renvoyer une réponse de redirection et
+ ainsi fournir au client l'adresse de serveur correcte,
+ entièrement qualifiée. C'est la méthode à privilégier car le
+ fichier des marque-pages de l'utilisateur contiendra alors des
+ noms de serveurs entièrement qualifiés.
Pour les cas où mod_proxy envoie des requêtes
+ vers un serveur qui n'implémente pas correctement les connexions
+ persistantes ou le protocole HTTP/1.1, il existe deux variables
+ d'environnement qui permettent de forcer les requêtes à utiliser
+ le protocole HTTP/1.0 avec connexions non persistantes. Elles
+ peuvent être définies via la directive SetEnv.
Il s'agit des variables force-proxy-request-1.0 et
+ proxy-nokeepalive.
<Location "/buggyappserver/"> + ProxyPass "http://buggyappserver:7001/foo/" + SetEnv force-proxy-request-1.0 1 + SetEnv proxy-nokeepalive 1 +</Location>+ + +
A partir de la version 2.4.26 du serveur HTTP Apache, la définition de
+ la variable d'environnement "no-proxy" permet de désactiver
+ mod_proxy dans le traitement de la requête courante.
+ Cette variable doit être définie via la directive SetEnvIf car la directive SetEnv n'est pas évaluée assez tôt.
Certaines méthodes de requêtes comme POST comportent un corps de
+ requête. Le protocole HTTP stipule que les requêtes qui comportent
+ un corps doivent soit utiliser un codage de transmission
+ fractionnée (chunked transfer encoding), soit envoyer un en-tête de requête
+ Content-Length. Lorsqu'il fait suivre ce genre de
+ requête vers le serveur demandé, mod_proxy_http
+ s'efforce toujours d'envoyer l'en-tête Content-Length.
+ Par contre, si la taille du corps est importante, et si la requête
+ originale utilise un codage à fractionnement, ce dernier peut aussi
+ être utilisé dans la requête montante. Ce comportement peut être
+ contrôlé à l'aide de variables
+ d'environnement. Ainsi, si elle est définie, la variable
+ proxy-sendcl assure une compatibilité maximale avec les
+ serveurs demandés en imposant l'envoi de l'en-tête
+ Content-Length, alors que
+ proxy-sendchunked diminue la consommation de ressources
+ en imposant l'utilisation d'un codage à fractionnement.
Dans certaines circonstances, le serveur doit mettre en file + d'attente sur disque les corps de requêtes afin de satisfaire le + traitement demandé des corps de requêtes. Par exemple, cette mise en + file d'attente se produira si le corps original a été envoyé selon un + codage morcelé (et possède une taille importante), alors que + l'administrateur a demandé que les requêtes du serveur + d'arrière-plan soient envoyées avec l'en-tête Content-Length ou en + HTTP/1.0. Cette mise en file d'attente se produira aussi si le corps + de la requête contient déjà un en-tête Content-Length, alors que le + serveur est configuré pour filtrer les corps des requêtes entrantes.
+ +La directive LimitRequestBody ne s'applique qu'aux
+ corps de requêtes que le serveur met en file d'attente sur disque.
Lorsqu'il est configuré en mode mandataire inverse (en utilisant
+ par exemple la directive ProxyPass),
+ mod_proxy_http ajoute plusieurs en-têtes de requête
+ afin de transmettre des informations au serveur demandé. Ces
+ en-têtes sont les suivants :
X-Forwarded-ForX-Forwarded-HostHost.X-Forwarded-ServerCes en-têtes doivent être utilisés avec précautions sur le
+ serveur demandé, car ils contiendront plus d'une valeur (séparées
+ par des virgules) si la requête originale contenait déjà un de ces
+ en-têtes. Par exemple, vous pouvez utiliser
+ %{X-Forwarded-For}i dans la chaîne de format du journal
+ du serveur demandé pour enregistrer les adresses IP des clients
+ originaux, mais il est possible que vous obteniez plusieurs adresses
+ si la requête passe à travers plusieurs mandataires.
Voir aussi les directives ProxyPreserveHost et ProxyVia directives, qui permettent
+ de contrôler d'autres en-têtes de requête.
Note : Si vous devez ajouter des en-têtes particuliers à la
+ requête mandatée, utilisez la directive RequestHeader.
| Description: | Nombre de membres supplémentaires pouvant être ajoutés +après la configuration initiale |
|---|---|
| Syntaxe: | BalancerGrowth # |
| Défaut: | BalancerGrowth 5 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | BalancerGrowth est disponible depuis la version 2.3.13 du +serveur HTTP Apache |
Cette directive permet de définir le nombre de membres pouvant + être ajoutés au groupe de répartition de charge préconfiguré d'un + serveur virtuel. Elle n'est active que si le groupe a été + préconfiguré avec un membre au minimum.
+ +| Description: | Héritage des membres du groupes de répartition de + charge du mandataire définis au niveau du serveur principal |
|---|---|
| Syntaxe: | BalancerInherit On|Off |
| Défaut: | BalancerInherit On |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur + HTTP Apache. |
Cette directive permet d'attribuer au serveur virtuel courant + l'héritage des membres de groupes de répartition de charge + définis au niveau du serveur + principal. Elle ne doit pas être activée si vous + utilisez la fonctionnalité de modifications dynamiques du + gestionnaire de répartition de charge (Balancer Manager) pour + éviter des problèmes et des comportements inattendus.
+Les définitions au niveau du serveur principal constituent + les définitions par défaut au niveau des serveurs virtuels.
+ + +| Description: | Ajoute un membre à un groupe de répartition de +charge |
|---|---|
| Syntaxe: | BalancerMember [balancerurl] url [clé=valeur [clé=valeur ...]] |
| Contexte: | répertoire |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | Disponible depuis la version 2.2 du serveur HTTP Apache. |
Cette directive permet d'ajouter un membre à un groupe de
+ répartition de charge. Elle peut se trouver dans un conteneur
+ <Proxy balancer://...>, et accepte
+ tous les paramètres de paires clé/valeur que supporte la directive
+ ProxyPass.
La directive BalancerMember accepte un paramètre
+ supplémentaire : loadfactor. Il s'agit du facteur de
+ charge du membre - un nombre décimal entre 1.0 (valeur par défaut) et 100.0, qui
+ définit la charge à appliquer au membre en question.
L'argument balancerurl n'est requis que s'il ne se trouve pas
+ dèjà dans la directive de conteneur <Proxy
+ balancer://...>. Il correspond à l'URL d'un
+ répartiteur de charge défini par une directive ProxyPass.
La partie chemin de l'URL du répartiteur dans toute directive de
+ conteneur <Proxy balancer://...> est
+ ignorée.
En particulier, le slash de fin de l'URL d'un
+ BalancerMember doit être supprimé.
| Description: | Tente de conserver les changements effectués par le + gestionnaire de répartition de charge après un redémarrage du + serveur. |
|---|---|
| Syntaxe: | BalancerPersist On|Off |
| Défaut: | BalancerPersist Off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | BalancerPersist n'est disponible qu'à partir de la + version 2.4.4 du serveur HTTP Apache. |
Cette directive permet de conserver le contenu de l'espace + mémoire partagé associé aux répartiteurs de charge et à leurs + membres après un redémarrage du serveur. Ces modifications + locales ne sont ainsi pas perdues lors des transitions d'état + dues à un redémarrage.
+ +| Description: | Serveurs, domaines ou réseaux auquels on se connectera +directement |
|---|---|
| Syntaxe: | NoProxy domaine [domaine] ... |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
Cette directive n'a d'utilité que pour les serveurs mandataires
+ Apache httpd au sein d'Intranets. La directive
+ NoProxy permet de spécifier une liste de
+ sous-réseaux, d'adresses IP, de serveurs et/ou de domaines séparés
+ par des espaces. Une requête pour un serveur qui correspond à un ou
+ plusieurs critères sera toujours servie par ce serveur directement,
+ sans être redirigée vers le(s) serveur(s) mandataire(s) défini(s) par
+ la directive ProxyRemote.
ProxyRemote "*" "http://firewall.example.com:81" +NoProxy ".example.com" "192.168.112.0/21"+
Le type des arguments serveur de la directive
+ NoProxy appartiennent à la liste suivante
+ :
Un domaine est ici un nom de domaine DNS partiellement + qualifié précédé d'un point. Il représente une liste de serveurs qui + appartiennent logiquement au même domaine ou à la même zonz DNS + (en d'autres termes, les nom des serveurs se terminent tous par + domaine).
+ +
+ .com .example.org.
+
Pour faire la distinction entre domaines et nom d'hôtes (des points de vue à la fois + syntaxique et + sémantique, un domaine DNS pouvant aussi avoir un enregistrement DNS + de type A !), les domaines sont toujours spécifiés en les + préfixant par un point.
+ +Les comparaisons de noms de domaines s'effectuent sans tenir
+ compte de la casse, et les parties droites des Domaines
+ sont toujours censées correspondre à la racine de l'arborescence
+ DNS, si bien que les domaines .ExEmple.com et
+ .example.com. (notez le point à la fin du nom) sont
+ considérés comme identiques. Comme une comparaison de domaines ne
+ nécessite pas de recherche DNS, elle est beaucoup plus efficace
+ qu'une comparaison de sous-réseaux.
Un Sous-réseau est une adresse internet partiellement + qualifiée sous forme numérique (quatre nombres séparés par des + points), optionnellement suivie d'un slash et du masque de + sous-réseau spécifiant le nombre de bits significatifs dans le + Sous-réseau. Il représente un sous-réseau de serveurs qui + peuvent être atteints depuis la même interface réseau. En l'absence + de masque de sous-réseau explicite, il est sous-entendu que les + digits manquants (ou caractères 0) de fin spécifient le masque de + sous-réseau (Dans ce cas, le masque de sous-réseau ne peut être + qu'un multiple de 8). Voici quelques exemples :
+ +192.168 ou 192.168.0.0255.255.0.0)192.168.112.0/21192.168.112.0/21 avec un masque de
+ sous-réseau implicite de 21 bits significatifs (parfois exprimé
+ sous la forme255.255.248.0)Comme cas extrêmes, un Sous-réseau avec un masque de + sous-réseau de 32 bits significatifs est équivalent à une adresse IP, alors qu'un Sous-réseau avec un masque de + sous-réseau de 0 bit significatif (c'est à dire 0.0.0.0/0) est + identique à la constante _Default_, et peut correspondre + à toute adresse IP.
Une Adresse IP est une adresse internet pleinement + qualifiée sous forme numérique (quatre nombres séparés par des + points). En général, cette adresse représente un serveur, mais elle + ne doit pas nécessairement correspondre à un nom de domaine DNS.
+
+ 192.168.123.7
+
Une Adresse IP ne nécessite pas de résolution DNS, + et peut ainsi s'avérer plus efficace quant aux performances + d'Apache.
+Un Nom de serveur est un nom de domaine DNS pleinement + qualifié qui peut être résolu en une ou plusieurs adresses IP par le + service de noms de domaines DNS. Il représente un hôte logique (par + opposition aux Domaines, voir + ci-dessus), et doit pouvoir être résolu en une ou plusieurs adresses IP (ou souvent en une liste + d'hôtes avec différentes adresses + IP).
+ +
+ prep.ai.example.edu
+ www.example.org
+
Dans de nombreuses situations, il est plus efficace de + spécifier une adresse IP qu'un + Nom de serveur car cela évite d'avoir à effectuer une + recherche DNS. La résolution de nom dans Apache httpd peut prendre un + temps très long lorsque la connexion avec le serveur de noms + utilise une liaison PPP lente.
+Les comparaisons de Nom de serveur s'effectuent sans tenir
+ compte de la casse, et les parties droites des Noms de serveur
+ sont toujours censées correspondre à la racine de l'arborescence
+ DNS, si bien que les domaines WWW.ExEmple.com et
+ www.example.com. (notez le point à la fin du nom) sont
+ considérés comme identiques.
| Description: | Conteneur de directives s'appliquant à des ressources +mandatées |
|---|---|
| Syntaxe: | <Proxy url-avec-jokers> ...</Proxy> |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
Les directives situées dans une section <Proxy> ne s'appliquent qu'au contenu
+ mandaté concerné. Les jokers de style shell sont autorisés.
Par exemple, les lignes suivantes n'autoriseront à accéder à un
+ contenu via votre serveur mandataire que les hôtes appartenant à
+ votre-reseau.example.com :
<Proxy "*"> + Require host votre-reseau.example.com +</Proxy>+ + +
Dans l'exemple suivant, tous les fichiers du répertoire
+ foo de example.com seront traités par le
+ filtre INCLUDES lorsqu'ils seront envoyés par
+ l'intermédiaire du serveur mandataire :
<Proxy "http://example.com/foo/*"> + SetOutputFilter INCLUDES +</Proxy>+ + +
Une URL d'arrière-plan sera concernée par le conteneur Proxy si
+ elle commence par la url-avec-jokers, même si le
+ dernier segment de chemin de la directive ne correspond qu'à un
+ préfixe de segment dee chemin de l'URL d'arrière-plan. Par exemple, <Proxy
+ "http://example.com/foo"> correspondra entre autres aux URLs
+ http://example.com/foo, http://example.com/foo/bar, et
+ http://example.com/foobar. La correspondance de l'URL finale
+ diffère du comportement de la section <Location> qui, pour le cas de cette note,
+ traitera le segment de chemin final comme s'il se terminait par un
+ slash.
Pour un contrôle plus fin de la correspondance des URL, voir la
+ directive <ProxyMatch>.
<ProxyMatch>| Description: | Ajoute des informations à propos du mandataire aux +en-têtes X-Forwarded-* |
|---|---|
| Syntaxe: | ProxyAddHeaders Off|On |
| Défaut: | ProxyAddHeaders On |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | Disponible depuis la version 2.3.10 |
Cette directive permet de passer au serveur d'arrière-plan des + informations à propos du mandataire via les en-têtes HTTP + X-Forwarded-For, X-Forwarded-Host et X-Forwarded-Server.
+Cette option n'est utile que dans le cas du mandat HTTP traité
+ par mod_proxy_http.
| Description: | Détermine la manière de traiter les lignes d'en-tête +incorrectes d'une réponse |
|---|---|
| Syntaxe: | ProxyBadHeader IsError|Ignore|StartBody |
| Défaut: | ProxyBadHeader IsError |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
La directive ProxyBadHeader permet de
+ déterminer le comportement de mod_proxy lorsqu'il
+ reçoit des lignes d'en-tête de réponse dont la syntaxe n'est pas valide (c'est
+ à dire ne contenant pas de caractère ':') en provenance du serveur
+ original. Les arguments disponibles sont :
IsErrorIgnoreStartBody| Description: | Termes, serveurs ou domaines bloqués par le +mandataire |
|---|---|
| Syntaxe: | ProxyBlock *|terme|serveur|domaine
+[terme|serveur|domaine] ... |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
La directive ProxyBlock permet de
+ spécifier une liste de termes, serveurs et/ou domaines, séparés par
+ des espaces. Les requêtes de documents HTTP, HTTPS, FTP vers des
+ sites dont les noms contiennent des termes, noms de serveur ou
+ domaine correspondants seront bloqués par le serveur
+ mandataire. La module proxy va aussi tenter de déterminer les
+ adresses IP des éléments de la liste qui peuvent correspondre à des
+ noms d'hôtes au cours du démarrage, et les mettra en cache à des
+ fins de comparaisons ultérieures. Ceci peut ralentir le démarrage du
+ serveur.
ProxyBlock "news.example.com" "auctions.example.com" "friends.example.com"+
Notez qu'example suffirait aussi pour atteindre
+ ces sites.
Hosts conviendrait aussi s'il était référencé par adresse IP.
+ +Notez aussi que
+ +ProxyBlock "*"+ + +
bloque les connexions vers tous les sites.
+ +| Description: | Nom de domaine par défaut pour les requêtes +mandatées |
|---|---|
| Syntaxe: | ProxyDomain Domaine |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
Cette directive n'a d'utilité que pour les serveurs mandataires
+ Apache httpd au sein d'un Intranet. La directive
+ ProxyDomain permet de spécifier le domaine
+ par défaut auquel le serveur mandataire apache appartient. Si le
+ serveur reçoit une requête pour un hôte sans nom de domaine, il va
+ générer une réponse de redirection vers le même hôte suffixé par le
+ Domaine spécifié.
ProxyRemote "*" "http://firewall.example.com:81" +NoProxy ".example.com" "192.168.112.0/21" +ProxyDomain ".example.com"+
| Description: | Outrepasser les pages d'erreur pour les contenus +mandatés |
|---|---|
| Syntaxe: | ProxyErrorOverride On|Off |
| Défaut: | ProxyErrorOverride Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy |
Cette directive est utile pour les configurations de mandataires
+ inverses, lorsque vous souhaitez que les pages d'erreur envoyées
+ aux utilisateurs finaux présentent un aspect homogène. Elle permet
+ aussi l'inclusion de fichiers (via les SSI de
+ mod_include) pour obtenir le code d'erreur et agir
+ en conséquence (le comportement par défaut afficherait la page
+ d'erreur du serveur mandaté, alors que c'est le message d'erreur SSI
+ qui sera affiché si cette directive est à "on").
Cette directive n'affecte pas le traitement des réponses + informatives (1xx), de type succès normal (2xx), ou de redirection + (3xx).
+ +| Description: | Détermine la taille du tampon interne de transfert de +données |
|---|---|
| Syntaxe: | ProxyIOBufferSize octets |
| Défaut: | ProxyIOBufferSize 8192 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
La directive ProxyIOBufferSize permet
+ d'ajuster la taille du tampon interne utilisé comme bloc-note pour
+ les transferts de données entre entrée et sortie. La taille minimale
+ est de 512 octets.
Dans la plupart des cas, il n'y a aucune raison de modifier cette + valeur.
+ +Si elle est utilisée avec AJP, cette directive permet de définir
+ la taille maximale du paquet AJP en octets. Si la valeur spécifiée
+ est supérieure à 65536, elle est corrigée et prend la valeur 65536.
+ Si vous ne conservez pas
+ la valeur par défaut, vous devez aussi modifier l'attribut
+ packetSize de votre connecteur AJP du côté de Tomcat !
+ L'attribut packetSize n'est disponible que dans Tomcat
+ 5.5.20+ et 6.0.2+.
Il n'est normalement pas nécessaire de modifier la taille + maximale du paquet. Des problèmes ont cependant été rapportés avec + la valeur par défaut lors de l'envoi de certificats ou de chaînes de + certificats.
+ + +| Description: | Conteneur de directives s'appliquant à des ressources +mandatées correspondant à une expression rationnelle |
|---|---|
| Syntaxe: | <ProxyMatch regex> ...</ProxyMatch> |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
La directive <ProxyMatch> est
+ identique à la directive <Proxy>, à l'exception qu'elle définit
+ les URLs auxquelles elle s'applique en utilisant une expression rationnelle.
A partir de la version 2.4.8, les groupes nommés et les
+ références arrières sont extraits et enregistrés dans
+ l'environnement avec leur nom en majuscules et préfixé par "MATCH_". Ceci permet
+ de référencer des URLs dans des expressions
+ ou au sein de modules comme mod_rewrite. Pour
+ éviter toute confusion, les références arrières numérotées (non
+ nommées) sont ignorées. Vous devez utiliser à la place des groupes
+ nommés.
<ProxyMatch "^http://(?<sitename>[^/]+)">
+ Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
+</ProxyMatch>
+
+
+<Proxy>| Description: | Nombre maximum de mandataires à travers lesquelles une +requête peut être redirigée |
|---|---|
| Syntaxe: | ProxyMaxForwards nombre |
| Défaut: | ProxyMaxForwards -1 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | Comportement par défaut +modifié dans 2.2.7 |
La directive ProxyMaxForwards permet de
+ spécifier le nombre maximum de mandataires à travers lesquels une
+ requête peut passer dans le cas où la la requête ne contient pas
+ d'en-tête Max-Forwards. Ceci permet de se prémunir
+ contre les boucles infinies de mandataires ou contre les attaques de
+ type déni de service.
ProxyMaxForwards 15+
Notez que la définition de la directive
+ ProxyMaxForwards constitue une violation du
+ protocole HTTP/1.1 (RFC2616), qui interdit à un mandataire de
+ définir Max-Forwards si le client ne l'a pas fait
+ lui-même. Les versions précédentes d'Apache httpd la définissaient
+ systématiquement. Une valeur négative de
+ ProxyMaxForwards, y compris la valeur par
+ défaut -1, implique un comportement compatible avec le protocole,
+ mais vous expose aux bouclages infinis.
| Description: | Référencer des serveurs distants depuis +l'espace d'URLs du serveur local |
|---|---|
| Syntaxe: | ProxyPass [chemin] !|url [clé=valeur
+ [clé=valeur ...]] [nocanon] [interpolate] [noquery] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | Les sockets de style Unix (Unix Domain Socket - UDS) +sont supportés à partir de la version 2.4.7 du serveur HTTP Apache |
Cette directive permet de référencer des serveurs distants depuis + l'espace d'URLs du serveur local. Le serveur + local n'agit pas en tant que mandataire au sens conventionnel, mais + plutôt comme miroir du serveur distant. Le serveur local est + souvent nommé mandataire inverse ou + passerelle. L'argument chemin est le nom d'un + chemin virtuel local ; url est une URL partielle pour le + serveur distant et ne doit pas contenir de chaîne d'arguments.
+ +<Directory>
+ et <Files>.ProxyRequests doit être définie à
+ off lorsqu'on utilise la directive
+ ProxyPass.Les sockets de style Unix sont supportés à partir de la version
+ 2.4.7 du serveur HTTP Apache ; pour utiliser cette fonctionnalité,
+ il suffit d'utiliser une URL cible préfixée par
+ unix:/path/lis.sock|. Par exemple, pour mandater HTTP
+ et cibler l'UDS /home/www/socket, vous devez utiliser
+ unix:/home/www.socket|http://localhost/whatever/.
unix: tient compte de la directive
+ DefaultRuntimeDir.Lorsque cette directive est utilisée dans une section <Location>, le premier
+ argument est omis et le répertoire local est obtenu à partir de
+ l'argument de la directive <Location>. Il en est de même à l'intérieur
+ d'une section <LocationMatch>, mais le résultat ne sera
+ probablement pas celui attendu car ProxyPassReverse va interpréter
+ l'expression rationnelle littéralement comme un chemin ; si besoin
+ est dans ce cas, définissez la directive ProxyPassReverse en dehors
+ de la section, ou dans une section <Location> séparée.
Supposons que le serveur local a pour adresse
+ http://example.com/ ; alors la ligne
<Location "/mirror/foo/"> + ProxyPass "http://backend.example.com/" +</Location>+ + +
va convertir en interne toute requête pour
+ http://example.com/mirror/foo/bar en une requête
+ mandatée pour http://backend.example.com/bar.
Si vous avez besoin d'un configuration de mandataire inverse plus
+ souple, reportez-vous à la documentaion de la directive RewriteRule et son drapeau
+ [P].
La syntaxe alternative suivante est valide, bien qu'elle puisse + induire une dégradation des performances lorsqu'elle est + présente en très grand nombre. Elle possède l'avantage de + permettre un contrôle dynamique via l'interface Balancer Manager :
+ +ProxyPass "/mirror/foo/" "http://backend.example.com/"+ + +
Si le premier argument se termine par un slash + /, il doit en être de même pour le second argument + et vice versa. Dans le cas contraire, il risque de manquer des + slashes nécessaires dans la requête résultante vers le serveur + d'arrière-plan et les résulats ne seront pas ceux attendus. +
+Le drapeau ! permet de soustraire un sous-répertoire
+ du mandat inverse, comme dans l'exemple suivant :
<Location "/mirror/foo/"> + ProxyPass "http://backend.example.com/" +</Location> +<Location "/mirror/foo/i"> + ProxyPass "!" +</Location>+ + +
ProxyPass "/mirror/foo/i" "!" +ProxyPass "/mirror/foo" "http://backend.example.com"+ + +
va mandater toutes les requêtes pour /mirror/foo
+ vers backend.example.com, sauf les requêtes
+ pour /mirror/foo/i.
Mélanger plusieurs configurations ProxyPass dans différents contextes ne + fonctionne pas :
+ProxyPass "/mirror/foo/i" "!" +<Location "/mirror/foo/"> + ProxyPass "http://backend.example.com/" +</Location>+ +
Dans ce cas, une requête pour /mirror/foo/i sera tout de
+ même mandatée car c'est la directive ProxyPass de la
+ section Location qui sera évaluée en premier. Le fait que la directive
+ ProxyPass supporte les deux contextes serveur
+ principal et répertoire ne signifie pas que sa portée et sa position dans le
+ fichier de configuration va garantir une quelconque priorité et/ou
+ chronologie de prise en compte.
Les directives ProxyPass et ProxyPassMatch sont évaluées dans
+ l'ordre de leur apparition dans le fichier de configuration. La
+ première règle qui correspond s'applique. Vous devez donc en
+ général classer les règles ProxyPass qui entrent en conflit de
+ l'URL la plus longue à la plus courte. Dans le cas contraire, les
+ règles situées après une règle dont l'URL correspond au début de
+ leur propre URL seront ignorées. Notez que tout ceci est en
+ relation avec le partage de workers.
On ne peut placer
+ qu'une seule directive ProxyPass dans une section
+ Location, et c'est la section
+ la plus spécifique qui l'emportera.
Les exclusions doivent se situer avant
+ les directives ProxyPass générales. A partir de la
+ version 2.4.26 du serveur HTTP Apache, la variable
+ d'environnement "no-proxy" est une alternative aux exclusions et constitue
+ le seul moyen de configurer une exclusion pour une directive
+ ProxyPass dans le contexte d'une section Location. Cette variable doit être définie via
+ la directive SetEnvIf car la
+ directive SetEnv n'est pas évaluée
+ assez tôt.
ProxyPass clé=valeur Paramètres
Depuis la version 2.1 du serveur HTTP Apache, mod_proxy supporte
+ les groupements de connexions vers un serveur d'arrière-plan. Les
+ connexions créées à la demande peuvent être enregistrées dans un
+ groupement pour une utilisation ultérieure. La taille du groupe
+ ainsi que d'autres caractéristiques peuvent être définies via la
+ directive ProxyPass au moyen de paramètres
+ clé=valeur dont la description fait l'objet des
+ tableaux ci-dessous.
Par défaut, mod_proxy permet et met en réserve le
+ nombre maximum de connexions pouvant être utilisées simultanément par le
+ processus enfant concerné du serveur web. Le paramètre max
+ permet de réduire cette valeur par défaut. Le jeu de connexions est maintenu
+ au niveau de chaque processus enfant du serveur web, max et les
+ autres réglages n'étant pas coordonnés entre ces différents processus, sauf
+ bien entendu lorsqu'un seul processus enfant n'est autorisé par la
+ configuration ou le MPM utilisé.
Le paramètre ttl,
+ quant à lui, permet de définir une durée de vie optionnelle ; les
+ connexions qui n'ont pas été utilisées pendant au moins
+ ttl secondes seront fermées. ttl permet
+ aussi d'empêcher l'utilisation d'une connexion susceptible d'être
+ fermée suite à une fin de vie de connexion persistante sur le
+ serveur d'arrière-plan.
ProxyPass "/example" "http://backend.example.com" max=20 ttl=120 retry=300+
| Paramètres de worker (directive BalancerMember) |
|---|
| Paramètre | +Défaut | +Description | |||||||
|---|---|---|---|---|---|---|---|---|---|
| min | +0 | +Nombre minimum d'entrées dans le pool de connexions, + distinct du nombre de connexions effectif. La valeur par défaut + ne doit être modifiée que dans des circonstances particulières + où la mémoire associée aux connexions avec le serveur + d'arrière-plan doit être préallouée ou réservée dans le tas. | |||||||
| max | +1...n | +Nombre maximum de connexions autorisées vers le serveur
+ d'arrière-plan. La valeur par défaut correspond au nombre de
+ threads par processus pour le MPM (Module Multi Processus)
+ actif. La valeur sera toujours 1 pour le MPM Prefork, alors
+ qu'elle dépendra de la définition de la directive
+ ThreadsPerChild pour les autres MPMs. | |||||||
| smax | +max | +Les entrées du pool de connexions conservées au delà de
+ cette limite sont libérées au cours de certaines opérations si
+ elles n'ont pas été utilisées au cours de leur durée de vie,
+ définie par le paramètre ttl. Si l'entrée du pool
+ de connexions est associée à une connexion, cette dernière sera
+ fermée. La valeur par défaut ne doit être modifiée que dans des
+ circonstances particulières où les entrées du pool de connexions
+ et toutes connexions associées qui ont dépassé leur durée de vie
+ doivent être libérées ou fermées de manière plus autoritaire. | |||||||
| acquire | +- | +Cette clé permet de définir le délai maximum d'attente pour
+ une connexion libre dans le jeu de connexions, en millisecondes.
+ S'il n'y a pas de connexion libre dans le jeu, Apache httpd renverra
+ l'état SERVER_BUSY au client.
+ | |||||||
| connectiontimeout | +timeout | +Délai d'attente d'une connexion en secondes. + La durée en secondes pendant laquelle Apache httpd va attendre pour + l'établissement d'une connexion vers le serveur d'arrière-plan. + Le délai peut être spécifié en millisecondes en ajoutant le + suffixe ms. + | |||||||
| disablereuse | +Off | +Vous pouvez utiliser cette clé pour forcer mod_proxy à
+ fermer immédiatement une connexion vers le serveur
+ d'arrière-plan après utilisation, et ainsi désactiver le jeu de
+ connexions permanentes vers ce serveur. Ceci peut s'avérer utile
+ dans des situations où un pare-feu situé entre Apache httpd et le
+ serveur d'arrière-plan (quelque soit le protocole) interrompt
+ des connexions de manière silencieuse, ou lorsque le serveur
+ d'arrière-plan lui-même est accessible par rotation de DNS
+ (round-robin DNS). Lorsque la réutilisation des connexions est activée,
+ chaque domaine d'arrière-plan n'est résolu (via une requête DNS) qu'une
+ seule fois par chaque processus enfant et mis en cache pour toutes les
+ connexions ultérieures jusqu'au recyclage du processus concerné.
+ Pour désactiver la réutilisation du jeu de
+ connexions, définissez cette clé à On.
+ | |||||||
| enablereuse | +On | +Ce paramètre est utilisé par les gestionnaires de protocole pour
+ lesquels la réutilisation des connexions est optionnelle (comme
+ mod_proxy_fcgi). C'est le contraire du
+ paramètre 'disablereuse' ci-dessus, et il est supporté par les
+ versions 2.4.11 et supérieures du serveur HTTP Apache.
+ | |||||||
| flushpackets | +off | +Permet de définir si le module mandataire doit vider + automatiquement le tampon de sortie après chaque tronçon de + données. 'off' signifie que le tampon sera vidé si + nécessaire ; + 'on' signifie que le tampon sera vidé après chaque envoi d'un + tronçon de données, et 'auto' que le tampon sera vidé après un + délai de 'flushwait' millisecondes si aucune entrée n'est reçue. + Actuellement, cette clé n'est supportée que par mod_proxy_ajp et + mod_proxy_fcgi. + | |||||||
| flushwait | +10 | +Le délai d'attente pour une entrée additionnelle, en + millisecondes, avant le vidage du tampon en sortie dans le cas + où 'flushpackets' est à 'auto'. + | |||||||
| iobuffersize | +8192 | +Permet de définir la taille du tampon d'entrées/sorties du
+ bloc-notes interne. Cette clé vous permet d'outrepasser la
+ directive ProxyIOBufferSize pour un
+ serveur cible spécifique. La valeur doit être au minimum 512 ou définie
+ à 0 pour la valeur par défaut du système de 8192.
+ | |||||||
| responsefieldsize | +8192 | +Contrôle la taille du tampon pour le champ de la réponse mandatée.
+ Cette taille doit être au moins égale à la taille attendue du plus grand
+ en-tête d'une réponse mandatée. Une valeur de 0 implique l'utilisation
+ de la valeur par défaut du système, à savoir 8192 octets. + Disponible à partir de la version 2.4.34 du serveur HTTP Apache. + | |||||||
| keepalive | +Off | +Cette clé doit être utilisée lorsque vous avez un pare-feu
+ entre Apache httpd et le serveur d'arrière-plan, et si ce dernier tend
+ à interrompre les connexions inactives. Cette clé va faire en
+ sorte que le système d'exploitation envoie des messages
+ La fréquence de vérification des connexions TCP persistantes + initiale et subséquentes dépend de la configuration globale de l'OS, + et peut atteindre 2 heures. Pour être utile, la fréquence configurée + dans l'OS doit être inférieure au seuil utilisé par le pare-feu. + + | |||||||
| lbset | +0 | +Définit le groupe de répartition de charge dont le serveur cible + est membre. Le répartiteur de charge va essayer tous les membres + d'un groupe de répartition de charge de numéro inférieur avant + d'essayer ceux dont le groupe possède un numéro supérieur. + | |||||||
| ping | +0 | +Avec la clé Ping, le serveur web va "tester" la connexion
+ vers le serveur d'arrière-plan avant de transmettre la requête.
+ Avec AJP, mod_proxy_ajp envoie une requête
+ CPING sur la connexion ajp13 (implémenté sur Tomcat
+ 3.3.2+, 4.1.28+ et 5.0.13+). Avec HTTP,
+ mod_proxy_http envoie 100-Continue
+ au serveur d'arrière-plan (seulement avecHTTP/1.1 - pour les
+ serveurs d'arrière-plan non HTTP/1.1, cette clé ne produit
+ aucun effet). Dans les deux cas, ce paramètre correspond au
+ délai en secondes pour l'attente de la réponse. Cette
+ fonctionnalité a été ajoutée pour éviter les problèmes avec les
+ serveurs d'arrière-plan bloqués ou surchargés.
+
+ Le trafic
+ réseau peut s'en trouver augmenté en fonctionnement normal, ce
+ qui peut poser problème, mais peut s'en trouver diminué dans les
+ cas où les noeuds de cluster sont arrêtés ou
+ surchargés. Le délai peut
+ aussi être défini en millisecondes en ajoutant le suffixe
+ ms.
+ | |||||||
| receivebuffersize | +0 | +Définit la taille du tampon réseau explicite (TCP/IP) pour
+ les connexions mandatées. Cette clé vous permet d'outrepasser la
+ directive ProxyReceiveBufferSize pour un
+ serveur cible spécifique. Sa valeur doit être au minimum 512 ou définie
+ à 0 pour la valeur par défaut du système.
+ | |||||||
| redirect | +- | +Route pour la redirection du serveur cible. Cette valeur est en + général définie dynamiquement pour permettre une suppression + sécurisée du noeud du cluster. Si cette clé est définie, toutes + les requêtes sans identifiant de session seront redirigées vers + le membre de groupe de répartition de charge dont la route + correspond à la valeur de la clé. + | |||||||
| retry | +60 | +Délai entre deux essais du serveur cible du jeu de connexions en + secondes. Si le serveur cible du jeu de connexions vers le serveur + d'arrière-plan est dans un état d'erreur, Apache httpd ne redirigera + pas de requête vers ce serveur avant l'expiration du délai + spécifié. Ceci permet d'arrêter le serveur d'arrière-plan pour + maintenance, et de le remettre en ligne plus tard. Une valeur de + 0 implique de toujours essayer les serveurs cibles dans un état d'erreur + sans délai. + | |||||||
| route | +- | +La route du serveur cible lorsqu'il est utilisé au sein d'un + répartiteur de charge. La route est une valeur ajoutée à + l'identifiant de session. + | |||||||
| status | +- | +Valeur constituée d'une simple lettre et définissant l'état
+ initial de ce serveur cible.
+
| |||||||
| timeout | +ProxyTimeout |
+ Délai d'attente de la connexion en secondes. Le nombre de + secondes pendant lesquelles Apache httpd attend l'envoi de + données vers le serveur d'arrière-plan. + | |||||||
| ttl | +- | +Durée de vie des connexions inactives et des entrées du pool + de connexions associées en secondes. Une fois cette + limite atteinte, une connexion ne sera pas réutilisée ; elle + sera fermée après un délai variable. + | |||||||
| flusher | +flush | +Nom du fournisseur utilisé par | |||||||
| secret | +- | +Le mot de passe utilisé par | |||||||
| upgrade | +WebSocket | +Le protocol accepté par |
Si l'URL de la directive Proxy débute par
+ balancer:// (par exemple:
+ balancer://cluster, toute information relative au
+ chemin est ignorée), alors un serveur cible virtuel ne communiquant pas
+ réellement avec le serveur d'arrière-plan sera créé. Celui-ci sera
+ en fait responsable de la gestion de plusieurs serveurs cibles "réels". Dans
+ ce cas, un jeu de paramètres particuliers s'applique à ce serveur cible
+ virtuel. Voir mod_proxy_balancer pour plus
+ d'informations à propos du fonctionnement du répartiteur de
+ charge.
+
| Paramètres du répartiteur |
|---|
| Paramètre | +Défaut | +Description |
|---|---|---|
| lbmethod | +byrequests | +Méthode de répartition de charge utilisée. Permet de
+ sélectionner la méthode de planification de la répartition de
+ charge à utiliser. La valeur est soit byrequests,
+ pour effectuer un décompte de requêtes pondérées, soit
+ bytraffic, pour effectuer une répartition en
+ fonction du décompte des octets transmis, soit
+ bybusyness, pour effectuer une répartition en
+ fonction des requêtes en attente. La valeur par défaut est
+ byrequests.
+ |
| maxattempts | +1 de moins que le nombre de workers, ou 1 avec un seul + worker | +Nombre maximum d'échecs avant abandon. + |
| nofailover | +Off | +Si ce paramètre est défini à On, la session va
+ s'interrompre si le serveur cible est dans un état d'erreur ou
+ désactivé. Définissez ce paramètre à On si le serveur
+ d'arrière-plan ne supporte pas la réplication de session.
+ |
| stickysession | +- | +Nom de session persistant du répartiteur. La valeur est
+ généralement du style JSESSIONID ou
+ PHPSESSIONID, et dépend du serveur d'application
+ d'arrière-plan qui supporte les sessions. Si le serveur
+ d'application d'arrière-plan utilise un nom différent pour
+ les cookies et les identifiants codés d'URL (comme les
+ conteneurs de servlet), séparez-les par le caractère '|'. La
+ première partie contient le cookie et la seconde le chemin.+ Disponible depuis la version 2.4.4 du serveur HTTP Apache. + |
| stickysessionsep | +"." | +Définit le caractère de séparation dans le cookie de + session. Certains serveurs d'application d'arrière-plan + n'utilisent pas le caractère '.' comme séparateur. Par exemple + le serveur Oracle Weblogic utilise le caractère '!'. Cette + option permet d'attribuer au caractère de séparation la valeur + appropriée. Si elle est définie à 'Off', aucun caractère de + séparation n'est utilisé. + |
| scolonpathdelim | +Off | +Si ce paramètre est défini à On, le caractère
+ ';' sera utilisé comme séparateur de chemin de session
+ persistante additionnel. Ceci permet principalement de simuler
+ le comportement de mod_jk lorsqu'on utilise des chemins du style
+ JSESSIONID=6736bcf34;foo=aabfa.
+ |
| timeout | +0 | +Délai du répartiteur en secondes. Si ce paramètre est + défini, sa valeur correspond à la durée maximale d'attente pour + un serveur cible libre. Le comportement par défaut est de ne pas + attendre. + |
| failonstatus | +- | +Une liste de codes d'état HTTP séparés par des virgules. Si + ce paramètre est présent, le worker se mettra en erreur si le + serveur d'arrière-plan renvoie un des codes d'état spécifiés + dans la liste. La récupération du worker s'effectue comme dans + le cas des autres erreurs de worker. + |
| failontimeout | +Off | +Si ce paramètre est défini à "On", un délai d'attente
+ dépassé en entrée/sortie après envoi d'une requête au serveur
+ d'arrière-plan va mettre le processus en état d'erreur. La
+ sortie de cet état d'erreur se passe de la même façon que pour
+ les autres erreurs. + Disponible à partir de la version 2.4.5 du serveur HTTP Apache. + |
| nonce | +<auto> | +Le nombre à usage unique de protection utilisé dans la page
+ de l'application balancer-manager. Par défaut, la
+ protection de la page est assurée par un nombre à usage unique
+ automatique à base d'UUID. Si une valeur est précisée, elle sera
+ utilisée comme nombre à usage unique. La valeur
+ None désactive la vérification du nombre à usage
+ unique.
+ Note+En plus du nombre à usage unique, la page de l'application
+ |
| growth | +0 | +Nombre de membres supplémentaires que l'on peut ajouter à ce + répartiteur en plus de ceux définis au niveau de la + configuration. + |
| forcerecovery | +On | +Force la relance immédiate de tous les membres sans tenir
+ compte de leur paramètre retry dans le cas où ils sont tous en
+ état d'erreur. Il peut cependant arriver qu'un membre déjà
+ surchargé entre dans une situation critique si la relance de
+ tous les membres est forcée sans tenir compte du paramètre retry
+ de chaque membre. Dans ce cas, définissez ce paramètre à
+ Off.+ Disponible depuis la version 2.4.2 du serveur HTTP Apache. + |
Exemple de configuration d'un répartiteur de charge
+ProxyPass "/special-area" "http://special.example.com" smax=5 max=10 +ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On +<Proxy "balancer://mycluster"> + BalancerMember "ajp://1.2.3.4:8009" + BalancerMember "ajp://1.2.3.5:8009" loadfactor=20 + # Less powerful server, don't send as many requests there, + BalancerMember "ajp://1.2.3.6:8009" loadfactor=5 +</Proxy>+ + +
La définition de remplaçants à chaud permet de s'assurer qu'un nombre + déterminé de serveurs sera toujours disponible dans le jeu de serveurs + cibles :
+ProxyPass "/" "balancer://sparecluster/" +<Proxy balancer://sparecluster> + BalancerMember ajp://1.2.3.4:8009 + BalancerMember ajp://1.2.3.5:8009 + # Les serveurs ci-dessous sont des remplaçants à chaud. Pour chaque serveur + # ci-dessus qui viendrait à être inutilisable (maintenance, arrêt, non + # contactable, en erreur, etc...), un de ces remplaçants à chaud prendra sa + # place. Deux serveurs seront toujours disponibles pour traiter une requête + # (à moins qu'un ou plusieurs remplaçant à chaud soit lui aussi + # indisponible). + BalancerMember ajp://1.2.3.6:8009 status=+R + BalancerMember ajp://1.2.3.7:8009 status=+R +</Proxy>+ + +
Configuration d'un serveur cible de réserve qui ne sera utilisé que si + aucun autre serveur cible ou remplaçant à chaud n'est disponible dans le jeu + de serveurs cibles :
+ProxyPass "/" "balancer://hotcluster/" +<Proxy "balancer://hotcluster"> + BalancerMember "ajp://1.2.3.4:8009" loadfactor=1 + BalancerMember "ajp://1.2.3.5:8009" loadfactor=2.25 + # The server below is on hot standby + BalancerMember "ajp://1.2.3.6:8009" status=+H + ProxySet lbmethod=bytraffic +</Proxy>+ + +
Mots-clés additionnels de ProxyPass
+ +Normalement, mod_proxy va mettre sous leur forme canonique les + URLs traitées par ProxyPass. Mais ceci peut être incompatible avec + certains serveurs d'arrière-plan, et en particulier avec ceux qui + utilisent PATH_INFO. Le mot-clé optionnel + nocanon modifie ce comportement et permet de transmettre + le chemin d'URL sous sa forme brute au serveur d'arrière-plan. Notez + que ceci peut affecter la sécurité de votre serveur d'arrière-plan, + car la protection limitée contre les attaques à base d'URL que + fournit le mandataire est alors supprimée.
+ +Par défaut, mod_proxy inclut la chaîne de paramètres lors de la + génération de la variable d'environnement + SCRIPT_FILENAME. Le mot-clé optionnel noquery + (disponible à partir de la version 2.4.1) permet d'exclure cette + chaîne.
+ +Lorsque la directive ProxyPass est utilisée à l'intérieur d'une
+ section <Location>, le premier argument est omis et le répertoire
+ local est obtenu à partir de la section <Location>. Il en sera de même dans une
+ section <LocationMatch> ; cependant, ProxyPass
+ n'interprète pas les expressions rationnelles, et il sera ici
+ nécessaire d'utiliser la directive
+ ProxyPassMatch à la place.
Cette directive ne peut pas être placée dans une section
+ <Directory> ou
+ <Files>.
Si vous avez besoin d'un configuration de mandataire inverse plus
+ souple, reportez-vous à la documentaion de la directive RewriteRule et son drapeau
+ [P].
Le mot-clé optionnel interpolate, en combinaison avec la directive
+ ProxyPassInterpolateEnv, permet à ProxyPass
+ d'interpoler les variables d'environnement à l'aide de la syntaxe
+ ${VARNAME}. Notez que de nombreuses variables
+ d'environnement standard dérivées de CGI n'existeront pas lorsque
+ l'interpolation se produit ; vous devrez alors encore avoir avoir
+ recours à mod_rewrite pour des règles
+ complexes. Notez aussi que l'interpolation n'est supportée dans
+ la partie protocole/hostname/port d'une URL que pour les variables qui sont
+ disponibles au moment où la directive est interprétée (comme pour la
+ directive Define). La détermination
+ dynamique de ces champs peut être effectuée à l'aide de
+ mod_rewrite, et l'exemple suivant décrit comment utiliser
+ mod_rewrite pour définir dynamiquement le protocole à http
+ ou https :
RewriteEngine On
+
+RewriteCond "%{HTTPS}" =off
+RewriteRule "". "-" [E=protocol:http]
+RewriteCond "%{HTTPS}" =on
+RewriteRule "." "-" [E=protocol:https]
+
+RewriteRule "^/mirror/foo/(.*)" "%{ENV:protocol}://backend.example.com/$1" [P]
+ProxyPassReverse "/mirror/foo/" "http://backend.example.com/"
+ProxyPassReverse "/mirror/foo/" "https://backend.example.com/"
+
+
+
+| Description: | Héritage des directives ProxyPass définies au niveau du +serveur principal |
|---|---|
| Syntaxe: | ProxyPassInherit On|Off |
| Défaut: | ProxyPassInherit On |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur +HTTP Apache. |
Cette directive permet à un serveur virtuel d'hériter des
+ directives ProxyPass définies
+ au niveau du serveur principal. Si vous utilisez la fonctionnalité de
+ modifications dynamiques du Balancer Manager, cette directive peut
+ causer des problèmes et des comportements inattendus et doit donc
+ être désactivée.
Les valeurs définies au niveau du serveur principal + constituent les valeurs par défaut pour tous les serveurs virtuels.
+La désactivation de ProxyPassInherit désactive aussi la
+ directive BalancerInherit.
| Description: | Active l'interpolation des variables d'environnement dans +les configurations de mandataires inverses |
|---|---|
| Syntaxe: | ProxyPassInterpolateEnv On|Off |
| Défaut: | ProxyPassInterpolateEnv Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | Disponible depuis la version 2.2.9 d'Apache |
Cette directive, ainsi que l'argument interpolate des
+ directives ProxyPass,
+ ProxyPassReverse,
+ ProxyPassReverseCookieDomain et
+ ProxyPassReverseCookiePath, permet de
+ configurer dynamiquement un mandataire inverse à l'aide de
+ variables d'environnement, ces dernières pouvant être définies par un
+ autre module comme mod_rewrite. Elle affecte les
+ directives ProxyPass,
+ ProxyPassReverse,
+ ProxyPassReverseCookieDomain, et
+ ProxyPassReverseCookiePath, en leur indiquant
+ de remplacer la chaîne ${nom_var} dans les directives
+ de configuration par la valeur de la variable d'environnement
+ nom_var (si l'option interpolate est
+ spécifiée).
La partie protocole/hostname/port de ProxyPass
+ peut contenir des variables, mais seulement celles qui sont accessibles au
+ moment où la directive est interprétée (similairement à la directive
+ Define). Pour tous les autres cas,
+ utilisez plutôt mod_rewrite.
Laissez cette directive à off, à moins que vous n'en ayez réellemnt
+ besoin ! Par exemple, ajouter des variables à
+ ProxyPass peut entraîner l'utilisation des serveurs
+ d'arrière-plan de mod_proxy configurés par défaut, et ceux-ci ne permettent
+ pas un réglage fin comme la réutilisation des connexions, entre
+ autres...).
| Description: | Fait correspondre des serveurs distants dans l'espace d'URL +du serveur local en utilisant des expressions rationnelles |
|---|---|
| Syntaxe: | ProxyPassMatch [regex] !|url
+[clé=valeur
+ [clé=valeur ...]] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy |
Cette directive est identique à la directive ProxyPass, mais fait usage des
+ expressions rationnelles, au lieu d'une simple comparaison de
+ préfixes. L'expression rationnelle spécifiée est comparée à
+ l'url, et si elle correspond, le serveur va substituer
+ toute correspondance entre parenthèses dans la chaîne donnée et
+ l'utiliser comme nouvelle url.
Supposons que le serveur local a pour adresse
+ http://example.com/ ; alors
ProxyPassMatch "^(/.*\.gif)$" "http://backend.example.com/$1"+ + +
va provoquer la conversion interne de la requête locale
+ http://example.com/foo/bar.gif en une requête mandatée
+ pour http://backend.example.com/foo/bar.gif.
L'argument URL doit pouvoir être interprété en tant qu'URL + avant les substitutions d'expressions rationnelles (et + doit aussi l'être après). Ceci limite les correspondances que vous + pouvez utiliser. Par exemple, si l'on avait utilisé
+ProxyPassMatch "^(/.*\.gif)$" + "http://backend.example.com:8000$1"+ +
dans l'exemple précédent, nous aurions provoqué une erreur de + syntaxe au démarrage du serveur. C'est une bogue (PR 46665 dans + ASF bugzilla), et il est possible de la contourner en reformulant + la correspondance :
+ProxyPassMatch "^/(.*\.gif)$" "http://backend.example.com:8000/$1"+ +
Le drapeau ! vous permet de ne pas mandater un
+ sous-répertoire donné.
Dans une section <LocationMatch>, le premier argument est
+ omis et l'expression rationnelle est obtenue à partir de la directive
+ <LocationMatch>.
Si vous avez besoin d'une configuration du mandataire inverse
+ plus flexible, voyez la directive RewriteRule avec le drapeau
+ [P].
Lorsque le paramètre URL n'utilise pas de références arrières + dans l'expression rationnelle, l'URL originale sera ajoutée au + paramètre URL. +
+Lors de la construction de l'URL cible de la règle, il convient + de prendre en compte l'impact en matière de sécurité qu'aura le + fait de permettre au client d'influencer le jeu d'URLs pour + lesquelles votre serveur agira en tant que mandataire. + Assurez-vous que la partie protocole://nom-serveur de l'URL soit + fixe, ou ne permette pas au client de l'influencer induement.
+| Description: | Ajuste l'URL dans les en-têtes de la réponse HTTP envoyée +par un serveur mandaté en inverse |
|---|---|
| Syntaxe: | ProxyPassReverse [chemin] url
+[interpolate] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy |
Cette directive permet de faire en sorte qu'Apache httpd ajuste l'URL
+ dans les en-têtes Location,
+ Content-Location et URI des réponses de
+ redirection HTTP. Ceci est essentiel lorsqu'Apache httpd est utilisé en
+ tant que mandataire inverse (ou passerelle), afin d'éviter de
+ court-circuiter le mandataire inverse suite aux redirections HTTP
+ sur le serveur d'arrière-plan qui restent derrière le mandataire
+ inverse.
Seuls les en-têtes de réponse HTTP spécialement mentionnés
+ ci-dessus seront réécrits. Apache httpd ne réécrira ni les autres en-têtes
+ de réponse, ni par défaut les références d'URLs dans les pages HTML. Cela
+ signifie que dans le cas où un contenu mandaté contient des
+ références à des URLs absolues, elles court-circuiteront le
+ mandataire. Pour réécrire un contenu HTML afin qu'il corresponde au
+ mandataire, vous devez charger et activer le module
+ mod_proxy_html.
+
chemin est le nom d'un chemin virtuel local.
+ url est une URL partielle pour le serveur distant. Ces
+ paramètres s'utilisent de la même façon qu'avec la
+ directive ProxyPass.
Supposons par exemple que le serveur local a pour adresse
+ http://example.com/ ; alors
ProxyPass "/mirror/foo/" "http://backend.example.com/" +ProxyPassReverse "/mirror/foo/" "http://backend.example.com/" +ProxyPassReverseCookieDomain "backend.example.com" "public.example.com" +ProxyPassReverseCookiePath "/" "/mirror/foo/"+ + +
ne va pas seulement provoquer la conversion interne d'une requête
+ locale pour http://example.com/mirror/foo/bar en une
+ requête mandatée pour http://backend.example.com/bar
+ (la fonctionnalité fournie par ProxyPass). Il va
+ aussi s'occuper des redirections que le serveur
+ backend.example.com envoie lorsqu'il redirige
+ http://backend.example.com/bar vers
+ http://backend.example.com/quux. Apache
+ httpd corrige ceci en http://example.com/mirror/foo/quux
+ avant de faire suivre la redirection HTTP au client. Notez que le
+ nom d'hôte utilisé pour construire l'URL est choisi en respectant la
+ définition de la directive UseCanonicalName.
Notez que la directive ProxyPassReverse
+ peut aussi être utilisée en conjonction avec la
+ fonctionnalité de mandataire
+ (RewriteRule ... [P]) du module
+ mod_rewrite, car elle ne dépend pas d'une directive
+ ProxyPass
+ correspondante.
Le mot-clé optionnel interpolate, en
+ combinaison avec la directive
+ ProxyPassInterpolateEnv, permet
+ l'interpolation des variables d'environnement spécifiées en
+ utilisant le format ${VARNAME} Notez que l'interpolation
+ n'est pas supportée dans la partie protocole d'une URL.
+
Lorsque cette directive est utilisée dans une section <Location>, le premier
+ argument est omis et le répertoire local est obtenu à partir de
+ l'argument de la directive <Location>. Il en est de même à l'intérieur
+ d'une section <LocationMatch>, mais le résultat ne sera
+ probablement pas celui attendu car ProxyPassReverse va interpréter
+ l'expression rationnelle littéralement comme un chemin ; si besoin
+ est dans ce cas, définissez la directive ProxyPassReverse en dehors
+ de la section, ou dans une section <Location> séparée.
Cette directive ne peut pas être placée dans une section
+ <Directory> ou
+ <Files>.
| Description: | Ajuste la chaîne correspondant au domaine dans les en-têtes +Set-Cookie en provenance d'un serveur mandaté |
|---|---|
| Syntaxe: | ProxyPassReverseCookieDomain domaine-interne
+domaine-public [interpolate] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy |
L'utilisation de cette directive est similaire à celle de la
+directive ProxyPassReverse,
+mais au lieu de réécrire des en-têtes qui contiennent des URLs, elle
+réécrit la chaîne correspondant au domaine dans les en-têtes
+Set-Cookie.
| Description: | Ajuste la chaîne correspondant au chemin dans les en-têtes +Set-Cookie en provenance d'un serveur mandaté |
|---|---|
| Syntaxe: | ProxyPassReverseCookiePath chemin-interne
+chemin-public [interpolate] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy |
+Cette directive s'avère utile en conjonction avec la directive
+ProxyPassReverse dans les
+situations où les chemins d'URL d'arrière-plan correspondent à des
+chemins publics sur le mandataire inverse. Cette directive permet de
+réécrire la chaîne path dans les en-têtes
+Set-Cookie. Si le début du chemin du cookie correspond à
+chemin-interne, le chemin du cookie sera remplacé par
+chemin-public.
+
+Dans l'exemple fourni avec la directive ProxyPassReverse, la directive :
+
ProxyPassReverseCookiePath "/" "/mirror/foo/"+ +
+va réécrire un cookie possédant un chemin d'arrière-plan /
+(ou /example ou en fait tout chemin)
+en /mirror/foo/..
+
| Description: | Utilise l'en-tête de requête entrante Host pour la requête +du mandataire |
|---|---|
| Syntaxe: | ProxyPreserveHost On|Off |
| Défaut: | ProxyPreserveHost Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | Utilisable +dans un contexte de répertoire depuis la version 2.3.3. |
Lorsqu'elle est activée, cette directive va transmettre l'en-tête
+ Host: de la requête entrante vers le serveur mandaté, au lieu du nom
+ d'hôte spécifié par la directive ProxyPass.
Cette directive est habituellement définie à Off.
+ Elle est principalement utile dans les configurations particulières
+ comme l'hébergement virtuel mandaté en masse à base de nom, où
+ l'en-tête Host d'origine doit être évalué par le serveur
+ d'arrière-plan.
| Description: | Taille du tampon réseau pour les connexions mandatées HTTP +et FTP |
|---|---|
| Syntaxe: | ProxyReceiveBufferSize octets |
| Défaut: | ProxyReceiveBufferSize 0 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
La directive ProxyReceiveBufferSize permet
+ de spécifier une taille de tampon réseau explicite (TCP/IP) pour les
+ connexions mandatées HTTP et FTP, afin d'améliorer le débit de
+ données. Elle doit être supérieure à 512 ou définie à
+ 0 pour indiquer que la taille de tampon par défaut du
+ système doit être utilisée.
ProxyReceiveBufferSize 2048+
| Description: | Mandataire distant à utiliser pour traiter certaines +requêtes |
|---|---|
| Syntaxe: | ProxyRemote comparaison serveur-distant |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
Cette directive permet de définir des mandataires distants pour
+ ce mandataire. comparaison est soit le nom d'un protocole
+ que supporte le serveur distant, soit une URL partielle pour
+ laquelle le serveur distant devra être utilisé, soit *
+ pour indiquer que le serveur distant doit être utilisé pour toutes
+ les requêtes. serveur-distant est une URL partielle
+ correspondant au serveur distant. Syntaxe :
+ serveur-distant =
+ protocole://nom-serveur[:port]
+
protocole est effectivement le protocole à utiliser
+ pour communiquer avec le serveur distant ; ce module ne supporte que
+ http et https. Lorsqu'on utilise
+ https, les requêtes sont redirigées par le mandataire
+ distant en utilisant la méthode HTTP CONNECT.
ProxyRemote "http://goodguys.example.com/" "http://mirrorguys.example.com:8000" +ProxyRemote "*" "http://cleverproxy.localdomain" +ProxyRemote "ftp" "http://ftpproxy.mydomain:8080"+
Dans la dernière ligne de l'exemple, le mandataire va faire + suivre les requêtes FTP, encapsulées dans une autre requête mandatée + HTTP, vers un autre mandataire capable de les traiter.
+ +Cette directive supporte aussi les configurations de mandataire + inverse ; un serveur web d'arrière-plan peut être intégré dans + l'espace d'URL d'un serveur virtuel, même si ce serveur est caché + par un autre mandataire direct.
+ +| Description: | Le mandataire distant à utiliser pour traiter les requêtes +correspondant à une expression rationnelle |
|---|---|
| Syntaxe: | ProxyRemoteMatch regex serveur-distant |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
La directive ProxyRemoteMatch est
+ identique à la directive ProxyRemote, à l'exception du
+ premier argument qui est une expression
+ rationnelle à mettre en correspondance avec l'URL de la
+ requête.
| Description: | Active la fonctionnalité (standard) de mandataire +direct |
|---|---|
| Syntaxe: | ProxyRequests On|Off |
| Défaut: | ProxyRequests Off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
Cette directive permet d'activer/désactiver la fonctionnalité de
+ serveur mandataire direct d'Apache httpd. Définir ProxyRequests à
+ Off n'interdit pas l'utilisation de la directive
+ ProxyPass.
Pour une configuration typique de mandataire inverse ou
+ passerelle, cette directive doit être définie à
+ Off.
Afin d'activer la fonctionnalité de mandataire pour des sites
+ HTTP et/ou FTP, les modules mod_proxy_http et/ou
+ mod_proxy_ftp doivent également être chargés dans le
+ serveur.
Pour activer la fonctionnalité de mandataire sur les sites chiffrés en HTTPS, le module
+ mod_proxy_connect doit également être chargé dans le serveur.
N'activez pas la fonctionnalité de mandataire avec la directive
+ ProxyRequests avant
+ d'avoir sécurisé votre serveur. Les serveurs
+ mandataires ouverts sont dangereux non seulement pour votre
+ réseau, mais aussi pour l'Internet au sens large.
| Description: | Définit différents paramètres relatifs à la répartition de +charge des mandataires et aux membres des groupes de répartition de +charge |
|---|---|
| Syntaxe: | ProxySet url clé=valeur [clé=valeur ...] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | ProxySet n'est disponible que depuis la version 2.2 +du serveur HTTP Apache. |
Cette directive propose une méthode alternative pour définir tout
+ paramètre relatif aux répartiteurs de charge et serveurs cibles de
+ mandataires normalement définis via la directive ProxyPass. Si elle se trouve dans un
+ conteneur <Proxy url de répartiteur|url de
+ serveur cible>, l'argument url n'est pas
+ nécessaire. Comme effet de bord, le répartiteur ou serveur cible respectif
+ est créé. Ceci peut s'avérer utile pour la mise en oeuvre d'un
+ mandataire inverse via une directive RewriteRule au lieu de ProxyPass.
<Proxy "balancer://hotcluster"> + BalancerMember "http://www2.example.com:8080" loadfactor=1 + BalancerMember "http://www3.example.com:8080" loadfactor=2 + ProxySet lbmethod=bytraffic +</Proxy>+
<Proxy "http://backend"> + ProxySet keepalive=On +</Proxy>+ + +
ProxySet "balancer://foo" lbmethod=bytraffic timeout=15+ + +
ProxySet "ajp://backend:7001" timeout=15+ + +
Gardez à l'esprit qu'une même clé de paramètre peut avoir + différentes significations selon qu'elle s'applique à un + répartiteur ou à un serveur cible, et ceci est illustré par les deux + exemples précédents où il est question d'un timeout.
+| Description: | Définit l'adresse IP locale pour les connexions mandatées +sortantes |
|---|---|
| Syntaxe: | ProxySourceAddress adresse |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | Disponible depuis la version 2.3.9 |
Cette directive permet de définir une adresse IP locale + spécifique à laquelle faire référence lors d'une connexion à un + serveur d'arrière-plan.
+ + +| Description: | Affiche l'état du répartiteur de charge du mandataire dans +mod_status |
|---|---|
| Syntaxe: | ProxyStatus Off|On|Full |
| Défaut: | ProxyStatus Off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
| Compatibilité: | Disponible depuis la version 2.2 d'Apache |
Cette directive permet de spécifier si les données d'état du
+ répartiteur de charge du mandataire doivent être affichées via la
+ page d'état du serveur du module mod_status.
L'argument Full produit le même effet que + l'argument On.
+| Description: | Délai d'attente réseau pour les requêtes +mandatées |
|---|---|
| Syntaxe: | ProxyTimeout secondes |
| Défaut: | Valeur de la directive |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
Cette directive permet à l'utilisateur de spécifier un délai pour + les requêtes mandatées. Ceci s'avère utile dans le cas d'un serveur + d'applications lent et bogué qui a tendance à se bloquer, et si vous + préférez simplement renvoyer une erreur timeout et abandonner la + connexion en douceur plutôt que d'attendre jusqu'à ce que le serveur + veuille bien répondre.
+ +| Description: | Information fournie dans l'en-tête de réponse HTTP
+Via pour les requêtes mandatées |
|---|---|
| Syntaxe: | ProxyVia On|Off|Full|Block |
| Défaut: | ProxyVia Off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy |
Cette directive permet de contrôler l'utilisation de l'en-tête
+ HTTP Via: par le mandataire. Le but recherché est de
+ contrôler le flux des requêtes mandatées tout au long d'une chaîne
+ de serveurs mandataires. Voir RFC 2616 (HTTP/1.1),
+ section 14.45 pour une description des lignes d'en-tête
+ Via:.
Off, valeur par défaut, cette
+ directive n'effectue aucun traitement particulier. Si une requête ou
+ une réponse contient un en-tête Via:, il est transmis
+ sans modification.On, chaque requête ou réponse
+ se verra ajouter une ligne d'en-tête Via: pour le
+ serveur courant.Full, chaque ligne d'en-tête
+ Via: se verra ajouter la version du serveur Apache
+ httpd sous la forme d'un champ de commentaire Via:.Block, chaque requête
+ mandatée verra ses lignes d'en-tête Via: supprimées.
+ Aucun nouvel en-tête Via: ne sera généré.Serveur HTTP Apache Version 2.4
+| Description: | Module de support AJP pour
+mod_proxy |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_ajp_module |
| Fichier Source: | mod_proxy_ajp.c |
| Compatibilité: | Disponible depuis la version 2.1 d'Apache |
Ce module nécessite le chargement de mod_proxy. Il fournit le support du Protocole Apache
+ JServ version 1.3 (nommé dans la suite de ce document
+ AJP13).
Pour être en mesure d'exploiter le protocole AJP13,
+ il est donc nécessaire de charger les modules
+ mod_proxy et mod_proxy_ajp.
N'activez pas la fonctionnalité de mandataire avant d'avoir sécurisé votre serveur. Les + serveurs mandataires ouverts sont dangereux non seulement pour + votre réseau, mais aussi pour l'Internet au sens large.
+ Utilisation Variables d'environnement Vue d'ensemble du protocole Structure de base des paquets Structure des paquets de
+requête Structure du paquet de la
+réponseCe module ne fournit aucune directive.
+Ce module permet de mandater en inverse un serveur d'application
+ d'arrière-plan (comme Apache Tomcat) qui utilise le protocole AJP13.
+ Son utilisation est similaire à celle d'un mandataire inverse HTTP,
+ mais s'appuie sur le prefixe ajp:// :
ProxyPass "/app" "ajp://backend.example.com:8009/app"+
On peut aussi configurer un répartiteur de charge :
+<Proxy balancer://cluster> + BalancerMember "ajp://app1.example.com:8009" loadfactor=1 + BalancerMember "ajp://app2.example.com:8009" loadfactor=2 + ProxySet lbmethod=bytraffic +</Proxy> +ProxyPass "/app" "balancer://cluster/app"+
Notez qu'en général, la directive ProxyPassReverse n'est pas
+ nécessaire. La requête AJP inclut l'en-tête host original fourni
+ au mandataire, et le serveur d'application est sensé générer des
+ en-têtes auto-référençants relatifs à cet hôte ; aucune réécriture
+ n'est donc nécessaire.
La situation la plus courante dans laquelle la directive ProxyPassReverse est nécessaire se
+ rencontre lorsque le chemin de l'URL au niveau du mandataire est
+ différente de celle du serveur d'arrière-plan. Dans ce cas, un
+ en-tête redirect peut être réécrit relativement à l'URL de l'hôte
+ original (et non du serveur d'arrière-plan ajp:// URL)
+ ; par exemple :
ProxyPass "/apps/foo" "ajp://backend.example.com:8009/foo" +ProxyPassReverse "/apps/foo" "http://www.example.com/foo"+
Il est cependant préférable en général de déployer l'application + sur le serveur d'arrière-plan avec le même chemin que sur le + mandataire. +
+Les variables d'environnement dont le nom possède le préfixe
+ AJP_ sont transmises au serveur original en tant
+ qu'attributs de requête AJP (le préfixe AJP_ étant supprimé du nom
+ de la clé).
Le protocole AJP13 est orienté paquet. Le format
+ binaire a été préféré, probablement pour des raisons de
+ performances, au format texte pourtant plus lisible. Le serveur web
+ communique avec le conteneur de servlets sur une connexion TCP. Pour
+ diminuer la charge induite par le processus de création de socket,
+ le serveur web va tenter d'utiliser des connexions TCP persistantes
+ avec le conteneur de servlets, et de réutiliser les connexions
+ pendant plusieurs cycles requêtes/réponse.
Lorsqu'une connexion a été assignée à une requête particulière, + elle ne sera utilisée pour aucune autre jusqu'à ce que le cycle de + traitement de la requête se soit terminé. En d'autres termes, il n'y + a pas de multiplexage des requêtes sur une connexion. Ceci se + traduit par un code beaucoup plus simple à chaque extrémité de la + connexion, un nombre plus important de connexions étant cependant + ouvertes en même temps.
+Lorsque le serveur web a ouvert une connexion vers le conteneur + de servlets, celle-ci peut se trouver dans l'un des états suivants + :
+Lorsqu'une connexion est assignée au traitement d'une requête
+ particulière, les informations de base de cette dernière (comme les
+ en-têtes HTTP, etc...) sont envoyées sur la connexion sous une forme
+ très condensée (par exemple les chaînes courantes sont codées sous
+ forme d'entiers). Vous trouverez des détails sur ce format plus
+ loin dans la structure des paquets de requête. Si la requête possède
+ un corps (content-length > 0), il est envoyé dans un
+ paquet séparé immédiatement après.
A ce moment, le conteneur est probablement prêt à traiter la + requête. Au cours de ce traitement, il peut renvoyer les messages + suivants au serveur web :
+Chaque message est associé à un paquet de données formaté + différemment. Voir plus loin les structures des paquets de réponses + pour plus de détails.
+Ce protocole hérite en partie de XDR, mais il diffère sur de + nombreux points (pas d'alignement sur 4 bits, par exemple).
+AJP13 utilise les octets selon leur ordre d'arrivée par le réseau + pour tous les types de données.
+Le protocole comporte quatre types de données : octets, booléens, + entiers et chaînes de caractères.
+1 = vrai, 0 = faux.
+ L'utilisation d'autres valeurs non nulles (dans le style C) peut
+ fonctionner dans certains cas, mais pas dans certains autres..0 et 2^16 (32768), stocké
+ sur 2 octets en débutant par l'octet de poids forts.strlen. Cela peut
+ prêter à confusion du point de vue de Java qui est surchargé de
+ déclarations d'autoincrémentation étranges destinées à traiter
+ ces terminateurs. Je suppose que le but dans lequel cela a
+ été conçu ainsi était de permettre au code C d'être plus efficace
+ lors de la lecture de chaînes en provenance du conteneur de
+ servlets -- avec le caractère \0 final, le code C peut transmettre
+ des références dans un seul tampon, sans avoir à effectuer de
+ copie. En l'absence du caractère \0 final, le code C doit
+ effectuer une copie afin de pouvoir tenir compte de sa notion de
+ chaîne.Selon la majorité du code, la taille maximale du paquet est de
+ 8 * 1024 bytes (8K). La taille réelle du paquet est
+ encodée dans l'en-tête.
Les paquets envoyés par le serveur vers le conteneur commencent
+ par 0x1234. Les paquets envoyés par le conteneur vers
+ le serveur commencent par AB (c'est à dire le code
+ ASCII de A suivi du code ASCII de B). Ensuite, vient un entier (codé
+ comme ci-dessus) représentant la longueur des données transmises.
+ Bien que ceci puisse faire croire que la taille maximale des données
+ est de 2^16, le code définit en fait ce maximum à 8K.
| Format du paquet (Serveur->Conteneur) | +|||||
|---|---|---|---|---|---|
| Octet | +0 | +1 | +2 | +3 | +4...(n+3) | +
| Contenu | +0x12 | +0x34 | +Taille des données (n) | +Data | +|
| Format du paquet + (Conteneur->Serveur) | +|||||
|---|---|---|---|---|---|
| Octet | +0 | +1 | +2 | +3 | +4...(n+3) | +
| Contenu | +A | +B | +Taille des données (n) | +Data | +|
Pour la plupart des paquets, le premier octet de la charge utile
+ encode le type de message, à l'exception des paquets contenant un
+ corps de requête envoyés du serveur vers le conteneur -- ils
+ comportent un en-tête standard (0x1234 suivi de la taille
+ du paquet), mais celui-ci n'est suivi d'aucun préfixe.
Le serveur web peut envoyer les messages suivants au conteneur + de servlets :
+| Code | +Type de paquet | +Signification | +
| 2 | +Fait suivre la requête | +Débute le cycle de traitement de la requête avec les données + qui suivent. | +
| 7 | +Arrêt | +Le serveur web demande au conteneur de s'arrêter. | +
| 8 | +Ping | +Le serveur web demande au conteneur de prendre le contrôle + (phase de connexion sécurisée). | +
| 10 | +CPing | +Le serveur web demande au conteneur de répondre rapidement + avec un CPong. + | +
| none | +Données | +Taille (2 octets) et les données correspondantes. | +
À des fins de sécurité, le conteneur n'effectuera réellement son
+ Arrêt que si la demande provient de la machine par
+ laquelle il est hébergé.
Le premier paquet Données est envoyé immédiatement
+ après le paquet Faire suivre la requête par le serveur
+ web.
Le conteneur de servlets peut envoyer les types de messages + suivants au serveur web :
+| Code | +Type de paquet | +Signification | +
| 3 | +Envoi d'un tronçon de corps | +Envoi d'un tronçon de corps depuis le conteneur de servlets + vers le serveur web (et probablement vers le navigateur). | +
| 4 | +Envoie les en-têtes | +Envoi des en-têtes de réponse depuis le conteneur de + servlets vers le serveur web (et probablement vers le + navigateur). | +
| 5 | +Fin de la réponse | +Marque la fin de la réponse (et par conséquent du cycle de + traitement de la requête). + | +
| 6 | +Réception du tronçon de corps suivant | +Réception de la suite des données de la requête si elles + n'ont pas encore été entièrement transmises. | +
| 9 | +Réponse CPong | +La réponse à une requête CPing | +
Chacun des messages ci-dessus possède une structure interne + différente dont vous trouverez les détails ci-dessous.
+ +Pour les messages de type Faire suivre la requête depuis + le serveur vers le conteneur :
+AJP13_FORWARD_REQUEST := + prefix_code (byte) 0x02 = JK_AJP13_FORWARD_REQUEST + method (byte) + protocol (string) + req_uri (string) + remote_addr (string) + remote_host (string) + server_name (string) + server_port (integer) + is_ssl (boolean) + num_headers (integer) + request_headers *(req_header_name req_header_value) + attributes *(attribut_name attribute_value) + request_terminator (byte) OxFF
Les request_headers possèdent la structure suivante
+ :
+
req_header_name := + sc_req_header_name | (string) [voir ci-dessous pour la manière dont + ceci est interprété] + +sc_req_header_name := 0xA0xx (integer) + +req_header_value := (string)
Les attributes sont optionnels et possèdent la
+ structure suivante :
attribute_name := sc_a_name | (sc_a_req_attribute string) + +attribute_value := (string)
Un des en-têtes les plus importants est
+ content-length, car il indique si le conteneur doit ou
+ non attendre un autre paquet immédiatement.
Pour toutes les requêtes, ce préfixe est 2. Voir ci-dessus pour + les détails des autres codes de préfixes.
+ +La méthode HTTP, encodée sous la forme d'un seul octet :
+| Nom commande | Code |
| OPTIONS | 1 |
| GET | 2 |
| HEAD | 3 |
| POST | 4 |
| PUT | 5 |
| DELETE | 6 |
| TRACE | 7 |
| PROPFIND | 8 |
| PROPPATCH | 9 |
| MKCOL | 10 |
| COPY | 11 |
| MOVE | 12 |
| LOCK | 13 |
| UNLOCK | 14 |
| ACL | 15 |
| REPORT | 16 |
| VERSION-CONTROL | 17 |
| CHECKIN | 18 |
| CHECKOUT | 19 |
| UNCHECKOUT | 20 |
| SEARCH | 21 |
| MKWORKSPACE | 22 |
| UPDATE | 23 |
| LABEL | 24 |
| MERGE | 25 |
| BASELINE_CONTROL | 26 |
| MKACTIVITY | 27 |
Les versions futures d'ajp13 pourront transmettre des méthodes + supplémentaires, même si elles ne font pas partie de cette + liste.
+ +Les significations de ces éléments sont triviales. Ils sont tous + obligatoires et seront envoyés avec chaque requête.
+ +La structure de request_headers est la suivante
+ : tout d'abord, le nombre d'en-têtes num_headers est
+ encodé, suivi d'une liste de paires nom d'en-tête
+ req_header_name / valeur req_header_value.
+ Les noms d'en-têtes courants sont codés sous forme d'entiers afin de
+ gagner de la place. Si le nom d'en-tête ne fait partie de la liste
+ des en-têtes courants, il est encodé normalement (une chaîne de
+ caractères préfixée par la taille). La liste des en-têtes courants
+ sc_req_header_name avec leurs codes se présente comme
+ suit (il sont tous sensibles à la casse) :
| Nom | Valeur du code | Nom du code |
| accept | 0xA001 | SC_REQ_ACCEPT |
| accept-charset | 0xA002 | SC_REQ_ACCEPT_CHARSET + |
| accept-encoding | 0xA003 | SC_REQ_ACCEPT_ENCODING + |
| accept-language | 0xA004 | SC_REQ_ACCEPT_LANGUAGE + |
| authorization | 0xA005 | SC_REQ_AUTHORIZATION | +
| connection | 0xA006 | SC_REQ_CONNECTION |
| content-type | 0xA007 | SC_REQ_CONTENT_TYPE | +
| content-length | 0xA008 | SC_REQ_CONTENT_LENGTH | +
| cookie | 0xA009 | SC_REQ_COOKIE |
| cookie2 | 0xA00A | SC_REQ_COOKIE2 |
| host | 0xA00B | SC_REQ_HOST |
| pragma | 0xA00C | SC_REQ_PRAGMA |
| referer | 0xA00D | SC_REQ_REFERER |
| user-agent | 0xA00E | SC_REQ_USER_AGENT |
Le code Java qui lit ceci extrait l'entier représenté par les
+ deux premiers octets, et si le premier octet est
+ '0xA0', il utilise l'entier représenté par le deuxième
+ octet comme index d'un tableau de noms d'en-têtes. Si le premier
+ octet n'est pas 0xA0, l'entier représenté par les deux
+ octets est considéré comme la longueur d'une chaîne qui est alors
+ lue.
Ceci ne peut fonctionner que si aucun nom d'en-tête ne possède
+ une taille supérieure à 0x9FFF (==0xA000 - 1), ce qui
+ est vraisemblable, bien qu'un peu arbitraire.
content-length est extrêmement important.
+ S'il est présent et non nul, le conteneur considère que la requête
+ possède un corps (une requête POST, par exemple), et lit
+ immédiatement le paquet suivant dans le flux d'entrée pour extraire
+ ce corps.
+ Les attributs préfixés par ? (par exemple
+ ?context) sont tous optionnels. Chacun d'eux est
+ représenté par un octet correspondant au type de l'attribut et par
+ sa valeur (chaîne ou entier). Ils peuvent être envoyés dans un ordre
+ quelconque (bien que le code C les envoie dans l'ordre ci-dessous).
+ Un code de terminaison spécial est envoyé pour signaler la fin de la
+ liste des attributs optionnels. La liste des codes est la suivante
+ :
| Information | Valeur code | Type de valeur | Note |
| ?context | 0x01 | - | Non implémenté + actuellement + |
| ?servlet_path | 0x02 | - | Non implémenté + actuellement + |
| ?remote_user | 0x03 | String | |
| ?auth_type | 0x04 | String | |
| ?query_string | 0x05 | String | |
| ?jvm_route | 0x06 | String | |
| ?ssl_cert | 0x07 | String | |
| ?ssl_cipher | 0x08 | String | |
| ?ssl_session | 0x09 | String | |
| ?req_attribute | 0x0A | String | Nom (le + nom de l'attribut vient ensuite) |
| ?ssl_key_size | 0x0B | Integer | |
| are_done | 0xFF | - | request_terminator |
context et servlet_path ne sont pas
+ définis actuellement par le code C, et la majorité du code Java
+ ignore complètement ce qui est envoyé par l'intermédiaire de ces
+ champs (il va même parfois s'interrompre si une chaîne est
+ envoyée après un de ces codes). Je ne sais pas si c'est une bogue ou
+ une fonctionnalité non implémentée, ou tout simplement du code
+ obsolète, mais en tout cas, il n'est pris en charge par aucune des
+ deux extrémités de la connexion.
remote_user et auth_type concernent
+ probablement l'authentification au niveau HTTP, et contiennent le
+ nom de l'utilisateur distant ainsi que le type d'authentification
+ utilisée pour établir son identité (à savoir Basic, Digest).
query_string, ssl_cert,
+ ssl_cipher et ssl_session contiennent les
+ éléments HTTP et HTTPS correspondants.
jvm_route est utilisé dans le cadre des sessions
+ persistantes, en associant une session utilisateur à une instance
+ Tomcat particulière en présence de plusieurs répartiteurs de
+ charge.
Au delà de cette liste de base, tout autre attribut
+ supplémentaire peut être envoyé via le code
+ req_attribute 0x0A. Une paire de chaînes
+ représentant le nom et la valeur de l'attribut est envoyée
+ immédiatement après chaque instance de ce code. Les variables
+ d'environnement sont transmises par cette méthode.
Enfin, lorsque tous les attributs ont été transmis, le
+ terminateur d'attributs, 0xFF, est envoyé. Ce dernier
+ indique à la fois la fin de la liste d'attributs et la fin du paquet
+ de la requête
Pour les messages que le conteneur peut renvoyer au + serveur.
+AJP13_SEND_BODY_CHUNK := + prefix_code 3 + chunk_length (integer) + chunk *(byte) + chunk_terminator (byte) Ox00 + + +AJP13_SEND_HEADERS := + prefix_code 4 + http_status_code (integer) + http_status_msg (string) + num_headers (integer) + response_headers *(res_header_name header_value) + +res_header_name := + sc_res_header_name | (string) [voir ci-dessous pour la manière + dont ceci est interprété] + +sc_res_header_name := 0xA0 (byte) + +header_value := (string) + +AJP13_END_RESPONSE := + prefix_code 5 + reuse (boolean) + + +AJP13_GET_BODY_CHUNK := + prefix_code 6 + requested_length (integer)
Le tronçon se compose essentiellement de données binaires et est + renvoyé directement au navigateur.
+ +Les code et message d'état correspondent aux code et message HTTP
+ habituels (par exemple 200 et OK). Les
+ noms d'en-têtes de réponses sont codés de la même façon que les noms
+ d'en-têtes de requêtes. Voir ci-dessus le codage des en-têtes pour
+ plus de détails à propos de la manière dont les codes se distinguent
+ des chaînes.
+ Les codes des en-têtes courants sont ::
| Nom | Valeur code |
| Content-Type | 0xA001 |
| Content-Language | 0xA002 |
| Content-Length | 0xA003 |
| Date | 0xA004 |
| Last-Modified | 0xA005 |
| Location | 0xA006 |
| Set-Cookie | 0xA007 |
| Set-Cookie2 | 0xA008 |
| Servlet-Engine | 0xA009 |
| Status | 0xA00A |
| WWW-Authenticate | 0xA00B |
La valeur de l'en-tête est codée immédiatement après le code ou + la chaîne du nom d'en-tête.
+ +Signale la fin de ce cycle de traitement de requête. Si le
+ drapeau reuse est à true (toute valeur autre que
+ 0 en langage C pur), cette
+ connexion TCP peut être réutilisée pour traiter de nouvelles
+ requêtes entrantes. Si reuse est à false
+ (==0), la connexion sera fermée.
Le conteneur réclame la suite des données de la requête (dans le
+ cas où la taille du corps était trop importante pour pouvoir être
+ contenue dans le premier paquet envoyé, où lorsque la requête est
+ fractionnée). Le serveur va alors envoyer un paquet contenant une
+ quantité de données correspondant au minimum de la
+ request_length, la taille maximale de corps envoyée
+ (8186 (8 Koctets - 6)), et le nombre réel d'octets
+ restants à envoyer pour ce corps de requête.
+ S'il ne reste plus de données à transmettre pour ce corps de requête
+ (c'est à dire si le conteneur de servlets tente de lire au delà de
+ la fin du corps), le serveur va renvoyer un paquet vide
+ dont la charge utile est de longueur 0 et se présentant sous la
+ forme (0x12,0x34,0x00,0x00).
Serveur HTTP Apache Version 2.4
+| Description: | Extension de mod_proxy pour le support de
+la répartition de charge |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_balancer_module |
| Fichier Source: | mod_proxy_balancer.c |
| Compatibilité: | Disponible depuis la version 2.1 d'Apache |
Pour pouvoir fonctionner, ce module requiert le
+ chargement de mod_proxy, et il fournit le support de
+ la répartition de charge pour tous les protocoles supportés. Parmi ces
+ protocoles, les plus importants sont :
mod_proxy_httpmod_proxy_ftpmod_proxy_ajpmod_proxy_wstunnelL'algorithme de planification de la répartition de charge n'est pas + fourni par ce module, mais par ceux-ci :
+mod_lbmethod_byrequestsmod_lbmethod_bytrafficmod_lbmethod_bybusynessmod_lbmethod_heartbeatAinsi, pour mettre en oeuvre la répartition de charge,
+ mod_proxy, mod_proxy_balancer et
+ au moins un des modules fournissant l'algorithme de planification de
+ la répartition de charge doivent être chargés dans le serveur.
N'activez pas la fonctionnalité de mandataire avant d'avoir sécurisé votre serveur. Les + serveurs mandataires ouverts sont dangereux non seulement pour + votre réseau, mais aussi pour l'Internet au sens large.
+ L'algorithme de planification de la répartition de
+ charge Répartition de charge avec abonnement utilisateur
+ (stickyness) Exemples de configuration d'un répartiteur Variables d'environnement exportées Activation du support du gestionnaire de répartiteur Détails à propos de la répartition de charge par abonnement
+ (stickyness) Résolution des problèmes liés à la répartition de charge par
+ abonnementCe module ne fournit aucune directive.
+A l'heure actuelle, 4 algorithmes de planification de la répartition de
+ charge sont disponibles : ils se basent respectivement sur le comptage des
+ requêtes (mod_lbmethod_byrequests), la mesure de
+ l'intensité du trafic (mod_lbmethod_bytraffic), le comptage
+ des requêtes en attente (mod_lbmethod_bybusyness) et la
+ mesure de l'activité du serveur (mod_lbmethod_heartbeat).
+ Ils sont contrôlés par la valeur de lbmethod dans la définition
+ du répartiteur. Voir la directive ProxyPass pour plus de détails, et en
+ particulier la configuration du répartiteur et de ses membres.
Le répartiteur supporte l'abonnement utilisateur. Lorsqu'une + requête est mandatée vers un serveur d'arrière-plan particulier, + toutes les requêtes suivantes du même utilisateur seront alors + mandatées vers le même serveur d'arrière-plan. De nombreux + répartiteurs de charge implémentent cette fonctionnalité via une + table qui associe les adresses IP des clients aux serveurs + d'arrière-plan. Cette approche est transparente aux clients et aux + serveurs d'arrière-plan, mais induit certains problèmes : + distribution de charge inégale si les clients se trouvent eux-mêmes + derrière un mandataire, erreurs d'abonnement lorsqu'un client + possède une adresse IP dynamique qui peut changer au cours d'une + session et perte d'abonnement en cas de dépassement de la table de + correspondances.
+Le module mod_proxy_balancer implémente
+ l'abonnement selon deux alternatives : les cookies et le codage
+ d'URL. Le cookie peut être fourni par le serveur d'arrière-plan ou
+ par le serveur web Apache lui-même, alors que le codage d'URL est en
+ général effectué par le serveur d'arrière-plan.
Avant de nous plonger dans les détails techniques, voici un
+ exemple d'utilisation de mod_proxy_balancer mettant
+ en oeuvre la répartition de charge entre deux serveurs
+ d'arrière-plan :
+
<Proxy "balancer://mycluster"> + BalancerMember "http://192.168.1.50:80" + BalancerMember "http://192.168.1.51:80" +</Proxy> +ProxyPass "/test" "balancer://mycluster" +ProxyPassReverse "/test" "balancer://mycluster"+ + + +
Voici un autre exemple de répartiteur de charge avec
+ abonnement utilisant mod_headers,
+ fonctionnant même si le serveur d'arrière-plan ne définit pas de
+ cookie de session approprié :
+
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED
+<Proxy "balancer://mycluster">
+ BalancerMember "http://192.168.1.50:80" route=1
+ BalancerMember "http://192.168.1.51:80" route=2
+ ProxySet stickysession=ROUTEID
+</Proxy>
+ProxyPass "/test" "balancer://mycluster"
+ProxyPassReverse "/test" "balancer://mycluster"
+
+
+A l'heure actuelle, 6 variables d'environnement sont exportées :
+ +Cette variable se voir assignée la valeur de + stickysession pour la requête courante. Il s'agit du + nom du cookie ou du paramètre de requête utilisé pour les sessions + avec abonnement.
+Cette variable se voit assignée la route interprétée + pour la requête courante.
+Cette variable se voit assigné le nom du répartiteur pour la
+ requête courante. Il s'agit d'une valeur du style
+ balancer://foo.
Cette variable se voit assigné le nom du membre du groupe de
+ répartition de charge utilisé pour la requête courante. Il s'agit
+ d'une valeur du style http://hostA:1234.
Cette variable se voit assignée la route du membre du + groupe de répartition de charge qui sera utilisé pour la requête + courante.
+Cette variable est définie à 1 si la route de la session ne + correspond pas à celle du membre du groupe de répartition de charge + (BALANCER_SESSION_ROUTE != BALANCER_WORKER_ROUTE), ou si la session + ne possède pas encore de route établie. Elle peut servir à + déterminer quand il est éventuellement nécessaire d'envoyer au + client une route mise à jour lorsque les sessions persistantes sont + utilisées.
+Cette fonctionnalité nécessite le chargement du module
+ mod_status. Le gestionnaire de répartiteur permet
+ la mise à jour dynamique des membres du groupe de répartition de
+ charge. Vous pouvez utiliser le gestionnaire de répartiteur pour
+ modifier le facteur de charge d'un membre particulier, ou passer ce
+ dernier en mode hors ligne.
+
Ainsi, pour mettre en oeuvre la gestion du répartiteur de charge,
+ mod_status et mod_proxy_balancer
+ doivent être chargés dans le serveur.
Pour permettre la gestion du répartiteur de charge aux
+ navigateurs appartenant au domaine example.com, ajoutez ces lignes à
+ votre fichier de configuration httpd.conf :
<Location "/balancer-manager"> + SetHandler balancer-manager + Require host example.com +</Location>+ + +
Vous pourrez alors accéder au gestionnaire du répartiteur de
+ charge en utilisant un navigateur web pour afficher la page
+ http://nom.de.votre.serveur/balancer-manager. Notez que
+ pour pouvoir contrôler dynamiquement un membre de groupe de
+ répartition, ce dernier ne doit pas être défini au sein d'une
+ section <Location ...>.
Si l'abonnement s'appuie sur un cookie, vous devez définir le nom
+ de ce cookie dont le contenu précise le serveur d'arrière-plan à
+ utiliser. Pour ce faire, on utilise l'attribut
+ stickysession avec la directive ProxyPass ou ProxySet. Le nom du cookie est
+ sensible à la casse. Le répartiteur extrait le contenu du cookie et
+ recherche un serveur membre dont la route correspond à
+ cette valeur. La route doit aussi être définie dans la directive ProxyPass ou ProxySet. Le cookie peut être défini
+ soit par le serveur d'arrière-plan, soit, comme indiqué dans l'exemple ci-dessus par le serveur web Apache
+ lui-même.
Certains serveurs d'arrière-plan, tels qu'Apache Tomcat,
+ utilisent une forme sensiblement différente de cookie d'abonnement.
+ Tomcat ajoute le nom de l'instance Tomcat à la fin de son
+ identifiant de session, précédé par un point. Ainsi, si le serveur
+ web Apache trouve un point dans la valeur du cookie d'abonnement, il
+ n'utilisera que la partie située après ce point pour
+ rechercher sa route. Pour que Tomcat puisse connaître son nom
+ d'instance, vous devez définir l'attribut jvmRoute dans
+ son fichier de configuration conf/server.xml à la
+ valeur de la route du serveur qui se connecte au Tomcat
+ considéré. Le nom du cookie de session utilisé par Tomcat (et plus
+ généralement par les applications web Java à base de servlets) est
+ JSESSIONID (en majuscules), mais peut être modifié.
La seconde méthode pour implémenter l'abonnement est le codage
+ d'URL. Ici, le serveur web recherche un paramètre dans l'URL de la
+ requête. Le nom du paramètre est spécifié par l'attribut
+ stickysession. Pour trouver un serveur membre, on
+ recherche un serveur dont la route est égale à la valeur
+ du paramètre. Comme il n'est pas aisé d'extraire et de manipuler
+ tous les liens URL contenus dans les réponses, le travail consistant
+ à ajouter les paramètres à chaque lien est généralement effectué par
+ le serveur d'arrière-plan qui génère le contenu. Bien qu'il soit
+ possible dans certains cas d'effectuer ces ajouts au niveau du
+ serveur web via les modules mod_substitute ou
+ mod_sed, cette méthode peut dégrader les
+ performances.
Les standards Java implémentent le codage d'URL de manière
+ sensiblement différente. Ils ajoutent une information de chemin à
+ l'URL en utilisant un point-virgule (;) comme
+ séparateur, puis ajoutent enfin l'identifiant de session. Comme dans
+ le cas des cookies, Apache Tomcat peut insérer la valeur de
+ l'attribut jvmRoute dans cette information de chemin.
+ Pour qu'Apache puisse trouver ce genre d'information de chemin, vous
+ devez définir scolonpathdelim à On dans la
+ directive ProxyPass ou
+ ProxySet.
Enfin, vous pouvez utiliser simultanément les cookies et le codage
+ d'URL en définissant le nom du cookie et le nom du paramètre d'URL
+ séparés par une barre verticale (|) comme dans
+ l'exemple suivant :
ProxyPass "/test" "balancer://mycluster" stickysession=JSESSIONID|jsessionid scolonpathdelim=On +<Proxy "balancer://mycluster"> + BalancerMember "http://192.168.1.50:80" route=node1 + BalancerMember "http://192.168.1.51:80" route=node2 +</Proxy>+ +
Si le cookie et le paramètre de requête fournissent tous deux une + information de route correcte pour la même requête, c'est + l'information en provenance du paramètre de requête qui sera + retenue.
+Si vous êtes confronté à des erreurs d'abonnement, comme la + nécessité pour les utilisateurs de se reconnecter suite à une perte + de session d'application, vous devez tout d'abord vérifier si ceci + n'est pas du à une indisponibilité sporadique des serveurs + d'arrière-plan ou à une erreur de configuration. La présence de + messages d'erreur de type proxy dans le journal des erreurs d'Apache + pourra révéler des problèmes de stabilité au niveau des serveurs + d'arrière-plan.
+Pour contrôler votre configuration, regardez tout d'abord si
+ l'abonnement est à base de cookie ou de codage d'URL. L'étape
+ suivante consiste à enregistrer certaines données dans le journal
+ des accès en utilisant un format
+ de journalisation personnalisé. Les champs intéressants
+ sont les suivants :
%{MONCOOKIE}CMONCOOKIE.
+ Le nom doit correspondre au nom défini par l'attribut
+ stickysession.%{Set-Cookie}o%{BALANCER_SESSION_STICKY}e%{BALANCER_SESSION_ROUTE}e%{BALANCER_WORKER_ROUTE}e%{BALANCER_ROUTE_CHANGED}e1 si la route extraite de la
+ requête est différente de la route du serveur ; autrement dit, le
+ traitement de la requête n'a pas pu être effectué dans le cadre
+ d'une répartition de charge par abonnement.Les pertes de session sont souvent dues à des expirations de + session dont la valeur peut en général être configurée au niveau du + serveur d'arrière-plan.
+Si le niveau de journalisation est défini à debug ou
+ plus, le répartiteur journalise aussi des informations détaillées à
+ propos de l'abonnement dans le journal des erreurs, ce qui facilite
+ la résolution des problèmes d'abonnement. Notez cependant que le
+ volume de journalisation pourra alors s'avérer trop important pour
+ un serveur en production sous forte charge.
Serveur HTTP Apache Version 2.4
+| Description: | Extension de mod_proxy pour le traitement
+des requêtes CONNECT |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_connect_module |
| Fichier Source: | mod_proxy_connect.c |
Pour fonctionner, ce module nécessite le chargement de
+ mod_proxy. Il fournit le support de la méthode HTTP
+ CONNECT. Cette méthode est principalement utilisée pour
+ faire franchir les serveurs mandataires aux requêtes SSL à l'aide
+ d'un tunnel.
Ainsi, pour pouvoir traiter les requêtes CONNECT,
+ mod_proxy et mod_proxy_connect
+ doivent être chargés dans le serveur.
CONNECT est aussi utilisée lorsque le serveur doit envoyer une
+ requête HTTPS via un mandataire. Dans ce cas, le serveur se comporte
+ comme un client CONNECT. Cette fonctionnalité étant fournie par le
+ module mod_proxy, le module
+ mod_proxy_connect n'est dans ce cas pas nécessaire.
N'activez pas la fonctionnalité de mandataire avant d'avoir sécurisé votre serveur. Les + serveurs mandataires ouverts sont dangereux non seulement pour + votre réseau, mais aussi pour l'Internet au sens large.
+mod_proxy_connect enregistre les informations
+ suivantes pour journalisation via le format %{NOMVAR}n
+ dans les directives LogFormat ou ErrorLogFormat :
+
| Description: | Ports autorisés à se CONNECTer à travers le
+mandataire |
|---|---|
| Syntaxe: | AllowCONNECT port[-port]
+[port[-port]] ... |
| Défaut: | AllowCONNECT 443 563 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_connect |
| Compatibilité: | Déplacé depuis mod_proxy à partir
+d'Apache 2.3.5. Plages de ports disponibles depuis Apache 2.3.7. |
La directive AllowCONNECT permet de
+ spécifier une liste de numéros ou de plages de ports auxquels la
+ méthode de mandataire CONNECT pourra se connecter. Les
+ navigateurs récents utilisent cette méthode dans le cas où une
+ connexion https est requise et où le tunneling
+ mandataire sur HTTP est en service.
Par défaut, seuls les ports par défauts https (443)
+ et snews (563) sont pris en compte. Vous pouvez
+ utiliser la directive AllowCONNECT pour
+ outrepasser ces valeurs par défaut et n'autoriser les connexions que
+ vers les ports spécifiés.
Serveur HTTP Apache Version 2.4
+| Description: | Extension à mod_proxy pour le mandatement
+dynamique inverse de masse |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_express_module |
| Fichier Source: | mod_proxy_express.c |
Ce module crée dynamiquement en masse des mandataires inverses en
+ faisant correspondre l'en-tête Host: de la requête HTTP à un nom de
+ serveur et une URL d'arrière-plan stockés dans un fichier DBM. Il
+ est ainsi plus aisé d'utiliser un grand nombre de
+ mandataires inverses sans avoir à modifier la configuration. Il est
+ loin de posséder autant de fonctionnalités que
+ mod_proxy_balancer, qui propose aussi la croissance
+ dynamique, mais il est conçu pour gérer un nombre beaucoup plus important
+ de serveurs d'arrière-plan. Il convient parfaitement pour créer un
+ commutateur HTTP frontal et pour les architectures Microservices.
Pour pouvoir être utilisé, ce module nécessite le chargement de
+ mod_proxy.
N'activez le mandatement que si vous avez sécurisé votre serveur. Les + serveurs mandataires ouverts sont dangereux pour votre réseau, et + dans une plus large mesure pour Internet.
+mod_proxy_balancer. Par contre, il
+ peut constituer une alternative légère et rapide à
+ mod_rewrite lorsque ce dernier utilise la directive
+ RewriteMap et le drapeau [P]
+ pour le mandatement inverse à partir d'une table de correspondances.
+ <VirtualHost *:80> + ServerName front.end.server + ProxyPass "/" "back.end.server:port" + ProxyPassReverse "/" "back.end.server:port" +</VirtualHost>+ + En d'autres termes, l'URL dans son ensemble est ajoutée à l'URL + d'arrière-plan correspondante, tout ceci dans le but de + proposer un commutateur mandataire inverse simple mais rapide. +
| Description: | Chemin du fichier DBM. |
|---|---|
| Syntaxe: | ProxyExpressDBMFile <chemin> |
| Défaut: | None |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_express |
| Compatibilité: | Disponible à partir de la version 2.3.13 d'Apache |
La directive ProxyExpressDBMFile permet de
+ définir le chemin du fichier DBM de correspondance Express. Ce fichier
+ permet de faire correspondre le nom de serveur extrait de l'en-tête
+ Host: de la requête entrante avec une URL d'arrière-plan.
Ce fichier est élaboré à partir d'un fichier texte à l'aide de
+ l'utilitaire httxt2dbm.
+ ##
+ ##express-map.txt:
+ ##
+
+ www1.example.com http://192.168.211.2:8080
+ www2.example.com http://192.168.211.12:8088
+ www3.example.com http://192.168.212.10
+
+ httxt2dbm -i express-map.txt -o emap
+
+ ProxyExpressEnable on
+ ProxyExpressDBMFile emap
+
| Description: | Type de fichier DBM. |
|---|---|
| Syntaxe: | ProxyExpressDBMFile <type> |
| Défaut: | "default" |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_express |
| Compatibilité: | Disponible à partir de la version 2.3.13 d'Apache |
La directive ProxyExpressDBMType permet de
+ définir le type de fichier DBM requis par le module. La valeur par
+ défaut correspond au type DBM par défaut du fichier créé par
+ l'utilitaire httxt2dbm.
Les valeurs possibles sont (mais toutes ne seront pas disponibles à + l'exécution) :
+| Value | Description |
|---|---|
db | Fichiers Berkeley DB |
gdbm | Fichiers GDBM |
ndbm | Fichiers NDBM |
sdbm | Fichiers SDBM (toujours disponible) |
default | type DBM par défaut |
| Description: | Active la fonctionnalité du module. |
|---|---|
| Syntaxe: | ProxyExpressEnable [on|off] |
| Défaut: | off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_express |
| Compatibilité: | Disponible à partir de la version 2.3.13 d'Apache |
La directive ProxyExpressEnable permet
+ d'activer/désactiver le module.
Serveur HTTP Apache Version 2.4
+| Description: | Module fournissant le support de FastCGI à
+mod_proxy |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_fcgi_module |
| Fichier Source: | mod_proxy_fcgi.c |
| Compatibilité: | Disponible depuis la version 2.3 d'Apache |
Pour fonctionner, ce module nécessite le chargement de
+ mod_proxy. Il fournit le support du protocole FastCGI.
Ainsi, pour pouvoir traiter le protocole FastCGI,
+ mod_proxy et mod_proxy_fcgi
+ doivent être chargés dans le serveur.
A la différence de mod_fcgid et mod_fastcgi,
+ mod_proxy_fcgi n'est pas en mesure de démarrer le
+ processus de l'application ; fcgistarter est
+ fourni à cet effet sur certaines plateformes. Le framework
+ applicatif FastCGI utilisé peut aussi fournir la gestion des
+ processus ou des lancements de programmes externes.
N'activez pas la fonctionnalité de mandataire avant d'avoir sécurisé votre serveur. Les + serveurs mandataires ouverts sont dangereux non seulement pour + votre réseau, mais aussi pour l'Internet au sens large.
+Pour que ces exemples fonctionnent, vous ne devez pas oublier
+ d'activer mod_proxy et
+ mod_proxy_fcgi.
ProxyPass "/mon_appli/" "fcgi://localhost:4000/"+
mod_proxy_fcgi interdisant par défaut la
+ réutilisation des connexions, lorsqu'une requête a été traitée, la
+ connexion ne sera pas maintenue ouverte par le processus enfant
+ httpd, et ne sera donc pas réutilisée. Cependant, si l'application
+ FastCGI supporte les connexions httpd simultanées, vous pouvez opter
+ pour la réutilisation des connexions comme dans l'exemple suivant :
ProxyPass "/myapp/" "fcgi://localhost:4000/" enablereuse=on+
Il faut garder à l'esprit que PHP-FPM (en février 2018) utilise un modèle
+ du style prefork ; autrement dit, chacun de ses processus de travail ne peut
+ gérer qu'une connexion à la fois.
Par défaut et lorsqu'il est
+ configuré avec enablereuse=on et lorsqu'un MPM à base de
+ threads est utilisé (comme worker ou
+ event), mod_proxy autorise un jeu de ThreadsPerChild connexions vers le serveur
+ d'arrière-plan pour chaque processus httpd, et par conséquent, il faut
+ prêter une attention particulière aux situations suivantes :
MaxRequestWorkers.mod_http2 est implémenté, il y a des threads de travail
+ h2 additionnels qui peuvent forcer la création de connexions
+ supplémentaires vers le serveur d'arrière-plan. Le nombre total de
+ connexions que contiennent les jeux de connexions peut alors dépasser
+ MaxRequestWorkers.Le nombre maximum de processus de travail PHP-FPM doit être défini + judicieusement car il est possible qu'ils finissent par rester dans l'état + occupé ("busy") pour ne gérer que des connexions persistantes inactives, + sans avoir la possibilité d'en établir de nouvelles ; ce qui se traduira + pour l'utilisateur final par une pile de "HTTP request timeouts".
+Dans l'exemple suivant, l'URI de la requête est transmis en tant + que chemin du système de fichiers pour l'exécution du démon PHP-FPM. + L'URL de la requête est implicitement ajoutée au second paramètre. + PHP-FPM est à l'écoute de l'hôte et du port qui + suivent fcgi://. La conservation/réutilisation des connexions est activée.
+ProxyPassMatch "^/myapp/.*\.php(/.*)?$" "fcgi://localhost:9000/var/www/" enablereuse=on+
Dans l'exemple suivant, l'URI de la requête est transmis en tant + que chemin du système de fichiers pour l'exécution du démon PHP-FPM. + Dans ce cas cependant, PHP-FPM est à l'écoute d'un socket de domaine + unix (UDS). Cette fonctionnalité est disponible à partir de la + version 2.4.9. Avec cette syntaxe, si un nom d'hôte et un port sont + ajoutés après fcgi://, ils seront ignorés.
+ProxyPassMatch "^/(.*\.php(/.*)?)$" "unix:/var/run/php5-fpm.sock|fcgi://localhost/var/www/"+
La passerelle à répartition de charge nécessite le chargement du
+ module mod_proxy_balancer et d'au moins un module
+ fournissant un algorithme de répartition de charge, comme
+ mod_lbmethod_byrequests en plus des modules
+ déjà cités. mod_lbmethod_byrequests est le module
+ par défaut et sera utilisé dans cet exemple de configuration.
ProxyPass "/myapp/" "balancer://myappcluster/" +<Proxy "balancer://myappcluster/"> + BalancerMember "fcgi://localhost:4000" + BalancerMember "fcgi://localhost:4001" +</Proxy>+
Vous pouvez aussi forcer le traitement d'une requête en tant que + requête de mandataire inverse en créant un court-circuiteur de + gestionnaire approprié. Dans l'exemple ci-dessous, toutes les + requêtes pour des scripts PHP seront transmises au serveur FastCGI + spécifié par mandat inverse. Cette fonctionnalité est disponible à + partir de la version 2.4.10 du serveur HTTP Apache. Pour des raisons + de performances, il est recommandé de définir un worker (configuration d'un + mandataire) représentant le même serveur fcgi:// d'arrière-plan. + Avec cette configuration, il est possible d'effectuer une + correspondance directe entre l'URI et le chemin du fichier sur le + serveur, et le chemin local du fichier sera alors transmis au serveur + d'arrière-plan. Lorsque FastCGI est configuré ainsi, le serveur est + en mesure de calculer le PATH_INFO le plus approprié. +
+<FilesMatch "\.php$"> + # Note : la seule partie variable est /path/to/app.sock + SetHandler "proxy:unix:/path/to/app.sock|fcgi://localhost/" +</FilesMatch> + # Définition d'une configuration de mandataire qui convient. + # La partie qui est mise en correspondance avec la valeur de + # SetHandler est la partie qui suit le "pipe". Si vous devez faire + # une distinction, "localhost" peut être changé en un nom de serveur + # unique. + <Proxy "fcgi://localhost/" enablereuse=on max=10> + </Proxy> + +<FilesMatch ...> + SetHandler "proxy:fcgi://localhost:9000" +</FilesMatch> + +<FilesMatch ...> + SetHandler "proxy:balancer://myappcluster/" +</FilesMatch>+
En plus des directives de configuration qui contrôlent le
+ comportement de mod_proxy, de nombreuses
+ variables d'environnement permettent de piloter le
+ fournisseur du protocole FCGI :
ProxyPass ou ProxyPassMatch,
+ mod_proxy_fcgi ne définit
+ pas la variable d'environnement PATH_INFO,
+ ce qui permet au serveur FCGI d'arrière-plan de déterminer
+ correctement SCRIPT_NAME et Script-URI, et
+ de se conformer à la section 3.3 de la RFC 3875. Si au contraire
+ vous avez souhaitez que mod_proxy_fcgi génère une
+ "estimation la plus exacte possible" de PATH_INFO,
+ définissez la variable d'environnement
+ proxy-fcgi-pathinfo. Ceci peut servir de
+ contournement pour une bogue présente dans certaines
+ implémentations de FCGI. Cette variable peut être
+ multivaluée afin de pouvoir choisir la valeur la plus appropriée
+ (versions 2.4.11 et supérieures) :
+ | Description: | Spécifie le type de l'application FastCGI d'arrière-plan |
|---|---|
| Syntaxe: | ProxyFCGIBackendType FPM|GENERIC |
| Défaut: | ProxyFCGIBackendType FPM |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_proxy_fcgi |
| Compatibilité: | Disponible à partir de la version 2.4.26 du serveur HTTP Apache |
Cette directive permet de spécifier le type de l'application FastCGI +d'arrière-plan. Certains serveurs FastCGI, comme PHP-FPM, utilisent de manière +historique des variables d'environnement exotiques pour identifier le type du +serveur mandataire utilisé. Définissez cette directive à "GENERIC" si votre +application n'est pas de type PHP-FPM et n'interpréter pas correctement des +variables d'environnement comme SCRIPT_FILENAME ou PATH_TRANSLATED telles +qu'elles sont définies par le serveur.
+ +SCRIPT_FILENAME est un exemple de valeur modifiée par la définition de cette
+directive. Historiquement, lorsqu'on utilisait le module
+mod_proxy_fcgi, SCRIPT_FILENAME était préfixé par la chaîne
+"proxy:fcgi://". C'est cette variable que lisent certaines applications FastCGI
+génériques en tant que valeur en entrée pour leur script ; cependant, PHP-FPM
+peut supprimer le préfixe, puis garder en mémoire qu'il communique avec Apache.
+Avec les versions 2.4.21 à 2.4.25, ce préfixe était automatiquement supprimé par
+le serveur, empêchant ainsi PHP-FPM de détecter et interopérer avec Apache dans
+certains scénarios.
| Description: | Permet d'adapter la valeur des variables envoyées aux serveurs +FastCGI |
|---|---|
| Syntaxe: | ProxyFCGISetEnvIf conditional-expression
+ [!]environment-variable-name
+ [value-expression] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_proxy_fcgi |
| Compatibilité: | Disponible à partir de la version 2.4.26 du serveur HTTP Apache. |
Juste avant la transmission d'une requête au serveur FastCGI configuré, le +coeur du programme du serveur web définit un certain nombre de variables +d'environnement en fonction de certains détails de la requête considérée. Les +programmes FastCGI utilisent souvent ces variables comme données en entrée afin +de déterminer quels scripts sous-jacents ils vont exécuter, ou quelles données +en sortie doivent être produites.
+Voici quelques exemples de variables d'environnement importantes :
+Cette directive permet de passer outre les variables d'environnement +ci-dessus, entre autres. Elle est évaluée après la définition de la valeur +initiale de ces variables ; elle peuvent donc être utilisées comme entrées dans +les expressions définissants les conditions et les valeurs.
+Syntaxe des paramètres :
+# Une modification basique, inconditionnelle
+ProxyFCGISetEnvIf "true" PATH_INFO "/example"
+
+# Utilisation d'une variable d'environnement pour spécifier la nouvelle valeur
+ProxyFCGISetEnvIf "true" PATH_INFO "%{reqenv:SCRIPT_NAME}"
+
+# Utilisation de captures dans la condition et de références arrières dans la
+# nouvelle valeur
+ProxyFCGISetEnvIf "reqenv('PATH_TRANSLATED') =~ m#(/.*prefix)(\d+)(.*)#" PATH_TRANSLATED "$1$3"
+VARIABLE,
+ ce qui l'empêche d'être envoyée au serveur FastCGI :
+
+ ProxyFCGISetEnvIf true !VARIABLE+ + + La ligne suivante, quant à elle, efface la valeur de la variable +
VARIABLE en lui affectant la chaîne vide ; cette variable
+ VARIABLE sera alors tout de même envoyée au serveur FastCGI :
+
+ ProxyFCGISetEnvIf true VARIABLE+ + + La spécification CGI/1.1 ne fait pas de + distinction entre une variable contenant une chaîne vide et une variable qui + n'existe pas. De nombreuses implémentations CGI et FastCGI font cependant + cette distinction (ou permettent aux scripts de la faire). Le choix de celle + que vous allez utiliser dépend de votre implémentation et de la raison qui + vous pousse à modifier cette variable. +
Serveur HTTP Apache Version 2.4
+| Description: | Module fournissant le support des processus externes fdpass
+à mod_proxy |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_fdpass_module |
| Fichier Source: | mod_proxy_fdpass.c |
| Compatibilité: | Disponible pour unix depuis la version 2.3 +d'Apache |
Pour fonctionner, ce module nécessite le chargement de
+ mod_proxy. Il permet le passage de la socket du client
+ vers un autre processus.
mod_proxy_fdpass utilise la capacité des sockets de
+ domaine AF_UNIX à transmettre un
+ descripteur de fichier ouvert afin de permettre à un autre
+ processus de terminer le traitement de la requête.
+
Le module possède une interface de fournisseur
+ proxy_fdpass_flusher qui permet éventuellement à un
+ autre module d'envoyer les en-têtes de la réponse, ou même le début
+ du corps de la réponse. Le fournisseur par défaut flush désactive la
+ persistence, et envoie les en-têtes de la réponse, laissant le soin
+ au processus externe d'envoyer le corps de la réponse.
Pour utiliser un autre fournisseur, vous devez spécifier le paramètre
+ flusher de la directive ProxyPass.
+
À l'heure actuelle, la seule donnée transmise au processus
+ externe est la socket du client. Pour recevoir une socket client,
+ appelez recvfrom avec une structure struct cmsghdr allouée. Les versions
+ futures de ce module pourront transmettre d'autres données que le
+ socket client.
+
Ce module ne fournit aucune directive.
+Serveur HTTP Apache Version 2.4
+| Description: | Module fournissant le support FTP à
+mod_proxy |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_ftp_module |
| Fichier Source: | mod_proxy_ftp.c |
Pour pouvoir fonctionner, ce module requiert le
+ chargement de mod_proxy. Il fournit le support du
+ mandatement des sites FTP. Notez que le support FTP est
+ actuellement limité à la méthode GET.
Ainsi, pour pouvoir traiter les requêtes FTP mandatées,
+ mod_proxy, et mod_proxy_ftp
+ doivent être chargés dans le serveur.
N'activez pas la fonctionnalité de mandataire avant d'avoir sécurisé votre serveur. Les + serveurs mandataires ouverts sont dangereux non seulement pour + votre réseau, mais aussi pour l'Internet au sens large.
+ Pourquoi les fichiers du type
+ xxx ne sont-ils pas téléchargeables par FTP ? Comment puis-je forcer le téléchargement
+ FTP en mode ASCII du fichier xxx ? Comment puis-je effectuer un
+ chargement FTP ? Comment puis-je accéder par FTP à
+ des fichiers situés en dehors de mon répertoire home ? Comment puis-je dissimuler le mot de
+ passe FTP apparaissant en clair dans la ligne d'URL de mon
+ navigateur ? Pourquoi reçois-je un listing de
+ fichiers alors que j'ai demandé le téléchargement d'un fichier
+ ?Ce type particulier de fichier n'est probablement pas défini en
+ temps que application/octet-stream dans le fichier
+ de configuration mime.types de votre mandataire. La ligne suivante
+ peut y remédier :
application/octet-stream bin dms lha lzh exe class tgz taz
Vous pouvez aussi utiliser la directive ForceType pour définir par défaut tous les types
+ de fichiers en tant que fichiers binaires :
ForceType application/octet-stream+
Dans les rares siruations où vous devez télécharger un fichier
+ spécifique en utilisant la méthode de transfert FTP
+ ASCII (alors que le mode transfert par défaut est
+ binary), vous pouvez modifier le mode de transfert de
+ mod_proxy en suffixant la requête avec
+ ;type=a pour forcer un transfert en mode ASCII (les
+ listings de répertoires FTP sont cependant quant à eux transmis en
+ mode ASCII).
Actuellement, seule la méthode GET est supportée pour FTP dans
+ mod_proxy. Vous pouvez par contre utiliser le chargement HTTP (POST
+ or PUT) via un mandataire Apache.
Un URI FTP est considéré comme relatif au répertoire home de
+ l'utilisateur connecté. Hélas, vous ne pouvez pas utiliser /../
+ pour atteindre des répertoires de niveau supérieur, car les points
+ sont interprétés par le navigateur et ne sont donc pas vraiment
+ envoyés au serveur FTP. Pour traiter ce problème, une méthode
+ nommée Squid %2f hack a été implémentée dans le
+ mandataire FTP Apache ; cette solution est aussi utilisée par
+ d'autres serveurs mandataires courants comme le Cache mandataire Squid. En
+ préfixant par /%2f le chemin de votre requête, vous
+ pouvez faire en sorte que le mandataire modifie le répertoire FTP
+ racine en / (au lieu du répertoire home). Par
+ exemple, pour extraire le fichier /etc/motd, vous
+ pourriez utiliser l'URL :
+ ftp://utilisateur@serveur/%2f/etc/motd
+
Apache utilise différentes stratégies pour effectuer une + connexion à un serveur FTP à l'aide d'un nom d'utilisateur et d'un + mot de passe. En l'absence de nom d'utilisateur et de mot de passe + dans l'URL, Apache tente une connexion anonyme auprès du serveur + FTP comme suit :
+ +
+ utilisateur : anonymous
+ mot de passe : apache-proxy@
+
Ceci fonctionne avec tous les serveurs FTP courants configurés + pour accepter les connexions anonymes.
+ +Pour une connexion personnalisée avec un nom d'utilisateur + spécifique, vous pouvez intégrer ce dernier dans l'URL comme suit + :
+ +
+ ftp://nom-utilisateur@serveur/mon-fichier
+
Si le serveur FTP demande un mot de passe pour ce nom
+ d'utilisateur (ce qu'il est censé faire), Apache va renvoyer au
+ client une réponse 401 (Autorisation requise), ce qui
+ fera afficher au navigateur une boîte de dialogue utilisateur/mot
+ de passe. Une fois le mot de passe saisi, la connexion est tentée
+ à nouveau, et si elle réussit, la ressource demandée est
+ présentée. L'avantage de cette procédure réside dans le fait que
+ votre navigateur n'affiche pas le mot de passe en clair, ce qu'il
+ aurait fait si vous aviez utilisé l'URL :
+ ftp://nom-utilisateur:mot-de-passe@serveur/mon-fichier
+
Le mot de passe transmis de cette manière n'est pas chiffré + lorsqu'il est envoyé. Il transite entre votre navigateur et le + serveur mandataire Apache sous la forme d'une chaîne de texte en + clair codée en base64, et entre le mandataire Apache et le + serveur FTP en texte pur. Vous devez par conséquent réfléchir à + deux fois avant d'accéder à votre serveur FTP via HTTP (et d'une + manière générale avant d'accéder à vos fichiers personnels via + FTP !) sur des canaux non sécurisés, car des oreilles + indiscrètes pourraient intercepter votre mot de passe au cours + de son transfert.
+Apache examine l'URL de la requête afin de permettre la + navigation dans les répertoires d'un serveur FTP ainsi que le + téléchargement de fichiers. Si elle ressemble à un répertoire, ou + contient des caractères génériques ("*?[{~"), alors Apache + considère que c'est un listing qui est demandé, et non un + téléchargement.
+Vous pouvez désactiver le traitement spécial des noms contenant
+ des caractères génériques. Voir à cet effet la directive
+ ProxyFtpListOnWildcard.
+
| Description: | Définit le jeu de caractères des listings FTP +mandatés |
|---|---|
| Syntaxe: | ProxyFtpDirCharset character_set |
| Défaut: | ProxyFtpDirCharset ISO-8859-1 |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy_ftp |
| Compatibilité: | Disponible à partir de la version 2.2.7 du serveur HTTP Apache. Déplacé
+depuis mod_proxy à partir de la version 2.3.5 |
La directive ProxyFtpDirCharset permet de
+ définir le jeu de caractères à utiliser pour les listings FTP en
+ HTML générés par mod_proxy_ftp.
| Description: | Les caractères génériques dans les noms de fichiers +doivent-ils être échappés lorsqu'ils sont envoyés au serveur FTP ? |
|---|---|
| Syntaxe: | ProxyFtpEscapeWildcards on|off |
| Défaut: | ProxyFtpEscapeWildcards on |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy_ftp |
| Compatibilité: | Disponible depuis la version 2.3.3 du serveur HTTP Apache |
La directive ProxyFtpEscapeWildcards permet
+ de déterminer si les caractères génériques ("*?[{~") que contiennent
+ les noms de fichiers demandés doivent être échappés pas un slash
+ inversé avant d'être envoyés au serveur FTP. Il s'agit du comportement
+ par défaut ; cependant, de nombreux serveurs FTP n'ont aucune
+ connaissance de la notion d'échappement, et tentent de servir le
+ fichier demandé sous sa forme littérale, en incluant les slashes
+ inversés dans son nom.
Définissez cette directive à "off" pour permettre le + téléchargement de fichiers dont les noms contiennent des caractères + génériques depuis des serveurs FTP qui ne connaissent pas + l'échappement des caractères génériques.
+ +| Description: | Les caractères génériques dans les noms de fichiers +demandés doivent-ils déclencher l'affichage d'un listing ? |
|---|---|
| Syntaxe: | ProxyFtpListOnWildcard on|off |
| Défaut: | ProxyFtpListOnWildcard on |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy_ftp |
| Compatibilité: | Disponible depuis la version 2.3.3 du serveur HTTP Apache |
La directive ProxyFtpListOnWildcard permet
+ de déterminer si les caractères génériques ("*?[{~") que contiennent
+ les noms de fichiers demandés provoquent l'affichage d'un listing de
+ fichiers par mod_proxy_ftp au lieu de télécharger un
+ fichier. Il s'agit de leur comportement par défaut (valeur on).
Définissez cette directive à "off" pour permettre le téléchargement de + fichiers même si leur nom contient des caractères génériques.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Check up dynamique des membres du groupe de répartition de charge
+(équipiers) pour mod_proxy |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_hcheck_module |
| Fichier Source: | mod_proxy_hcheck.c |
| Compatibilité: | Disponible à partir de la version 2.4.21 du serveur HTTP Apache |
Ce module permet d'effectuer un check up dynamique des membres du groupe + de répartition de charge (équipiers). Ce check up peut être activé pour un + ou plusieurs équipiers et il est indépendant des requêtes de mandataire + inverse proprement dites.
+ +Pour fonctionner, ce module nécessite le chargement préalable de
+ mod_watchdog.
Le mécanisme de check up est activé via l'utilisation de paramètres
+ supplémentaires de la directive BalancerMember configurés de manière standard
+ via la directive ProxyPass :
Ce module définit un nouveau drapeau d'état status pour BalancerMember :
+ "C". Lorsque l'équipier est mis hors service suite à un
+ disfonctionnement déterminé par le module de check up, ce drapeau est activé
+ et peut être lu (et modifié) via le balancer-manager.
| Paramètre | +Défaut | +Description | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| hcmethod | +None | +Aucun check up dynamique n'est effectué. Les choix possibles sont :
+
| ||||||||||||||||||||||||
| hcpasses | +1 | +Nombre de check up à passer avec succès avant de remettre en service + l'équipier | ||||||||||||||||||||||||
| hcfails | +1 | +Nombre de check up échoués avant mettre hors service l'équipier | ||||||||||||||||||||||||
| hcinterval | +30 | +Intervalle entre deux check up en secondes (par défaut effectué + toutes les 30 secondes) | ||||||||||||||||||||||||
| hcuri | ++ | URI supplémentaire à ajouter à l'URL de l'équipier pour le check up. | ||||||||||||||||||||||||
| hctemplate | ++ | Nom du modèle créé via ProxyHCTemplate à
+ utiliser pour définir les paramètres de check up de cet équipier | ||||||||||||||||||||||||
| hcexpr | ++ | Nom de l'expression créée via ProxyHCExpr
+ utilisée pour analyser les en-têtes de la réponse du check up.+ Si ce paramètre est absent, un état HTTP de 2xx à 3xx est + interprété comme un check up réussi. | ||||||||||||||||||||||||
ProxyHCExpr ProxyHCTemplate ProxyHCTPsizeL'exemple suivant montre comment configurer le check up pour différents + serveurs d'arrière-plan :
+ + +ProxyHCExpr ok234 {%{REQUEST_STATUS} =~ /^[234]/}
+ProxyHCExpr gdown {%{REQUEST_STATUS} =~ /^[5]/}
+ProxyHCExpr in_maint {hc('body') !~ /Under maintenance/}
+
+<Proxy balancer://foo>
+ BalancerMember http://www.example.com/ hcmethod=GET hcexpr=in_maint hcuri=/status.php
+ BalancerMember http://www2.example.com/ hcmethod=HEAD hcexpr=ok234 hcinterval=10
+ BalancerMember http://www3.example.com/ hcmethod=TCP hcinterval=5 hcpasses=2 hcfails=3
+ BalancerMember http://www4.example.com/
+</Proxy>
+
+ProxyPass "/" "balancer://foo"
+ProxyPassReverse "/" "balancer://foo"
+
+
+Dans ce scénario, on teste l'équipier http://www.example.com/ en lui
+envoyant une requête GET /status.php et en regardant si la réponse
+contient la chaîne Under maintenance. Si c'est le cas, le check up est
+considéré comme ayant échoué et l'équipier est mis hors service. Ce check up
+dynamique est effectué toutes les 30 secondes, ce qui correspond à la valeur par
+défaut.
On teste l'équipier http://www2.example.com/ en lui envoyant
+simplement une requête HEAD toutes les 10 secondes et en vérifiant
+que la réponse HTTP est bien un code d'état de 2xx, 3xx ou 4xx. On teste
+l'équipier http://www3.example.com/ en vérifiant simplement toutes
+les 5 secondes que le socket vers ce serveur est bien opérationnel. Si ce
+serveur est marqué "hors service", il lui faudra 2 check up réussis pour être
+réactivé et participer à nouveau à la répartition de charge. Si à ce moment-là
+il échoue à 3 check up successifs, il sera à nouveau mis hors service. Enfin,
+l'équipier http://www4.example.com/ ne fait l'objet d'aucun check
+up.
| Description: | Crée et nomme une expression conditionnelle à utiliser pour +déterminer la santé d'un serveur d'arrière-plan en fonction de sa valeur |
|---|---|
| Syntaxe: | ProxyHCExpr name {ap_expr expression} |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_hcheck |
La directive ProxyHCExpr permet de créer et nommer
+ une expression conditionnelle dont la valeur calculée en fonction des
+ en-têtes de la réponse du serveur d'arrière-plan permettra d'évaluer la
+ santé de ce dernier. Cette expression nommée peut alors être assignée aux
+ serveurs d'arrière-plan via le paramètre hcexpr.
ProxyHCExpr ok234 {%{REQUEST_STATUS} =~ /^[234]/}
+ProxyPass "/apps" "balancer://foo"
+
+<Proxy balancer://foo>
+ BalancerMember http://www2.example.com/ hcmethod=HEAD hcexpr=ok234 hcinterval=10
+</Proxy>
+Si l'on utilise une méthode de check up (par exemple GET)
+ qui génère un corps de réponse, ce corps peut lui-même être ausculté via
+ ap_expr en utilisant la fonction associée aux expressions
+ hc() spécifique à ce module.
Dans l'exemple suivant, on envoie une requête GET au serveur
+ d'arrière-plan, et si le corps de la réponse contient la chaîne Under
+ maintenance, ce serveur d'arrière-plan est mis hors service.
ProxyHCExpr in_maint {hc('body') !~ /Under maintenance/}
+ProxyPass "/apps" "balancer://foo"
+
+<Proxy balancer://foo>
+ BalancerMember http://www.example.com/ hcexpr=in_maint hcmethod=get hcuri=/status.php
+</Proxy>
+NOTE: Comme le corps de la réponse peut être assez grand, il est + recommandé de privilégier un check up basé sur les codes d'état.
+ +| Description: | Crée et nomme un modèle permettant de définir différents +paramètres de check up |
|---|---|
| Syntaxe: | ProxyHCTemplate name parameter=setting [...] |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_proxy_hcheck |
La directive ProxyHCTemplate permet de créer et
+ nommer un modèle de paramètres de check up qui peut alors être assigné aux
+ équipiers via le paramètre hctemplate.
ProxyHCTemplate tcp5 hcmethod=tcp hcinterval=5 +ProxyPass "/apps" "balancer://foo" + +<Proxy balancer://foo> + BalancerMember http://www2.example.com/ hctemplate=tcp5 +</Proxy>+
| Description: | Définit la taille totale, pour l'ensemble du +serveur, du jeu de threads utilisé pour le check up des +équipiers |
|---|---|
| Syntaxe: | ProxyHCTPsize size |
| Défaut: | ProxyHCTPsize 16 |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_proxy_hcheck |
Si Apache httpd et APR ont été compilés avec le support des threads, le
+ module de check up peut confier ce travail à un jeu de threads associé au
+ processus Watchdog, ce qui permet l'exécution des check up en parallèle. La
+ directive ProxyHCTPsize permet de déterminer la
+ taille de ce jeu de threads. Une valeur de 0 signifie qu'aucun
+ jeu de threads ne sera utilisé, et le check up des différents équipiers sera
+ alors effectué séquentiellement.
ProxyHCTPsize 32+
Serveur HTTP Apache Version 2.4
+| Description: | Réécrit les liens HTML afin de s'assurer qu'ils soient bien +adressables depuis les réseaux des clients dans un contexte de +mandataire. |
|---|---|
| Statut: | Base |
| Identificateur de Module: | proxy_html_module |
| Fichier Source: | mod_proxy_html.c |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.x antérieures |
Ce module fournit un filtre en sortie permettant de réécrire les liens
+ HTML dans un contexte de mandataire, afin de s'assurer que ces liens
+ fonctionnent pour les utilisateurs en dehors du mandataire. Il accomplit la
+ même tâche que la directive ProxyPassReverse d'Apache accomplit pour les
+ en-têtes HTTP, et fait partie des composants essentiels d'un mandataire
+ inverse.
Par exemple, si une entreprise possède un serveur d'applications
+nommé appserver.example.com qui n'est visible que depuis son réseau
+interne, et un serveur web public www.example.com, il peut
+être souhaitable de fournir une passerelle vers le serveur d'application
+à l'adresse http://www.example.com/appserver/. Lorsque le
+serveur d'applications présente un lien vers lui-même, ce lien doit être
+réécrit pour fonctionner à travers la passerelle. A cet effet,
+mod_proxy_html permet de réécrire <a
+href="http://appserver.example.com/foo/bar.html">foobar</a>
+en <a
+href="http://www.example.com/appserver/foo/bar.html">foobar</a>,
+ce qui permet de rendre le serveur d'applications accessible depuis
+l'extérieur.
mod_proxy_html a été développé à l'origine à WebÞing, dont la documentation +détaillée pourra s'avérer utile aux utilisateurs.
+ ProxyHTMLBufSize ProxyHTMLCharsetOut ProxyHTMLDocType ProxyHTMLEnable ProxyHTMLEvents ProxyHTMLExtended ProxyHTMLFixups ProxyHTMLInterp ProxyHTMLLinks ProxyHTMLMeta ProxyHTMLStripComments ProxyHTMLURLMap| Description: | Définit l'incrément de la taille du tampon, ainsi que sa +taille initiale, pour la mise en +tampon des scripts en ligne et des feuilles de style. |
|---|---|
| Syntaxe: | ProxyHTMLBufSize nb-octets |
| Défaut: | ProxyHTMLBufSize 8192 |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_proxy_html |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.x antérieures. |
Pour pouvoir interpréter du contenu non HTML (feuilles de style et
+scripts) embarqué dans des documents HTML, mod_proxy_html doit
+le lire et le mémoriser en entier dans un
+tampon. Ce tampon devra être étendu autant que nécessaire afin de
+pouvoir accueillir le plus grand script ou la plus grande feuille de
+style de la page, selon un incrément de nb-octets que cette
+directive permet de définir.
La valeur par défaut est 8192 et sera suffisante pour la plupart des +pages. Cependant, si vous savez que vous allez mandater des +pages contenant des feuilles de style et/ou scripts plus grands que 8k +(cette taille s'entend pour chaque script ou feuilles de style, non pour +leur ensemble), il sera plus efficace de définir une taille de +tampon initiale plus grande afin d'éviter d'avoir à le redimensionner +dynamiquement au cours du traitement d'une requête. +
+ +| Description: | Spécifie un jeu de caractères pour la sortie de +mod_proxy_html. |
|---|---|
| Syntaxe: | ProxyHTMLCharsetOut jeu-de-caractères | * |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_proxy_html |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.x antérieures. |
Cette directive permet de spécifier un jeu de caractères pour la
+sortie de mod_proxy_html. Elle ne devrait jamais être utilisée, car tout
+changement par rapport à la valeur par défaut UTF-8 (Unicode -
+utilisé en interne par libxml2) induit une charge supplémentaire de
+traitement. La définition spéciale ProxyHTMLCharsetOut *
+permet de générer une sortie qui utilisera le même encodage que
+l'entrée.
Notez que tout ceci ne fonctionne que si le module
+mod_xml2enc est chargé.
| Description: | Définit une déclaration de type de document HTML ou XHTML. |
|---|---|
| Syntaxe: | ProxyHTMLDocType HTML|XHTML [Legacy] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_proxy_html |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.x antérieures. |
Avec la première syntaxe, les documents seront déclarés de type HTML
+4.01 ou XHTML 1.0 selon l'option spécifiée. Cette option détermine aussi
+si la syntaxe utilisée en sortie est HTML ou XHTML. Notez que le format
+des documents en provenance du serveur d'arrière-plan n'est pas
+important, car l'interpréteur le détectera automatiquement. Si le
+second argument optionnel est défini à Legacy, les documents seront
+déclarés de type "Transitional" ; cette option peut être nécessaire si
+vous mandatez du contenu datant d'avant 1998, ou si vous travaillez avec
+des outils de création/publication déficients.
Avec la deuxième syntaxe, cette directive vous permet d'insérer votre +propre FPI (Formal Public Identifier). Le second argument optionnel +détermine si la syntaxe utilisée sera SGML/HTML ou XML/XHTML.
+Par défaut, aucun FPI n'est inséré, étant donné qu'il vaut mieux pas +de FPI du tout qu'un FPI bogué. Si par contre votre serveur d'arrière-plan +génère du contenu HTML ou XHTML correct, vous pouvez définir cette +directive en conséquence.
+Avec la première syntaxe, mod_proxy_html va aussi mettre le code HTML
+en conformité avec le standard spécifié. Il ne pourra pas corriger
+toutes les erreurs, mais il va supprimer les éléments et attributs non
+conformes. Il peut aussi journaliser les autres erreurs si la directive
+LogLevel est définie à
+Debug.
| Description: | Permet d'activer/désactiver le filtre proxy_html. |
|---|---|
| Syntaxe: | ProxyHTMLEnable On|Off |
| Défaut: | ProxyHTMLEnable Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_proxy_html |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.x antérieures. |
Cette directive est un simple commutateur permettant
+ d'activer/désactiver le filtre proxy_html. Si
+ mod_xml2enc est chargé, elle va aussi activer
+ automatiquement le support de l'internationalisation.
Notez que le filtre proxy_html s'agira que si les données sont de + type HTML (Content-Type text/html ou application/xhtml+xml), et si + elles passent par un mandataire. Vous pouvez passer outre ces + contraintes (à vos risques et périls) en définissant la variable + d'environnement PROXY_HTML_FORCE.
+ +| Description: | Spécifie les attributs à traiter comme des évènements de +type scripting. |
|---|---|
| Syntaxe: | ProxyHTMLEvents attribut [attribut ...] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_proxy_html |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.x antérieures. |
Cette directive permet de spécifier un ou plusieurs attributs à
+traiter comme
+des évènements de type scripting et de leur appliquer les règles
+ProxyHTMLURLMap lorsqu'elles ont été définies. Vous
+pouvez spécifier un nombre quelconque d'attributs dans une ou plusieurs
+directives ProxyHTMLEvents.
Normalement, cette directive est définie globalement. Si vous
+définissez ProxyHTMLEvents à plusieurs niveaux, certains niveaux
+l'emportant sur d'autres, vous devrez spécifier un jeu complet
+d'évènements pour chaque niveau.
Le fichier proxy-html.conf fournit une configuration par +défaut et définit les évènements selon les standards +HTML 4 et XHTML 1.
+ +| Description: | Détermine si l'on doit corriger les liens dans les scripts +en ligne, les feuilles de style et les évènements de type scripting. |
|---|---|
| Syntaxe: | ProxyHTMLExtended On|Off |
| Défaut: | ProxyHTMLExtended Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_proxy_html |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.x antérieures. |
Si cette directive est définie à Off, les liens HTML
+sont réécrits en fonction des directives
+ProxyHTMLURLMap, mais les liens qui apparaissent
+dans le code Javascript et les feuilles de style restent inchangés.
Si elle est définie à On, tous les évènements de type
+scripting (définis par la directive
+ProxyHTMLEvents) et les scripts inclus ou les
+feuilles de style sont aussi
+traités par les règles ProxyHTMLURLMap, en
+fonction des drapeaux définis pour chacune d'entre elles. Ne définissez
+cette directive à On qu'en cas de nécessité absolue, car la
+charge supplémentaire induite impacte les performances.
Vous devez aussi prêter attention aux modèles de comparaison, car
+l'interpréteur n'a aucune notion de la forme que pourrait prendre une URL dans un
+script embarqué ou une feuille de style. En particulier, la comparaison
+étendus du caractère / a de fortes chances d'induire des
+correspondances erronées.
| Description: | Corrige les erreurs HTML simples. |
|---|---|
| Syntaxe: | ProxyHTMLFixups [lowercase] [dospath] [reset] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_proxy_html |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.x antérieures. |
Cette directive accepte un à trois arguments parmi les suivants :
+lowercaseLes Urls sont réécrites en minusculesdospathLes slashes inversés dans les URLs sont
+remplacés par des slashes directs.resetAnnule toute option définie à un niveau supérieur
+dans la configurationCette directive doit être utilisée avec prudence. Elle peut corriger +certaines erreurs de création, mais risque aussi de modifier par erreur +des liens corrects. Ne l'utilisez que si vous êtes sûr que le serveur +d'arrière-plan est déficient.
+ +| Description: | Active la réinterprétation des règles
+ProxyHTMLURLMap pour chaque requête. |
|---|---|
| Syntaxe: | ProxyHTMLInterp On|Off |
| Défaut: | ProxyHTMLInterp Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_proxy_html |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.x antérieures. |
Cette directive permet d'activer le réinterprétation pour chaque
+ requête des modèles source et cible de la directive
+ ProxyHTMLURLMap.
Si la réinterprétation n'est pas activée, toutes les règles sont + précompilées au démarrage du serveur. Si elle est activée, les + règles doivent être recompilées pour chaque requête, ce qui induit + une charge de traitement supplémentaire. Elle ne doit donc être activée que si + cela s'avère nécessaire.
+ +| Description: | Spécifie les éléments HTML dont les attributs d'URL doivent +être réécrits. |
|---|---|
| Syntaxe: | ProxyHTMLLinks élément attribut [attribut2 ...] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_proxy_html |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.x antérieures. |
Cette directive permet de spécifier les éléments dont les attributs d'URL
+doivent être réécrits en utilisant les règles standards ProxyHTMLURLMap. Vous devez définir une
+directive ProxyHTMLLinks pour chaque élément, mais chacune d'entre elles peut
+spécifier un nombre quelconque d'attributs
Normalement, cette directive
+est définie globalement. Si vous définissez ProxyHTMLLinks à plusieurs niveaux,
+certains niveaux l'emportant sur d'autres, vous devrez spécifier un jeu complet
+de liens pour chaque niveau.
Le fichier proxy-html.conf +fournit une configuration par défaut et définit les liens HTML selon les +standards HTML 4 et XHTML 1.
+ProxyHTMLLinks a href +ProxyHTMLLinks area href +ProxyHTMLLinks link href +ProxyHTMLLinks img src longdesc usemap +ProxyHTMLLinks object classid codebase data usemap +ProxyHTMLLinks q cite +ProxyHTMLLinks blockquote cite +ProxyHTMLLinks ins cite +ProxyHTMLLinks del cite +ProxyHTMLLinks form action +ProxyHTMLLinks input src usemap +ProxyHTMLLinks head profile +ProxyHTMLLinks base href +ProxyHTMLLinks script src for+
| Description: | Active ou désactive une préinterprétation supplémentaire
+des métadonnées dans les sections HTML <head>. |
|---|---|
| Syntaxe: | ProxyHTMLMeta On|Off |
| Défaut: | ProxyHTMLMeta Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_proxy_html |
| Compatibilité: | Disponible à partir de la version 2.4 du serveur HTTP +Apache ; proposé en tant que module tiers dans les versions 2.x +précédentes. |
Cette directive permet d'activer ou désactiver une
+ préinterprétation supplémentaire des métadonnées dans les sections
+ HTML <head>. Si cette préinterprétation n'est pas
+ requise, définissez ProxyHTMLMeta à Off et les performances
+ seront légèrement améliorées. Cependant, elle s'avère parfois
+ nécessaire pour assurer un fonctionnement correct de l'internationalisation.
La directive ProxyHTMLMeta a deux effets. Le premier et le plus
+ important est la détection des codages de caractères déclarés sous
+ la forme
<meta http-equiv="Content-Type" content="text/html;charset=foo">+
ou, dans le cas d'un document XHTML, sous la forme d'une
+ déclaration XML. Elle n'est pas nécessaire si le jeu de caractères
+ est déclaré explicitement dans un en-tête HTTP (ce qui est
+ préférable) en provenance du serveur d'arrière-plan, ou si le
+ document est en utf-8 (unicode) ou un de ses
+ sous-ensembles comme ASCII. Vous pourrez aussi vous en passer
+ lorsque le document utilise une valeur par défaut déclarée via la
+ directive xml2EncDefault, avec le risque de
+ propager une déclaration incorrecte. Une directive
+ ProxyHTMLCharsetOut permettra d'annuler ce
+ risque, mais pourra induire une surcharge de traitement supérieure à
+ celle de ProxyHTMLMeta.
Le deuxième effet est l'interprétation de toutes les déclarations
+ <meta http-equiv=...> et leur conversion en
+ en-têtes HTTP, afin de conserver le but original de cette forme
+ de métaélément HTML.
http-equiv au rang d'en-têtes HTTP, il est conseillé de ne
+ l'activer que si vous faites autant confiance au contenu HTML qu'à votre
+ serveur mandataire. Avec cette directive en effet, si ce contenu est géré
+ par des gens malintentionnés, ces derniers seront en mesure d'injecter des
+ en-têtes HTTP arbitraires et peut-être malveillants dans les réponses de
+ votre serveur.
+ | Description: | Détermine si les commentaires HTML doivent être supprimés. |
|---|---|
| Syntaxe: | ProxyHTMLStripComments On|Off |
| Défaut: | ProxyHTMLStripComments Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_proxy_html |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.x antérieures. |
Si cette directive est définie à On, mod_proxy_html
+supprimera les commentaires HTML. Notez que cela supprimera aussi tout
+script ou style inclus dans les commentaires (une monstruosité
+introduite en 1995/1996 avec Netscape 2 pour les navigateurs plus
+anciens, et encore utilisée de nos jours). Cette directive peut aussi
+interférer avec des processeurs basés sur les commentaires comme SSI ou
+ESI : assurez-vous d'exécuter ces derniers avant mod_proxy_html
+dans la chaîne de filtrage si vous supprimez les commentaires !
| Description: | Définit une règle de réécriture des liens HTML |
|---|---|
| Syntaxe: | ProxyHTMLURLMap modèle-source modèle-cible [drapeaux] [cond] |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Base |
| Module: | mod_proxy_html |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.x antérieures. |
Il s'agit de la directive la plus importante pour la réécriture des
+liens HTML. Lors de l'interprétation d'un document, chaque fois qu'un
+lien correspond à modèle-source, la partie du lien concernée
+sera réécrite en modèle-cible, en tenant compte des
+modifications induites par les drapeaux éventuellement spécifiés et par
+la directive ProxyHTMLExtended.
+Ne seront considérés comme des liens HTML que les éléments spécifiés via la
+directive ProxyHTMLLinks.
Le troisième argument optionnel permet de définir un des drapeaux +suivants (les drapeaux sont sensibles à la casse) :
+Ignore les liens HTML (les traverse sans les modifier)
Ignore les évènements de scripting (les traverse sans les +modifier)
Traverse les sections de type style ou script sans les modifier.
Last-match. Si cette règle s'applique, aucune autre règle ne sera +prise en compte (notez qu'il s'agit du comportement automatique pour les +liens HTML).
L'opposé de L. Passe outre le comportement par défaut du +changement unique pour les liens HTML.
Utilise des expressions rationnelles pour les modèles.
+modèle-source est une expression rationnelle, et
+modèle-cible une chaîne de remplacement qui peut être basée
+elle aussi sur une expression rationnelle. La mémorisation dans les
+expressions rationnelles est supportée : vous pouvez utiliser des
+parenthèses () dans le modèle-source, et récupérer la
+correspondance de leur contenu via les variables $1 à $9 dans le
+modèle-cible.
Si le drapeau R n'est pas fourni, la directive utilisera des chaînes +littérales pour les différents modèles de recherche/remplacement. La +logique de recherche est "commence par" dans les liens HTML, et +"contient" dans les évènements de scripting et les sections de +type style ou script. +
+Utilise les expressions rationnelles étendues POSIX. Ne +s'applique qu'avec R.
Recherche de correspondance sensible à la casse. Ne +s'applique qu'avec R.
Désactive la mémorisation dans les expressions rationnelles (pour +améliorer les performances). Ne s'applique qu'avec R.
Recherche de correspondance dans les expressions rationnelles +basée sur la ligne. Ne s'applique qu'avec R.
Recherche de correspondance au début seulement. Ne concerne que +les recherches de correspondance par rapport à des chaînes, et ne +s'applique pas aux liens HTML.
Recherche de correspondance à la fin seulement. Ne concerne que +les recherches de correspondance par rapport à des chaînes, et ne +s'applique pas aux liens HTML.
Insère des variables d'environnement dans le
+modèle-cible. Un modèle-cible de la forme
+${varname|default} sera remplacé par la valeur de la
+variable d'environnement varname. Si cette dernière n'est
+pas définie, modèle-cible sera remplacé par
+default. La spécification de |default est
+facultative.
NOTE: l'insertion de variables d'environnement n'est possible que si
+la directive ProxyHTMLInterp a été définie à
+On.
Insère des variables d'environnement dans le
+modèle-source. La syntaxe du modèle est identique à la
+syntaxe précédente.
NOTE: l'insertion de variables d'environnement n'est possible que si
+la directive ProxyHTMLInterp a été définie à
+On.
Le quatrième argument optionnel cond définit une
+condition qui sera évaluée pour chaque requête, sous réserve que la
+directive ProxyHTMLInterp ait été définie à
+On. Si la condition est évaluée à FALSE, la règle ne sera pas
+appliquée à la requête. Si elle est évaluée à TRUE, ou si aucune
+condition n'est définie, la règle s'applique.
La condition est évaluée par l'interpréteur d'expression. La syntaxe simple des +conditions dans mod_proxy_html 3.x pour HTTPD 2.0 et 2.2 est aussi +supportée.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Module fournissant le support HTTP à
+mod_proxy |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_http_module |
| Fichier Source: | mod_proxy_http.c |
Pour pouvoir fonctionner, ce module requiert le
+ chargement de mod_proxy. Il fournit le support du
+ mandatement des requêtes HTTP et HTTPS. mod_proxy_http
+ supporte HTTP/0.9, HTTP/1.0 et HTTP/1.1. Il ne fournit
+ aucune fonctionnalité de mise en cache. Si vous souhaitez
+ mettre en oeuvre un mandataire qui assure aussi les fonctions de
+ mise en cache, vous devez utiliser les services du module
+ mod_cache.
Ainsi, pour pouvoir traiter les requêtes HTTP mandatées,
+ mod_proxy, et mod_proxy_http
+ doivent être chargés dans le serveur.
N'activez pas la fonctionnalité de mandataire avant d'avoir sécurisé votre serveur. Les + serveurs mandataires ouverts sont dangereux non seulement pour + votre réseau, mais aussi pour l'Internet au sens large.
+Ce module ne fournit aucune directive.
+Outre les directives de configuration qui contrôlent le
+ comportement de mod_proxy, plusieurs variables
+ d'environnement permettent de contrôler le fournisseur du
+ protocole HTTP. Parmi les variables suivantes, celle qui ne
+ nécessitent pas de valeur particulière sont définies quelle que soit
+ la valeur qu'on leur affecte.
RFC
+ (valeur par défaut) ou
+ Suppress. Les versions précédentes de httpd
+ supprimaient les réponses intermédiaires HTTP (1xx) envoyées par
+ le serveur cible. En pratique, si un serveur cible envoie une
+ réponse intermédiaire, il se peut qu'il étende lui-même le
+ protocole d'une manière dont nous n'avons pas connaissance, ou
+ tout simplement non conforme. Le comportement du mandataire est
+ donc maintenant configurable : définissez
+ proxy-interim-response RFC pour être totalement
+ compatible avec le protocole, ou proxy-interim-response
+ Suppress pour supprimer les réponses intermédiaires.mod_proxy_http enregistre les informations
+ suivantes pour journalisation via le format %{NOMVAR}n
+ dans les directives LogFormat ou ErrorLogFormat :
+
Serveur HTTP Apache Version 2.4
+| Description: | Support de HTTP/2 pour mod_proxy |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_http2_module |
| Fichier Source: | mod_proxy_http2.c |
mod_proxy_http2 ne
+ supporte que HTTP/2 et ne permet pas de rétrogradation vers HTTP/1.1. Cela
+ signifie que le serveur d'arrière-plan doit supporter HTTP/2 car HTTP/1.1 ne
+ pourra alors pas être utilisé.
Ce module nécessite la présence de mod_proxy ;
+ pour pouvoir traiter les requêtes mandatées HTTP/2,
+ mod_proxy et mod_proxy_http2 doivent donc
+ être chargés par le serveur.
mod_proxy_http2 travaille avec des requêtes entrantes en
+ HTTP/1.1 ou HTTP/2. Dans les deux cas, les requêtes vers le même serveur
+ d'arrière-plan sont envoyées
+ via une seule connexion TCP, dans la mesure du possible (autrement dit
+ lorsque la connexion peut être réutilisée).
Avertissement : il ne sera effectué aucune tentative de fusion de + plusieurs requêtes entrantes HTTP/1 (devant être mandatées vers le même + serveur d'arrière-plan) vers des flux HTTP/2 appartenant à la même requête + HTTP/2. Chaque requête HTTP/1 entrante sera mandatée vers le serveur + d'arrière-plan en utilisant une requête HTTP/2 séparée (tout en réutilisant + si possible la même connexion TCP).
+ +Ce module s'appuie sur libnghttp2 pour + fournir le moteur central http/2.
+ +Ce module en est au + stade expérimental. Ses comportement, directives et valeurs par défauts sont + donc susceptibles de modifications d'une version à l'autre plus fréquentes + que pour les autres modules. A ce titre, il est fortement conseillé aux + utilisateurs de consulter le fichier "CHANGES" pour prendre connaissance de + ces modifications.
N'activez pas le mandatement avant d'avoir sécurisé votre serveur. Les serveurs + mandataires ouverts sont dangereux non seulement pour votre propre réseau, + mais aussi pour l'Internet au sens large.
+Ce module ne fournit aucune directive.
+Les exemples ci-dessous montrent comment configurer HTTP/2 pour des + connexions d'arrière-plan vers un mandataire inverse.
+ +ProxyPass "/app" "h2://app.example.com" +ProxyPassReverse "/app" "https://app.example.com"+
ProxyPass "/app" "h2c://app.example.com" +ProxyPassReverse "/app" "http://app.example.com"+
Pour mandater en inverse les protocoles h2 ou
+ h2c, on utilise la directive
+ ProxyPassReverse avec les schèmes habituels
+ https et respectivement
+ http qui sont connus et utilisés par l'agent utilisateur.
mod_proxy_http fournit les informations sur les requêtes
+ suivantes pour enregistrement dans les journaux en utilisant le format
+ %{VARNAME}n avec les directives LogFormat ou ErrorLogFormat :
+
Serveur HTTP Apache Version 2.4
+| Description: | Module fournissant le support de la passerelle SCGI à
+mod_proxy |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_scgi_module |
| Fichier Source: | mod_proxy_scgi.c |
| Compatibilité: | Disponible depuis la version 2.2.14 d'Apache |
Pour pouvoir fonctionner, ce module requiert le
+ chargement de mod_proxy. Il fournit le support du
+ protocole SCGI, version
+ 1.
Ainsi, pour être en mesure de traiter le protocole SCGI,
+ mod_proxy et mod_proxy_scgi
+ doivent être chargés dans le serveur.
N'activez pas la fonctionnalité de mandataire avant d'avoir sécurisé votre serveur. Les + serveurs mandataires ouverts sont dangereux non seulement pour + votre réseau, mais aussi pour l'Internet au sens large.
+Rappelez-vous, pour que les exemples suivants puissent
+ fonctionner, vous devez activer mod_proxy et
+ mod_proxy_scgi.
ProxyPass /scgi-bin/ scgi://localhost:4000/+
La passerelle à répartition de charge nécessite le chargement du
+ module mod_proxy_balancer et d'au moins un module
+ fournissant un algorithme de répartition de charge, comme
+ mod_lbmethod_byrequests en plus des modules
+ déjà cités. mod_lbmethod_byrequests est le module
+ par défaut et sera utilisé dans cet exemple de configuration.
ProxyPass "/scgi-bin/" "balancer://somecluster/" +<Proxy "balancer://somecluster"> + BalancerMember "scgi://localhost:4000" + BalancerMember "scgi://localhost:4001" +</Proxy>+
En plus des directives de configuration qui permettent de
+ contrôler le comportement de mod_proxy, une
+ variable d'environnement peut aussi
+ contrôler le fournisseur de protocole SCGI :
mod_proxy_scgi ne créera ni
+ exportera jamais la variable d'environnement
+ PATH_INFO. Ceci permet au serveur SCGI d'arrière-plan
+ de déterminer correctement SCRIPT_NAME et
+ Script-URI, et de rester en conformité avec la section
+ 3.3 de la RFC 3875. Si au contraire vous souhaitez que
+ mod_proxy_scgi génère une estimation la plus
+ précise possible de PATH_INFO, définissez cette
+ variable d'environnement. La variable doit être définie avant
+ que la directive SetEnv ne soit effective. Il est possible
+ d'utiliser à la place la directive SetEnvIf : SetEnvIf Request_URI . proxy-scgi-pathinfo
+ | Description: | Active ou désactive les réponses de redirection interne en +provenance du serveur cible. |
|---|---|
| Syntaxe: | ProxySCGIInternalRedirect On|Off|Headername |
| Défaut: | ProxySCGIInternalRedirect On |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy_scgi |
| Compatibilité: | Le paramètre Headername est disponible depuis +la version 2.4.13 du serveur HTTP Apache. |
La directive ProxySCGIInternalRedirect
+ permet au serveur cible de rediriger en interne la passerelle vers
+ une URL différente. Cette fonctionnalité trouve son origine dans
+ mod_cgi qui redirige la réponse en interne si
+ l'état de la réponse est OK (200), et si
+ la réponse contient un en-tête Location
+ (ou un autre en-tête défini) dont la valeur
+ débute par un slash (/). Cette valeur est interprétée
+ comme une nouvelle URL locale vers laquelle Apache httpd effectue sa
+ redirection.
De ce point de vue, mod_proxy_scgi fait la même
+ chose que mod_cgi, mais vous pouvez en plus
+ désactiver la fonctionnalité ou spécifier
+ l'utilisation d'un en-tête autre que Location.
ProxySCGIInternalRedirect Off +# Django et certains autres frameworks qualifient pleinement les "URLs +# locales" définies par l'application ; il faut donc utiliser un autre +# en-tête. +<Location /django-app/> + ProxySCGIInternalRedirect X-Location +</Location>+
| Description: | Active l'évaluation du pseudo en-tête de réponse +X-Sendfile |
|---|---|
| Syntaxe: | ProxySCGISendfile On|Off|nom-en-tête |
| Défaut: | ProxySCGISendfile Off |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Extension |
| Module: | mod_proxy_scgi |
La directive ProxySCGISendfile permet au
+ serveur cible SCGI de faire servir les fichiers directement par la
+ passerelle. Ceci s'avère bénéfique en
+ matière de performances —
+ httpd peut alors utiliser sendfile ou d'autres
+ optimisations, ce qui n'est pas possible si les fichiers passent par
+ la socket du serveur cible. En outre, les fichiers ne sont transmis
+ qu'une seule fois.
L'argument de la directive
+ ProxySCGISendfile détermine le comportement
+ de la passerelle :
OffOnX-Sendfile, et interprète sa valeur comme
+ le nom du fichier à servir. L'en-tête est ensuite supprimé de la
+ réponse finale. Cet argument produit le même effet que
+ ProxySCGISendfile X-Sendfile.On, mais au lieu de rechercher le nom
+ d'en-tête codé en dur X-Sendfile, c'est la
+ valeur de l'argument qui constitue le nom de l'en-tête
+ à rechercher.# Utilise le nom d'en-tête par défaut (X-Sendfile) + ProxySCGISendfile On + + # Utilise un nom d'en-tête différent + ProxySCGISendfile X-Send-Static+
Serveur HTTP Apache Version 2.4
+| Description: | Module pour mod_proxy supportant les
+websockets |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | proxy_wstunnel_module |
| Fichier Source: | mod_proxy_wstunnel.c |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP +Apache |
Pour utiliser ce module, mod_proxy doit être
+ chargé. Il fournit le support du tunnelling pour les connexions
+ websocket vers un serveur websockets d'arrière-plan. La connexion
+ est automatiquement promue en connexion websocket :
Upgrade: WebSocket +Connection: Upgrade+
Le mandatement des requêtes vers un serveur websockets comme
+echo.websocket.org peut être configuré via la directive ProxyPass :
ProxyPass "/ws2/" "ws://echo.websocket.org/" +ProxyPass "/wss2/" "wss://echo.websocket.org/"+ + +
La répartition de charge entre plusieurs serveurs d'arrière-plan peut être
+configurée via le module mod_proxy_balancer.
En fait, ce module permet d'accepter d'autres protocoles ; vous pouvez à cet
+effet utiliser le paramètre upgrade de la directive ProxyPass. La valeur NONE
+signifie que vous court-circuitez la consultation de l'en-tête, mais que vous
+autorisez quand-même WebSocket. La valeur ANY signifie que Upgrade
+va lire les en-têtes de la requête et les utilisera dans l'en-tête
+Upgrade de la réponse.
Ce module ne fournit aucune directive.
+Serveur HTTP Apache Version 2.4
+| Description: | Limitation de la bande passante pour les clients |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | ratelimit_module |
| Fichier Source: | mod_ratelimit.c |
| Compatibilité: |
+ rate-initial-burst est disponible à partir de la version 2.4.24
+ du serveur HTTP Apache. La limitation de bande passante pour les contenus
+ mandatés ne fonctionne pas correctement jusqu'à la version 2.4.33.
+ |
Ce module fournit un filtre RATE_LIMIT pour limiter la
+bande passante des clients. Cette contrainte s'applique à chaque réponse HTTP au
+moment où elle est envoyée au client ; elle n'affecte pas les autres échanges
+entre le client et le serveur. La variable d'environnement
+rate-limit permet de spécifier, en kb/s, le débit de la
+connexion à simuler.
Optionnellement, il est possible, via la variable d'environnement
+rate-initial-burst, de définir une quantité de données en
+kOctets à transmettre à pleine vitesse avant de limiter la bande passante à la
+valeur voulue.
<Location "/downloads"> + SetOutputFilter RATE_LIMIT + SetEnv rate-limit 400 + SetEnv rate-initial-burst 512 +</Location>+
rate-limit dépasse la valeur maximale à
+affecter à un entier, la limitation de bande passante sera désactivée. Si la
+valeur affectée à rate-limit-burst dépasse la valeur maximale à
+affecter à un entier, la transmission du burst initial sans limitation de bande
+passante sera désactivée.
+Ce module ne fournit aucune directive.
+Serveur HTTP Apache Version 2.4
+| Description: | Renvoie un corps de requête comme réponse via la pile de +filtres en sortie. |
|---|---|
| Statut: | Base |
| Identificateur de Module: | reflector_module |
| Fichier Source: | mod_reflector.c |
| Compatibilité: | Versions 2.3 et ultérieures |
Ce module permet de renvoyer un corps de requête au client, après + l'avoir fait passer par la pile de filtres en sortie. Une chaîne de + filtres configurée de manière appropriée peut être utilisée pour + transformer la requête en réponse. Ce module peut ainsi être utilisé + pour transformer un filtre en sortie en service HTTP.
+<Location "/compress"> + SetHandler reflector + SetOutputFilter DEFLATE +</Location>+ +
<Location "/downsample"> + SetHandler reflector + SetOutputFilter DOWNSAMPLE +</Location>+ +
| Description: | Renvoie un en-tête d'entrée dans les en-têtes de sortie |
|---|---|
| Syntaxe: | ReflectorHeader en-tête-entrée [en-tête-sortie] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Options |
| Statut: | Base |
| Module: | mod_reflector |
Cette directive permet de contrôler la répercution des en-têtes + de la requête dans la réponse. Le premier argument correspond au nom + de l'en-tête à copier. Si le second argument (optionnel) est + spécifié, il définit le nom sous lequel l'en-tête sera répercuté + dans la réponse ; dans le cas contraire, c'est le nom de l'en-tête + original qui sera utilisé.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Remplace l'adresse IP du client +pour la requête par l'adresse IP présentée par un mandataire ou un +répartiteur de charge via les en-têtes de la requête. + |
|---|---|
| Statut: | Base |
| Identificateur de Module: | remoteip_module |
| Fichier Source: | mod_remoteip.c |
Ce module permet de traiter le client qui a initié la + requête en tant que client original du point de vue de httpd à + des fins d'autorisation et de connexion, même si ce client se + trouve derrière un répartiteur de charge, un serveur frontal, ou un + serveur mandataire.
+ +Le module remplace l'adresse IP du client
+ pour la connexion par l'adresse IP indiquée dans
+ l'en-tête de requête configuré via la directive
+ RemoteIPHeader.
Ce module implémente aussi la partie serveur du protocole PROXY
+ de HAProxy via la directive RemoteIPProxyProtocol.
Une fois sa valeur modifiée comme indiqué, cette adresse IP client est
+ utilisée pour la fonctionnalité Require ip de mod_authz_host ;
+ elle est aussi affichée par mod_status, et enregistrée via
+ les chaînes de formatage %a des modules
+ mod_log_config et core. L'adresse IP
+ client sous-jacente de la connexion est enregistrée via la chaîne de
+ formatage %{c}a.
RemoteIPHeader RemoteIPInternalProxy RemoteIPInternalProxyList RemoteIPProxiesHeader RemoteIPProxyProtocol RemoteIPProxyProtocolExceptions RemoteIPTrustedProxy RemoteIPTrustedProxyListPar défaut, Apache identifie le client via la valeur client_ip de la + connexion, et de cette valeur découlent les valeurs remote_host et + remote_logname de la connexion. Ces champs jouent un rôle + dans l'authentification, l'autorisation et la journalisation, ainsi que + dans d'autres traitements effectués par d'autres modules + chargeables.
+ +mod_remoteip remplace l'adresse IP client de la connexion par l'adresse IP client + indiquée par exemple par un mandataire ou un répartiteur de charge + pour toute la durée de la requête. Un répartiteur de charge pourra ainsi + établir une connexion keepalive de longue durée avec le serveur, chaque + requête conservant alors l'adresse IP client correcte bien que l'adresse IP + client sous-jacente du répartiteur de charge reste inchangée.
+ +Lorsque la valeur de l'en-tête comporte plusieurs adresses IP + client séparées par des virgules, celles-ci sont traitées de la + droite vers la gauche. Le traitement s'arrête lorsque l'adresse IP + client courante n'est pas digne de confiance pour présenter + l'adresse IP précédente. Le champ d'en-tête est alors mis à jour de + façon à ne contenir que cette liste d'adresses non confirmées, ou + bien, si toutes les adresses IP sont dignes de confiance, cet + en-tête est tout bonnement supprimé de la requête.
+ +Lors du remplacement de l'adresse IP client, le module stocke
+ la liste des hôtes intermédiaires dans un mémo
+ remoteip-proxy-ip-list, que l'on peut faire enregistrer par
+ mod_log_config en utilisant le symbole de format
+ %{remoteip-proxy-ip-list}n. Si l'administrateur doit
+ stocker ceci dans un en-tête additionnel, la même valeur peut aussi
+ être enregistrée sous la forme d'un en-tête en utilisant la
+ directive RemoteIPProxiesHeader.
RemoteIPInternalProxy sont enregistrés.| Description: | Définit le champ d'en-tête qui contiendra les adresses IP +du client |
|---|---|
| Syntaxe: | RemoteIPHeader en-tête |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_remoteip |
La directive RemoteIPHeader indique à
+ mod_remoteip de traiter la valeur de
+ l'en-tête spécifié comme l'adresse IP du client, ou comme
+ une liste d'adresses IP clients intermédiaires, en fonction de la
+ configuration des directives
+ RemoteIPInternalProxy et
+ RemoteIPTrustedProxy. Si ces
+ deux dernières directives ne sont pas utilisées,
+ mod_remoteip traitera tout hôte présentant une adresse non
+ interne dans l'en-tête RemoteIPHeader comme hôte de confiance.
mod_remoteip
+ traitera tout hôte présentant une adresse non interne
+ dans l'en-tête RemoteIPHeader comme hôte de
+ confiance.RemoteIPHeader X-Client-IP+
RemoteIPHeader X-Forwarded-For+
| Description: | Déclare les adresses IP intranet clients comme dignes de +confiance pour présenter la valeur RemoteIPHeader |
|---|---|
| Syntaxe: | RemoteIPInternalProxy
+ip-mandataire|ip-mandataire/sous-réseau|nom-hôte ... |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_remoteip |
La directive RemoteIPInternalProxy permet
+ d'ajouter une ou plusieurs adresses (ou blocs d'adresses) auxquelles
+ on peut faire confiance pour présenter une valeur RemoteIPHeader
+ valide de l'adresse IP du client. A la différence de la directive
+ RemoteIPTrustedProxy, toute adresse IP
+ présentée dans cet en-tête, y comprises les adresses intranet
+ privées, sont considérées comme dignes de confiance lorsqu'elles
+ sont indiquées par ces mandataires.
RemoteIPHeader X-Client-IP +RemoteIPInternalProxy 10.0.2.0/24 +RemoteIPInternalProxy gateway.localdomain+
| Description: | Déclare les adresses IP intranet clients comme dignes de +confiance pour présenter la valeur RemoteIPHeader |
|---|---|
| Syntaxe: | RemoteIPInternalProxyList nom-fichier |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_remoteip |
La directive RemoteIPInternalProxyList
+ permet de spécifier un fichier parcouru au démarrage du serveur pour
+ construire une liste d'adresses (ou blocs d'adresses), auxquelles
+ on peut faire confiance pour présenter une valeur RemoteIPHeader
+ valide de l'adresse IP du client.
Le caractère '#' indique une ligne de commentaires,
+ sinon, toutes les lignes séparées par un caractère nouvelle
+ ligne ou
+ tous les éléments d'une ligne séparés par un espace sont traités de
+ la même façon qu'avec la directive
+ RemoteIPInternalProxy.
RemoteIPHeader X-Client-IP +RemoteIPInternalProxyList conf/trusted-proxies.lst+
# Nos mandataires internes de confiance + 10.0.2.0/24 # Tout le monde dans le groupe de test + passerelle.domaine-local # Le frontal répartiteur de charge
| Description: | Déclare le champ d'en-tête qui contiendra toutes les +adresses IP intermédiaires |
|---|---|
| Syntaxe: | RemoteIPProxiesHeader Nom_en-tête |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_remoteip |
La directive RemoteIPProxiesHeader permet
+ de spécifier l'en-tête dans lequel mod_remoteip va
+ collecter une liste de toutes les adresses IP clients intermédiaires
+ auxquelles on pourra faire confiance pour résoudre l'adresse IP
+ client de la requête. Notez que les adresses intermédiaires
+ RemoteIPTrustedProxy sont enregistrées dans
+ cet en-tête, alors que toute adresse intermédiaire
+ RemoteIPInternalProxy est omise.
RemoteIPHeader X-Forwarded-For +RemoteIPProxiesHeader X-Forwarded-By+
| Description: | Active ou désactive la gestion du protocole PROXY |
|---|---|
| Syntaxe: | RemoteIPProxyProtocol On|Off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_remoteip |
| Compatibilité: | Disponible à partir de la version 2.4.31 du serveur HTTP Apache |
La directive RemoteIPProxyProtocol permet
+ d'activer ou de désactiver la prise en compte et la gestion de l'en-tête de
+ connexion du protocole PROXY. Si elle est définie à On, la
+ demande du client doit envoyer l'en-tête approprié pour chaque
+ nouvelle connexion, sinon cette dernière sera fermée à moins qu'il ne fasse
+ partie de la liste, définie via la directive RemoteIPProxyProtocolDisableHosts, des
+ hôtes pour lesquels le protocole PROXY est désactivé.
Bien que cette directive peut être définie au niveau de n'importe quel + serveur virtuel, il est important de garder à l'esprit que, étant donné que + le protocole PROXY est basé sur la connexion et agnostique quant au + protocle, son activation/désactivation est basée sur le couple adresse + IP/port. Cela signifie que si plusieurs serveurs virtuels à base de nom sont + configurés avec le même couple adresse IP/port, et si vous activez le + protocole PROXY pour l'un d'entre eux, il le sera aussi pour tous les autres + (avec le même couple adresse IP/port). Cela signifie aussi que si vous + tentez d'activer le protocole PROXY pour un serveur virtuel et de le + désactiver pour un autre, cela ne marchera pas ; dans ce dernier cas, la + dernière directive l'emporte sur les autres et une notification sera + enregistrée dans le journal pour indiquer les réglages qui ont été annulés.
+ +Listen 80 +<VirtualHost *:80> + ServerName www.example.com + RemoteIPProxyProtocol On + + #Les requêtes pour ce serveur virtuel doivent contenir un en-tête du + #protocole PROXY. Si ce n'est pas le cas, la connexion sera fermée. +</VirtualHost> + +Listen 8080 +<VirtualHost *:8080> + ServerName www.example.com + RemoteIPProxyProtocol On + RemoteIPProxyProtocolExceptions 127.0.0.1 10.0.0.0/8 + + #Les requêtes pour ce serveur virtuel doivent contenir un en-tête du + #protocole PROXY. Si ce n'est pas le cas, la connexion sera fermée à moins + que sa source ne soit localhost ou la gamme d'adresses RFC1918 10.x.x.x +</VirtualHost>+ + +
| Description: | Désactive la prise en compte de l'en-tête PROXY pour certains hôtes +ou réseaux |
|---|---|
| Syntaxe: | RemoteIPProxyProtocolExceptions host|range [host|range] [host|range] |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_remoteip |
| Compatibilité: | RemoteIPProxyProtocolExceptions est disponible à partir de la +version 2.4.31 du serveur HTTP Apache |
La directive RemoteIPProxyProtocol permet de
+ contrôler la prise en compte de l'en-tête de connexion du protocole PROXY.
+ Il est parfois souhaitable d'exiger pour certains clients la
+ présence de l'en-tête PROXY, mais aussi de permettre aux autres clients de
+ se connecter sans ce dernier. Cette directive permet à l'administrateur du
+ serveur d'autoriser cette possibilité à un hôte isolé ou à une gamme d'hôtes
+ au format CIDR.
| Description: | Déclare les adresses IP clientes de l'intranet dignes de +confiance pour présenter la valeur RemoteIPHeader |
|---|---|
| Syntaxe: | RemoteIPTrustedProxy
+ip-mandataire|ip-mandataire/sous-réseau|nom-hôte ... |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_remoteip |
La directive RemoteIPTrustedProxy permet
+ d'ajouter une ou plusieurs adresses, ou blocs d'adresses, auxquelles
+ on peut faire confiance pour présenter une valeur RemoteIPHeader
+ valide de l'adresse IP du client. A la différence de la directive
+ RemoteIPInternalProxy, toutes les adresses IP
+ intranet ou privées indiquées par de tels mandataires, y compris les
+ blocs d'adresses 10/8, 172.16/12, 192.168/16, 169.254/16 et 127/8
+ (ou située en dehors du bloc IPv6 public 2000::/3), ne sont pas
+ dignes de confiance en tant qu'adresses IP distantes, et se situent
+ à gauche dans le contenu de l'en-tête
+ RemoteIPHeader.
RemoteIPHeader X-Forwarded-For +RemoteIPTrustedProxy 10.0.2.16/28 +RemoteIPTrustedProxy proxy.example.com+
| Description: | Déclare les adresses IP intranet clients comme dignes de +confiance pour présenter la valeur RemoteIPHeader |
|---|---|
| Syntaxe: | RemoteIPTrustedProxyList nom-fichier |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_remoteip |
La directive RemoteIPTrustedProxyList
+ permet de spécifier un fichier parcouru au démarrage du serveur pour
+ construire une liste d'adresses (ou blocs d'adresses), auxquelles
+ on peut faire confiance pour présenter une valeur RemoteIPHeader
+ valide de l'adresse IP du client.
Le caractère '#' indique une ligne de commentaires,
+ sinon, toutes les lignes séparées par un caractère nouvelle ligne ou
+ tous les éléments d'une ligne séparés par un espace sont traités de
+ la même façon qu'avec la directive
+ RemoteIPTrustedProxy.
RemoteIPHeader X-Forwarded-For +RemoteIPTrustedProxyList conf/trusted-proxies.lst+
+ # Mandataires externes identifiés
+ 192.0.2.16/28 #groupe wap phone de mandataires
+ proxy.isp.example.com #un FAI bien connu
+
Serveur HTTP Apache Version 2.4
+| Description: | Définit le délai maximum et le taux minimum de transfert des +données pour la réception des requêtes + |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | reqtimeout_module |
| Fichier Source: | mod_reqtimeout.c |
| Compatibilité: | Disponible depuis la version 2.2.15 du serveur HTTP Apache |
RequestReadTimeout headerinit=10 body=30+ +
LimitRequestBody) :
+
+ RequestReadTimeout body=10,MinRate=1000+ +
RequestReadTimeout header=10-30,MinRate=500+ +
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500+ +
| Description: | Définit des délais maximums pour la réception des en-têtes +et corps des requêtes en provenance du client. + |
|---|---|
| Syntaxe: | RequestReadTimeout
+[header=délai[-délai-maxi][,MinRate=taux-mini]
+[body=délai[-délai-maxi][,MinRate=taux-mini]
+ |
| Défaut: | header=20-40,MinRate=500 body=20,MinRate=500 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_reqtimeout |
| Compatibilité: | Disponible depuis la version 2.2.15 du serveur HTTP +Apache ; désactivée par défaut depuis la version 2.3.14. |
Cette directive permet de définir différents délais pour la
+ réception des en-têtes et corps des requêtes en provenance du
+ client. Si le client ne parvient pas à respecter ces délais, un code
+ d'erreur 408 REQUEST TIME OUT est envoyé.
Pour les serveurs virtuels SSL, le délai concernant les en-têtes + inclut le temps nécessaire à la négociation SSL initiale. Si le + navigateur du client est configuré pour demander des listes de + révocations de certificats, et si le serveur correspondant n'est pas + disponible, le délai avant lequel le navigateur va abandonner son + attente de CRL au cours de la négociation SSL initiale peut être + assez important. Par conséquent, les valeurs de délais d'en-têtes ne + doivent pas être trop basses pour les serveurs virtuels SSL. Le délai + concernant le corps inclut le temps nécessaire à la renégociation + SSL (si elle est nécessaire).
+ +Lorsqu'une directive AcceptFilter est active (ce qui est en
+ général le cas sous Linux et FreeBSD), la socket n'est envoyée au
+ processus du serveur qu'après la réception du premier octet (ou de
+ l'ensemble de la requête si httpready est défini). Le
+ délai configuré pour les en-têtes via la directive
+ RequestReadTimeout n'entre en ligne de compte qu'une fois
+ la socket reçue par le processus du serveur.
Il existe deux méthodes pour spécifier le délai (pour l'en-tête + ou le corps) : +
+ +type=délai
Le temps en secondes alloué pour la lecture des en-têtes ou du + corps de la requête. La valeur 0 signifie aucune limite.
+header=0 body=0
Avec cet exemple, le module mod_reqtimeout est
+ complètement désactivé.
+ type=délai,MinRate=taux-mini
+
Identique à ce qui précède, mais chaque fois que des données sont + reçues, la valeur du délai est augmentée en fonction du taux-mini + spécifié (en octets par seconde).
+
+ type=délai-délai-maxi,MinRate=taux-mini
+
Identique à ce qui précède, mais le délai n'augmentera pas au + delà de la borne supérieure du délai spécifiée.
+Serveur HTTP Apache Version 2.4
+| Description: | Filtres permettant de traiter et de mettre à disposition +les corps de requêtes HTTP |
|---|---|
| Statut: | Base |
| Identificateur de Module: | request_module |
| Fichier Source: | mod_request.c |
| Compatibilité: | Disponible depuis la version 2.3 d'Apache |
| Description: | Conserve le corps de la requête à concurrence de la taille +maximale spécifiée, pour une utilisation éventuelle par des filtres +comme mod_include. |
|---|---|
| Syntaxe: | KeptBodySize taille maximale en octets |
| Défaut: | KeptBodySize 0 |
| Contexte: | répertoire |
| Statut: | Base |
| Module: | mod_request |
Dans une situation normale, les gestionnaires de requête tels que
+ le gestionnaire par défaut des fichiers statiques suppriment le
+ corps de la requête s'il n'est pas nécessaire au gestionnaire de
+ requête. Il en résulte que les filtres comme mod_include sont
+ limités à des requêtes GET lors de l'inclusion d'autres
+ URLs en tant que sous-requêtes, et ceci même si la requête originale
+ était une requête POST, car le corps de la requête a
+ été supprimé et n'est donc plus disponible une fois le traitement du
+ filtre mis en oeuvre.
Lorsque l'argument de cette directive a une valeur supérieure à
+ zéro, les gestionnaires de requête qui suppriment habituellement les
+ corps de requête vont alors conserver ces corps de requête, à
+ concurrence de la taille maximale spécifiée, pour être
+ éventuellement utilisés par des filtres. Dans le cas du filtre
+ mod_include, une tentative de requête POST pour un
+ fichier shtml statique se traduira par des sous-requêtes
+ POST, et non par des sous-requêtes GET
+ comme avant.
Cette fonctionnalité permet de découper des pages web complexes
+ et des applications web en petits éléments individuels, et de
+ combiner ces éléments avec la structure de la page web sous-jacente
+ en utilisant mod_include. Les éléments peuvent se
+ présenter sous la forme de programmes CGI, de langages de scripts,
+ ou d'URLs issues d'un mandataire inverse dans l'espace d'URL d'un
+ autre serveur en utilisant mod_proxy.
Note : Chaque requête dont le corps est ainsi + conservé doit être enregistrée temporairement en mémoire vive + jusqu'à la fin du traitement de la requête. Il faut donc s'assurer + que la mémoire RAM du serveur est suffisante pour pouvoir supporter + la charge induite. L'utilisation de cette directive doit être + limitée à certaines portions de votre espace d'URL bien précises qui + le nécessitent, et en spécifiant comme taille maximale une valeur la + plus petite possible, mais tout de même suffisante pour un corps de + requête.
+ +Si la taille de la requête envoyée par le client dépasse la taille
+ maximale autorisée par cette directive, le serveur renverra l'erreur
+ 413 Request Entity Too Large.
Serveur HTTP Apache Version 2.4
+| Description: | Ce module fournit un moteur de réécriture à base de +règles permettant de réécrire les URLs des requêtes +à la volée |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | rewrite_module |
| Fichier Source: | mod_rewrite.c |
Le module mod_rewrite utilise un moteur de
+ réécriture à base de règles, basé sur un interpréteur
+ d'expressions rationnelles PCRE, pour réécrire les URLs à la volée. Par
+ défaut, mod_rewrite met en correspondance une URL
+ avec le système de fichiers. Cependant, on peut aussi l'utiliser
+ pour rediriger une URL vers une autre URL, ou pour invoquer une
+ requête interne à destination du mandataire.
mod_rewrite fournit une méthode souple et
+ puissante pour manipuler les URLs en utilisant un nombre illimité
+ de règles. Chaque règle peut être associée à un nombre illimité de
+ conditions, afin de vous permettre de réécrire les URLs en
+ fonction de variables du serveur, de variables d'environnement,
+ d'en-têtes HTTP, ou de repères temporels.
mod_rewrite agit sur la totalité de l'URL, y
+ compris la partie chemin. Une règle de réécriture peut être
+ invoquée dans httpd.conf ou dans un fichier
+ .htaccess. Le chemin généré par une règle de
+ réécriture peut inclure une chaîne de paramètres, ou peut renvoyer
+ vers un traitement secondaire interne, une redirection vers une
+ requête externe ou vers le mandataire interne.
Vous trouverez d'avantage de détails, discussions et exemples + dans la + documentation détaillée + sur mod_rewrite.
+ Journalisation RewriteBase RewriteCond RewriteEngine RewriteMap RewriteOptions RewriteRulemod_rewrite offre une journalisation détaillée
+ de ses actions aux niveaux de journalisation trace1 à
+ trace8. Le niveau de journalisation peut être défini de
+ manière spécifique à mod_rewrite via la directive
+ LogLevel : jusqu'au niveau
+ debug aucune action n'est journalisée, alors qu'elles
+ le sont pratiquement toutes au niveau trace8.
mod_rewrite va ralentir votre serveur HTTP Apache
+ de manière dramatique ! N'utilisez un niveau de journalisation
+ supérieur à trace2 qu'à des fins de débogage !
+ LogLevel alert rewrite:trace3+
Ceux qui sont familiers avec les versions précédentes de
+ mod_rewrite vont probablement rechercher en vain les
+ directives RewriteLog et
+ RewriteLogLevel. Elles ont été en effet remplacées
+ par une configuration de la journalisation par module, comme
+ mentionné plus haut.
+
Pour extraire les traces spécifiques à
+ mod_rewrite, affichez le fichier journal en
+ redirigeant la sortie vers grep :
+ tail -f error_log|fgrep '[rewrite:'
+
| Description: | Définit l'URL de base pour les réécritures au niveau +répertoire |
|---|---|
| Syntaxe: | RewriteBase chemin_URL |
| Défaut: | Pas de valeur par défaut |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_rewrite |
La directive RewriteBase permet de
+ spécifier le préfixe d'URL à utiliser dans un contexte de
+ répertoire (htaccess) pour les directives
+ RewriteRule qui réécrivent vers un chemin
+ relatif.
Cette directive est obligatoire si vous utilisez un + chemin relatif dans une substitution, et dans un contexte de + répertoire (htaccess), sauf si au moins une de ces conditions est + vérifiée :
+DocumentRoot (c'est à
+ dire que pour y accéder, il n'est pas nécessaire d'utiliser
+ une directive telle qu'Alias).RewriteRule, suffixé par
+ la substitution relative est aussi valide en tant qu'URL sur
+ le serveur (ce qui est rare).Alias ou le module
+ mod_userdir.Dans l'exemple ci-dessous, la directive
+RewriteBase est nécessaire afin d'éviter une
+réécriture en http://example.com/opt/myapp-1.2.3/welcome.html car la
+ressource n'était pas relative à la racine des documents. Cette erreur
+de configuration aurait conduit le serveur à rechercher un répertoire
+"opt" à la racine des documents.
DocumentRoot "/var/www/example.com" +AliasMatch "^/myapp" "/opt/myapp-1.2.3" +<Directory "/opt/myapp-1.2.3"> + RewriteEngine On + RewriteBase "/myapp/" + RewriteRule "^index\.html$" "welcome.html" +</Directory>+ + + +
| Description: | Définit une condition qui devra être satisfaite pour que +la réécriture soit effectuée + |
|---|---|
| Syntaxe: | RewriteCond
+ chaîne_de_test expression_de_comparaison [drapeaux] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_rewrite |
La directive RewriteCond permet de définir une
+ condition d'exécution d'une règle. Une ou plusieurs conditions
+ RewriteCond peuvent précéder une
+ directive RewriteRule. La règle de réécriture correspondante n'est
+ ainsi exécutée que si ces conditions sont satisfaites,
+ et si l'URI correspond au modèle spécifié dans la
+ règle.
TestString est une chaîne qui peut contenir les + extensions suivantes en plus du texte simple :
+ +$N (0 <= N <= 9). $1 à $9
+ permettent d'accéder aux parties regroupées (entre
+ parenthèses) du modèle, issues de la RewriteRule
+ concernée par le jeu de conditions RewriteCond
+ courant. $0 donne accès à l'ensemble de la chaîne
+ correspondant au modèle.%N (0 <= N <= 9). %1 à %9
+ permettent d'accéder aux parties regroupées (entre
+ parenthèses) du modèle, issues de la dernière
+ condition RewriteCond satisfaite du jeu de conditions RewriteCond
+ courant. %0 donne accès à l'ensemble de la chaîne
+ correspondant au modèle.${nomTable:clé|défaut}. Voir la href="#mapfunc">documentation sur RewriteMap
+ pour plus de détails.
+ %{ NAME_OF_VARIABLE },
+ où NOM_DE_VARIABLE peut contenir une chaîne issue
+ de la liste suivante :
+
+ | En-têtes HTTP : | connexion & requête: | + |
|---|---|---|
|
+ HTTP_ACCEPT + HTTP_COOKIE + HTTP_FORWARDED + HTTP_HOST + HTTP_PROXY_CONNECTION + HTTP_REFERER + HTTP_USER_AGENT + |
+
+
+ AUTH_TYPE + CONN_REMOTE_ADDR + CONTEXT_PREFIX + CONTEXT_DOCUMENT_ROOT + IPV6 + PATH_INFO + QUERY_STRING + REMOTE_ADDR + REMOTE_HOST + REMOTE_IDENT + REMOTE_PORT + REMOTE_USER + REQUEST_METHOD + SCRIPT_FILENAME + |
+
+ + |
| variables internes au serveur : | date et heure : | spéciaux : | +
|
+ DOCUMENT_ROOT + SCRIPT_GROUP + SCRIPT_USER + SERVER_ADDR + SERVER_ADMIN + SERVER_NAME + SERVER_PORT + SERVER_PROTOCOL + SERVER_SOFTWARE + |
+
+
+ TIME_YEAR + TIME_MON + TIME_DAY + TIME_HOUR + TIME_MIN + TIME_SEC + TIME_WDAY + TIME + |
+
+
+ API_VERSION + CONN_REMOTE_ADDR + HTTPS + IS_SUBREQ + REMOTE_ADDR + REQUEST_FILENAME + REQUEST_SCHEME + REQUEST_URI + THE_REQUEST + |
+
Ces variables correspondent toutes aux en-têtes MIME
+ HTTP de mêmes noms, au variables C du serveur HTTP Apache, ou
+ aux champs struct tm du système Unix. La
+ plupart d'entre elles sont documentées ici, dans la
+ spécification CGI ou ailleurs dans le
+ manuel.
SERVER_NAME et SERVER_PORT dépendent respectivement
+ des valeurs des directives UseCanonicalName et UseCanonicalPhysicalPort.
Parmi les variables
+ spécifiques à mod_rewrite, ou trouve les suivantes :
API_VERSIONCONN_REMOTE_ADDRmod_remoteip).HTTPSmod_ssl soit chargé ou non).IS_SUBREQREMOTE_ADDRmod_remoteip).REQUEST_FILENAMEREQUEST_FILENAME contient la
+ valeur de REQUEST_URI. En fonction de la
+ valeur de la directive AcceptPathInfo, le serveur
+ peut n'utiliser que certains éléments de tête du
+ REQUEST_URI pour déterminer à quel
+ fichier correspond la requête.REQUEST_SCHEMEServerName.REQUEST_URIQUERY_STRING.THE_REQUESTGET
+ /index.html HTTP/1.1"), à l'exclusion de tout
+ en-tête ajouté par le navigateur. Cette
+ valeur n'a pas été déséchappée (décodée), à la
+ différence de la plupart des variables suivantes.Si la chaîne_de_test contient la valeur spéciale
+ expr, expression_de_comparaison sera traité
+ en tant qu'expression rationnelle de type ap_expr. Si des en-têtes HTTP sont
+ référencés dans l'expression rationnelle, et si le drapeau
+ novary n'est pas activé, ils seront ajoutés à
+ l'en-tête Vary.
Autres points à connaître ::
+Les variables SCRIPT_FILENAME et
+ REQUEST_FILENAME contiennent toutes deux la valeur
+ du champ filename de la
+ structure interne request_recdu serveur HTTP Apache.
+ Le premier nom correspond au nom de variable bien connu CGI,
+ alors que le second est l'équivalent de REQUEST_URI (qui
+ contient la valeur du champ uri de
+ request_rec).
Si une substitution intervient et si la réécriture se + poursuit, la valeur des deux variables sera mise à jour en + conséquence.
+Dans le contexte du serveur principal (c'est à dire avant que
+ la requête ne soit mise en correspondance avec le système de
+ fichiers), SCRIPT_FILENAME et REQUEST_FILENAME ne peuvent pas
+ contenir le chemin entier dans le système de fichiers local car
+ ce chemin b'est pas connu à ce stade du traitement. Dans ce cas,
+ les deux variables contiendront la valeur de REQUEST_URI. Pour
+ obtenir le chemin complet de la requête dans le système de
+ fichiers local dans le contexte du serveur principal, utilisez une
+ référence avant à base d'URL
+ %{LA-U:REQUEST_FILENAME} pour déterminer la valeur
+ finale de REQUEST_FILENAME.
%{ENV:variable}, où variable peut
+ correspondre à une variable d'environnement quelconque.%{ENV:variable} est aussi disponible, où
+ variable peut correspondre à toute variable
+ d'environnement. Peut être consulté via des structures internes
+ d'Apache httpd et (si on ne les trouve pas ici) via la fonction
+ getenv() à partir du processus du serveur Apache
+ httpd.mod_ssl soit chargé ou non, on peut
+ utiliser %{SSL:variable}, où variable
+ peut être remplacé par le nom d'une
+ variable
+ d'environnement SSL . Si mod_ssl n'est pas
+ chargé, cette variable contiendra toujours une chaîne vide.
+ Exemple : %{SSL:SSL_CIPHER_USEKEYSIZE} pourra
+ contenir la valeur 128. Ces variables sont
+ disponibles même si l'option StdEnvVars de la
+ directive SSLOptions n'a
+ pas été définie.%{HTTP:en-tête}, où
+ en-tête peut correspondre à tout nom d'en-tête MIME
+ HTTP, pour extraire la valeur d'un en-tête envoyé dans la
+ requête HTTP. Par exemple, %{HTTP:Proxy-Connection}
+ contiendra la valeur de l'en-tête HTTP
+ "Proxy-Connection:".
+ Si on utilise un en-tête HTTP
+ dans une condition, et si cette condition est évaluée à
+ vrai pour la requête, cet en-tête sera ajouté à l'en-tête Vary de
+ la réponse. Il ne le sera pas si la condition est évaluée à
+ faux. L'ajout de l'en-tête HTTP à l'en-tête Vary
+ est nécessaire à une mise en cache appropriée.
+ Il faut garder à l'esprit que les conditions suivent une
+ logique de cout-circuit si le drapeau
+ 'ornext|OR' est utilisé, et que de
+ ce fait, certaines d'entre elles ne seront pas évaluées.
%{LA-U:variable}, qui
+ permet d'effectuer une sous-requête interne à base d'URL, afin
+ de déterminer la valeur finale de variable. Ceci permet
+ d'accéder à la valeur d'une variable pour la réécriture inconnue
+ à ce stade du traitement, mais qui sera définie au
+ cours d'une phase ultérieure.
+ Par exemple, pour effectuer une réécriture dépendant de la
+ variable REMOTE_USER dans le contexte du serveur
+ principal (fichier httpd.conf), vous devez utiliser
+ %{LA-U:REMOTE_USER} - cette variable est définie
+ par la phase d'autorisation qui intervient après la
+ phase de traduction d'URL (pendant laquelle mod_rewrite
+ opère).
Par contre, comme mod_rewrite implémente son contexte de
+ répertoire (fichier .htaccess) via la phase Fixup
+ de l'API, et comme la phase d'autorisation intervient
+ avant cette dernière, vous pouvez vous contenter
+ d'utiliser %{REMOTE_USER} dans ce contexte.
%{LA-F:variable} peut être utilisée pour effectuer
+ une sous-requête interne (basée sur le nom de fichier), afin de
+ déterminer la valeur finale de variable. La plupart du
+ temps, elle est identique à LA-U (voir ci-dessus).expression_de_comparaison est une expression + rationnelle qui est appliquée à l'instance actuelle de + chaîne_de_test. chaîne_de_test est d'abord + évaluée, puis comparée à + l'expression_de_comparaison.
+ +expression_de_comparaison est en général une + expression rationnelle compatible perl, mais vous + disposez des syntaxes supplémentaires suivantes pour effectuer + d'autres tests utiles sur chaîne_de_test : +
+ +!' (point d'exclamation) pour inverser le résultat
+ de la condition, quelle que soit l'expression de
+ comparaison utilisée."" (deux guillemets),
+ chaîne_de_test est comparée à la
+ chaîne vide.!-eq.test de l'existence d'une
+ URL via une sous-requête
+ Vérifie si chaîne_de_test est une URL valide,
+ accessible à travers tous les contrôles d'accès du serveur
+ actuellement configurés pour ce chemin. C'est une
+ sous-requête interne qui effectue cette vérification - à
+ utiliser avec précautions car les performances du serveur
+ peuvent s'en trouver affectées !
Ce drapeau ne renvoie que des informations + concernant le contrôle d'accès, l'authentification et + l'autorisation. Il ne renvoie pas d'informations + concernant le code d'état que le gestionnaire configuré + (static file, CGI, proxy, etc...) aurait, quant à lui, + retourné.
RewriteCond /var/www/%{REQUEST_URI} !-f
+RewriteRule ^(.+) /other/archive/$1 [R]
+
+
+ Si la chaîne_de_test contient la valeur spéciale
+ expr, la chaîne de comparaison sera
+ traitée en tant qu'expression rationnelle de type ap_expr.
+ Dans l'exemple ci-dessous, on utilise -strmatch
+ pour comparer le REFERER avec le nom d'hôte du
+ site afin de bloquer le hotlinking (référencement direct)
+ non désiré.
+
RewriteCond expr "! %{HTTP_REFERER} -strmatch '*://%{HTTP_HOST}/*'"
+ RewriteRule "^/images" "-" [F]
+
+ Vous pouvez aussi définir certains drapeaux pour
+ l'expression_de_comparaison en ajoutant ces
+ [drapeaux]
+ comme troisième argument de la directive
+ RewriteCond, où drapeaux est un
+ sous-ensemble séparé par des virgules des drapeaux suivants :
nocase|NC'
+ (no case)ornext|OR'
+ (ou condition suivante)RewriteCond "%{REMOTE_HOST}" "^host1" [OR]
+RewriteCond "%{REMOTE_HOST}" "^host2" [OR]
+RewriteCond "%{REMOTE_HOST}" "^host3"
+RewriteRule ...règles concernant tous ces hôtes...
+
+
+ Sans ce drapeau, les paires
+ condition/règle devraient être écrites trois fois.
+ novary|NV'
+ (no vary)Exemple :
+ +Pour réécrire la page d'accueil d'un site en fonction de
+ l'en-tête ``User-Agent:'' de la requête, vous
+ pouvez utiliser ce qui suit :
RewriteCond "%{HTTP_USER_AGENT}" "(iPhone|Blackberry|Android)"
+RewriteRule "^/$" "/homepage.mobile.html" [L]
+
+RewriteRule "^/$" "/homepage.std.html" [L]
+
+
+ Explications : si vous utilisez un navigateur + qui s'identifie comme un + navigateur de plateforme mobile (notez que l'exemple est + incomplet car il existe de nombreuses autres plateformes + mobiles), c'est la version pour mobile de la page d'accueil qui + sera renvoyée. Dans le cas contraire, ce sera la page d'accueil + standard.
+ + +| Description: | Active ou désactive l'exécution du +moteur de réécriture |
|---|---|
| Syntaxe: | RewriteEngine on|off |
| Défaut: | RewriteEngine off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_rewrite |
La directive RewriteEngine active ou
+ désactive l'exécution du moteur de réécriture. Si sa valeur est
+ off, ce module n'exécutera aucun traitement et ne
+ mettra pas à jour les variables d'environnement
+ SCRIPT_URx.
Plutôt que de commenter toutes les directives RewriteRule, il est préférable
+ d'utiliser cette directive si l'on souhaite désactiver les
+ règles de réécriture dans un contexte particulier.
Notez que les hôtes virtuels n'héritent pas des
+ configurations de réécriture. Ceci implique que vous devez
+ insérer une directive RewriteEngine on dans chaque
+ hôte virtuel pour lequel vous souhaitez utiliser des règles
+ de réécriture.
Les directives RewriteMap du type
+ prg ne sont pas prises en compte au cours de
+ l'initialisation du serveur si elle ont été définies dans un
+ contexte où la directive RewriteEngine n'a
+ pas été définie à on.
| Description: | Définit une fonction de mise en correspondance pour la +recherche de mots-clés |
|---|---|
| Syntaxe: | RewriteMap MapName MapType:MapSource [MapTypeOptions]
+ |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_rewrite |
| Compatibilité: | Le troisième paramètre, MapTypeOptions, est disponible à partir +de la version 2.4.29 du serveur HTTP Apache |
La directive RewriteMap définit une
+ Table de correspondance pour la réécriture que les
+ fonctions de mise en correspondance
+ peuvent utiliser dans les chaînes de substitution des règles
+ pour insérer/substituer des champs en recherchant des mots-clés.
+ La source utilisée pour cette recherche peut être de plusieurs
+ types.
MapName est le nom de la table de correspondance + et servira à spécifier une fonction de mise en correspondance + pour les chaînes de substitution d'une règle de réécriture selon + une des constructions suivantes :
+ +
+ ${ MapName :
+ mot-clé }
+ ${ MapName :
+ mot-clé | valeur par défaut
+ }
+
Lorsqu'une telle construction est rencontrée, la table de + correspondance MapName est consultée + et la clé mot-clé recherchée. Si la clé est trouvée, la + construction est remplacée par + la valeur de remplacement. Si la clé n'est pas trouvée, + elle est remplacée par la valeur par défaut, ou par une + chaîne vide si aucune valeur par défaut n'est + spécifiée. La valeur vide se comporte comme si la + clé était absente ; il est donc impossible de distinguer une + valeur vide d'une absence de clé.
+ +Par exemple, vous pouvez définir une directive
+ RewriteMap comme suit
RewriteMap map-exemple "txt:/chemin/vers/fichier/map.txt"+ + +
Vous pourrez ensuite utiliser cette table dans une
+ directive RewriteRule comme suit :
RewriteRule "^/ex/(.*)" "${map-exemple:$1}"
+
+
+ La signification de l'argument MapTypeOptions dépend du MapType + spécifié. Veuillez vous référer au document Utiliser RewriteMap pour + plus de détails.
+ +Les combinaisons suivantes pour type de correspondance + et MapSource + peuvent être utilisées :
+ +httxt2dbm (Détails ...).RewriteMap: toupper, tolower, escape ou unescape
+ (Détails ...).Vous trouverez plus de détails et de nombreux exemples dans le RewriteMap HowTo.
+ + +| Description: | Configure certaines options spéciales +pour le moteur de réécriture |
|---|---|
| Syntaxe: | RewriteOptions Options |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_rewrite |
La directive RewriteOptions définit
+ certaines options spéciales pour la configuration au niveau du
+ serveur ou du répertoire. La chaîne de caractères Option
+ ne peut actuellement prendre qu'une des valeurs suivantes :
InheritCeci force la configuration locale à hériter de la
+ configuration du niveau supérieur. Dans le contexte des hôtes
+ virtuels, cela signifie que les correspondances, conditions et
+ règles du serveur principal sont héritées. Dans le contexte des
+ répertoires, cela signifie que les conditions et règles de la
+ configuration .htaccess ou les sections <Directory> du répertoire
+ parent sont héritées. Les règles héritées sont virtuellement
+ copiées dans la section où cette directive est utilisée. Si elles
+ sont utilisées avec des règles locales, les règles héritées sont
+ placées après ces dernières. La place de cette directive - avant
+ ou après les règles locales - n'a aucune influence sur ce
+ comportement. Si des règles locales ont forcé l'arrêt de la
+ réécriture, les règles héritées ne seront pas traitées.
InheritBeforeMême effet que l'option Inherit ci-dessus, mais
+ les règles spécifiées dans le niveau parent s'appliquent
+ avant les règles spécifiées dans le niveau
+ enfant.
+ Disponible depuis la version 2.3.10 du serveur HTTP Apache.
InheritDownSi cette option est activée, toutes les configurations enfants
+ hériteront de la configuration courante. Il en est de même si l'on
+ spécifie RewriteOptions Inherit dans toutes les
+ configurations enfants. Voir l'option Inherit pour
+ plus de détails à propos de la manière dont les relations
+ parent-enfants sont traitées.
+ Cette option est disponible à partir
+ de la version 2.4.8 du serveur HTTP Apache.
InheritDownBeforeL'effet de cette option est équivalent à celui de l'option
+ InheritDown ci-dessus, mais les règles de la
+ configuration parente s'appliquent avant toute
+ règle de la configuration enfant.
+ Cette option est disponible à partir
+ de la version 2.4.8 du serveur HTTP Apache.
IgnoreInheritSi cette option est activée, les configurations courante et
+ enfants ignoreront toute règle héritée d'une configuration parente
+ via les options InheritDown ou
+ InheritDownBefore.
+ Cette option est disponible à partir
+ de la version 2.4.8 du serveur HTTP Apache.
AllowNoSlashPar défaut, mod_rewrite ignore les URLs qui
+ correspondent à un répertoire sur disque, mais ne comportent pas
+ de slash final, afin que le module mod_dir
+ redirige le client vers l'URL canonique avec un slash final.
Lorsque la directive DirectorySlash est définie à off, il
+ est possible de spécifier l'option AllowNoSlash pour
+ s'assurer que les règles de réécriture ne soient plus ignorées.
+ Si on le souhaite, cette option permet de faire s'appliquer des
+ règles de réécriture qui correspondent à un répertoire sans slash
+ final au sein de fichiers .htaccess.
+ Elle est disponible à
+ partir de la version 2.4.0 du serveur HTTP Apache.
AllowAnyURIA partir de la version 2.2.22 de httpd, lorsqu'une directive RewriteRule se situe dans un
+ contexte de serveur virtuel ou de serveur principal,
+ mod_rewrite ne traitera les règles de réécriture
+ que si l'URI de la requête respecte la syntaxe d'un chemin URL. Ceci permet
+ d'éviter certains problèmes de sécurité où des règles
+ particulières pourraient permettre des développements de modèles
+ inattendus (voir CVE-2011-3368
+ et CVE-2011-4317).
+ Pour s'affranchir de la restriction relative à la syntaxe des chemins URL, on peut
+ utiliser l'option AllowAnyURI, afin de permettre à
+ mod_rewrite d'appliquer le jeu de règles à toute
+ chaîne de requête URI, sans vérifier si cette dernière respecte la
+ grammaire des chemins URL définie dans la spécification HTTP.
+ Disponible depuis la version 2.4.3 du serveur HTTP Apache.
L'utilisation de cette option rendra le serveur vulnérable à
+ certains problèmes de sécurité si les règles de réécritures
+ concernées n'ont pas été rédigées avec soin. Il est par conséquent
+ fortement recommandé de ne pas utiliser cette
+ option. En particulier, prêtez attention aux chaînes en entrée contenant le
+ caractère '@', qui peuvent modifier l'interprétation
+ de l'URI réécrite, comme indiqué dans les liens ci-dessus.
MergeBaseAvec cette option, la valeur de la directive RewriteBase est recopiée depuis
+ une valeur explicitement définie dans tout sous-répertoire qui ne
+ définit pas sa propre directive RewriteBase. Il s'agissait du
+ comportement par défaut avec les versions 2.4.0 à 2.4.3, et ce
+ drapeau qui permet de retrouver ce comportement est disponible
+ depuis la version 2.4.4 du serveur HTTP Apache.
IgnoreContextInfoLors d'une
+ substitution relative dans un contexte de répertoire (htaccess),
+ et si la directive RewriteBase n'a pas été définie,
+ ce module utilise des informations en provenance d'une extension
+ d'URL et du contexte du système de fichiers pour transformer la
+ sustitution relative en URL. Par exemple, les modules
+ mod_userdir et mod_alias
+ utilisent ces informations de contexte étendu. Disponible à partir de la
+ version 2.4.16 du serveur HTTP Apache.
LegacyPrefixDocRootAvant la version 2.4.26, si une substitution était une URL absolue qui
+ correspondait au serveur virtuel courant, l'URL pouvait être tout d'abord
+ réduite à sa partie chemin, puis enfin en chemin local. Comme l'URL peut
+ être réduite en chemin local, le chemin doit être préfixé par la
+ valeur de la directive DocumentRoot, ce qui permet d'interdire l'accès à
+ un fichier tel que /tmp/myfile suite à une requête pour
+ http://host/file/myfile avec la RewriteRule suivante :
RewriteRule /file/(.*) http://localhost/tmp/$1+ +
Cette option permet de restaurer l'ancien comportement lorsqu'un chemin + local obtenu à partir de la réduction d'une URL n'est pas préfixé par la + valeur de la directive DocumentRoot. Disponible à partir de la version + 2.4.26 du serveur HTTP Apache.
+| Description: | Définit les règles pour le moteur de réécriture |
|---|---|
| Syntaxe: | RewriteRule
+ Modèle Substitution [drapeaux] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_rewrite |
La directive RewriteRule est le
+ véritable cheval de trait de la réécriture. La directive peut
+ apparaître plusieurs fois, chaque instance définissant une
+ règle de réécriture particulière. L'ordre dans lequel ces règles
+ sont définies est important - il s'agit de l'ordre dans lequel
+ les règles seront appliquées au cours du processus de
+ réécriture.
Modèle est une
+ expression rationnelle
+ compatible perl. Ce avec quoi ce modèle est comparé dépend de l'endroit où
+ la directive RewriteRule est définie.
Dans un contexte de serveur virtuel VirtualHost, le modèle est tout
+ d'abord comparé à la portion de l'URL située entre le nom d'hôte
+ éventuellement accompagné du port, et la chaîne de paramètres (par
+ exemple "/app1/index.html"). Il s'agit du URL-path décodé de sa valeur "%xx".
Dans un contexte de répertoire (sections Directory et fichiers .htaccess), le
+ Modèle est comparé avec une partie de chemin ; par exemple une
+ requête pour "/app1/index.html" entraînera une comparaison avec
+ "app1/index.html" ou "index.html" selon l'endroit où la directive
+ RewriteRule est définie.
Le chemin où la règle est défini est supprimé du chemin correspondant + du système de fichiers avant comparaison (jusqu'au slash final compris). + En conséquence de cette suppression, les règles définies dans + ce contexte n'effectuent des comparaisons qu'avec la portion du chemin + du système de fichiers "en dessous" de l'endroit où la règle est définie.
+ +Le chemin correspondant actuel du système de fichiers est déterminé par
+ des directives telles que DocumentRoot et
+ Alias, ou même le résultat de
+ substitutions dans des règles RewriteRule précédentes.
+
Si vous souhaitez faire une comparaison sur le nom
+ d'hôte, le port, ou la chaîne de requête, utilisez une
+ directive RewriteCond
+ comportant respectivement les variables
+ %{HTTP_HOST}, %{SERVER_PORT}, ou
+ %{QUERY_STRING}.
<Directory> est un peu plus
+complexe.RewriteEngine On" et
+"Options FollowSymLinks". Si l'administrateur a désactivé
+la possibilité de modifier l'option FollowSymLinks au
+niveau du répertoire d'un utilisateur, vous ne pouvez pas utiliser le
+moteur de réécriture. Cette restriction a été instaurée à des fins de
+sécurité.RewriteBase pour plus de détails à
+propos de l'ajout du préfixe après les substitutions relatives.%{REQUEST_URI} dans la directive
+RewriteCond.^/ ne correspondra jamais dans un contexte de répertoire.<Location> et <Files> (y compris leurs versions sous forme
+d'expression rationnelle), elles n'y sont pas prises en compte, et
+n'y sont à priori d'aucune utilité. Les substitutions
+relatives sont une fonctionnalité qui n'est, elle non-plus pas supportée
+dans ce genre de contexte.Pour quelques conseils à propos des expressions rationnelles, voir le + document Introduction à + mod_rewrite.
+ +Dans mod_rewrite, on peut aussi utiliser le caractère
+ NOT ('!') comme préfixe de modèle. Ceci vous permet
+ d'inverser la signification d'un modèle, soit pour dire
+ ``si l'URL considérée ne correspond PAS à
+ ce modèle''. Le caractère NON peut donc être utilisé à
+ titre exceptionnel, lorsqu'il est plus simple d'effectuer une
+ comparaison avec le modèle inversé, ou dans la dernière règle
+ par défaut.
$N dans la chaîne de
+substitution !
+Dans une règle de réécriture, + Substitution est la chaîne + de caractères qui remplace le chemin de l'URL original qui + correspondait au Modèle. Substitution peut + être :
+ +DocumentRoot vers la ressource qui
+ doit être servie. Notez que mod_rewrite
+ essaie de deviner si vous avez spécifié un chemin du système
+ de fichiers ou un chemin d'URL en vérifiant si la première
+ partie du chemin existe à la racine du système de fichiers.
+ Par exemple, si vous avez spécifié comme chaîne de
+ Substitution /www/file.html, cette
+ dernière sera traitée comme un chemin d'URL à moins
+ qu'un répertoire nommé www n'existe à la racine
+ de votre système de fichiers (ou dans le cas d'une
+ réécriture au sein d'un fichier .htaccess,
+ relativement à la racine des documents), auquel cas la chaîne de
+ substitution sera traitée comme un chemin du système de
+ fichiers. Si vous désirez que d'autres directives de
+ correspondance d'URL (comme la directive Alias) soient appliquées au
+ chemin d'URL résultant, utilisez le drapeau [PT]
+ comme décrit ci-dessous.mod_rewrite vérifie si le nom d'hôte
+ correspond à celui de l'hôte local. Si c'est le cas, le
+ protocole et le nom d'hôte sont supprimés, et ce qui reste est
+ traité comme un chemin d'URL. Dans le cas contraire, une
+ redirection externe vers l'URL indiquée est effectuée. Pour
+ forcer une redirection externe vers l'hôte local, voir le
+ drapeau [R] ci-dessous.- (tiret)En plus du texte, la chaîne Substitution peut + comporter :
+ +$N) vers le modèle
+ d'une directive RewriteRule%N) vers le dernier
+ modèle d'une directive RewriteCond qui correspondait%{VARNAME})${nom correspondance:clé|défaut})Les références arrières sont des identificateurs de la forme
+ $N (N=0..9), qui
+ seront remplacés par le contenu du Nème groupe
+ du Modèle qui correspondait. Les variables du serveur
+ sont les mêmes que dans la Chaîne_de_test d'une
+ directive RewriteCond. Les
+ fonctions de comparaison sont issues de la directive RewriteMap dans la
+ section de laquelle elles sont décrites. Ces trois types de
+ variables sont évaluées dans l'ordre ci-dessus.
Chaque règle de réécriture s'applique au résultat de la règle
+ précédente, selon l'ordre dans lequel elles ont été définies dans
+ le fichier de configuration. Le chemin de l'URL ou du système de fichier (voir
+ ci-dessus Qu'est-ce qui est
+ comparé ?) est intégralement
+ remplacée par la chaîne de Substitution et le
+ processus de réécriture se poursuit jusqu'à ce que toutes les
+ règles aient été appliquées, ou qu'il soit explicitement stoppé
+ par un drapeau L,
+ ou par un autre drapeau qui implique un arrêt immédiat, comme
+ END ou
+ F.
Par défaut, la chaîne de requête est transmise sans
+ modification. Vous pouvez cependant créer dans la chaîne de
+ substitution des URLs dont une partie constitue une chaîne de
+ requête. Pour cela, ajoutez simplement un point d'interrogation
+ dans la chaîne de substitution pour indiquer que le texte qui
+ suit doit être réinjecté dans la chaîne de requête. Pour
+ supprimer une chaîne de requête, terminez simplement la chaîne de
+ substitution par un point d'interrogation. Pour combiner les
+ nouvelles chaînes de requête avec les anciennes, utilisez le
+ drapeau [QSA].
En outre, vous pouvez spécifier des actions spéciales à effectuer en ajoutant
+ des
+ [drapeaux]
+ comme troisième argument de la directive
+ RewriteRule. Séparés par des virgules au sein d'une
+ liste encadrée par des crochets, les drapeaux peuvent
+ être choisis dans la table suivante. Vous trouverez plus de
+ détails, et des exemples pour chaque drapeau dans le document à propos des drapeaux de
+ réécriture.
| Drapeaux et syntaxe | +Fonction | +
|---|---|
| B | +Echappe les caractères non-alphanumériques + dans les références arrières avant + d'appliquer la transformation. détails ... | +
| backrefnoplus|BNP | +Avec ce drapeau, si les références arrières sont échappées, + les espaces seront échappés en %20 au lieu de +. Ceci s'avère + utile lorsqu'une référence arrière est utilisée dans la partie + chemin, et non dans la chaîne de paramètres de la requête ; + pour plus de détails, voir ici. | +
| chain|C | +La règle est chaînée avec la règle suivante. Si la règle + échoue, la ou les règles avec lesquelles elle est est chaînée + seront sautées. détails ... | +
| cookie|CO=NAME:VAL | +Définit un cookie au niveau du navigateur client. La syntaxe + complète est : + CO=NAME:VAL:domain[:lifetime[:path[:secure[:httponly]]]] details ... + détails ... + | +
| discardpath|DPI | +Supprime la partie PATH_INFO de l'URI réécrit. détails + ... | +
| END | +Stoppe le processus de réécriture immédiatement et + n'applique plus aucune règle. Empêche aussi l'application + ultérieure de règles de réécriture dans les contextes de + répertoire et de fichier .htaccess (disponible à partir de la + version 2.3.9 du serveur HTTP Apache). détails ... | +
| env|E=[!]VAR[:VAL] | +Définit la variable d'environnement VAR (à la valeur + VAL si elle est fournie). La variante !VAR + annule la définition de la variable VAR.détails ... | +
| forbidden|F | +Renvoie une réponse 403 FORBIDDEN au navigateur client. + détails ... | +
| gone|G | +Renvoie un message d'erreur 410 GONE au navigateur client. détails ... | +
| Handler|H=Gestionnaire de contenu | +L'URI résultant est envoyé au Gestionnaire de + contenu pour traitement. détails ... | +
| last|L | +Arrête le processus de réécriture immédiatement et n'applique + plus aucune règle. Prêtez une attention particulière aux mises + en garde concernant les contextes de niveau répertoire et + .htaccess (voir aussi le drapeau END). détails ... | +
| next|N | +Réexécute le processus de réécriture à partir de la première + règle, en utilisant le résultat du jeu de règles, sous réserve + qu'il y ait un point de départ. détails + ... | +
| nocase|NC | +Rend la comparaison entre modèles insensible à la casse. + détails ... | +
| noescape|NE | +Empêche mod_rewrite d'effectuer un échappement hexadécimal + des caractères spéciaux dans le résultat de la réécriture. détails ... | +
| nosubreq|NS | +La règle est sautée si la requête courante est une + sous-requête interne. détails ... | +
| proxy|P | +Force l'envoi en interne de l'URL de substitution en tant + que requête mandataire. détails + ... | +
| passthrough|PT | +L'URI résultant est repassé au moteur de mise en
+ correspondance des URLs pour y être traité par d'autres
+ traducteurs URI-vers-nom de fichier, comme Alias ou
+ Redirect. détails ... |
+
| qsappend|QSA | +Ajoute toute chaîne de paramètres présente dans l'URL de la + requête originale à toute chaîne de paramètres créée dans la + cible de réécriture. détails ... | +
| qsdiscard|QSD | +Supprime toute chaîne de paramètres de l'URI entrant. détails + ... | +
| qslast|QSL | +Interprète le dernier (le plus à droite) point d'interrogation comme + le délimiteur de la chaîne de paramètres de la requête, au lieu du + premier (le plus à gauche) comme c'est le cas habituellement. Disponble + à partir de la version 2.4.19 du serveur HTTP Apache. détails ... | +
| redirect|R[=code] | +Force une redirection externe, avec un code de statut HTTP + optionnel. détails ... + | +
| skip|S=nombre | +Si la règle courante s'applique, le moteur de réécriture + doit sauter les nombre règles suivantes. détails ... | +
| type|T=MIME-type | +Force l'attribution du Type-MIME + spécifié au fichier cible. détails ... | +
Quand la chaîne de substitution commence par quelque chose comme
+"/~user" (de manière explicite ou par références arrières), mod_rewrite
+développe le répertoire home sans tenir compte de la présence ou de la
+configuration du module mod_userdir.
Ce développement n'est pas effectué si le drapeau PT est
+utilisé dans la directive RewriteRule
Voici toutes les combinaisons de substitution et leurs + significations :
+ +Dans la configuration au niveau du serveur principal
+ (httpd.conf)
+ pour la requête ``GET
+ /chemin/infochemin'':
+
| Règle | +Résultat de la substitution | +
|---|---|
| ^/un_chemin(.*) autre_chemin$1 | +invalide, non supporté | +
| ^/un_chemin(.*) autre_chemin$1 [R] | +invalide, non supporté | +
| ^/un_chemin(.*) autre_chemin$1 [P] | +invalide, non supporté | +
| ^/un_chemin(.*) /autre_chemin$1 | +/autre_chemin/info_chemin | +
| ^/un_chemin(.*) /autre_chemin$1 [R] | +http://cet_hote/autre_chemin/info_chemin via une redirection externe | +
| ^/un_chemin(.*) /autre_chemin$1 [P] | +sans objet, non supporté | +
| ^/un_chemin(.*) http://cet_hote/autre_chemin$1 | +/autre_chemin/info_chemin | +
| ^/un_chemin(.*) http://cet_hote/autre_chemin$1 [R] | +http://cet_hote/autre_chemin/info_chemin via une redirection externe | +
| ^/un_chemin(.*) http://cet_hote/autre_chemin$1 [P] | +sans objet, non supporté | +
| ^/un_chemin(.*) http://autre_hote/autre_chemin$1 | +http://autre_hote/autre_chemin/info_chemin via une redirection externe | +
| ^/un_chemin(.*) http://autre_hote/autre_chemin$1 [R] | +http://autre_hote/autre_chemin/info_chemin (le drapeau [R] est +redondant) | +
| ^/somepath(.*) http://otherhost/otherpath$1 [P] | +http://otherhost/otherpath/pathinfo via internal proxy | +
Dans une configuration de niveau répertoire pour
+ /chemin
+ (/chemin/physique/vers/chemin/.htacccess, avec
+ RewriteBase "/chemin")
+ pour la requête ``GET
+ /chemin/chemin-local/infochemin'':
+
| Règle | +Résultat de la substitution | +
|---|---|
| ^chemin-local(.*) autre-chemin$1 | +/chemin/autre-chemin/infochemin | +
| ^chemin-local(.*) autre-chemin$1 [R] | +http://cet-hôte/chemin/autre-chemin/infochemin via redirection +externe | +
| ^chemin-local(.*) autre-chemin$1 [P] | +n'a pas lieu d'être, non supporté | +
| ^chemin-local(.*) /autre-chemin$1 | +/autre-chemin/infochemin | +
| ^chemin-local(.*) /autre-chemin$1 [R] | +http://cet-hôte/autre-chemin/infochemin via redirection externe | +
| ^chemin-local(.*) /autre-chemin$1 [P] | +n'a pas lieu d'être, non supporté | +
| ^chemin-local(.*) http://cet-hôte/autre-chemin$1 | +/autre-chemin/infochemin | +
| ^chemin-local(.*) http://cet-hôte/autre-chemin$1 [R] | +http://cet-hôte/autre-chemin/infochemin via redirection externe | +
| ^chemin-local(.*) http://cet-hôte/autre-chemin$1 [P] | +n'a pas lieu d'être, non supporté | +
| ^chemin-local(.*) http://autre hôte/autre-chemin$1 | +http://autre hôte/autre-chemin/infochemin via redirection externe | +
| ^chemin-local(.*) http://autre hôte/autre-chemin$1 [R] | +http://autre hôte/autre-chemin/infochemin via redirection externe +(le drapeau [R] est redondant) | +
| ^chemin-local(.*) http://autre hôte/autre-chemin$1 [P] | +http://autre hôte/autre-chemin/infochemin via un mandataire interne | +
Serveur HTTP Apache Version 2.4
+| Description: | Filtre les contenus en entrée (requêtes) et en sortie
+(réponses) en utilisant la syntaxe de sed |
|---|---|
| Statut: | |
| Identificateur de Module: | sed_module |
| Fichier Source: | mod_sed.c sed0.c sed1.c regexp.c regexp.h sed.h |
| Compatibilité: | Disponible depuis la version 2.3 d'Apache |
mod_sed est un filtre de contenu "in-process". Le
+filtre mod_sed fournit les commandes d'édition de
+sed implémentées par le programme sed de
+Solaris 10 comme décrit dans la page de
+manuel. Cependant, à la différence de sed,
+mod_sed ne reçoit pas de données sur son entrée
+standard. Au lieu de cela, le filtre agit sur les données échangées
+entre le client et le serveur. mod_sed peut être
+utilisé comme filtre en entrée ou en sortie. mod_sed
+est un filtre de contenu, ce qui signifie qu'on ne peut pas l'utiliser
+pour modifier les en-têtes http du client ou du serveur.
+
+Le filtre en sortie mod_sed accepte un tronçon de
+données, exécute le script sed sur ces données, puis génère
+une sortie qui est transmise au filtre suivant dans la chaîne.
+
+Le filtre en entrée mod_sed reçoit des données en
+provenance du filtre suivant dans la chaîne, exécute les scripts
+sed, et renvoie les données générées au filtre appelant
+dans la chaîne de filtrage.
+
+Les filtres en entrée ou en sortie ne traitent les données que si des +caractères newline sont détectés dans le contenu à filtrer. A la fin des +données, ce qui reste est traité comme la dernière ligne. +
+ +# Dans l'exemple suivant, le filtre sed va remplacer la chaîne + # "monday" par "MON" et la chaîne "sunday" par "SUN" dans les + # documents html avant de les envoyer au client. +<Directory "/var/www/docs/sed"> + AddOutputFilter Sed html + OutputSed "s/monday/MON/g" + OutputSed "s/sunday/SUN/g" +</Directory>+
# Dans l'exemple suivant, le filtre sed va remplacer la chaîne + # "monday" par "MON" et la chaîne "sunday" par "SUN" dans les + # données POST envoyées à PHP. + <Directory "/var/www/docs/sed"> + AddInputFilter Sed php + InputSed "s/monday/MON/g" + InputSed "s/sunday/SUN/g" +</Directory>+
+ Vous trouverez tous les détails à propos de la commande
+ sed dans sa page
+ de manuel.
+
bhHgGx| Description: | Commande sed à exécuter pour le filtrage des données d'une
+requête (en général des données POST) |
|---|---|
| Syntaxe: | InputSed commande-sed |
| Contexte: | répertoire, .htaccess |
| Statut: | |
| Module: | mod_sed |
La directive InputSed permet de spécifier
+ la commande sed à exécuter pour le filtrage des données (en général
+ des données POST) d'une requête.
+
| Description: | Commande sed pour le filtrage des contenus de type +réponse |
|---|---|
| Syntaxe: | OutputSed commande-sed |
| Contexte: | répertoire, .htaccess |
| Statut: | |
| Module: | mod_sed |
La directive OutputSed permet de spécifier
+ la commande sed à exécuter dans le cadre du traitement
+ d'une réponse.
+
Serveur HTTP Apache Version 2.4
+| Description: | Support des sessions |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | session_module |
| Fichier Source: | mod_session.c |
| Compatibilité: | Disponible depuis la version 2.3 d'Apache |
Le module session fait usage des cookies HTTP, et peut à ce + titre être victime d'attaques de type Cross Site Scripting, ou + divulguer des informations à caractère privé aux clients. Veuillez + vous assurer que les risques ainsi encourus ont été pris en compte + avant d'activer le support des sessions sur votre serveur.
+Ce module fournit le support d'une interface de session pour + chaque utilisateur au niveau du serveur global. Les sessions + permettent de transmettre diverses informations : l'utilisateur + est-il connecté ou non, ou toute autre information qui doit être + conservée d'une requête à l'autre.
+ +Les sessions peuvent être stockées sur le serveur, ou au niveau
+ du navigateur. Les sessions peuvent également être chiffrées pour une
+ sécurité accrue. Ces fonctionnalités sont réparties entre différents
+ modules complémentaires de mod_session :
+ mod_session_crypto,
+ mod_session_cookie et
+ mod_session_dbd. Chargez les modules appropriés
+ en fonction des besoins du serveur (soit statiquement à la
+ compilation, soit dynamiquement via la directive LoadModule).
Les sessions peuvent être manipulées par d'autres modules qui + dépendent de la session, ou la session peut être lue et écrite dans + des variables d'environnement et des en-têtes HTTP, selon les + besoins.
+ + Qu'est-ce qu'une session ? Qui peut utiliser une session
+ ? Stockage des sessions sur le
+ serveur Stockage des sessions au niveau
+ du navigateur Exemples simples Confidentialité des
+ sessions Confidentialité du cookie Support des sessions pour
+ l'authentification Intégration des sessions avec les
+ applications externes Session SessionEnv SessionExclude SessionHeader SessionInclude SessionMaxAgeAu coeur de l'interface de session se trouve une table de + paires clé/valeur qui sont accessibles d'une requête du navigateur + à l'autre. Les valeurs de clés peuvent se voir affecter toute chaîne + de caractères valide, en fonction des besoins de l'application qui + fait usage de la session.
+ +Une "session" est une chaîne + application/x-www-form-urlencoded qui contient la + paire clé/valeur définie par la spécification HTML.
+ +Selon les souhaits de l'administrateur, la session peut être + chiffrée et codée en base64 avant d'être soumise au dispositif de + stockage.
+ +L'interface de session a été conçue à l'origine pour être
+ utilisée par d'autres modules du serveur comme
+ mod_auth_form ; les applications à base de
+ programmes CGI peuvent cependant se voir accorder l'accès au
+ contenu d'une session via la variable d'environnement
+ HTTP_SESSION. Il est possible de modifier et/ou de mettre à jour
+ une session en insérant un en-tête de réponse HTTP contenant les
+ nouveaux paramètres de session.
Apache peut être configuré pour stocker les sessions + utilisateurs sur un serveur particulier ou un groupe de serveurs. + Cette fonctionnalité est similaire aux sessions disponibles sur + les serveurs d'applications courants.
+ +Selon la configuration, les sessions sont suivies à + partir d'un identifiant de session stocké dans un cookie, ou + extraites de la chaîne de paramètres de l'URL, comme dans les + requêtes GET courantes.
+ +Comme le contenu de la session est stocké exclusivement sur le + serveur, il est nécessaire de préserver la confidentialité de ce + contenu. Ceci a des implications en matière de performance et de + consommation de ressources lorsqu'un grand nombre de sessions est + stocké, ou lorsqu'un grand nombre de serveurs doivent se partager + les sessions entre eux.
+ +Le module mod_session_dbd permet de stocker
+ les sessions utilisateurs dans une base de données SQL via le
+ module mod_dbd.
Dans les environnements à haut trafic où le stockage d'une + session sur un serveur consomme trop + de ressources, il est possible de stocker le contenu de la session + dans un cookie au niveau du navigateur client.
+ +Ceci a pour avantage de ne nécessiter qu'une quantité minimale de + ressources sur le serveur pour suivre les sessions, et évite à + plusieurs serveurs parmi une forêt de serveurs de devoir partager + les informations de session.
+ +Le contenu de la session est cependant présenté au client, avec
+ pour conséquence un risque de perte de confidentialité. Le module
+ mod_session_crypto peut être configuré pour
+ chiffrer le contenu de la session avant qu'elle soit stockée au
+ niveau du client.
Le module mod_session_cookie permet de stocker
+ les sessions au niveau du navigateur dans un cookie HTTP.
La création d'une session consiste simplement à ouvrir la
+ session, et à décider de l'endroit où elle doit être stockée. Dans
+ l'exemple suivant, la session sera stockée au niveau du
+ navigateur, dans un cookie nommé session.
Session On +SessionCookieName session path=/+
Une session est inutile s'il n'est pas possible d'y lire
+ ou d'y écrire. L'exemple suivant montre comment des valeurs
+ peuvent être injectées dans une session à l'aide d'un en-tête de
+ réponse HTTP prédéterminé nommé
+ X-Replace-Session.
Session On +SessionCookieName session path=/ +SessionHeader X-Replace-Session+
L'en-tête doit contenir des paires clé/valeur sous le même + format que celui de la chaîne d'argument d'une URL, comme dans + l'exemple suivant. Donner pour valeur à une clé la chaîne vide a + pour effet de supprimer la clé de la session.
+ +#!/bin/bash +echo "Content-Type: text/plain" +echo "X-Replace-Session: key1=foo&key2=&key3=bar" +echo +env+
Selon la configuration, les informations de la session peuvent
+ être extraites de la variable d'environnement HTTP_SESSION. Par
+ défaut la session est privée, et cette fonctionnalité doit donc
+ être explicitement activée via la directive SessionEnv.
Session On +SessionEnv On +SessionCookieName session path=/ +SessionHeader X-Replace-Session+
Une fois la lecture effectuée, la variable CGI
+ HTTP_SESSION doit contenir la valeur
+ clé1=foo&clé3=bar.
En utilisant la fonctionnalité de votre navigateur "Afficher + les cookies", vous pouvez voir une réprésentation de la session + sous forme de texte en clair. Ceci peut poser problème si le + contenu de la session doit être dissimulé à l'utilisateur final, + ou si un tiers accède sans autorisation aux informations de + session.
+ +À ce titre, le contenu de la session peut être chiffré à l'aide
+ du module mod_session_crypto avant d'être stocké
+ au niveau du navigateur.
Session On +SessionCryptoPassphrase secret +SessionCookieName session path=/+
La session sera automatiquement déchiffrée à la lecture, et + rechiffrée par Apache lors de la sauvegarde, si bien que + l'application sous-jacente qui utilise la session n'a pas à se + préoccuper de savoir si un chiffrement a été mis en oeuvre ou + non.
+ +Les sessions stockées sur le serveur plutôt qu'au niveau du
+ navigateur peuvent aussi être chiffrées, préservant par là-même la
+ confidentialité lorsque des informations sensibles sont partagées
+ entre les serveurs web d'une forêt de serveurs à l'aide du module
+ mod_session_dbd.
Le mécanisme de cookie HTTP offre aussi des fonctionnalités + quant à la confidentialité, comme la possibilité de + restreindre le transport du cookie aux pages protégées par SSL + seulement, ou l'interdiction pour les scripts java qui + s'exécutent au niveau du navigateur d'obtenir l'accès au contenu + du cookie.
+ +Certaines fonctionnalités de confidentialité du cookie HTTP ne
+ sont pas standardisées, ou ne sont pas toujours implémentées au
+ niveau du navigateur. Les modules de session vous permettent de
+ définir les paramètres du cookie, mais il n'est pas garanti que la
+ confidentialité sera respectée par le navigateur. Si la sécurité
+ est la principale préoccupation, chiffrez le contenu de la session
+ avec le module mod_session_crypto, ou stockez la
+ session sur le serveur avec le module
+ mod_session_dbd.
Les paramètres standards du cookie peuvent être spécifiés après + le nom du cookie comme dans l'exemple suivant :
+ +Session On +SessionCryptoPassphrase secret +SessionCookieName session path=/private;domain=example.com;httponly;secure;+
Dans les cas où le serveur Apache sert de frontal pour des
+ serveurs d'arrière-plan, il est possible de supprimer les cookies
+ de session des en-têtes HTTP entrants à l'aide de la directive
+ SessionCookieRemove. Ceci
+ permet d'empêcher les serveurs d'arrière-plan d'accéder au contenu
+ des cookies de session.
+
Comme il est possible de le faire avec de nombreux serveurs
+ d'applications, les modules d'authentification peuvent utiliser
+ une session pour stocker le nom d'utilisateur et le mot de passe
+ après connexion. Le module mod_auth_form par
+ exemple, sauvegarde les nom de connexion et mot de passe de
+ l'utilisateur dans une session.
Session On +SessionCryptoPassphrase secret +SessionCookieName session path=/ +AuthFormProvider file +AuthUserFile "conf/passwd" +AuthType form +AuthName realm +#...+
Pour la documentation et des exemples complets, voir le module
+ mod_auth_form.
Pour que les sessions soient utiles, leur contenu doit être + accessible aux applications externes, et ces dernières doivent + elles-mêmes être capables d'écrire une session.
+ +L'exemple type est une application qui modifie le mot de passe
+ d'un utilisateur défini par mod_auth_form. Cette
+ application doit pouvoir extraire les nom d'utilisateur et mot de
+ passe courants de la session, effectuer les modifications
+ demandées, puis écrire le nouveau mot de passe dans la session,
+ afin que la transition vers le nouveau mot de passe soit
+ transparente.
Un autre exemple met en jeu une application qui enregistre un + nouvel utilisateur pour la première fois. Une fois + l'enregistrement terminé, le nom d'utilisateur et le mot de passe + sont écrits dans la session, fournissant là aussi une transition + transparente.
+ +mod_auth_form
+ utilisent ce mécanisme.
+ SessionEnv. Un script peut écrire
+ dans la session en renvoyant un en-tête de réponse
+ application/x-www-form-urlencoded dont le nom est
+ défini via la directive SessionHeader. Dans les deux cas,
+ tout chiffrement ou déchiffrement, ainsi que la lecture ou
+ l'écriture de ou vers la session à partir du mécanisme de stockage
+ choisi sont gérés par le module mod_session et la
+ configuration correspondante.
+ mod_proxySessionHeader est utilisée pour
+ définir un en-tête de requête HTTP, la session codée sous la forme
+ d'une chaîne application/x-www-form-urlencoded
+ sera accessible pour l'application. Si ce même en-tête est fourni
+ dans la réponse, sa valeur sera utilisée pour remplacer la
+ session. Comme précédemment, tout chiffrement ou déchiffrement,
+ ainsi que la lecture ou
+ l'écriture de ou vers la session à partir du mécanisme de stockage
+ choisi sont gérés par le module mod_session et la
+ configuration correspondante.| Description: | Ouvre une session pour le contexte courant |
|---|---|
| Syntaxe: | Session On|Off |
| Défaut: | Session Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_session |
La directive Session permet d'ouvrir une
+ session pour le contexte ou conteneur courant. Les directives
+ suivantes permettent de définir où la session sera stockée et
+ comment sera assurée la confidentialité.
| Description: | Définit si le contenu de la session doit être enregistré +dans la variable d'environnement HTTP_SESSION |
|---|---|
| Syntaxe: | SessionEnv On|Off |
| Défaut: | SessionEnv Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_session |
Lorsque la directive SessionEnv est
+ définie à On, le contenu de la session est enregistré
+ dans une variable d'environnement CGI nommée
+ HTTP_SESSION.
La chaîne est écrite sous le même format que celui de la chaîne + d'arguments d'une URL, comme dans l'exemple suivant :
+ +
+ clé1=foo&clé3=bar
+
| Description: | Définit les préfixes d'URLs pour lesquels une session sera +ignorée |
|---|---|
| Syntaxe: | SessionExclude chemin |
| Défaut: | none |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_session |
La directive SessionExclude permet de
+ définir les préfixes d'URLs pour lesquels la session sera
+ désactivée. Ceci peut améliorer l'efficacité d'un site web, en
+ ciblant de manière plus précise l'espace d'URL pour lequel une
+ session devra être maintenue. Par défaut, toutes les URLs du
+ contexte ou du conteneur courant sont incluses dans la session. La
+ directive SessionExclude
+ l'emporte sur la directive SessionInclude.
Cette directive a un comportement similaire à celui de l'attribut + chemin des cookies HTTP, mais ne doit pas être confondue + avec cet attribut. En effet, cette directive ne définit pas + l'attribut chemin, qui doit être configuré + séparément.
| Description: | Importation des mises à jour de session depuis l'en-tête de +réponse HTTP spécifié |
|---|---|
| Syntaxe: | SessionHeader en-tête |
| Défaut: | none |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_session |
La directive SessionHeader permet de
+ définir le nom d'un en-tête de réponse HTTP qui, s'il est présent,
+ sera lu et son contenu écrit dans la session courante.
Le contenu de l'en-tête doit se présenter sous le même format que + celui de la chaîne d'arguments d'une URL, comme dans l'exemple + suivant :
+ +
+ clé1=foo&clé2=&clé3=bar
+
Si une clé a pour valeur la chaîne vide, elle sera supprimée de + la session.
+ + +| Description: | Définit les préfixes d'URL pour lesquels une session est +valide |
|---|---|
| Syntaxe: | SessionInclude chemin |
| Défaut: | toutes URLs |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_session |
La directive SessionInclude permet de
+ définir les préfixes d'URL spécifiques pour lesquels une session
+ sera valide. Ceci peut améliorer l'efficacité d'un site web, en
+ ciblant de manière plus précise l'espace d'URL pour lequel une
+ session devra être maintenue. Par défaut, toutes les URLs du
+ contexte ou du conteneur courant sont incluses dans la session.
Cette directive a un comportement similaire à celui de l'attribut + chemin des cookies HTTP, mais ne doit pas être confondue + avec cet attribut. En effet, cette directive ne définit pas + l'attribut chemin, qui doit être configuré séparément.
| Description: | Définit une durée de vie maximale pour la session en +secondes |
|---|---|
| Syntaxe: | SessionMaxAge durée de vie maximale |
| Défaut: | SessionMaxAge 0 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_session |
La directive SessionMaxAge permet de
+ définir la durée maximale pendant laquelle une session restera
+ valide. Lorsqu'une session est sauvegardée, cette durée est
+ réinitialisée et la session peut continuer d'exister. Si la durée
+ d'une session dépasse cette limite sans qu'une requête au serveur ne
+ vienne la rafraîchir, la session va passer hors délai et sera
+ supprimée. Lorsqu'une session est utilisée pour stocker les
+ informations de connexion d'un utilisateur, ceci aura pour effet de
+ le déconnecter automatiquement après le délai spécifié.
Donner à cette directive la valeur 0 empêche l'expiration de la + session.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Support des sessions basé sur les cookies |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | session_cookie_module |
| Fichier Source: | mod_session_cookie.c |
| Compatibilité: | Disponible depuis la version 2.3 d'Apache |
Les modules de session font usage des cookies HTTP, et peuvent + à ce titre être victimes d'attaques de type Cross Site Scripting, + ou divulguer des informations à caractère privé aux clients. + Veuillez vous assurer que les risques ainsi encourus ont été pris + en compte avant d'activer le support des sessions sur votre + serveur.
+Ce sous-module du module mod_session fournit le
+ support du stockage des sessions utilisateur au niveau du navigateur
+ distant dans des cookies HTTP.
L'utilisation de cookies pour stocker les sessions décharge le + serveur ou le groupe de serveurs de la nécessité de stocker les + sessions localement, ou de collaborer pour partager les sessions, et + peut être utile dans les environnements à fort trafic où le stockage + des sessions sur le serveur pourrait s'avérer trop consommateur de + ressources.
+ +Si la confidentialité de la session doit être préservée, le
+ contenu de cette dernière peut être chiffré avant d'être enregistré
+ au niveau du client à l'aide du module
+ mod_session_crypto.
Pour plus de détails à propos de l'interface des sessions, voir
+ la documentation du module mod_session.
Pour créer une session et la stocker dans un cookie nommé + session, configurez-la comme suit :
+ +Session On +SessionCookieName session path=/+
Pour plus d'exemples sur la manière dont une session doit être
+ configurée pour qu'une application CGI puisse l'utiliser, voir la
+ section exemples de la documentation du module
+ mod_session.
Pour des détails sur la manière dont une session peut être
+ utilisée pour stocker des informations de type nom
+ d'utilisateur/mot de passe, voir la documentation du module
+ mod_auth_form.
| Description: | Nom et attributs du cookie RFC2109 dans lequel la session +est stockée |
|---|---|
| Syntaxe: | SessionCookieName nom attributs |
| Défaut: | none |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_session_cookie |
La directive SessionCookieName permet de
+ spécifier le nom et les attributs optionnels d'un cookie compatible
+ RFC2109 dans lequel la session sera stockée. Les cookies RFC2109
+ sont définis en utilisant l'en-tête HTTP Set-Cookie.
+
Une liste optionnelle d'attributs peut être spécifiée, comme dans + l'exemple suivant. Ces attributs sont insérés tels quels dans le + cookie, et ne sont pas interprétés par Apache. Assurez-vous que vos + attributs soient définis correctement selon la spécification des + cookies. +
+ +Session On +SessionCookieName session path=/private;domain=example.com;httponly;secure;version=1;+
| Description: | Nom et attributs pour le cookie RFC2965 dans lequel est +stockée la session |
|---|---|
| Syntaxe: | SessionCookieName2 nom attributs |
| Défaut: | none |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_session_cookie |
La directive SessionCookieName2 permet de
+ spécifier le nom et les attributs optionnels d'un cookie compatible
+ RFC2965 dans lequel la session sera stockée. Les cookies RFC2965
+ sont définis en utilisant l'en-tête HTTP
+ Set-Cookie2.
+
Une liste optionnelle d'attributs peut être spécifiée, comme dans + l'exemple suivant. Ces attributs sont insérés tels quels dans le + cookie, et ne sont pas interprétés par Apache. Assurez-vous que vos + attributs soient définis correctement selon la spécification des + cookies. +
+ +Session On +SessionCookieName2 session path=/private;domain=example.com;httponly;secure;version=1;+
| Description: | Détermine si les cookies de session doivent être supprimés +des en-têtes HTTP entrants |
|---|---|
| Syntaxe: | SessionCookieRemove On|Off |
| Défaut: | SessionCookieRemove Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_session_cookie |
La directive SessionCookieRemove permet de
+ déterminer si les cookies contenant la session doivent être
+ supprimés des en-têtes pendant le traitement de la requête.
Dans le cas d'un mandataire inverse où le serveur Apache sert de + frontal à un serveur d'arrière-plan, révéler le contenu du cookie de + session à ce dernier peut conduire à une violation de la + confidentialité. À ce titre, si cette directive est définie à "on", + le cookie de session sera supprimé des en-têtes HTTP entrants.
+ + +Serveur HTTP Apache Version 2.4
+| Description: | Support du chiffrement des sessions |
|---|---|
| Statut: | Expérimental |
| Identificateur de Module: | session_crypto_module |
| Fichier Source: | mod_session_crypto.c |
| Compatibilité: | Disponible depuis la version 2.3 d'Apache |
Les modules de session font usage des cookies HTTP, et peuvent + à ce titre être victimes d'attaques de type Cross Site Scripting, + ou divulguer des informations à caractère privé aux clients. + Veuillez vous assurer que les risques ainsi encourus ont été pris + en compte avant d'activer le support des sessions sur votre + serveur.
+Ce sous-module du module mod_session fournit le
+ support du chiffrement des sessions utilisateur avant de les
+ enregistrer dans une base de données locale, ou dans un cookie HTTP
+ au niveau du navigateur distant.
Il peut contribuer à préserver la confidentialité des sessions + lorsque leur contenu doit rester privé pour + l'utilisateur, ou lorsqu'une protection contre les attaques de type + cross site scripting est nécessaire.
+ +Pour plus de détails à propos de l'interface des sessions, voir
+ la documentation du module mod_session.
SessionCryptoCipher SessionCryptoDriver SessionCryptoPassphrase SessionCryptoPassphraseFilePour créer une session chiffrée et la stocker dans un cookie + nommé session, configurez la comme suit :
+ +Session On +SessionCookieName session path=/ +SessionCryptoPassphrase secret+
La session sera chiffrée avec la clé spécifiée. Il est possible + de configurer plusieurs serveurs pour qu'ils puissent partager des + sessions, en s'assurant que la même clé de chiffrement est + utilisée sur chaque serveur.
+ +Si la clé de chiffrement est modifiée, les sessions seront + automatiquement invalidées.
+ +Pour des détails sur la manière dont une session peut être
+ utilisée pour stocker des informations de type nom
+ d'utilisateur/mot de passe, voir la documentation du module
+ mod_auth_form.
| Description: | L'algorithme à utiliser pour le chiffrement de la session |
|---|---|
| Syntaxe: | SessionCryptoCipher algorithme |
| Défaut: | aes256 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Expérimental |
| Module: | mod_session_crypto |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP Apache |
La directive SessionCryptoCipher permet de
+ spécifier l'algorithme à utiliser pour le chiffrement. En l'absence
+ de spécification, l'algorithme par défaut est aes256.
L'algorithme peut être choisi, en fonction du moteur de chiffrement + utilisé, parmi les valeurs suivantes :
+ +| Description: | Le pilote de chiffrement à utiliser pour chiffrer les +sessions |
|---|---|
| Syntaxe: | SessionCryptoDriver nom [param[=valeur]] |
| Défaut: | aucun |
| Contexte: | configuration globale |
| Statut: | Expérimental |
| Module: | mod_session_crypto |
| Compatibilité: | Disponible depuis la version 2.3.0 +d'Apache |
La directive SessionCryptoDriver permet de
+ spécifier le nom du pilote à utiliser pour le chiffrement. Si aucun
+ pilote n'est spécifié, le pilote utilisé par défaut sera le pilote
+ recommandé compilé avec APR-util.
Le pilote de chiffrement NSS nécessite certains + paramètres de configuration, qui seront spécifiés comme arguments de + la directive avec des valeurs optionnelles après le nom du + pilote.
+ +SessionCryptoDriver nss+
SessionCryptoDriver nss dir=certs+
SessionCryptoDriver nss dir=certs clé3=clé3.db cert7=cert7.db secmod=secmod+
SessionCryptoDriver nss "dir=My Certs" key3=key3.db cert7=cert7.db secmod=secmod+
Le pilote de chiffrement NSS peut avoir été configuré
+ au préalable dans une autre partie du serveur, par exemple depuis
+ mod_nss ou mod_ldap. Si c'est le
+ cas, un avertissement sera enregistré dans le journal, et la
+ configuration existante s'en trouvera affectée. Pour éviter cet
+ avertissement, utilisez le paramètre noinit comme suit :
SessionCryptoDriver nss noinit+
Pour éviter la confusion, assurez-vous que tous les modules + utilisant NSS soient configurés avec des paramètres identiques.
+ +Le pilote de chiffrement openssl accepte un paramètre + optionnel permettant de spécifier le moteur de chiffrement à + utiliser.
+ +SessionCryptoDriver openssl engine=nom-moteur+
| Description: | La clé utilisée pour chiffrer la session |
|---|---|
| Syntaxe: | SessionCryptoPassphrase secret [ secret ... ] |
| Défaut: | none |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Expérimental |
| Module: | mod_session_crypto |
| Compatibilité: | Disponible depuis la version 2.3.0 +d'Apache |
La directive SessionCryptoPassphrase
+ permet de spécifier les clés à utiliser pour chiffrer de manière
+ symétrique le contenu de la session avant de l'enregistrer, ou pour
+ déchiffrer le contenu de la session après sa lecture.
L'utilisation de clés longues et composées de caractères vraiment + aléatoires est plus performant en matière de sécurité. Modifier une + clé sur un serveur a pour effet d'invalider toutes les sessions + existantes.
+ +Il est possible de spécifier plusieurs clés afin de mettre en + oeuvre la rotation de clés. La première clé spécifiée sera utilisée + pour le chiffrement, alors que l'ensemble des clés spécifiées le + sera pour le déchiffrement. Pour effectuer une rotation périodique + des clés sur plusieurs serveurs, ajoutez une nouvelle clé en fin de + liste, puis, une fois la rotation complète effectuée, supprimez la + première clé de la liste.
+ +Depuis la version 2.4.7, si la valeur de l'argument commence par exec: , la commande + spécifiée sera exécutée, et la première ligne que cette dernière + renverra sur la sortie standard sera utilisée comme clé.
+# clé spécifiée et utilisée en tant que tel +SessionCryptoPassphrase secret + +# exécution de /path/to/program pour générer la clé +SessionCryptoPassphrase exec:/path/to/program + +# exécution de /path/to/program avec un argument pour générer la clé +SessionCryptoPassphrase "exec:/path/to/otherProgram argument1"
| Description: | Le fichier contenant les clés utilisées pour chiffrer la +session |
|---|---|
| Syntaxe: | SessionCryptoPassphraseFile nom-fichier |
| Défaut: | none |
| Contexte: | configuration globale, serveur virtuel, répertoire |
| Statut: | Expérimental |
| Module: | mod_session_crypto |
| Compatibilité: | Disponible depuis la version 2.3.0 du serveur HTTP Apache |
La directive SessionCryptoPassphraseFile
+ permet de spécifier le nom d'un fichier de configuration contenant
+ les clés à utiliser pour le chiffrement et le déchiffrement de la
+ session (une clé par ligne). Le fichier est lu au démarrage du
+ serveur, et un redémarrage graceful est nécessaire pour prendre en
+ compte un éventuel changement de clés.
À la différence de la directive
+ SessionCryptoPassphrase, les clés ne sont pas
+ présentes dans le fichier de configuration de httpd et peuvent être
+ cachées via une protection appropriée du fichier de clés.
Il est possible de spécifier plusieurs clés afin de mettre en + oeuvre la rotation de clés. La première clé spécifiée sera utilisée + pour le chiffrement, alors que l'ensemble des clés spécifiées le + sera pour le déchiffrement. Pour effectuer une rotation périodique + des clés sur plusieurs serveurs, ajoutez une nouvelle clé en fin de + liste, puis, une fois la rotation complète effectuée, supprimez la + première clé de la liste.
+ + +Serveur HTTP Apache Version 2.4
+| Description: | Support des session basé sur DBD/SQL |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | session_dbd_module |
| Fichier Source: | mod_session_dbd.c |
| Compatibilité: | Disponible depuis la version 2.3 d'Apache |
Les modules de session font usage des cookies HTTP, et peuvent + à ce titre être victimes d'attaques de type Cross Site Scripting, + ou divulguer des informations à caractère privé aux clients. + Veuillez vous assurer que les risques ainsi encourus ont été pris + en compte avant d'activer le support des sessions sur votre + serveur.
+Ce sous-module du module mod_session fournit le
+ support du stockage des sessions utilisateur dans une base de
+ données SQL en utilisant le module mod_dbd.
Les sessions sont soit anonymes, et la session + est alors identifiée par un UUID unique stocké dans un cookie au + niveau du navigateur, soit propres à l'utilisateur, + et la session est alors identifiée par l'identifiant de + l'utilisateur connecté.
+ +Les sessions basées sur SQL sont dissimulées au navigateur, et + permettent ainsi de préserver la confidentialité sans avoir recours + au chiffrement.
+ +Plusieurs serveurs web d'une forêt de serveurs peuvent choisir de + partager une base de données, et ainsi partager les sessions entre + eux.
+ +Pour plus de détails à propos de l'interface des sessions, voir
+ la documentation du module mod_session.
Configuration de DBD Sessions anonymes Sessions propres à un
+ utilisateur Nettoyage de la base de
+ données SessionDBDCookieName SessionDBDCookieName2 SessionDBDCookieRemove SessionDBDDeleteLabel SessionDBDInsertLabel SessionDBDPerUser SessionDBDSelectLabel SessionDBDUpdateLabelPour que le module mod_session_dbd puisse être
+ configuré et maintenir une session, il faut tout d'abord
+ configurer le module mod_dbd pour que le serveur
+ puisse exécuter des requêtes vers la base de données.
Quatre types de requêtes sont nécessaires pour maintenir une + session, sélectionner ou mettre à jour une session existante, + insérer une nouvelle session et supprimer une session vide ou + arrivée à expiration. Ces requêtes sont configurées comme dans + l'exemple suivant :
+ +DBDriver pgsql +DBDParams "dbname=apachesession user=apache password=xxxxx host=localhost" +DBDPrepareSQL "delete from session where key = %s" deletesession +DBDPrepareSQL "update session set value = %s, expiry = %lld, key = %s where key = %s" updatesession +DBDPrepareSQL "insert into session (value, expiry, key) values (%s, %lld, %s)" insertsession +DBDPrepareSQL "select value from session where key = %s and (expiry = 0 or expiry > %lld)" selectsession +DBDPrepareSQL "delete from session where expiry != 0 and expiry < %lld" cleansession+
Les sessions anonymes sont identifiées par un UUID unique, et + stockées dans un cookie au niveau du navigateur. Cette méthode est + similaire à celle utilisée par la plupart des serveurs + d'applications pour stocker les informations de session.
+ +Pour créer une session anonyme, la stocker dans une table de + base de donnée postgres nommée apachesession, et + sauvegarder l'identifiant de session dans un cookie nommé + session, configurez la session comme suit :
+ +Session On +SessionDBDCookieName session path=/+
Pour plus d'exemples sur la manière dont une application CGI
+ peut accéder aux informations de session, voir la section exemples
+ de la documentation du module mod_session.
Pour des détails sur la manière dont une session peut être
+ utilisée pour stocker des informations de type nom
+ d'utilisateur/mot de passe, voir la documentation du module
+ mod_auth_form.
Les sessions propres à un utilisateur sont identifiées par le + nom de l'utilisateur authentifié avec succès. Ceci permet + d'assurer une confidentialité optimale, car aucun traitement + externe à la session n'existe en dehors du contexte + authentifié.
+ +Les sessions propres à un utilisateur ne fonctionnent que dans
+ un environnement d'authentification correctement configuré, qu'il
+ s'agisse d'une authentification de base, à base de condensés
+ (digest) ou de certificats client SSL. Suite à des limitations
+ dues à des dépendances mutuelles, les sessions propres à un
+ utilisateur ne peuvent pas être utilisées pour stocker les données
+ d'authentification en provenance d'un module comme
+ mod_auth_form.
Pour créer une session propre à un utilisateur, la stocker dans + une table de base de données postgres nommée + apachesession, avec comme clé de session l'identifiant + utilisateur, ajoutez les lignes suivantes :
+ +Session On +SessionDBDPerUser On+
Avec le temps, la base de données va commencer à accumuler des
+ sessions expirées. Pour le moment, le module
+ mod_session_dbd n'est pas en mesure de gérer
+ automatiquement l'expiration des sessions.
L'administrateur devra mettre en oeuvre un traitement externe + via cron pour nettoyer les sessions expirées.
+| Description: | Nom et attributs du cookie RFC2109 qui contient +l'identifiant de session |
|---|---|
| Syntaxe: | SessionDBDCookieName nom attributs |
| Défaut: | none |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_session_dbd |
La directive SessionDBDCookieName permet
+ de spécifier le nom et les attributs optionnels d'un cookie
+ compatible RFC2109 qui contiendra l'identifiant de session. Les
+ cookies RFC2109 sont définis à l'aide de l'en-tête HTTP
+ Set-Cookie.
+
Une liste optionnelle d'attributs peut être spécifiée pour ce + cookie, comme dans l'exemple ci-dessous. Ces attributs sont insérés + dans le cookie tels quels, et ne sont pas interprétés par Apache. + Assurez-vous que vos attributs sont définis correctement selon la + spécification des cookies. +
+ +Session On +SessionDBDCookieName session path=/private;domain=example.com;httponly;secure;version=1;+
| Description: | Nom et attributs du cookie RFC2965 qui contient +l'identifiant de session |
|---|---|
| Syntaxe: | SessionDBDCookieName2 nom attributs |
| Défaut: | none |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_session_dbd |
La directive SessionDBDCookieName2 permet
+ de spécifier le nom et les attributs optionnels d'un cookie
+ compatible RFC2965 qui contiendra l'identifiant de session. Les
+ cookies RFC2965 sont définis à l'aide de l'en-tête HTTP
+ Set-Cookie2.
+
Une liste optionnelle d'attributs peut être spécifiée pour ce + cookie, comme dans l'exemple ci-dessous. Ces attributs sont insérés + dans le cookie tel quel, et ne sont pas interprétés par Apache. + Assurez-vous que vos attributs sont définis correctement selon la + spécification des cookies. +
+ +Session On +SessionDBDCookieName2 session path=/private;domain=example.com;httponly;secure;version=1;+
| Description: | Détermine si les cookies de session doivent être supprimés +des en-têtes HTTP entrants |
|---|---|
| Syntaxe: | SessionDBDCookieRemove On|Off |
| Défaut: | SessionDBDCookieRemove On |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_session_dbd |
La directive SessionDBDCookieRemove permet
+ de déterminer si les cookies contenant l'identifiant de session
+ doivent être supprimés des en-têtes pendant le traitement de la
+ requête.
Dans le cas d'un mandataire inverse où le serveur Apache sert de + frontal à un serveur d'arrière-plan, révéler le contenu du cookie de + session à ce dernier peut conduire à une violation de la + confidentialité. À ce titre, si cette directive est définie à "on", + le cookie de session sera supprimé des en-têtes HTTP entrants.
+ + +| Description: | La requête SQL à utiliser pour supprimer des sessions de la +base de données |
|---|---|
| Syntaxe: | SessionDBDDeleteLabel étiquette |
| Défaut: | SessionDBDDeleteLabel deletesession |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_session_dbd |
La directive SessionDBDDeleteLabel permet
+ de définir l'étiquette de la requête de suppression à utiliser par
+ défaut pour supprimer une session vide ou expirée. Cette
+ étiquette doit avoir été définie au préalable via une directive
+ DBDPrepareSQL.
| Description: | La requête SQL à utiliser pour insérer des sessions dans la +base de données |
|---|---|
| Syntaxe: | SessionDBDInsertLabel étiquette |
| Défaut: | SessionDBDInsertLabel insertsession |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_session_dbd |
La directive SessionDBDInsertLabel permet
+ de définir l'étiquette de la requête d'insertion par défaut à
+ charger dans une session. Cette
+ étiquette doit avoir été définie au préalable via une directive
+ DBDPrepareSQL.
Si une tentative de mise à jour d'une session ne concerne aucun + enregistrement, c'est cette requête qui sera utilisée pour insérer + la session dans la base de données.
+ + +| Description: | Active une session propre à un utilisateur |
|---|---|
| Syntaxe: | SessionDBDPerUser On|Off |
| Défaut: | SessionDBDPerUser Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_session_dbd |
La directive SessionDBDPerUser permet
+ d'activer une session propre à un utilisateur, dont la clé sera le
+ nom de l'utilisateur connecté. Si l'utilisateur n'est pas connecté,
+ la directive sera ignorée.
| Description: | La requête SQL à utiliser pour sélectionner des sessions +dans la base de données |
|---|---|
| Syntaxe: | SessionDBDSelectLabel étiquette |
| Défaut: | SessionDBDSelectLabel selectsession |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_session_dbd |
La directive SessionDBDSelectLabel permet
+ de définir l'étiquette de la requête de sélection par défaut à
+ utiliser pour charger une session. Cette étiquette doit avoir été
+ définie au préalable via une directive DBDPrepareSQL.
| Description: | La requête SQL à utiliser pour mettre à jour des sessions +préexistantes dans la base de données |
|---|---|
| Syntaxe: | SessionDBDUpdateLabel étiquette |
| Défaut: | SessionDBDUpdateLabel updatesession |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Extension |
| Module: | mod_session_dbd |
La directive SessionDBDUpdateLabel permet
+ de définir l'étiquette de la requête de mise à jour par défaut à
+ charger dans une session. Cette
+ étiquette doit avoir été définie au préalable via une directive
+ DBDPrepareSQL.
Si une tentative de mise à jour d'une session ne concerne aucun + enregistrement, c'est la requête d'insertion qui sera appelée pour + insérer la session dans la base de données. Si la base de données + supporte InsertOrUpdate, modifiez cette requête pour effectuer la + mise à jour en une seule requête au lieu de deux.
+ + +Serveur HTTP Apache Version 2.4
+| Description: | Permet de définir des variables d'environnement en fonction +de certainescaractéristiques de la requête |
|---|---|
| Statut: | Base |
| Identificateur de Module: | setenvif_module |
| Fichier Source: | mod_setenvif.c |
Le module mod_setenvif vous permet de définir
+ des variables d'environnement internes de manière conditionnelle en fonction
+ de critères que vous pouvez spécifier. Ces variables d'environnement
+ peuvent être utilisées par d'autres parties du serveur pour prendre
+ des décisions quant aux actions à entreprendre, et pour déterminer
+ si les scripts CGI et les pages SSI doivent pouvoir y accéder.
Les directives sont interprétées selon l'ordre dans lequel elles + apparaîssent dans les fichiers de configuration. Ainsi, des + séquences plus complexes peuvent être utilisées, comme dans cet + exemple qui définit netscape si le navigateur est Mozilla et non + MSIE.
+ +BrowserMatch ^Mozilla netscape +BrowserMatch MSIE !netscape+ + +
Lorsque le serveur cherche un chemin via une sous-requête interne (par exemple la
+ recherche d'un DirectoryIndex), ou lorsqu'il génère un
+ listing du contenu d'un répertoire via le module
+ mod_autoindex, la sous-requête n'hérite pas des
+ variables d'environnement spécifiques à la requête. En outre, à cause
+ des phases de l'API auxquelles mod_setenvif prend
+ part, les directives SetEnvIf ne sont pas évaluées
+ séparément dans la sous-requête.
BrowserMatch BrowserMatchNoCase SetEnvIf SetEnvIfExpr SetEnvIfNoCase| Description: | Définit des variables d'environnement en fonction du +contenu de l'en-tête HTTP User-Agent |
|---|---|
| Syntaxe: | BrowserMatch regex [!]env-variable[=valeur]
+[[!]env-variable[=valeur]] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_setenvif |
La directive BrowserMatch est un cas
+ particulier de la directive SetEnvIf, qui définit des variables
+ d'environnement en fonction du contenu de l'en-tête de requête HTTP
+ User-Agent. Les deux lignes suivantes produisent le même
+ effet :
BrowserMatch Robot is_a_robot +SetEnvIf User-Agent Robot is_a_robot+ + +
Quelques exemples supplémentaires :
+BrowserMatch ^Mozilla forms jpeg=yes browser=netscape +BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript +BrowserMatch MSIE !javascript+ + +
| Description: | Définit des variables d'environnement en fonction du +contenu de l'en-tête HTTP User-Agent sans tenir compte de la +casse |
|---|---|
| Syntaxe: | BrowserMatchNoCase regex [!]env-variable[=valeur]
+ [[!]env-variable[=valeur]] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_setenvif |
La directive BrowserMatchNoCase est
+ identique sur le plan sémantique à la directive BrowserMatch. Elle permet
+ cependant une comparaison insensible à la casse. Par exemple :
BrowserMatchNoCase mac platform=macintosh +BrowserMatchNoCase win platform=windows+ + +
Les directives BrowserMatch et
+ BrowserMatchNoCase sont des cas particuliers
+ des directives SetEnvIf
+ et SetEnvIfNoCase.
+ Ainsi, les deux lignes suivantes produisent le même effet :
BrowserMatchNoCase Robot is_a_robot +SetEnvIfNoCase User-Agent Robot is_a_robot+ + +
| Description: | Définit des variables d'environnement en fonction des +attributs de la requête |
|---|---|
| Syntaxe: | SetEnvIf attribut
+ regex [!]env-variable[=valeur]
+ [[!]env-variable[=valeur]] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_setenvif |
La directive SetEnvIf permet de définir
+ des variables d'environnement en fonction des attributs de la
+ requête. L'attribut spécifié comme premier argument peut
+ se présenter sous l'une des trois formes suivantes :
Host,
+ User-Agent, Referer, ou
+ Accept-Language. Il est possible d'utiliser une
+ expression rationnelle pour spécifier un jeu d'en-têtes de
+ requête.Remote_Host - le nom d'hôte (s'il est disponible)
+ du client qui effectue la requêteRemote_Addr - l'adresse IP du client qui effectue
+ la requêteServer_Addr - l'adresse IP du serveur qui a reçu
+ la requête (uniquement à partir des versions supérieures à
+ 2.0.43)Request_Method - Le nom de la méthode HTTP
+ utilisée (GET, POST, et
+ cetera...)Request_Protocol - le nom et la version du
+ protocole utilisé pour la requête (par exemple "HTTP/0.9",
+ "HTTP/1.1", etc...)Request_URI - la ressource demandée dans la ligne
+ de requête HTTP -- en général la partie de l'URL suivant le
+ protocole et le nom du serveur, sans la chaîne d'arguments. Voir
+ la directive RewriteCond du module
+ mod_rewrite pour plus d'informations sur la
+ manière de mettre en correspondance votre chaîne d'arguments.SetEnvIf d'effectuer des tests en fonction du
+résultat de comparaisons précédentes. Seules les variables
+d'environnement définies par des directives
+SetEnvIf[NoCase] précédentes sont disponibles pour
+effectuer des tests de cette manière. 'Précédentes' signifie qu'elles se
+trouvent à un niveau plus global de la configuration (par exemple au
+niveau du serveur principal), ou plus haut chronologiquement dans le
+contexte de la directive. Les variables d'environnement ne seront prises
+en compte que si aucune correspondance n'a été trouvée parmi les
+caractéristiques de la requête, et si attribut n'a pas été
+spécifié sous la forme d'une expression rationnelle.Le second argument (regex) est une expression rationnelle. Si regex +correspond à l'attribut, les arguments suivants sont évalués.
+ +Le reste des arguments constitue les noms des variables à définir, +ainsi que les valeurs optionnelles qui doivent leur être affectées. Ils +peuvent se présenter sous les formes suivantes :
+ +nom-variable, ou!nom-variable, ounom-variable=valeurDans la première forme, la valeur sera définie à "1". Dans la
+ seconde forme, la variable sera supprimée si elle a été définie au
+ préalable, et dans la troisième forme, la variable sera définie à la
+ valeur littérale spécifiée par valeur. Depuis
+ la version 2.0.51, Apache httpd reconnaît les occurrences de variables
+ $1..$9 à l'intérieur de
+ valeur, et les remplace par les
+ sous-expressions entre parenthèses correspondantes de
+ regex. $0 permet d'accéder à l'ensemble de la chaîne
+ qui correspond à ce modèle.
SetEnvIf Request_URI "\.gif$" object_is_image=gif +SetEnvIf Request_URI "\.jpg$" object_is_image=jpg +SetEnvIf Request_URI "\.xbm$" object_is_image=xbm + +SetEnvIf Referer www\.mydomain\.example\.com intra_site_referral + +SetEnvIf object_is_image xbm XBIT_PROCESSING=1 + +SetEnvIf Request_URI "\.(.*)$" EXTENSION=$1 + +SetEnvIf ^TS ^[a-z] HAVE_TS+ + +
Les trois premières lignes définissent la variable
+ d'environnement objet_est_une_image si l'objet de la
+ requête est un fichier image, et la quatrième définit la variable
+ intra_site_referral si la page référante se trouve
+ quelque part dans le site web
+ www.mydomain.example.com.
La dernière ligne définit la variable d'environnement
+ HAVE_TS si la requête contient un en-tête dont le nom
+ commence par "TS" et dont la valeur commence par tout caractère du
+ jeu [a-z].
| Description: | Définit des variables d'environnement en fonction d'une expression ap_expr |
|---|---|
| Syntaxe: | SetEnvIfExpr expr
+ [!]env-variable[=valeur]
+ [[!]env-variable[=valeur]] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_setenvif |
La directive SetEnvIfExpr permet de
+ définir des variables d'environnement en fonction d'une expression
+ <If> ap_expr. Cette
+ expression est évaluée à l'exécution, et utilise les variables
+ d'environnement env-variable de la même manière que la
+ directive SetEnvIf.
SetEnvIfExpr "tolower(req('X-Sendfile')) == 'd:\images\very_big.iso')" iso_delivered
+
+
+ Dans cet exemple, la variable d'environnement
+ iso_delivered est définie chaque fois que notre
+ application tente de l'envoyer via X-Sendfile.
Il pourrait être plus utile de définir une variable rfc1918 si + l'adresse IP distante est une adresse privée au sens de la RFC 1918 + :
+ +SetEnvIfExpr "-R '10.0.0.0/8' || -R '172.16.0.0/12' || -R '192.168.0.0/16'" rfc1918+ + +
<If> permet d'obtenir des résultats
+similaires.mod_filter| Description: | Définit des variables d'environnement en fonction des +attributs de la requête sans tenir compte de la casse |
|---|---|
| Syntaxe: | SetEnvIfNoCase attribut regex
+ [!]env-variable[=valeur]
+ [[!]env-variable[=valeur]] ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Base |
| Module: | mod_setenvif |
La directive SetEnvIfNoCase est identique
+ d'un point de vue sémantique à la directive SetEnvIf, et ne s'en distingue que
+ par le fait que la comparaison des expressions rationnelles est
+ effectuée sans tenir compte de la casse. Par exemple :
SetEnvIfNoCase Host Example\.Org site=example+ + +
Cette ligne va définir la variable d'environnement
+ site avec la valeur "example" si le champ
+ d'en-tête de requête HTTP Host: est présent et contient
+ Example.Org, example.org, ou une autre
+ combinaison des mêmes caractères, sans tenir compte de la casse.
Serveur HTTP Apache Version 2.4
+| Description: | Fournisseur de mémoire partagée à base de +slots. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | slotmem_plain_module |
| Fichier Source: | mod_slotmem_plain.c |
mod_slotmem_plain est un fournisseur de mémoire qui
+ permet la création et l'utilisation d'un segment de mémoire contigu
+ dans lequel les ensembles de données sont organisés en "slots".
+
Si la mémoire doit être partagée entre des threads et des
+ processus, il est préférable d'utiliser le fournisseur
+ mod_slotmem_shm.
+
mod_slotmem_plain fournit une API comprenant les
+ fonctions suivantes :
+
/* appelle le callback sur tous les slots actifs */ +apr_status_t doall(ap_slotmem_instance_t *s, ap_slotmem_callback_fn_t *func, void *data, apr_pool_t *pool) + +/* crée un nouveau slot de mémoire dont chaque item aura une taille de item_size. */ +apr_status_t create(ap_slotmem_instance_t **new, const char *name, apr_size_t item_size, unsigned int item_num, ap_slotmem_type_t type, apr_pool_t *pool) + +/* rattache à un slot de mémoire existant. */ +apr_status_t attach(ap_slotmem_instance_t **new, const char *name, apr_size_t *item_size, unsigned int *item_num, apr_pool_t *pool) + +/* indique la mémoire associée à ce slot actif. */ +apr_status_t dptr(ap_slotmem_instance_t *s, unsigned int item_id, void **mem) + +/* lit la mémoire depuis ce slot et la transfert vers dest */ +apr_status_t get(ap_slotmem_instance_t *s, unsigned int item_id, unsigned char *dest, apr_size_t dest_len) + +/* écrit dans ce slot la mémoire en provenance de src */ +apr_status_t put(ap_slotmem_instance_t *slot, unsigned int item_id, unsigned char *src, apr_size_t src_len) + +/* renvoie le nombre total de slots contenus dans ce segment */ +unsigned int num_slots(ap_slotmem_instance_t *s) + +/* renvoie la taille totale des données, en octets, contenues dans un slot de ce segment */ +apr_size_t slot_size(ap_slotmem_instance_t *s) + +/* alloue le premier slot libre et le marque comme utilisé (n'effectue aucune copie de données) */ +apr_status_t grab(ap_slotmem_instance_t *s, unsigned int *item_id) + +/* appropriation ou allocation forcée du slot spécifié et marquage comme utilisé (n'effectue aucune copie de données) */ +apr_status_t fgrab(ap_slotmem_instance_t *s, unsigned int item_id) + +/* libère un slot et le marque comme non utilisé (n'effectue aucune copie de données) */ +apr_status_t release(ap_slotmem_instance_t *s, unsigned int item_id)+ + +
Ce module ne fournit aucune directive.
+Serveur HTTP Apache Version 2.4
+| Description: | Fournisseur de mémoire partagée basée sur les +slots. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | slotmem_shm_module |
| Fichier Source: | mod_slotmem_shm.c |
mod_slotmem_shm est un fournisseur de mémoire qui
+ permet la création et l'accès à un segment de mémoire partagée dans
+ lequel les ensembles de données sont organisés en "slots".
+
L'ensemble de la mémoire partagée est effacé à chaque
+ redémarrage, que ce dernier soit graceful ou non. Les données sont
+ stockées et restituées dans/à partir d'un fichier défini par le
+ paramètre name des appels create et
+ attach. Si son chemin absolu n'est pas spécifié, le
+ chemin du fichier sera relatif au chemin défini par la directive
+ DefaultRuntimeDir.
+
mod_slotmem_shm fournit les fonctions d'API suivantes
+ :
+
/* appelle le callback pour tous les slots actifs */ +apr_status_t doall(ap_slotmem_instance_t *s, ap_slotmem_callback_fn_t *func, void *data, apr_pool_t *pool) + +/* crée un nouveau slot de mémoire dont chaque taille d'item est + item_size. 'name' est utilisé pour générer le nom du fichier + permettant de stocker/restaurer le contenu de la mémoire partagée, + si elle est configurée. Les valeurs possibles sont : + "none" - Mémoire partagée anonyme et pas de stockage permanent + "file-name" - [DefaultRuntimeDir]/file-name + "/absolute-file-name" - Chemin absolu du fichier */ +apr_status_t create(ap_slotmem_instance_t **new, const char *name, apr_size_t item_size, unsigned int item_num, ap_slotmem_type_t type, apr_pool_t *pool) + +/* attache à un slot de mémoire existant. Voir + 'create' pour la description du paramètre + 'name'. */ +apr_status_t attach(ap_slotmem_instance_t **new, const char *name, apr_size_t *item_size, unsigned int *item_num, apr_pool_t *pool) + +/* obtient la mémoire associée à ce slot actif. */ +apr_status_t dptr(ap_slotmem_instance_t *s, unsigned int item_id, void **mem) + +/* lit la mémoire depuis ce slot et la transfert vers dest */ +apr_status_t get(ap_slotmem_instance_t *s, unsigned int item_id, unsigned char *dest, apr_size_t dest_len) + +/* écrit dans ce slot la mémoire en provenance de src */ +apr_status_t put(ap_slotmem_instance_t *slot, unsigned int item_id, unsigned char *src, apr_size_t src_len) + +/* renvoie le nombre total de slots contenus dans ce segment */ +unsigned int num_slots(ap_slotmem_instance_t *s) + +/* renvoie la taille totale des données, en octets, contenues + dans un slot de ce segment */ +apr_size_t slot_size(ap_slotmem_instance_t *s) + +/* alloue le premier slot libre et le marque comme utilisé (n'effectue aucune + copie de données) */ +apr_status_t grab(ap_slotmem_instance_t *s, unsigned int *item_id) + +/* appropriation ou allocation forcée du slot spécifié et marquage comme + utilisé (n'effectue aucune copie de données) */ +apr_status_t fgrab(ap_slotmem_instance_t *s, unsigned int item_id) + +/* libère un slot et le marque comme non utilisé (n'effectue aucune + copie de données) */ +apr_status_t release(ap_slotmem_instance_t *s, unsigned int item_id)+ + +
Ce module ne fournit aucune directive.
+Serveur HTTP Apache 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. Ces modules DLL
+ peuvent être distribués et exécutés sur toute installation d'Apache
+ httpd pour Windows, sans avoir à recompiler le serveur.
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 globale, 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 globale, 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.
Par 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.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Fournisseur de cache d'objets partagés basé sur DBM. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | socache_dbm_module |
| Fichier Source: | mod_socache_dbm.c |
Le module mod_socache_dbm est un fournisseur de cache
+ d'objets partagés qui permet la création et l'accès à un cache
+ maintenu par une base de données DBM.
+
+ dbm:/chemin/vers/datafile
+
Vous trouverez des détails à propos des autres fournisseurs de + cache d'objets partagés ici. +
+ +Ce module ne fournit aucune directive.
+Serveur HTTP Apache Version 2.4
+| Description: | Fournisseur de cache d'objets partagés basé sur dc. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | socache_dc_module |
| Fichier Source: | mod_socache_dc.c |
Le module mod_socache_dc est un fournisseur de cache
+ d'objets partagés qui permet la création et l'accès à un cache
+ maintenu par les bibliothèques de mise en cache de sessions
+ distribuées distcache.
+
Vous trouverez des détails à propos des autres fournisseurs de + cache d'objets partagés ici. +
+ +Ce module ne fournit aucune directive.
+Serveur HTTP Apache Version 2.4
+| Description: | Fournisseur de cache d'objets partagés basé sur Memcache. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | socache_memcache_module |
| Fichier Source: | mod_socache_memcache.c |
Le module mod_socache_memcache est un fournisseur de cache
+ d'objets partagés qui permet la création et l'accès à un cache
+ maintenu par le système de mise en cache d'objets en mémoire
+ distribuée à hautes performances memcached.
+
Cette méthode "create" du fournisseur de cache d'objets partagés
+ requiert une liste de spécifications hôte/port en cache mémoire
+ séparées par des virgules. Si vous utilisez ce fournisseur
+ dans la configuration d'autres modules (comme
+ SSLSessionCache), vous devez
+ fournir la liste des serveurs sous la forme du paramètre optionnel
+ "arg".
SSLSessionCache memcache:memcache.example.com:12345,memcache2.example.com:12345+ + +
Vous trouverez des détails à propos des autres fournisseurs de + cache d'objets partagés ici. +
+ +| Description: | Durée de conservation des connexions inactives |
|---|---|
| Syntaxe: | MemcacheConnTTL num[units] |
| Défaut: | MemcacheConnTTL 15s |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_socache_memcache |
| Compatibilité: | Disponible à partir de la version 2.4.17 du serveur HTTP +Apache. |
Définit la durée pendant laquelle les connexions + inactives avec le(s) serveur(s) memcache seront conservées + (plateformes threadées seulement).
+ +Les valeurs valides de la directive
+ MemcacheConnTTL sont des durées d'une heure
+ maximum. La valeur 0 signifie une absence de péremption
L'unité par défaut pour ce délai est la seconde, mais vous + pouvez ajouter un suffixe pour spécifier une unité différente ; ms + pour milliseconde, s pour seconde, min pour minute et h pour heure.. +
Dans les versions antérieures à 2.4.17, ce délai était codé en
+ dur et sa valeur était 600 microsecondes. La valeur la plus proche
+ de cette ancienne valeur pour la directive
+ MemcacheConnTTL est donc 1ms.
# Définition d'un délai de 10 minutes +MemcacheConnTTL 10min +# Définition d'un délai de 60 secondes +MemcacheConnTTL 60+
Serveur HTTP Apache Version 2.4
+| Description: | Fournisseur de cache d'objets partagés basé sur shmcb. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | socache_shmcb_module |
| Fichier Source: | mod_socache_shmcb.c |
Le module mod_socache_shmcb est un fournisseur de cache
+ d'objets partagés qui permet la création et l'accès à un cache
+ maintenu par un tampon cyclique à hautes performances au sein d'un
+ segment de mémoire partagée.
+
+ shmcb:/chemin/vers/datafile(512000)
+
Vous trouverez des détails à propos des autres fournisseurs de + cache d'objets partagés ici. +
+ +Ce module ne fournit aucune directive.
+Serveur HTTP Apache Version 2.4
+| Description: | Tente de corriger les erreurs de casse dans les URLs ou les +fautes de frappe mineures. |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | speling_module |
| Fichier Source: | mod_speling.c |
Il arrive que des requêtes pour des documents ne puissent pas + être traitées par le serveur Apache de base à cause d'une erreur + de frappe ou de casse. Ce module permet de traiter ce + problème en essayant de trouver un document correspondant, même + lorsque tous les autres modules y ont renoncé. Sa méthode de travail + consiste à comparer chaque nom de document du répertoire demandé + avec le document de la requête sans tenir compte de la + casse, et en acceptant jusqu'à une erreur + (insertion, omission, inversion de caractère ou caractère + erroné). Une liste de tous les documents qui correspondent est alors + élaborée en utilisant cette stratégie.
+ +Si après le parcours du répertoire,
+ +| Description: | Limite l'action du module aux corrections de +majuscules |
|---|---|
| Syntaxe: | CheckCaseOnly on|off |
| Défaut: | CheckCaseOnly Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Options |
| Statut: | Extension |
| Module: | mod_speling |
Lorsqu'elle est définie à "on", cette directive permet de limiter + l'action du module aux inversions majuscule/minuscule. Les autres + corrections ne sont pas effectuées.
+ + +| Description: | Active le module de correction |
|---|---|
| Syntaxe: | CheckSpelling on|off |
| Défaut: | CheckSpelling Off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Options |
| Statut: | Extension |
| Module: | mod_speling |
Cette directive permet d'activer ou de désactiver le module de + correction. Lorsqu'il est activé, rappelez-vous que :
+ +http://mon.serveur/~apahce/), mais seulement les noms
+ de fichiers ou de répertoires.<Location
+ "/status"> pour être traitée de manière incorrecte comme
+ une requête pour le fichier négocié "/stats.html".mod_speling ne doit pas être activé pour des répertoires où DAV l'est aussi, car il va essayer de
+ "corriger" les noms des ressources nouvellement créées en fonction
+ des noms de fichiers existants ; par exemple, lors du chargement
+ d'un nouveau document doc43.html, il est possible qu'il
+ redirige vers un document existant doc34.html, ce qui
+ ne correspond pas à ce que l'on souhaite.
+
Serveur HTTP Apache Version 2.4
+| Description: | Chiffrement de haut niveau basé sur les protocoles Secure +Sockets Layer (SSL) et Transport Layer Security (TLS) |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | ssl_module |
| Fichier Source: | mod_ssl.c |
Ce module fournit le support SSL v3 et TLS v1 au serveur HTTP +Apache. SSL v2 n'est plus supporté.
+ +Ce module s'appuie sur OpenSSL +pour fournir le moteur de chiffrement.
+ +D'autres détails, discussions et exemples sont fournis dans la documentation SSL.
+ Variables d'environnement Formats de journaux
+personnalisés Information à propos de la requête Extension pour l'interprétation
+des expressions Fournisseurs d'autorisation
+disponibles avec Require SSLCACertificateFile SSLCACertificatePath SSLCADNRequestFile SSLCADNRequestPath SSLCARevocationCheck SSLCARevocationFile SSLCARevocationPath SSLCertificateChainFile SSLCertificateFile SSLCertificateKeyFile SSLCipherSuite SSLCompression SSLCryptoDevice SSLEngine SSLFIPS SSLHonorCipherOrder SSLInsecureRenegotiation SSLOCSPDefaultResponder SSLOCSPEnable SSLOCSPNoverify SSLOCSPOverrideResponder SSLOCSPProxyURL SSLOCSPResponderCertificateFile SSLOCSPResponderTimeout SSLOCSPResponseMaxAge SSLOCSPResponseTimeSkew SSLOCSPUseRequestNonce SSLOpenSSLConfCmd SSLOptions SSLPassPhraseDialog SSLProtocol SSLProxyCACertificateFile SSLProxyCACertificatePath SSLProxyCARevocationCheck SSLProxyCARevocationFile SSLProxyCARevocationPath SSLProxyCheckPeerCN SSLProxyCheckPeerExpire SSLProxyCheckPeerName SSLProxyCipherSuite SSLProxyEngine SSLProxyMachineCertificateChainFile SSLProxyMachineCertificateFile SSLProxyMachineCertificatePath SSLProxyProtocol SSLProxyVerify SSLProxyVerifyDepth SSLRandomSeed SSLRenegBufferSize SSLRequire SSLRequireSSL SSLSessionCache SSLSessionCacheTimeout SSLSessionTicketKeyFile SSLSessionTickets SSLSRPUnknownUserSeed SSLSRPVerifierFile SSLStaplingCache SSLStaplingErrorCacheTimeout SSLStaplingFakeTryLater SSLStaplingForceURL SSLStaplingResponderTimeout SSLStaplingResponseMaxAge SSLStaplingResponseTimeSkew SSLStaplingReturnResponderErrors SSLStaplingStandardCacheTimeout SSLStrictSNIVHostCheck SSLUserName SSLUseStapling SSLVerifyClient SSLVerifyDepthCe module peut être configuré pour fournir aux espaces de nommage SSI
+et CGI de nombreux éléments d'informations concernant SSL par le biais
+de variables d'environnement supplémentaires. Par défaut, et pour
+des raisons de performances, ces informations ne sont pas fournies (Voir
+la directive SSLOptions StdEnvVars ci-dessous).
+Les variables générées se trouvent dans la table ci-dessous.
+Ces informations peuvent également être disponible sous des noms différents
+à des fins de compatibilité ascendante. Reportez-vous au chapitre Compatibilité pour plus de détails à
+propos des variables de compatibilité.
| Nom de la variable : | +Type de valeur : | +Description : | +
|---|---|---|
HTTPS | drapeau | +HTTPS est utilisé. |
SSL_PROTOCOL | chaîne | +La version du protocole SSL (SSLv3, TLSv1, TLSv1.1, TLSv1.2) |
SSL_SESSION_ID | chaîne | +L'identifiant de session SSL codé en hexadécimal |
SSL_SESSION_RESUMED | chaîne | +Session SSL initiale ou reprise. Note : plusieurs requêtes peuvent +être servies dans le cadre de la même session SSL (initiale ou reprise) +si les connexions persistantes (HTTP KeepAlive) sont utilisées |
SSL_SECURE_RENEG | chaîne | +true si la renégociation sécurisée est supportée,
+false dans le cas contraire |
SSL_CIPHER | chaîne | +Le nom de l'algorithme de chiffrement |
SSL_CIPHER_EXPORT | chaîne | +true si l'algorithme de chiffrement est un algorithme
+exporté |
SSL_CIPHER_USEKEYSIZE | nombre | +Nombre de bits de chiffrement (réellement utilisés) |
SSL_CIPHER_ALGKEYSIZE | nombre | +Nombre de bits de chiffrement (possible) |
SSL_COMPRESS_METHOD | chaîne | +Méthode de compression SSL négociée |
SSL_VERSION_INTERFACE | chaîne | +La version du programme mod_ssl |
SSL_VERSION_LIBRARY | chaîne | +La version du programme OpenSSL |
SSL_CLIENT_M_VERSION | chaîne | +La version du certificat client |
SSL_CLIENT_M_SERIAL | chaîne | +Le numéro de série du certificat client |
SSL_CLIENT_S_DN | chaîne | +Le DN sujet du certificat client |
SSL_CLIENT_S_DN_x509 | chaîne | +Elément du DN sujet du client |
SSL_CLIENT_SAN_Email_n | chaîne | +Les entrées d'extension subjectAltName du certificat client de type rfc822Name |
SSL_CLIENT_SAN_DNS_n | chaîne | +Les entrées d'extension subjectAltName du certificat client de type dNSName |
SSL_CLIENT_SAN_OTHER_msUPN_n |
+chaîne | Extensions subjectAltName de type otherName du +certificat client, forme Microsoft du nom principal de l'utilisateur (OID 1.3.6.1.4.1.311.20.2.3) |
SSL_CLIENT_I_DN | chaîne | +DN de l'émetteur du certificat du client |
SSL_CLIENT_I_DN_x509 | chaîne | +Elément du DN de l'émetteur du certificat du client |
SSL_CLIENT_V_START | chaîne | +Validité du certificat du client (date de début) |
SSL_CLIENT_V_END | chaîne | +Validité du certificat du client (date de fin) |
SSL_CLIENT_V_REMAIN | chaîne | +Nombre de jours avant expiration du certificat du client |
SSL_CLIENT_A_SIG | chaîne | +Algorithme utilisé pour la signature du certificat du client |
SSL_CLIENT_A_KEY | chaîne | +Algorithme utilisé pour la clé publique du certificat du client |
SSL_CLIENT_CERT | chaîne | +Certificat du client au format PEM |
SSL_CLIENT_CERT_CHAIN_n |
+chaîne | Certificats de la chaîne de certification du +client au format PEM |
SSL_CLIENT_CERT_RFC4523_CEA | chaîne | +Numéro de série et fournisseur du certificat. le format correspond à +celui de la CertificateExactAssertion dans la RFC4523 |
SSL_CLIENT_VERIFY | chaîne | +NONE, SUCCESS, GENEROUS ou
+FAILED:raison |
SSL_SERVER_M_VERSION | chaîne | +La version du certificat du serveur |
SSL_SERVER_M_SERIAL | chaîne | + +The serial of the server certificate |
SSL_SERVER_S_DN | chaîne | +DN sujet du certificat du serveur |
SSL_SERVER_S_DN_x509 | chaîne | +Elément du DN sujet du certificat du serveur |
SSL_SERVER_SAN_Email_n |
+chaîne | Les entrées d'extension subjectAltName du +certificat de serveur de type rfc822Name |
SSL_SERVER_SAN_DNS_n | chaîne | +Les entrées d'extension subjectAltName du +certificat de serveur de type dNSName |
SSL_SERVER_SAN_OTHER_dnsSRV_n |
+chaîne | Extensions subjectAltName de type otherName du +certificat serveur, sous la forme SRVName (OID 1.3.6.1.5.5.7.8.7, RFC 4985) |
SSL_SERVER_I_DN | chaîne | +DN de l'émetteur du certificat du serveur |
SSL_SERVER_I_DN_x509 | chaîne | +Elément du DN de l'émetteur du certificat du serveur |
SSL_SERVER_V_START | chaîne | +Validité du certificat du serveur (date de dédut) |
SSL_SERVER_V_END | chaîne | +Validité du certificat du serveur (date de fin) |
SSL_SERVER_A_SIG | chaîne | +Algorithme utilisé pour la signature du certificat du serveur |
SSL_SERVER_A_KEY | chaîne | +Algorithme utilisé pour la clé publique du certificat du serveur |
SSL_SERVER_CERT | chaîne | +Certificat du serveur au format PEM |
SSL_SRP_USER | chaîne | +nom d'utilisateur SRP |
SSL_SRP_USERINFO | chaîne | +informations sur l'utilisateur SRP |
SSL_TLS_SNI | string | +Contenu de l'extension SNI TLS (si supporté par ClientHello) |
x509 spécifie un élément de DN X.509 parmi
+C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email. A partir de la version
+2.2.0 d'Apache, x509 peut aussi comporter un suffixe numérique
+_n. Si le DN en question comporte plusieurs attributs de
+noms identiques, ce suffixe constitue un index débutant à zéro et
+permettant de sélectionner un
+attribut particulier. Par exemple, si le DN sujet du certificat du
+serveur comporte deux champs OU, on peut utiliser
+SSL_SERVER_S_DN_OU_0 et SSL_SERVER_S_DN_OU_1
+pour référencer chacun d'entre eux. Un nom de variable sans suffixe
+_n est équivalent au même nom avec le suffixe
+_0, ce qui correspond au premier attribut (ou au seul)
+caractérisant le DN.
+Lorsque la table d'environnement est remplie en utilisant l'option
+StdEnvVars de la directive SSLOptions, le premier attribut (ou le
+seul) caractérisant le DN est enregistré avec un nom sans suffixe ;
+autrement dit, aucune entrée possédant comme suffixe _0
+n'est enregistrée.
A partir de la version 2.4.32 de httpd, on peut ajouter le suffixe
+_RAW à x509 dans un composant DN afin d'empêcher la conversion
+de la valeur de l'attribut en UTF-8. Il doit être placé après le suffixe index
+(s'il existe). On utilisera par exemple SSL_SERVER_S_DN_OU_RAW ou
+SSL_SERVER_S_DN_OU_0_RAW.
Le format des variables *_DN a changé depuis la version
+2.3.11 d'Apache HTTPD. Voir l'option LegacyDNStringFormat
+de la directive SSLOptions pour
+plus de détails.
SSL_CLIENT_V_REMAIN n'est disponible qu'à partir de la
+version 2.1.
Plusieurs variables d'environnement additionnelles peuvent être
+utilisées dans les expressions SSLRequire, ou
+dans les formats de journalisation personnalisés :
HTTP_USER_AGENT PATH_INFO AUTH_TYPE +HTTP_REFERER QUERY_STRING SERVER_SOFTWARE +HTTP_COOKIE REMOTE_HOST API_VERSION +HTTP_FORWARDED REMOTE_IDENT TIME_YEAR +HTTP_HOST IS_SUBREQ TIME_MON +HTTP_PROXY_CONNECTION DOCUMENT_ROOT TIME_DAY +HTTP_ACCEPT SERVER_ADMIN TIME_HOUR +THE_REQUEST SERVER_NAME TIME_MIN +REQUEST_FILENAME SERVER_PORT TIME_SEC +REQUEST_METHOD SERVER_PROTOCOL TIME_WDAY +REQUEST_SCHEME REMOTE_ADDR TIME +REQUEST_URI REMOTE_USER
Dans ces contextes, deux formats spéciaux peuvent aussi être utilisés +:
+ +ENV:nom_variableHTTP:nom_en-têteLorsque mod_ssl est compilé dans le serveur Apache
+ou même chargé (en mode DSO), des fonctions supplémentaires sont
+disponibles pour le Format de journal personnalisé du
+module mod_log_config. A ce titre, la fonction de
+format d'eXtension ``%{nom-var}x''
+peut être utilisée pour présenter en extension toute variable fournie
+par tout module, et en particulier celles fournies par mod_ssl et que
+vous trouverez dans la table ci-dessus.
+A des fins de compatibilité ascendante, il existe une fonction de format
+cryptographique supplémentaire
+``%{nom}c''. Vous trouverez toutes
+les informations à propos de cette fonction dans le chapitre Compatibilité.
CustomLog "logs/ssl_request_log" "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
+Ces formats sont disponibles même si l'option StdEnvVars de la
+directive SSLOptions n'a pas été
+définie.
mod_ssl enregistre des informations à propos de la
+requête que l'on peut restituer dans les journaux avec la chaîne de
+format %{nom}n via le module
+mod_log_config.
Les informations enregistrées sont les suivantes :
+ +ssl-access-forbidden1 si l'accès a
+ été refusé suite à une directive SSLRequire ou
+ SSLRequireSSL.ssl-secure-renegmod_ssl a été compilé avec une version
+ d'OpenSSL qui supporte la renégociation sécurisée, si SSL est utilisé
+ pour la connexion courante et si le client supporte lui aussi la
+ renégociation sécurisée, cette information contiendra la valeur
+ 1. Si le client ne supporte pas la renégociation
+ sécurisée, l'information contiendra la valeur 0. Si
+ mod_ssl n'a pas été compilé avec une version
+ d'OpenSSL qui supporte la renégociation sécurisée, ou si SSL n'est pas
+ utilisé pour la connexion courante, le contenu de l'information ne
+ sera pas défini.Lorsque mod_ssl est compilé statiquement avec
+Apache, ou même chargé dynamiquement (en tant que module DSO), toute variable en provenance de mod_ssl peut
+être utilisée pour l'interprétation des
+expression ap_expr. Les variables peuvent être référencées en
+utilisant la syntaxe ``%{varname}''.
+A partir de la version 2.4.18, on peut aussi utiliser la syntaxe de
+style mod_rewrite
+``%{SSL:varname}'', ou la syntaxe de
+style fonction ``ssl(varname)''.
mod_headers)Header set X-SSL-PROTOCOL "expr=%{SSL_PROTOCOL}"
+Header set X-SSL-CIPHER "expr=%{SSL:SSL_CIPHER}"
+Cette fonctionnalité est disponible même si l'option
+StdEnvVars de la directive SSLOptions n'a pas été définie.
mod_ssl propose quelques fournisseurs
+ d'autorisation à utiliser avec la directive Require du module
+ mod_authz_core.
Le fournisseur ssl refuse l'accès si une connexion
+ n'est pas chiffrée avec SSL. L'effet est similaire à celui de la
+ directive SSLRequireSSL.
Require ssl+ + + + + +
Le fournisseur ssl autorise l'accès si
+ l'utilisateur est authentifié via un certificat client valide. Ceci
+ n'a un effet que si SSLVerifyClient optional est actif.
Dans l'exemple suivant, l'accès est autorisé si le client est + authentifié via un certificat client ou par nom d'utilisateur/mot de + passe :
+ +Require ssl-verify-client +Require valid-user+ + + + +
| Description: | Fichier contenant une concaténation des certificats de CA +codés en PEM pour l'authentification des clients |
|---|---|
| Syntaxe: | SSLCACertificateFile chemin-fichier |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir le fichier tout-en-un où vous
+pouvez rassembler les certificats des Autorités de Certification (CAs)
+pour les clients auxquels vous avez à faire. On les utilise pour
+l'authentification des clients. Un tel fichier contient la simple
+concaténation des différents fichiers de certificats codés en PEM, par
+ordre de préférence. Cette directive peut être utilisée à la place et/ou
+en complément de la directive SSLCACertificatePath.
SSLCACertificateFile "/usr/local/apache2/conf/ssl.crt/ca-bundle-client.crt"+
| Description: | Répertoire des certificats de CA codés en PEM pour +l'authentification des clients |
|---|---|
| Syntaxe: | SSLCACertificatePath chemin-répertoire |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir le répertoire où sont stockés les +certificats des Autorités de Certification (CAs) pour les clients +auxquels vous avez à faire. On les utilise pour vérifier le certificat +du client au cours de l'authentification de ce dernier.
+
+Les fichiers de ce répertoire doivent être codés en PEM et ils sont
+accédés via des noms de fichier sous forme de condensés ou hash. Il ne
+suffit donc pas de placer les fichiers de certificats dans ce répertoire
+: vous devez aussi créer des liens symboliques nommés
+valeur-de-hashage.N, et vous devez toujours vous
+assurer que ce répertoire contient les liens symboliques appropriés.
SSLCACertificatePath "/usr/local/apache2/conf/ssl.crt/"+
| Description: | Fichier contenant la concaténation des certificats de CA +codés en PEM pour la définition de noms de CA acceptables |
|---|---|
| Syntaxe: | SSLCADNRequestFile chemin-fichier |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
Lorsque mod_ssl demande un certificat client, une liste de noms +d'Autorités de Certification acceptables est envoyée au client au +cours de la phase d'initialisation de la connexion SSL. Le client peut +alors utiliser cette liste de noms de CA pour sélectionner un certificat +client approprié parmi ceux dont il dispose.
+ +Si aucune des directives SSLCADNRequestPath ou SSLCADNRequestFile n'est définie, la liste
+de noms de CsA acceptables envoyée au client est la liste des noms de
+tous les certificats de CA spécifiés par les directives SSLCACertificateFile et SSLCACertificatePath ; en d'autres termes,
+c'est la liste des noms de CAs qui sera effectivement utilisée pour
+vérifier le certificat du client.
Dans certaines situations, il est utile de pouvoir envoyer
+une liste de noms de CA acceptables qui diffère de la liste des CAs
+effectivement utilisés pour vérifier le certificat du client ;
+considérons par exemple le cas où le certificat du client est signé par
+des CAs intermédiaires. On peut ici utiliser les directives SSLCADNRequestPath et/ou SSLCADNRequestFile, et les noms de CA
+acceptables seront alors extraits de l'ensemble des certificats contenus
+dans le répertoire et/ou le fichier définis par cette paire de
+directives.
SSLCADNRequestFile doit
+spécifier un fichier tout-en-un contenant une concaténation des
+certificats de CA codés en PEM.
SSLCADNRequestFile "/usr/local/apache2/conf/ca-names.crt"+
| Description: | Répertoire contenant des fichiers de certificats de CA +codés en PEM pour la définition de noms de CA acceptables |
|---|---|
| Syntaxe: | SSLCADNRequestPath chemin-répertoire |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
Cette directive optionnelle permet de définir la liste de noms de
+CAs acceptables qui sera envoyée au client lorsqu'un certificat de
+client est demandé. Voir la directive SSLCADNRequestFile pour plus de
+détails.
Les fichiers de ce répertoire doivent être codés en PEM et ils sont
+accédés via des noms de fichier sous forme de condensés ou hash. Il ne
+suffit donc pas de placer les fichiers de certificats dans ce répertoire
+: vous devez aussi créer des liens symboliques nommés
+valeur-de-hashage.N, et vous devez toujours vous
+assurer que ce répertoire contient les liens symboliques appropriés.
SSLCADNRequestPath "/usr/local/apache2/conf/ca-names.crt/"+
| Description: | Active la vérification des révocations basée sur les CRL |
|---|---|
| Syntaxe: | SSLCARevocationCheck chain|leaf|none flags |
| Défaut: | SSLCARevocationCheck none |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Le drapeau optionnel flags est disponible à partir de la +version 2.4.21 du serveur HTTP Apache |
+Active la vérification des révocations basée sur les Listes de
+Révocations de Certificats (CRL). Au moins une des directives SSLCARevocationFile ou SSLCARevocationPath doit être définie.
+Lorsque cette directive est définie à chain (valeur
+recommandée), les vérifications CRL sont effectuées sur tous les
+certificats de la chaîne, alors que la valeur leaf limite
+la vérification au certificat hors chaîne (la feuille).
+
flags peut prendre comme valeurs
+no_crl_for_cert_ok
+
+Avant la version 2.3.15, les vérifications CRL dans mod_ssl
+réussissaient même si aucune CRL n'était trouvée dans les chemins
+définis par les directives SSLCARevocationFile ou SSLCARevocationPath.
Le comportement a
+changé avec l'introduction de la directive
+SSLCARevocationFile : par défaut avec
+chain ou leaf, les CRLs doivent être présentes pour que la
+validation réussisse ; dans le cas contraire, elle échouera avec une
+erreur "unable to get certificate CRL".
La valeur no_crl_for_cert_ok du drapeau flag permet de
+retrouver le comportement précédent.
SSLCARevocationCheck chain+
SSLCARevocationCheck chain no_crl_for_cert_ok+
| Description: | Fichier contenant la concaténation des CRLs des CA codés en +PEM pour l'authentification des clients |
|---|---|
| Syntaxe: | SSLCARevocationFile chemin-fichier |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir le fichier tout-en-un où sont
+rassemblées les Listes de Révocation de Certificats (CRLs) des Autorités
+de certification (CAs) pour les clients auxquels vous avez à faire. On
+les utilise pour l'authentification des clients. Un tel fichier contient
+la simple concaténation des différents fichiers de CRLs codés en PEM,
+dans l'ordre de préférence. Cette directive peut être utilisée à la
+place et/ou en complément de la directive SSLCARevocationPath.
SSLCARevocationFile +"/usr/local/apache2/conf/ssl.crl/ca-bundle-client.crl"+
| Description: | Répertoire des CRLs de CA codés en PEM pour +l'authentification des clients |
|---|---|
| Syntaxe: | SSLCARevocationPath chemin-répertoire |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir le répertoire où sont stockées les +Listes de Révocation de Certificats (CRL) des Autorités de Certification +(CAs) pour les clients auxquels vous avez à faire. On les utilise pour +révoquer les certificats des clients au cours de l'authentification de +ces derniers.
+
+Les fichiers de ce répertoire doivent être codés en PEM et ils sont
+accédés via des noms de fichier sous forme de condensés ou hash. Il ne
+suffit donc pas de placer les fichiers de CRL dans ce répertoire
+: vous devez aussi créer des liens symboliques nommés
+valeur-de-hashage.N, et vous devez toujours vous
+assurer que ce répertoire contient les liens symboliques appropriés.
SSLCARevocationPath "/usr/local/apache2/conf/ssl.crl/"+
| Description: | Fichier contenant les certificats de CA du serveur codés en +PEM |
|---|---|
| Syntaxe: | SSLCertificateChainFile chemin-fichier |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
SSLCertificateChainFile est devenue obsolète avec la
+version 2.4.8, lorsque la directive
+SSLCertificateFile a été étendue
+pour supporter aussi les certificats de CA intermédiaires dans le
+fichier de certificats du serveur.
+Cette directive permet de définir le fichier optionnel +tout-en-un où vous pouvez rassembler les certificats des +Autorités de Certification (CA) qui forment la chaîne de certification +du certificat du serveur. Cette chaîne débute par le certificat de la CA +qui a délivré le certificat du serveur et peut remonter jusqu'au +certificat de la CA racine. Un tel fichier contient la simple +concaténation des différents certificats de CA codés en PEM, en général +dans l'ordre de la chaîne de certification.
+Elle doit être utilisée à la place et/ou en complément de la
+directive SSLCACertificatePath
+pour construire explicitement la chaîne de certification du serveur qui
+est envoyée au navigateur en plus du certificat du serveur. Elle s'avère
+particulièrement utile pour éviter les conflits avec les certificats de
+CA lorsqu'on utilise l'authentification du client. Comme le fait de
+placer un certificat de CA de la chaîne de certification du serveur dans
+la directive SSLCACertificatePath produit le même effet
+pour la construction de la chaîne de certification, cette directive a
+pour effet colatéral de faire accepter les certificats clients fournis
+par cette même CA, au cours de l'authentification du client.
+Soyez cependant prudent : fournir la chaîne de certification ne +fonctionne que si vous utilisez un simple certificat de +serveur RSA ou DSA. Si vous utilisez une paire de certificats +couplés RSA+DSA , cela ne fonctionnera que si les deux certificats +utilisent vraiment la même chaîne de certification. Dans le cas +contraire, la confusion risque de s'installer au niveau des +navigateurs.
+SSLCertificateChainFile "/usr/local/apache2/conf/ssl.crt/ca.crt"+
| Description: | Fichier de données contenant le certificat X.509 du serveur codé en +PEM |
|---|---|
| Syntaxe: | SSLCertificateFile chemin-fichier |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
Cette directive permet de définir le fichier de données contenant
+les informations de certificat
+X.509 du serveur codées au format PEM. Ce fichier doit contenir
+au minimum un certificat d'entité finale (feuille).
+La directive peut être utilisée plusieurs fois (elle référence des
+fichiers différents) pour accepter plusieurs algorithmes
+d'authentification au niveau du serveur - souvent RSA, DSA et ECC. Le
+nombre d'algorithmes supportés dépend de la version d'OpenSSL utilisée
+avec mod_ssl : à partir de la version 1.0.0, la commande openssl
+list-public-key-algorithms affiche la liste des algorithmes
+supportés. Voir aussi la note ci-dessous à propos des limitations des versions
+d'OpenSSL antérieures à 1.0.2 et la manière de les contourner.
+
Les fichiers peuvent aussi contenir des certificats de CA
+intermédiaires triés depuis la feuille vers la racine. Cette
+fonctionnalité est disponible depuis la version 2.4.8 du serveur HTTP
+Apache, et rend obsolète la directive SSLCertificateChainFile. A partir de la
+version 1.0.2 d'OpenSSL, il est alors possible de configurer la chaîne
+de certification en fonction du certificat.
Depuis la version 2.4.7 du serveur HTTP Apache, on peut aussi ajouter
+des paramètres DH personnalisés et un nom EC
+curve pour les clés éphémères à la fin du premier fichier défini par la
+directive SSLCertificateFile.
+Ces paramètres peuvent être générés avec les commandes openssl
+dhparam et openssl ecparam, et ils peuvent être
+ajoutés tel quel à la fin du premier fichier de certificat. En effet,
+seul le premier fichier de certificat défini peut être utilisé pour
+enregistrer des paramètres personnalisés, car ces derniers s'appliquent
+indépendamment de l'algorithme d'authentification utilisé.
+
Enfin, il est aussi possible d'ajouter la clé privée du certificat de
+l'entité finale au fichier de certificat, ce qui permet de se passer
+d'une directive SSLCertificateKeyFile séparée. Cette
+pratique est cependant fortement déconseillée. En effet, les fichiers de
+certificats qui contiennent de tels clés embarquées doivent être définis
+avant les certificats en utilisant un fichier de clé séparé. En outre,
+si la clé est chiffrée, une boîte de dialogue pour entrer le mot de
+passe de la clé s'ouvre au démarrage du serveur.
+
+Depuis la version 2.4.7, mod_ssl utilise des +paramètres DH standardisés avec des nombres premiers de 2048, 3072 et +4096 bits, et avec des nombres premiers de 6144 et 8192 bits depuis la +version 2.4.10 (voir RFC +3526), et les fournit aux clients en fonction de la longueur de la +clé du certificat RSA/DSA. En particulier avec les clients basés sur +Java (versions 7 et antérieures), ceci peut provoquer des erreurs au +cours de la négociation - voir cette réponse de la FAQ SSL pour +contourner les problèmes de ce genre. +
+
+Lorsqu'on utilise plusieurs certificats pour supporter différents algorithmes
+d'authentification (comme RSA, DSA, mais principalement ECC) et une
+version d'OpenSSL antérieure à 1.0.2, il est recommandé soit d'utiliser des
+paramètres DH spécifiques (solution à privilégier) en les ajoutant au premier
+fichier certificat (comme décrit ci-dessus), soit d'ordonner les directives
+SSLCertificateFile de façon à ce que les certificats
+RSA/DSA soit placés après les certificats ECC.
+
+Cette limitation est présente dans les anciennes versions d'OpenSSL qui +présentent toujours le dernier certificat configuré, au lieu +de laisser le serveur HTTP Apache déterminer le certificat sélectionné lors de +la phase de négociation de la connexion (lorsque les paramètres DH doivent être +envoyés à l'hôte distant). +De ce fait, le serveur peut sélectionner des paramètres DH par défaut basés sur +la longueur de la clé du mauvais certificat (les clés ECC sont beaucoup plus +petites que les clés RSA/DSA et leur longueur n'est pas pertinente pour la +sélection des nombres premiers DH). +
++Ce problème peut être résolu en créant et configurant des paramètres DH +spécifiques (comme décrit ci-dessus), car ils l'emportent toujours sur les +paramètres DH par défaut, et vous pourrez ainsi utiliser une longueur spécifique +et appropriée. +
+SSLCertificateFile "/usr/local/apache2/conf/ssl.crt/server.crt"+
| Description: | Fichier contenant la clé privée du serveur codée en +PEM |
|---|---|
| Syntaxe: | SSLCertificateKeyFile chemin-fichier |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
Cette directive permet de définir le fichier contenant la clé privée du +serveur codée en PEM. Si la clé privée est +chiffrée, une boîte de dialogue demandant le mot de passe s'ouvre au +démarrage.
+ +
+Cette directive peut être utilisée plusieurs fois pour référencer
+différents noms de fichiers, afin de supporter plusieurs algorithmes
+pour l'authentification du serveur. A chaque directive SSLCertificateKeyFile doit être associée
+une directive SSLCertificateFile correspondante.
+
+La clé privé peut aussi être ajoutée au fichier défini par la directive
+SSLCertificateFile, mais cette
+pratique est fortement déconseillée. En effet, les fichiers de
+certificats qui comportent une telle clé doivent être définis après les
+certificats en utilisant un fichier de clé séparé.
SSLCertificateKeyFile "/usr/local/apache2/conf/ssl.key/server.key"+
| Description: | Algorithmes de chiffrement disponibles pour la négociation +au cours de l'initialisation de la connexion SSL |
|---|---|
| Syntaxe: | SSLCipherSuite [protocol] cipher-spec |
| Défaut: | SSLCipherSuite DEFAULT (dépend de la version d'OpenSSL
+installée) |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive complexe utilise la chaîne cipher-spec +contenant la liste des algorithmes de chiffrement OpenSSL que le client +peut utiliser au cours de la phase d'initialisation de la connexion SSL. La +spécification optionnelle du protocole permet de configurer la suite +d'algorithmes de chiffrement pour une version spécifique de SSL. Une des valeurs +possibles est "SSL" pour toutes les versions du protocole SSL jusqu'à TLSv1.2 +compris. +
++Notez que cette directive peut être utilisée aussi bien dans un contexte +de serveur que dans un contexte de répertoire. Dans un contexte de +serveur, elle s'applique à l'initialisation SSL standard lorsqu'une +connexion est établie. Dans un contexte de répertoire, elle force une +renégociation SSL avec la liste d'algorithmes de chiffrement spécifiée +après la lecture d'une requête HTTP, mais avant l'envoi de la réponse +HTTP.
++Si la bibliothèque SSL supporte TLSv1.3 (versions d'OpenSSL 1.1.1 et +supérieures), il est possible de spécifier le paramètre "TLSv1.3" pour +configurer la suite d'algorithmes de chiffrement pour ce protocole. Comme +TLSv1.3 n'autorise pas la renégociation, spécifier pour lui des algorithmes de +chiffrement dans un contexte de répertoire n'est pas autorisé
++Pour obtenir la liste des noms d'algorithmes de chiffrement pour TLSv1.3, se +référer à la the +OpenSSL documentation.
++La liste d'algorithmes de chiffrement SSL spécifiée par l'argument +cipher-spec comporte quatre attributs principaux auxquels +s'ajoutent quelques attributs secondaires :
+L'algorithme de chiffrement peut aussi provenir de l'extérieur. Les +algorithmes SSLv2 ne sont plus supportés. +Pour définir les algorithmes à utiliser, on +peut soit spécifier tous les algorithmes à la fois, soit utiliser des +alias pour spécifier une liste d'algorithmes dans leur ordre de +préférence (voir Table 1). Les algorithmes et +alias effectivement disponibles dépendent de la version d'openssl +utilisée. Les versions ultérieures d'openssl sont susceptibles d'inclure +des algorithmes supplémentaires.
+ +| Symbole | Description |
|---|---|
| Algorithme d'échange de clés : | |
kRSA | Echange de clés RSA |
kDHr | Echange de clés Diffie-Hellman avec +clé RSA |
kDHd | Echange de clés Diffie-Hellman avec +clé DSA |
kEDH | Echange de clés Diffie-Hellman +temporaires (pas de certificat) |
kSRP | échange de clés avec mot de passe +distant sécurisé (SRP) |
| Algorithmes d'authentification : | |
aNULL | Pas d'authentification |
aRSA | Authentification RSA |
aDSS | Authentification DSS |
aDH | Authentification Diffie-Hellman |
| Algorithmes de chiffrement : | |
eNULL | Pas de chiffrement |
NULL | alias pour eNULL |
AES | Chiffrement AES |
DES | Chiffrement DES |
3DES | Chiffrement Triple-DES |
RC4 | Chiffrement RC4 |
RC2 | Chiffrement RC2 |
IDEA | Chiffrement IDEA |
| Algorithmes de condensés MAC : | |
MD5 | Fonction de hashage MD5 |
SHA1 | Fonction de hashage SHA1 |
SHA | alias pour SHA1 |
SHA256 | Fonction de hashage SHA256 |
SHA384 | Fonction de hashage SHA384 |
| Alias : | |
SSLv3 | tous les algorithmes de chiffrement +SSL version 3.0 |
TLSv1 | tous les algorithmes de chiffrement +TLS version 1.0 |
EXP | tous les algorithmes de chiffrement +externes |
EXPORT40 | tous les algorithmes de chiffrement +externes limités à 40 bits |
EXPORT56 | tous les algorithmes de chiffrement +externes limités à 56 bits |
LOW | tous les algorithmes de chiffrement +faibles (non externes, DES simple) |
MEDIUM | tous les algorithmes avec +chiffrement 128 bits |
HIGH | tous les algorithmes +utilisant Triple-DES |
RSA | tous les algorithmes +utilisant l'échange de clés RSA |
DH | tous les algorithmes +utilisant l'échange de clés Diffie-Hellman |
EDH | tous les algorithmes +utilisant l'échange de clés Diffie-Hellman temporaires |
ECDH | Echange de clés Elliptic Curve Diffie-Hellman |
ADH | tous les algorithmes +utilisant l'échange de clés Diffie-Hellman anonymes |
AECDH | tous les algorithmes utilisant +l'échange de clés Elliptic Curve Diffie-Hellman |
SRP | tous les algorithmes utilisant +l'échange de clés avec mot de passe distant sécurisé (SRP) |
DSS | tous les algorithmes +utilisant l'authentification DSS |
ECDSA | tous les algorithmes utilisant +l'authentification ECDSA |
aNULL | tous les algorithmes n'utilisant +aucune authentification |
+Cela devient intéressant lorsque tous ces symboles sont combinés
+ensemble pour spécifier les algorithmes disponibles et l'ordre dans
+lequel vous voulez les utiliser. Pour simplifier tout cela, vous
+disposez aussi d'alias (SSLv3, TLSv1, EXP, LOW, MEDIUM,
+HIGH) pour certains groupes d'algorithmes. Ces symboles peuvent
+être reliés par des préfixes pour former la chaîne algorithmes.
+Les préfixes disponibles sont :
+: déplace les algorithmes qui conviennent à la
+place courante dans la liste-: supprime l'algorithme de la liste (peut être rajouté
+plus tard)!: supprime définitivement l'algorithme de la liste (ne
+peut plus y être rajouté plus tard)aNULL, eNULL et
+EXP sont toujours désactivésDepuis la version 2.4.7, les
+algorithmes de type null ou destinés à l'exportation sont toujours
+désactivés car mod_ssl ajoute obligatoirement
+!aNULL:!eNULL:!EXP à toute chaîne d'algorithme de
+chiffrement à l'initialisation.
Pour vous simplifier la vie, vous pouvez utiliser la commande
+``openssl ciphers -v'' qui vous fournit un moyen simple de
+créer la chaîne algorithmes avec succès. La chaîne
+algorithmes par défaut dépend de la version des bibliothèques
+SSL installées. Supposons qu'elle contienne
+``RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5'', ce qui
+stipule de mettre RC4-SHA et AES128-SHA en
+premiers, car ces algorithmes présentent un bon compromis entre vitesse
+et sécurité. Viennent ensuite les algorithmes de sécurité élevée et
+moyenne. En fin de compte, les algorithmes qui n'offrent aucune
+authentification sont exclus, comme les algorithmes anonymes
+Diffie-Hellman pour SSL, ainsi que tous les algorithmes qui utilisent
+MD5 pour le hashage, car celui-ci est reconnu comme
+insuffisant.
$ openssl ciphers -v 'RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5' +RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 +AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 +DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 +... ... ... ... ... +SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 +PSK-RC4-SHA SSLv3 Kx=PSK Au=PSK Enc=RC4(128) Mac=SHA1 +KRB5-RC4-SHA SSLv3 Kx=KRB5 Au=KRB5 Enc=RC4(128) Mac=SHA1
Vous trouverez la liste complète des algorithmes RSA & DH +spécifiques à SSL dans la Table 2.
+SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW+
| Symbole algorithme | Protocole | +Echange de clés | Authentification | Chiffrement | +Condensé MAC | Type |
|---|---|---|---|---|---|---|
| Algorithmes RSA : | ||||||
DES-CBC3-SHA | SSLv3 | RSA | RSA | 3DES(168) | SHA1 | |
IDEA-CBC-SHA | SSLv3 | RSA | RSA | IDEA(128) | SHA1 | |
RC4-SHA | SSLv3 | RSA | RSA | RC4(128) | SHA1 | |
RC4-MD5 | SSLv3 | RSA | RSA | RC4(128) | MD5 | |
DES-CBC-SHA | SSLv3 | RSA | RSA | DES(56) | SHA1 | |
EXP-DES-CBC-SHA | SSLv3 | RSA(512) | RSA | DES(40) | SHA1 | export |
EXP-RC2-CBC-MD5 | SSLv3 | RSA(512) | RSA | RC2(40) | MD5 | export |
EXP-RC4-MD5 | SSLv3 | RSA(512) | RSA | RC4(40) | MD5 | export |
NULL-SHA | SSLv3 | RSA | RSA | None | SHA1 | |
NULL-MD5 | SSLv3 | RSA | RSA | None | MD5 | |
| Algorithmes Diffie-Hellman : | ||||||
ADH-DES-CBC3-SHA | SSLv3 | DH | None | 3DES(168) | SHA1 | |
ADH-DES-CBC-SHA | SSLv3 | DH | None | DES(56) | SHA1 | |
ADH-RC4-MD5 | SSLv3 | DH | None | RC4(128) | MD5 | |
EDH-RSA-DES-CBC3-SHA | SSLv3 | DH | RSA | 3DES(168) | SHA1 | |
EDH-DSS-DES-CBC3-SHA | SSLv3 | DH | DSS | 3DES(168) | SHA1 | |
EDH-RSA-DES-CBC-SHA | SSLv3 | DH | RSA | DES(56) | SHA1 | |
EDH-DSS-DES-CBC-SHA | SSLv3 | DH | DSS | DES(56) | SHA1 | |
EXP-EDH-RSA-DES-CBC-SHA | SSLv3 | DH(512) | RSA | DES(40) | SHA1 | export |
EXP-EDH-DSS-DES-CBC-SHA | SSLv3 | DH(512) | DSS | DES(40) | SHA1 | export |
EXP-ADH-DES-CBC-SHA | SSLv3 | DH(512) | None | DES(40) | SHA1 | export |
EXP-ADH-RC4-MD5 | SSLv3 | DH(512) | None | RC4(40) | MD5 | export |
| Description: | Permet d'activer la compression au niveau SSL |
|---|---|
| Syntaxe: | SSLCompression on|off |
| Défaut: | SSLCompression off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible à partir de la version 2.4.3 du serveur HTTP
+Apache, si on utilise une version d'OpenSSL 0.9.8 ou supérieure ;
+l'utilisation dans un contexte de serveur virtuel n'est disponible que
+si on utilise une version d'OpenSSL 1.0.0 ou supérieure. La valeur par
+défaut était on dans la version 2.4.3. |
Cette directive permet d'activer la compression au niveau SSL.
+L'activation de la compression est à l'origine de problèmes de +sécurité dans la plupart des configurations (l'attaque nommée CRIME).
+| Description: | Active l'utilisation d'un accélérateur matériel de +chiffrement |
|---|---|
| Syntaxe: | SSLCryptoDevice moteur |
| Défaut: | SSLCryptoDevice builtin |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet d'activer l'utilisation d'une carte accélératrice +de chiffrement qui prendra en compte certaines parties du traitement +relatif à SSL. Cette directive n'est utilisable que si la boîte à +outils SSL à été compilée avec le support "engine" ; les versions 0.9.7 +et supérieures d'OpenSSL possèdent par défaut le support "engine", alors +qu'avec la version 0.9.6, il faut utiliser les distributions séparées +"-engine".
+ +Pour déterminer les moteurs supportés, exécutez la commande
+"openssl engine".
# Pour un accélérateur Broadcom : +SSLCryptoDevice ubsec+
| Description: | Interrupteur marche/arrêt du moteur SSL |
|---|---|
| Syntaxe: | SSLEngine on|off|optional |
| Défaut: | SSLEngine off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet d'activer/désactiver le moteur du protocole
+SSL/TLS. Elle doit être utilisée dans une section <VirtualHost> pour activer
+SSL/TLS pour ce serveur virtuel particulier. Par défaut, le moteur du
+protocole SSL/TLS est désactivé pour le serveur principal et tous les
+serveurs virtuels configurés.
<VirtualHost _default_:443> +SSLEngine on +#... +</VirtualHost>+
Depuis la version 2.1 d'Apache, la directive
+SSLEngine peut être définie à
+optional, ce qui active le support de RFC 2817, Upgrading to
+TLS Within HTTP/1.1. Pour le moment, aucun navigateur web ne supporte
+RFC 2817.
| Description: | Coimmutateur du mode SSL FIPS |
|---|---|
| Syntaxe: | SSLFIPS on|off |
| Défaut: | SSLFIPS off |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet d'activer/désactiver l'utilisation du drapeau +FIPS_mode de la bibliothèque SSL. Elle doit être définie dans le +contexte du serveur principal, et n'accepte pas les configurations +sources de conflits (SSLFIPS on suivi de SSLFIPS off par exemple). Le +mode s'applique à toutes les opérations de la bibliothèque SSL. +
+
+Si httpd a été compilé avec une bibliothèque SSL qui ne supporte pas le
+drapeau FIPS_mode, la directive SSLFIPS on échouera.
+Reportez-vous au document sur la politique de sécurité FIPS 140-2 de la
+bibliothèque du fournisseur SSL, pour les prérequis spécifiques
+nécessaires à l'utilisation de mod_ssl selon un mode d'opération
+approuvé par FIPS 140-2 ; notez que mod_ssl en lui-même n'est pas
+validé, mais peut être décrit comme utilisant un module de chiffrement
+validé par FIPS 140-2, lorsque tous les composants sont assemblés et mis
+en oeuvre selon les recommandations de la politique de sécurité
+applicable.
+
| Description: | Option permettant de classer les algorithmes de chiffrement +du serveur par ordre de préférence |
|---|---|
| Syntaxe: | SSLHonorCipherOrder on|off |
| Défaut: | SSLHonorCipherOrder off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
Normalement, ce sont les préférences du client qui sont prises en +compte lors du choix d'un algorithme de chiffrement au cours d'une +négociation SSLv3 ou TLSv1. Si cette directive est activée, ce sont les +préférences du serveur qui seront prises en compte à la place.
+SSLHonorCipherOrder on+
| Description: | Option permettant d'activer le support de la renégociation +non sécurisée |
|---|---|
| Syntaxe: | SSLInsecureRenegotiation on|off |
| Défaut: | SSLInsecureRenegotiation off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible depuis httpd 2.2.15, si une version 0.9.8m +ou supérieure d'OpenSSL est utilisée |
Comme il a été spécifié, toutes les versions des protocoles SSL et +TLS (jusqu'à la version 1.2 de TLS incluse) étaient vulnérables à une +attaque de type Man-in-the-Middle (CVE-2009-3555) +au cours d'une renégociation. Cette vulnérabilité permettait à un +attaquant de préfixer la requête HTTP (telle qu'elle était vue du +serveur) avec un texte choisi. Une extension du protocole a été +développée pour corriger cette vulnérabilité, sous réserve qu'elle soit +supportée par le client et le serveur.
+ +Si mod_ssl est lié à une version 0.9.8m ou
+supérieure d'OpenSSL, par défaut, la renégociation n'est accordée qu'aux
+clients qui supportent la nouvelle extension du protocole. Si
+cette directive est activée, la renégociation sera accordée aux anciens
+clients (non patchés), quoique de manière non sécurisée
Si cette directive est activée, les connexions SSL seront vulnérables +aux attaques de type préfixe Man-in-the-Middle comme décrit dans CVE-2009-3555.
+SSLInsecureRenegotiation on+
La variable d'environnement SSL_SECURE_RENEG peut être
+utilisée dans un script SSI ou CGI pour déterminer si la renégociation
+sécurisée est supportée pour une connexion SSL donnée.
| Description: | Définit l'URI du répondeur par défaut pour la validation +OCSP |
|---|---|
| Syntaxe: | SSLOCSDefaultResponder uri |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
Cette directive permet de définir le répondeur OCSP par défaut. Si la
+directive SSLOCSPOverrideResponder n'est pas activée,
+l'URI spécifié ne sera utilisé que si aucun URI de répondeur n'est
+spécifié dans le certificat en cours de vérification.
| Description: | Active la validation OCSP de la chaîne de certificats du +client |
|---|---|
| Syntaxe: | SSLOCSPEnable on|leaf|off |
| Défaut: | SSLOCSPEnable off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Le mode leaf est disponible à partir de la version +2.4.34 du serveur HTTP Apache |
Cette directive permet d'activer la validation OCSP de la chaîne de +certificats du client. Si elle est activée, les certificats de la chaîne +de certificats du client seront validés auprès d'un répondeur OCSP, une +fois la vérification normale effectuée (vérification des CRLs +incluse). En mode 'leaf', seul le certificat du client sera validé.
+ +Le répondeur OCSP utilisé est soit extrait du certificat lui-même,
+soit spécifié dans la configuration ; voir les directives SSLOCSPDefaultResponder et SSLOCSPOverrideResponder.
SSLVerifyClient on +SSLOCSPEnable on +SSLOCSPDefaultResponder "http://responder.example.com:8888/responder" +SSLOCSPOverrideResponder on+
| Description: | Evite la vérification des certificats des répondeurs OCSP |
|---|---|
| Syntaxe: | SSLOCSPNoverify On/Off |
| Défaut: | SSLOCSPNoverify Off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible à partir de la version 2.4.26 du serveur HTTP Apache, +sous réserve d'utiliser une version 0.9.7 ou supérieure d'OpenSSL |
Cette directive permet d'éviter la vérification des certificats +des répondeurs OCSP, ce qui peut s'avérer utile lorsqu'on teste un serveur OCSP.
+ +| Description: | Force l'utilisation de l'URI du répondeur par défaut pour +la validation OCSP |
|---|---|
| Syntaxe: | SSLOCSPOverrideResponder on|off |
| Défaut: | SSLOCSPOverrideResponder off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
Force l'utilisation, au cours d'une validation OCSP de certificat, du +répondeur OCSP par défaut spécifié dans la configuration, que le +certificat en cours de vérification fasse mention d'un répondeur OCSP ou +non.
+ +| Description: | Adresse de mandataire à utiliser pour les requêtes OCSP |
|---|---|
| Syntaxe: | SSLOCSPProxyURL url |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible à partir de la version 2.4.19 du serveur HTTP Apache |
Cette directive permet de définir l'URL d'un mandataire HTTP qui devra être +utilisé pour toutes les requêtes vers un répondeur OCSP.
+ +| Description: | Fournit un jeu de certificats de confiance du répondeur OCSP avec +encodage PEM |
|---|---|
| Syntaxe: | SSLOCSPResponderCertificateFile file |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible à partir de la version 2.4.26 du serveur HTTP Apache, +sous réserve d'utiliser une version 0.9.7 ou supérieure d'OpenSSL |
Cette directive permet de définir un fichier contenant une liste de +certificats de confiance du répondeur OCSP à utiliser au cours de la validation +du certificat du répondeur OCSP. Les certificats fournis peuvent +être considérés comme de confiance sans avoir à effectuer de vérifications +supplémentaires. Ce processus de validation du certificat du répondeur OCSP +intervient en général lorsque ce dernier est autosigné ou tout simplement absent +de la réponse OCSP.
+ +| Description: | Délai d'attente pour les requêtes OCSP |
|---|---|
| Syntaxe: | SSLOCSPResponderTimeout secondes |
| Défaut: | SSLOCSPResponderTimeout 10 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
Cette option permet de définir le délai d'attente pour les requêtes à
+destination des répondeurs OCSP, lorsque la directive SSLOCSPEnable est à on.
| Description: | Age maximum autorisé pour les réponses OCSP |
|---|---|
| Syntaxe: | SSLOCSPResponseMaxAge secondes |
| Défaut: | SSLOCSPResponseMaxAge -1 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
Cette option permet de définir l'âge maximum autorisé (la
+"fraicheur") des réponses OCSP. La valeur par défault (-1)
+signifie qu'aucun âge maximum n'est défini ; autrement dit, les
+réponses OCSP sont considérées comme valides tant que la valeur de leur
+champ nextUpdate se situe dans le futur.
| Description: | Dérive temporelle maximale autorisée pour la validation des +réponses OCSP |
|---|---|
| Syntaxe: | SSLOCSPResponseTimeSkew secondes |
| Défaut: | SSLOCSPResponseTimeSkew 300 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
Cette option permet de définir la dérive temporelle maximale
+autorisée pour les réponses OCSP (lors de la vérification des champs
+thisUpdate et nextUpdate).
| Description: | Use a nonce within OCSP queries |
|---|---|
| Syntaxe: | SSLOCSPUseRequestNonce on|off |
| Défaut: | SSLOCSPUseRequestNonce on |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Available in httpd 2.4.10 and later |
La documentation de cette directive + n'a pas encore t traduite. Veuillez vous reporter la version + en langue anglaise.
| Description: | Configuration des paramètres d'OpenSSL via son API SSL_CONF |
|---|---|
| Syntaxe: | SSLOpenSSLConfCmd commande valeur |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible depuis la version 2.4.8 du serveur HTTP +Apache avec OpenSSL 1.0.2 ou supérieur |
Cette directive permet à mod_ssl d'accéder à l'API SSL_CONF
+d'OpenSSL. Il n'est ainsi plus nécessaire d'implémenter des
+directives supplémentaires pour mod_ssl lorsque de nouvelles
+fonctionnalités sont ajoutées à OpenSSL, ce qui rend la configuration de
+ce dernier beaucoup plus souple.
Le jeu de commandes disponibles pour la directive
+SSLOpenSSLConfCmd dépend de la version d'OpenSSL
+utilisée pour mod_ssl (la version minimale 1.0.2 est un
+prérequis). Pour obtenir la liste des commandes supportées, voir la
+section Supported configuration file commands de la page de
+manuel d'OpenSSL SSL_CONF_cmd(3).
Certaines commandes peuvent remplacer des directives existantes
+(comme SSLCipherSuite ou
+SSLProtocol) ; notez cependant
+que la syntaxe et/ou les valeurs possibles peuvent différer.
SSLOpenSSLConfCmd Options -SessionTicket,ServerPreference +SSLOpenSSLConfCmd ECDHParameters brainpoolP256r1 +SSLOpenSSLConfCmd ServerInfoFile +"/usr/local/apache2/conf/server-info.pem" +SSLOpenSSLConfCmd Protocol "-ALL, TLSv1.2" +SSLOpenSSLConfCmd SignatureAlgorithms RSA+SHA384:ECDSA+SHA256+
| Description: | Configure différentes options d'exécution du moteur SSL |
|---|---|
| Syntaxe: | SSLOptions [+|-]option ... |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | Options |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de contrôler différentes options d'exécution du
+moteur SSL dans un contexte de répertoire. Normalement, si plusieurs
+SSLOptions peuvent s'appliquer à un répertoire, c'est la
+plus spécifique qui est véritablement prise en compte ; les options ne
+se combinent pas entre elles. Elles se combinent cependant entre elles
+si elles sont toutes précédées par un symbole plus
+(+) ou moins (-). Toute option précédée d'un
++ est ajoutée aux options actuellement en vigueur, et toute
+option précédée d'un - est supprimée de ces mêmes
+options.
+
+Les options disponibles sont :
+StdEnvVars
+ + Lorsque cette option est activée, le jeu standard de variables + d'environnement SSL relatives à CGI/SSI est créé. Cette option est + désactivée par défaut pour des raisons de performances, car + l'extraction des informations constitue une opération assez coûteuse + en ressources. On n'active donc en général cette option que pour les + requêtes CGI et SSI.
+ExportCertData
+
+ Lorsque cette option est activée, des variables d'environnement
+ CGI/SSI supplémentaires sont créées : SSL_SERVER_CERT,
+ SSL_CLIENT_CERT et
+ SSL_CLIENT_CERT_CHAIN_n (avec n =
+ 0,1,2,..). Elles contiennent les certificats X.509 codés en PEM du
+ serveur et du client pour la connexion HTTPS courante, et peuvent
+ être utilisées par les scripts CGI pour une vérification de
+ certificat plus élaborée. De plus, tous les autres certificats de la
+ chaîne de certificats du client sont aussi fournis. Tout ceci gonfle
+ un peu l'environnement, et c'est la raison pour laquelle vous ne
+ devez activer cette option qu'à la demande.
FakeBasicAuth
+
+ Lorsque cette option est activée, le Nom Distinctif (DN) sujet du
+ certificat client X509 est traduit en un nom d'utilisateur pour
+ l'autorisation HTTP de base. Cela signifie que les méthodes
+ d'authentification standard d'Apache peuvent être utilisées pour le
+ contrôle d'accès. Le nom d'utilisateur est tout simplement le Sujet
+ du certificat X509 du client (il peut être déterminé en utilisant la
+ commande OpenSSL openssl x509 : openssl x509
+ -noout -subject -in certificat.crt).
+ Notez qu'aucun mot de passe n'est envoyé par l'utilisateur. Chaque
+ entrée du fichier des utilisateurs doit comporter ce mot de passe :
+ ``xxj31ZMTZzkVA'', qui est la version chiffrée en DES
+ du mot ``password''. Ceux qui travaillent avec un
+ chiffrement basé sur MD5 (par exemple sous FreeBSD ou BSD/OS,
+ etc...) doivent utiliser le condensé MD5 suivant pour le même mot :
+ ``$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/''.
Notez que la directive AuthBasicFake implémentée par le
+ module mod_auth_basic peut être utilisée d'une
+ manière plus générale comme simulation d'authentification basique,
+ ce qui permet de contrôler la structure nom utilisateur/mot de
+ passe.
StrictRequire
+
+ Cette option force l'interdiction d'accès lorsque
+ SSLRequireSSL ou SSLRequire a décidé que
+ l'accès devait être interdit. Par défaut, dans le cas où
+ une directive ``Satisfy any'' est utilisée, et si
+ d'autres restrictions d'accès ont été franchies, on passe en général
+ outre l'interdiction d'accès due à SSLRequireSSL ou
+ SSLRequire (parce que c'est ainsi que le mécanisme
+ Satisfy d'Apache doit fonctionner). Pour des
+ restrictions d'accès plus strictes, vous pouvez cependant utiliser
+ SSLRequireSSL et/ou SSLRequire en
+ combinaison avec une option ``SSLOptions
+ +StrictRequire''. Une directive ``Satisfy Any''
+ n'a alors aucune chance d'autoriser l'accès si mod_ssl a décidé de
+ l'interdire.
OptRenegotiate
+ + Cette option active la gestion optimisée de la renégociation des + connexions SSL intervenant lorsque les directives SSL sont utilisées + dans un contexte de répertoire. Par défaut un schéma strict est + appliqué, et chaque reconfiguration des paramètres SSL au + niveau du répertoire implique une phase de renégociation SSL + complète. Avec cette option, mod_ssl essaie d'éviter les + échanges non nécessaires en effectuant des vérifications de + paramètres plus granulaires (mais tout de même efficaces). + Néanmoins, ces vérifications granulaires peuvent ne pas correspondre + à ce qu'attend l'utilisateur, et il est donc recommandé de n'activer + cette option que dans un contexte de répertoire.
+LegacyDNStringFormat
+
+ Cette option permet d'agir sur la manière dont les valeurs des
+ variables SSL_{CLIENT,SERVER}_{I,S}_DN sont formatées.
+ Depuis la version 2.3.11, Apache HTTPD utilise par défaut un format
+ compatible avec la RFC 2253. Ce format utilise des virgules comme
+ délimiteurs entre les attributs, permet l'utilisation de caractères
+ non-ASCII (qui sont alors convertis en UTF8), échappe certains
+ caractères spéciaux avec des slashes inversés, et trie les attributs
+ en plaçant l'attribut "C" en dernière position.
Si l'option LegacyDNStringFormat est présente, c'est
+ l'ancien format qui sera utilisé : les attributs sont triés avec
+ l'attribut "C" en première position, les séparateurs sont des
+ slashes non inversés, les caractères non-ASCII ne sont pas supportés
+ et le support des caractères spéciaux n'est pas fiable.
+
SSLOptions +FakeBasicAuth -StrictRequire +<Files ~ "\.(cgi|shtml)$"> + SSLOptions +StdEnvVars -ExportCertData +</Files>+
| Description: | Méthode utilisée pour entrer le mot de passe pour les clés +privées chiffrées |
|---|---|
| Syntaxe: | SSLPassPhraseDialog type |
| Défaut: | SSLPassPhraseDialog builtin |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ssl |
+Lors de son démarrage, Apache doit lire les différents fichiers de
+certificats (voir la directive SSLCertificateFile) et de clés privées
+(voir la directive SSLCertificateKeyFile) des serveurs
+virtuels où SSL est activé. Comme, pour des raisons de sécurité, les
+fichiers de clés privées sont en général chiffrés, mod_ssl doit
+demander à l'administrateur un mot de passe pour déchiffrer ces
+fichiers. L'argument type permet de choisir la manière dont
+cette demande peut être formulée parmi les trois suivantes :
builtin
+ + C'est la méthode par défaut, et un dialogue interactive de terminal + s'ouvre au cours du démarrage juste avant qu'Apache ne se détache du + terminal. A ce moment, l'administrateur doit entrer manuellement un + mot de passe pour chaque fichier de clé privée chiffré. Etant donné + qu'il peut y avoir un grand nombre de serveurs virtuels configurés + avec SSL activé, le protocole de réutilisation suivant est utilisé + pour minimiser le dialogue : lorsqu'un fichier de clé privée est + chiffré, tous les mots de passe connus (au début, il n'y en a aucun, + bien entendu) sont essayés. Si l'un de ces mots de passe connus + convient, aucun dialogue ne s'ouvrira pour ce fichier de + clé privée particulier. Si aucun ne convient, un autre mot de passe + sera demandé à partir du terminal et sera mis en mémoire pour le + fichier de clé privée suivant (pour lequel il pourra éventuellement + être réutilisé).
++ Cette méthode confère à mod_ssl une grande souplesse (car pour N + fichiers de clé privée chiffrés, vous pouvez utiliser N + mots de passe différents - mais vous devrez alors tous les fournir, + bien entendu), tout en minimisant le dialogue de terminal (vous + pouvez en effet utiliser un seul mot de passe pour les N fichiers de + clé privée et vous n'aurez alors à l'entrer qu'une seule + fois).
|/chemin/vers/programme [arguments...]
+
+ Ce mode permet d'utiliser un programme externe qui va se présenter
+ comme une redirection vers un périphérique d'entrée particulier ; le
+ texte de prompt standard utilisé pour le mode builtin
+ est envoyé au programme sur stdin, et celui-ci doit
+ renvoyer des mots de passe sur stdout. Si
+ plusieurs mots de passe sont requis (ou si un mot de passe incorrect
+ a été entré), un texte de prompt supplémentaire sera écrit après le
+ retour du premier mot de passe, et d'autres mots de passe devront
+ alors être réécrits.
exec:/chemin/vers/programme
+
+ Ici, un programme externe est appelé au démarrage du serveur pour
+ chaque fichier de clé privée chiffré.Il est appelé avec deux
+ arguments (le premier est de la forme
+ ``nom-serveur:port'', le second
+ est ``RSA'', ``DSA'', ``ECC''
+ ou un index entier commençant à 3 si plus de 3 clés ont été
+ configurées), qui
+ indiquent pour quels serveur et algorithme il doit écrire le mot de
+ passe correspondant sur stdout. Avec les versions 2.4.8
+ (non réalisée) et
+ 2.4.9, il est appelé avec un seul argument, une chaîne de la forme
+ "servername:portnumber:index" (où index
+ est un nombre entier commençant à zéro), qui spécifie le serveur,
+ le port TCP et un numéro de certificat. Le but recherché est
+ l'exécution de vérifications de sécurité préalables permettant de
+ s'assurer que le système n'est pas victime d'une attaque, et de ne
+ fournir le mot de passe que si toutes les vérifications ont été
+ effectuées avec succès.
+ Ces vérifications de sécurité, ainsi que la manière dont le mot de
+ passe est déterminé peuvent être aussi sophistiqués que vous le
+ désirez. Mod_ssl ne définit que l'interface : un programme
+ exécutable qui écrit le mot de passe sur stdout. Ni
+ plus, ni moins ! Ainsi, si vous êtes vraiment paranoïaque en matière
+ de sécurité, voici votre interface. Tout le reste doit être confié à
+ l'administrateur à titre d'exercice, car les besoins en sécurité
+ locale sont très différents.
+ L'algorithme de réutilisation est utilisé ici aussi. En d'autres + termes, le programme externe n'est appelé qu'une fois par mot de + passe unique.
SSLPassPhraseDialog "exec:/usr/local/apache/sbin/pp-filter"+
| Description: | Indique les versions du protocole SSL/TLS +disponibles |
|---|---|
| Syntaxe: | SSLProtocol [+|-]protocole ... |
| Défaut: | SSLProtocol all -SSLv3 (jusqu'à la version 2.4.16 : all) |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir quelles versions du protocole SSL/TLS +seront acceptées lors de l'initialisation d'une nouvelle connexion.
++Les protocoles disponibles sont les suivants (sensibles à la +casse) :
+SSLv3
+ + Il s'agit du protocole Secure Sockets Layer (SSL) version 3.0 de + Netscape Corporation. C'est le successeur de SSLv2 et le + prédécesseur de TLSv1, mais est considéré comme + obsolète dans la RFC + 7568
TLSv1
+ + Il s'agit du protocole Transport Layer Security (TLS) version 1.0. + C'est le successeur de SSLv3, et il est défini dans la RFC2246. Il est + supporté par la plupart des clients.
TLSv1.1 (à partir de la version 1.0.1 d'OpenSSL)
+ + Une révision du protocole TLS 1.0 définie dans la RFC 4346.
TLSv1.2 (à partir de la version 1.0.1 d'OpenSSL)
+ + Une révision du protocole TLS 1.1 définie dans la RFC 5246.
TLSv1.3 (à partir de la version 1.1.1 d'OpenSSL)
+ + Une nouvelle version du protocole TLS définie dans la RFC 8446.
all
+
+ C'est un raccourci pour ``+SSLv3 +TLSv1'' ou - à partir
+ de la version 1.0.1 d'OpenSSL - ``+SSLv3 +TLSv1 +TLSv1.1
+ +TLSv1.2'' (sauf si OpenSSL a été compilé avec l'option
+ ``no-ssl3'', auquel cas all n'inclura pas
+ +SSLv3).
SSLProtocol TLSv1+
| Description: | Fichier contenant la concaténation des certificats de CA +codés en PEM pour l'authentification des serveurs distants |
|---|---|
| Syntaxe: | SSLProxyCACertificateFile file-path |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir le fichier tout-en-un où sont
+stockés les certificats des Autorités de Certification (CA) pour les
+serveurs distants auxquels vous avez à faire. On les utilise
+lors de l'authentification du serveur distant. Un tel fichier contient
+la simple concaténation des différents fichiers de certificats codés en
+PEM, classés par ordre de préférence. On peut utiliser cette directive à
+la place et/ou en complément de la directive SSLProxyCACertificatePath.
SSLProxyCACertificateFile +"/usr/local/apache2/conf/ssl.crt/ca-bundle-serveur.distant.crt"+
| Description: | Répertoire des certificats de CA codés en PEM pour +l'authentification des serveurs distants |
|---|---|
| Syntaxe: | SSLProxyCACertificatePath chemin-répertoire |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de spécifier le répertoire où sont stockés les +certificats des Autorités de Certification (CAs) pour les serveurs +distants auxquels vous avez à faire. On les utilise pour vérifier le +certificat du serveur distant lors de l'authentification de ce +dernier.
+
+Les fichiers de ce répertoire doivent être codés en PEM et ils sont
+accédés via des noms de fichier sous forme de condensés ou hash. Il ne
+suffit donc pas de placer les fichiers de certificats dans ce répertoire
+: vous devez aussi créer des liens symboliques nommés
+valeur-de-hashage.N, et vous devez toujours vous
+assurer que ce répertoire contient les liens symboliques appropriés.
SSLProxyCACertificatePath "/usr/local/apache2/conf/ssl.crt/"+
| Description: | Active la vérification des révocations basée sur les CRLs +pour l'authentification du serveur distant |
|---|---|
| Syntaxe: | SSLProxyCARevocationCheck chain|leaf|none |
| Défaut: | SSLProxyCARevocationCheck none |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Active la vérification des révocations basée sur les Listes de
+révocations de Certificats (CRL) pour les serveurs distants
+auxquels vous vous connectez. A moins une des directives SSLProxyCARevocationFile ou SSLProxyCARevocationPath doit être définie.
+Lorsque cette directive est définie à chain (valeur
+recommandée), les vérifications CRL sont effectuées sur tous les
+certificats de la chaîne, alors que la valeur leaf limite
+la vérification au certificat hors chaîne (la feuille).
+
chain ou
+leaf, les CRLs doivent être disponibles pour que la
+validation réussisse
+Avant la version 2.3.15, les vérifications CRL dans mod_ssl
+réussissaient même si aucune CRL n'était trouvée dans les chemins
+définis par les directives SSLProxyCARevocationFile ou SSLProxyCARevocationPath. Le comportement a
+changé avec l'introduction de cette directive : lorsque la vérification
+est activée, les CRLs doivent être présentes pour que la
+validation réussisse ; dans le cas contraire, elle échouera avec une
+erreur "CRL introuvable".
+
SSLProxyCARevocationCheck chain+
| Description: | Fichier contenant la concaténation des CRLs de CA codés en +PEM pour l'authentification des serveurs distants |
|---|---|
| Syntaxe: | SSLProxyCARevocationFile chemin-fichier |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir le fichier tout-en-un où sont
+rassemblées les Listes de Révocation de Certificats (CRLs) des Autorités
+de certification (CAs) pour les serveurs distants auxquels vous
+avez à faire. On les utilise pour l'authentification des serveurs
+distants. Un tel fichier contient la simple concaténation des différents
+fichiers de CRLs codés en PEM, classés par ordre de préférence. Cette
+directive peut être utilisée à la place et/ou en complément de la
+directive SSLProxyCARevocationPath.
SSLProxyCARevocationFile +"/usr/local/apache2/conf/ssl.crl/ca-bundle-serveur.distant.crl"+
| Description: | Répertoire des CRLs de CA codés en PEM pour +l'authentification des serveurs distants |
|---|---|
| Syntaxe: | SSLProxyCARevocationPath chemin-répertoire |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir le répertoire où sont stockées les +Listes de Révocation de Certificats (CRL) des Autorités de Certification +(CAs) pour les serveurs distants auxquels vous avez à faire. On les +utilise pour révoquer les certificats des serveurs distants au cours de +l'authentification de ces derniers.
+
+Les fichiers de ce répertoire doivent être codés en PEM et ils sont
+accédés via des noms de fichier sous forme de condensés ou hash. Il ne
+suffit donc pas de placer les fichiers de CRL dans ce répertoire
+: vous devez aussi créer des liens symboliques nommés
+valeur-de-hashage.rN, et vous devez toujours vous
+assurer que ce répertoire contient les liens symboliques appropriés.
SSLProxyCARevocationPath "/usr/local/apache2/conf/ssl.crl/"+
| Description: | Configuration de la vérification du champ CN du certificat +du serveur distant + |
|---|---|
| Syntaxe: | SSLProxyCheckPeerCN on|off |
| Défaut: | SSLProxyCheckPeerCN on |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir si le champ CN du certificat du serveur
+distant doit être comparé au nom de serveur de l'URL de la requête. S'ils ne
+correspondent pas, un code d'état 502 (Bad Gateway) est envoyé. A partir de la
+version 2.4.5, SSLProxyCheckPeerCN a été remplacé par SSLProxyCheckPeerName.
+
+De la version 2.4.5 à la version 2.4.20, spécifier SSLProxyCheckPeerName
+off était suffisant pour obtenir ce comportement (car la valeur par
+défaut de SSLProxyCheckPeerCN était on). Avec ces
+versions, les deux directives doivent être définies à off pour
+éviter toute validation du nom de certificat du serveur distant, et de
+nombreux utilisateurs ont signalé ce comportement comme très perturbant.
+
+A partir de la version 2.4.21, toutes les configurations qui activent au moins
+une des deux directives SSLProxyCheckPeerName ou
+SSLProxyCheckPeerCN adopteront le nouveau comportement de la
+directive SSLProxyCheckPeerName, et
+toutes les configurations qui désactivent une des deux directives
+SSLProxyCheckPeerName ou SSLProxyCheckPeerCN
+éviteront toute validation du nom de certificat du serveur distant. Seule la
+configuration suivante permettra de retrouver la comparaison de CN
+traditionnelle pour les versions 2.4.21 et supérieures :
+
SSLProxyCheckPeerCN on +SSLProxyCheckPeerName off+
| Description: | Configuration de la vérification de l'expiration du +certificat du serveur distant + |
|---|---|
| Syntaxe: | SSLProxyCheckPeerExpire on|off |
| Défaut: | SSLProxyCheckPeerExpire on |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir si l'expiration du certificat du +serveur distant doit être vérifiée ou non. Si la vérification échoue, un +code d'état 502 (Bad Gateway) est envoyé. +
+SSLProxyCheckPeerExpire on+
| Description: | Configure la vérification du nom d'hôte dans les +certificats serveur distants + |
|---|---|
| Syntaxe: | SSLProxyCheckPeerName on|off |
| Défaut: | SSLProxyCheckPeerName on |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP +Apache |
+Cette directive permet de configurer la vérification du nom d'hôte pour +les certificats serveur lorsque mod_ssl agit en tant que client SSL. La +vérification réussit si le nom d'hôte de l'URI de la requête correspond à un +des attributs CN du sujet du certificat, ou à l'extension subjectAltName. Si la +vérification échoue, la requête SSL +avorte, et un code d'erreur 502 (Bad Gateway) est renvoyé. +
+
+Les caractères génériques sont supportés dans certains cas bien spécifiques :
+une entrée subjectAltName de type dNSName ou les attributs CN
+commençant par *. correspondront à tout nom d'hôte comportant
+le même nombre de champs et le même suffixe ; par exemple,
+*.example.org correspondra à foo.example.org,
+mais pas à foo.bar.example.org car le nombre d'éléments dans les
+nom est différent.
+
+Cette fonctionnalité a été introduite avec la version 2.4.5 et l'emporte sur la
+directive SSLProxyCheckPeerCN qui ne
+comparait que la valeur exacte du premier attribut CN avec le nom d'hôte.
+Cependant, de nombreux utilisateurs étaient déconcertés par le comportement
+induit par l'utilisation de ces deux directives individuellement, si bien que ce
+comportement a été amélioré avec la version 2.4.21. Voir la description de la
+directive SSLProxyCheckPeerCN pour le
+comportement original et des détails à propos de ces améliorations.
+
| Description: | Algorithmes de chiffrement disponibles pour la négociation +lors de l'initialisation d'une connexion SSL de mandataire |
|---|---|
| Syntaxe: | SSLProxyCipherSuite [protocol] cipher-spec |
| Défaut: | SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
Cette directive est équivalente à la directive SSLCipherSuite, mais s'applique à une connexion de
+mandataire. Veuillez vous reporter à la directive SSLCipherSuite pour plus d'informations.
| Description: | Interrupteur marche/arrêt du moteur de mandataire +SSL |
|---|---|
| Syntaxe: | SSLProxyEngine on|off |
| Défaut: | SSLProxyEngine off |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet d'activer/désactiver l'utilisation du moteur de
+protocole SSL/TLS pour le mandataire. On l'utilise en général à
+l'intérieur d'une section <VirtualHost> pour activer le protocole SSL/TLS
+dans le cadre d'un mandataire pour un serveur virtuel particulier. Par
+défaut, le moteur de protocole SSL/TLS est désactivé pour la fonction de
+mandataire du serveur principal et de tous les serveurs virtuels
+configurés.
Notez que la directive SSLProxyEngine ne doit
+généralement pas être utilisée dans le cadre d'un serveur virtuel qui agit en
+tant que mandataire direct (via les directives <Proxy> ou ProxyRequests).
+SSLProxyEngine n'est pas nécessaire pour activer un
+serveur mandataire direct pour les requêtes SSL/TLS.
<VirtualHost _default_:443> + SSLProxyEngine on + #... +</VirtualHost>+
| Description: | Fichier de certificats de CA encodés PEM concaténés permettant au +mandataire de choisir un certificat |
|---|---|
| Syntaxe: | SSLProxyMachineCertificateChainFile nom-fichier |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir le fichier global où est enregistrée +la chaîne de certification pour tous les certificats clients utilisés. +Elle est nécessaire si le serveur distant présente une liste de +certificats de CA qui ne sont pas les signataires directs d'un des +certificats clients configurés. +
++Ce fichier contient tout simplement la concaténation des différents +fichiers de certificats encodés PEM. Au démarrage, chaque certificat +client configuré est examiné et une chaîne de certification est +construite. +
+Si cette directive est définie, tous les certificats contenus dans le
+fichier spécifié seront considérés comme étant de confiance, comme s'ils
+étaient aussi désignés dans la directive SSLProxyCACertificateFile.
SSLProxyMachineCertificateChainFile +"/usr/local/apache2/conf/ssl.crt/proxyCA.pem"+
| Description: | Fichier contenant la concaténation des clés et certificats +clients codés en PEM que le mandataire doit utiliser |
|---|---|
| Syntaxe: | SSLProxyMachineCertificateFile chemin-fichier |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir le fichier tout-en-un où sont stockés +les clés et certificats permettant au serveur mandataire de +s'authentifier auprès des serveurs distants. +
+
+Le fichier spécifié est la simple concaténation des différents fichiers
+de certificats codés en PEM, classés par ordre de préférence. Cette
+directive s'utilise à la place ou en complément de la directive
+SSLProxyMachineCertificatePath.
+
Actuellement, les clés privées chiffrées ne sont pas supportées.
+SSLProxyMachineCertificateFile +"/usr/local/apache2/conf/ssl.crt/proxy.pem"+
| Description: | Répertoire des clés et certificats clients codés en PEM que +le mandataire doit utiliser |
|---|---|
| Syntaxe: | SSLProxyMachineCertificatePath chemin-répertoire |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir le répertoire où sont stockés les clés +et certificats permettant au serveur mandataire de s'authentifier auprès +des serveurs distants. +
+Les fichiers de ce répertoire doivent être codés en PEM et ils sont
+accédés via des noms de fichier sous forme de condensés ou hash. Vous
+devez donc aussi créer des liens symboliques nommés
+valeur-de-hashage.N, et vous devez toujours vous
+assurer que ce répertoire contient les liens symboliques appropriés.
Actuellement, les clés privées chiffrées ne sont pas supportées.
+SSLProxyMachineCertificatePath "/usr/local/apache2/conf/proxy.crt/"+
| Description: | Définit les protocoles SSL disponibles pour la fonction de +mandataire |
|---|---|
| Syntaxe: | SSLProxyProtocol [+|-]protocole ... |
| Défaut: | SSLProxyProtocol all -SSLv3 (jusqu'à la version 2.4.16: all) |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir les protocoles SSL que mod_ssl peut +utiliser lors de l'élaboration de son environnement de serveur pour la +fonction de mandataire. Il ne se connectera qu'aux serveurs utilisant un +des protocoles spécifiés.
+Veuillez vous reporter à la directive SSLProtocol pour plus d'informations.
+
| Description: | Niveau de vérification du certificat du serveur +distant |
|---|---|
| Syntaxe: | SSLProxyVerify niveau |
| Défaut: | SSLProxyVerify none |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
Lorsqu'un mandataire est configuré pour faire suivre les requêtes +vers un serveur SSL distant, cette directive permet de configurer la +vérification du certificat de ce serveur distant.
+ ++Les valeurs de niveaux disponibles sont les suivantes :
+En pratique, seuls les niveaux none et +require sont vraiment intéressants, car le niveau +optional ne fonctionne pas avec tous les serveurs, et +le niveau optional_no_ca va tout à fait à l'encontre de +l'idée que l'on peut se faire de l'authentification (mais peut tout de +même être utilisé pour établir des pages de test SSL, etc...).
+ +SSLProxyVerify require+
| Description: | Niveau de profondeur maximum dans les certificats de CA +lors de la vérification du certificat du serveur distant |
|---|---|
| Syntaxe: | SSLProxyVerifyDepth niveau |
| Défaut: | SSLProxyVerifyDepth 1 |
| Contexte: | configuration globale, serveur virtuel, section proxy |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir le niveau de profondeur maximum +jusqu'auquel mod_ssl doit aller au cours de sa vérification avant de +décider que le serveur distant ne possède pas de certificat valide.
+
+La profondeur correspond en fait au nombre maximum de fournisseurs de
+certificats intermédiaires, c'est à dire le nombre maximum de
+certificats
+de CA que l'on peut consulter lors de la vérification du certificat du
+serveur distant. Une profondeur de 0 signifie que seuls les certificats
+de serveurs distants auto-signés sont acceptés, et la profondeur par
+défaut de 1 que le certificat du serveur distant peut être soit
+auto-signé, soit signé par une CA connue directement du serveur (en
+d'autres termes, le certificat de CA est référencé par la directive
+SSLProxyCACertificatePath),
+etc...
SSLProxyVerifyDepth 10+
| Description: | Source de déclenchement du Générateur de Nombres +Pseudo-Aléatoires (PRNG) |
|---|---|
| Syntaxe: | SSLRandomSeed contexte source
+[nombre] |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir une ou plusieurs sources de
+déclenchement du Générateur de Nombres Pseudo-Aléatoires (PRNG) dans
+OpenSSL au démarrage du serveur (si contexte a pour valeur
+startup) et/ou juste avant l'établissement d'une nouvelle
+connexion SSL (si contexte a pour valeur connect).
+Cette directive ne peut être utilisée qu'au niveau du serveur global car
+le PRNG est un service global.
+Les différentes valeurs de source disponibles sont :
+builtin
+ Cette source de déclenchement intégrée est toujours disponible. Son + utilisation consomme un minimum de cycles CPU en cours d'exécution, et son + utilisation ne présente de ce fait aucun problème. La source utilisée pour + déclencher le PRNG contient la date courante, l'identifiant du processus + courant et un extrait de 128 octets aléatoirement choisi dans la pile. Ceci + présente un inconvénient car le caractère aléatoire de cette source n'est + pas vraiment fort, et au démarrage (lorsque la structure d'échanges n'est + pas encore disponible), cette source ne produit que quelques octets + d'entropie. Vous devez donc toujours utiliser une source de déclenchement + additionnelle, au moins pour le démarrage.
file:/chemin/vers/source
+
+ Cette variante utilise un fichier externe
+ file:/chemin/vers/source comme source de déclenchement
+ du PRNG. Lorsque nombre est spécifié, seuls les
+ nombre premiers octets du fichier forment l'entropie (et
+ nombre est fourni comme premier argument à
+ /chemin/vers/source). Lorsque nombre n'est pas
+ spécifié, l'ensemble du fichier forme l'entropie (et 0
+ est fourni comme premier argument à
+ /chemin/vers/source). Utilisez cette source en
+ particulier au démarrage, par exemple avec un fichier de
+ périphérique /dev/random et/ou
+ /dev/urandom (qui sont en général présent sur les
+ plate-formes dérivées d'Unix modernes comme FreeBSD et Linux).
Soyez cependant prudent : en général,
+ /dev/random ne fournit que l'entropie dont il dispose
+ réellement ; en d'autres termes, lorsque vous demandez 512 octets
+ d'entropie, si le périphérique ne dispose que de 100 octets, deux
+ choses peuvent se produire : sur certaines plates-formes, vous ne
+ recevez que les 100 octets, alors que sur d'autres, la lecture se
+ bloque jusqu'à ce qu'un nombre suffisant d'octets soit disponible
+ (ce qui peut prendre beaucoup de temps). Il est préférable ici
+ d'utiliser le périphérique /dev/urandom, car il ne se
+ bloque jamais et fournit vraiment la quantité de données demandées.
+ Comme inconvénient, les données reçues ne sont pas forcément de la
+ meilleure qualité.
exec:/chemin/vers/programme
+
+ Cette variante utilise un exécutable externe
+ /chemin/vers/programme comme source de déclenchement du
+ PRNG. Lorsque nombre est spécifié, seules les
+ nombre premiers octets de son flux stdout
+ forment l'entropie. Lorsque nombre n'est pas spécifié,
+ l'intégralité des données produites sur stdout forment
+ l'entropie. N'utilisez cette variante qu'au démarrage où une source
+ de déclenchement fortement aléatoire est nécessaire, en utilisant
+ un programme externe (comme dans l'exemple
+ ci-dessous avec l'utilitaire truerand basé sur la
+ bibliothèque truerand de AT&T que vous trouverez
+ dans la distribution de mod_ssl). Bien entendu, l'utilisation de
+ cette variante dans un contexte "connection" ralentit le serveur de
+ manière trop importante, et en général, vous devez donc éviter
+ d'utiliser des programmes externes dans ce contexte.
egd:/chemin/vers/socket-egd (Unix seulement)
+ Cette variante utilise le socket de domaine Unix du Démon + Générateur d'Entropie externe ou Entropy Gathering Daemon ou EGD + (voir http://www.lothar.com/tech + /crypto/) pour déclencher le PRNG. N'utilisez cette variante que + si votre plate-forme ne possède pas de périphérique random ou + urandom.
SSLRandomSeed startup builtin +SSLRandomSeed startup "file:/dev/random" +SSLRandomSeed startup "file:/dev/urandom" 1024 +SSLRandomSeed startup "exec:/usr/local/bin/truerand" 16 +SSLRandomSeed connect builtin +SSLRandomSeed connect "file:/dev/random" +SSLRandomSeed connect "file:/dev/urandom" 1024+
| Description: | Définit la taille du tampon de renégociation +SSL |
|---|---|
| Syntaxe: | SSLRenegBufferSize taille |
| Défaut: | SSLRenegBufferSize 131072 |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_ssl |
Si une renégociation SSL est requise dans un contexte de répertoire,
+par exemple avec l'utilisation de SSLVerifyClient dans un bloc Directory ou
+Location, mod_ssl doit mettre en tampon en mémoire tout corps de requête
+HTTP en attendant qu'une nouvelle initialisation de connexion SSL puisse
+être effectuée. Cette directive permet de définir la quantité de mémoire
+à allouer pour ce tampon.
+Notez que dans de nombreuses configurations, le client qui envoie un +corps de requête n'est pas forcément digne de confiance, et l'on doit +par conséquent prendre en considération la possibilité d'une attaque de +type déni de service lorsqu'on modifie la valeur de cette directive. +
SSLRenegBufferSize 262144+
| Description: | N'autorise l'accès que lorsqu'une expression booléenne +complexe et arbitraire est vraie |
|---|---|
| Syntaxe: | SSLRequire expression |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_ssl |
SSLRequire est obsolète et doit en général être
+remplacée par l'expression Require. La syntaxe ap_expr de l'expression Require est
+une extension de la syntaxe de SSLRequire, avec les
+différences suivantes :
Avec SSLRequire, les opérateurs de comparaison
+<, <=, ... sont strictement équivalents
+aux opérateurs lt, le, ... , et fonctionnent
+selon une méthode qui compare tout d'abord la longueur des deux chaînes,
+puis l'ordre alphabétique. Les expressions ap_expr, quant à elles, possèdent deux jeux
+d'opérateurs de comparaison : les opérateurs <,
+<=, ... effectuent une comparaison alphabétique de
+chaînes, alors que les opérateurs -lt, -le,
+... effectuent une comparaison d'entiers. Ces derniers possèdent aussi
+des alias sans tiret initial : lt, le, ...
+
Cette directive permet de spécifier une condition générale d'accès +qui doit être entièrement satisfaite pour que l'accès soit autorisé. +C'est une directive très puissante, car la condition d'accès spécifiée +est une expression booléenne complexe et arbitraire contenant un nombre +quelconque de vérifications quant aux autorisations d'accès.
++L'expression doit respecter la syntaxe suivante (fournie ici +sous la forme d'une notation dans le style de la grammaire BNF) :
+
+expr ::= "true" | "false"
+ | "!" expr
+ | expr "&&" expr
+ | expr "||" expr
+ | "(" expr ")"
+ | comp
+
+comp ::= word "==" word | word "eq" word
+ | word "!=" word | word "ne" word
+ | word "<" word | word "lt" word
+ | word "<=" word | word "le" word
+ | word ">" word | word "gt" word
+ | word ">=" word | word "ge" word
+ | word "in" "{" wordlist "}"
+ | word "in" "PeerExtList(" word ")"
+ | word "=~" regex
+ | word "!~" regex
+
+wordlist ::= word
+ | wordlist "," word
+
+word ::= digit
+ | cstring
+ | variable
+ | function
+
+digit ::= [0-9]+
+cstring ::= "..."
+variable ::= "%{" varname "}"
+function ::= funcname "(" funcargs ")"
+
+Pour varname, toute variable décrite dans Variables d'environnement pourra être utilisée.
+Pour funcname, vous trouverez la liste des fonctions
+disponibles dans la documentation
+ap_expr.
expression est interprétée et traduite +sous une forme machine interne lors du chargement de la configuration, +puis évaluée lors du traitement de la requête. Dans le contexte des +fichiers .htaccess, expression est interprétée et exécutée +chaque fois que le fichier .htaccess intervient lors du traitement de la +requête.
+SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
+ and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
+ and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
+ and %{TIME_WDAY} -ge 1 and %{TIME_WDAY} -le 5 \
+ and %{TIME_HOUR} -ge 8 and %{TIME_HOUR} -le 20 ) \
+ or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
+La fonction PeerExtList(identifiant objet)
+recherche une instance d'extension de certificat X.509 identifiée par
+identifiant objet (OID) dans le certificat client. L'expression est
+évaluée à true si la partie gauche de la chaîne correspond exactement à
+la valeur d'une extension identifiée par cet OID (Si plusieurs
+extensions possèdent le même OID, l'une d'entre elles au moins doit
+correspondre).
+
SSLRequire "foobar" in PeerExtList("1.2.3.4.5.6")
+L'identifiant objet peut être spécifié soit comme un nom
+descriptif reconnu par la bibliothèque SSL, tel que
+"nsComment", soit comme un OID numérique tel que
+"1.2.3.4.5.6".
Les expressions contenant des types connus de la bibliothèque +SSL sont transformées en chaînes avant comparaison. Pour les extensions +contenant un type non connu de la bibliothèque SSL, mod_ssl va essayer +d'interpréter la valeur s'il s'agit d'un des types ASN.1 primaires UTF8String, +IA5String, VisibleString, ou BMPString. Si l'extension correspond à un +de ces types, la chaîne sera convertie en UTF-8 si nécessaire, puis +comparée avec la partie gauche de l'expression.
| Description: | Interdit l'accès lorsque la requête HTTP n'utilise pas +SSL |
|---|---|
| Syntaxe: | SSLRequireSSL |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive interdit l'accès si HTTP sur SSL (c'est à dire HTTPS) +n'est pas activé pour la connexion courante. Ceci est très pratique dans +un serveur virtuel où SSL est activé ou dans un répertoire pour se +protéger des erreurs de configuration qui pourraient donner accès à des +ressources protégées. Lorsque cette directive est présente, toutes les +requêtes qui n'utilisent pas SSL sont rejetées.
+SSLRequireSSL+
| Description: | Type du cache de session SSL global et +inter-processus |
|---|---|
| Syntaxe: | SSLSessionCache type |
| Défaut: | SSLSessionCache none |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de configurer le type de stockage du cache de +session SSL global et inter-processus. Ce cache est une fonctionnalité +optionnelle qui accélère le traitement parallèle des requêtes. Pour ce +qui est des requêtes vers un même processus du serveur (via HTTP +keep-alive), OpenSSL met en cache les informations de session SSL en +interne. Mais comme les clients modernes demandent des images en ligne +et d'autres données via des requêtes parallèles (un nombre de quatre +requêtes parallèles est courant), ces requêtes vont être servies par +plusieurs processus du serveur pré-déclenchés. Ici, un cache +inter-processus permet d'éviter des négociations de session +inutiles.
++Les quatre types de stockage suivants sont actuellement +supportés :
+none
+
+ Cette valeur désactive le cache de session global et + inter-processus, ce qui va ralentir le serveur de manière sensible + et peut poser problème avec certains navigateurs, en particulier si + les certificats clients sont activés. Cette configuration n'est pas + recommandée.
nonenotnull
+
+ Cette valeur désactive tout cache de session global et + inter-processus. Cependant, elle force OpenSSL à envoyer un + identifiant de session non nul afin de s'adapter aux clients bogués + qui en nécessitent un.
dbm:/chemin/vers/fichier-données
+
+ Cette valeur utilise un fichier de hashage DBM sur disque local
+ pour synchroniser les caches OpenSSL locaux en mémoire des processus
+ du serveur. Ce cache de session peut être sujet à des problèmes de
+ fiabilité sous forte charge. Pour l'utiliser, le module
+ mod_socache_dbm doit être chargé.
shmcb:/chemin/vers/fichier-données[(nombre)]
+
+ Cette valeur utilise un tampon cyclique à hautes performances
+ (d'une taille d'environ nombre octets) dans un segment de
+ mémoire partagée en RAM (établi via
+ /chemin/vers/fichier-données, pour synchroniser les
+ caches OpenSSL locaux en mémoire des processus du serveur. C'est le
+ type de cache de session recommandé. Pour l'utiliser, le module
+ mod_socache_shmcb doit être chargé.
dc:UNIX:/chemin/vers/socket
+
+ Cette valeur utilise les bibliothèques de mise en cache de
+ sessions distribuée sur distcache.
+ L'argument doit spécifier le serveur ou mandataire à utiliser en
+ utilisant la syntaxe d'adressage distcache ; par exemple,
+ UNIX:/chemin/vers/socket spécifie une socket de domaine
+ Unix (en général un mandataire de dc_client local) ;
+ IP:serveur.example.com:9001 spécifie une adresse IP.
+ Pour l'utiliser, le module mod_socache_dc doit être
+ chargé.
SSLSessionCache "dbm:/usr/local/apache/logs/ssl_gcache_data" +SSLSessionCache "shmcb:/usr/local/apache/logs/ssl_gcache_data(512000)"+
Le mutex ssl-cache permet de sérialiser l'accès au cache
+de session afin d'éviter toute corruption. Ce mutex peut être configuré
+via la directive Mutex.
| Description: | Nombre de secondes avant l'expiration d'une session SSL +dans le cache de sessions |
|---|---|
| Syntaxe: | SSLSessionCacheTimeout secondes |
| Défaut: | SSLSessionCacheTimeout 300 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | S'applique aussi à la reprise de session TLS (RFC 5077) à +partir de la version 2.4.10 du serveur HTTP Apache |
+Cette directive permet de définir la durée de vie en secondes des +informations stockées dans le cache de sessions SSL global et +inter-processus, dans le cache OpenSSL interne en mémoire et pour +les sessions réinitialisées par la reprise de session TLS (RFC 5077). elle peut +être définie à une valeur d'environ 15 à des fins de test, mais à une +valeur très supérieure comme 300 en production.
+SSLSessionCacheTimeout 600+
| Description: | Clé de chiffrement/déchiffrement permanente pour les +tickets de session TLS |
|---|---|
| Syntaxe: | SSLSessionTicketKeyFile chemin-fichier |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible depuis la version 2.4.0 du serveur HTTP +Apache, sous réserve que l'on utilise une version 0.9.8h ou supérieure +d'OpenSSL |
Cette directive permet de définir une clé secrète pour le chiffrement +et le déchiffrement des tickets de session TLS selon les préconisations +de la RFC 5077. Elle a +été conçue à l'origine pour les environnements de clusters où les +données des sessions TLS doivent être partagées entre plusieurs noeuds. +Pour les configurations ne comportant qu'une seule instance de httpd, il +est préférable d'utiliser les clés (aléatoires) générées par mod_ssl au +démarrage du serveur.
+Le fichier doit contenir 48 octets de données aléatoires créées de +préférence par une source à haute entropie. Sur un système de type UNIX, +il est possible de créer le fichier contenant la clé de la manière +suivante :
+ +
+dd if=/dev/random of=/chemin/vers/fichier.tkey bs=1 count=48
+
Ces clés doivent être renouvelées fréquemment, car il s'agit du seul +moyen d'invalider un ticket de session existant - OpenSSL ne permet pas +actuellement de spécifier une limite à la durée de +vie des tickets. Une nouvelle clé ne peut être utilisée qu'après avoir +redémarré le serveur. Tous les tickets de session existants deviennent +invalides après le redémarrage du serveur.
+ +Ce fichier contient des données sensibles et doit donc être protégé
+par des permissions similaires à celles du fichier spécifié par la
+directive SSLCertificateKeyFile.
| Description: | Active ou désactive les tickets de session TLS |
|---|---|
| Syntaxe: | SSLSessionTickets on|off |
| Défaut: | SSLSessionTickets on |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible à partir de la version 2.4.11 du serveur HTTP +Apache, sous réserve d'utiliser OpenSSL version 0.9.8f ou supérieure. + |
Cette directive permet d'activer ou de désactiver l'utilisation des +tickets de session TLS (RFC 5077).
+Les tickets de session TLS sont activés par défaut. Les utiliser sans +redémarrer le serveur selon une périodicité appropriée (par exemple +quotidiennement) compromet cependant le niveau de confidentialité.
+| Description: | Source d'aléa pour utilisateur SRP inconnu |
|---|---|
| Syntaxe: | SSLSRPUnknownUserSeed secret-string |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible depuis la version 2.4.4 du serveur HTTP +Apache, si la version 1.0.1 ou supérieure d'OpenSSL est utilisée. |
+Cette directive permet de définir la source d'aléa à utiliser +pour les utilisateurs SRP inconnus, ceci afin de combler les manques en +cas d'existence d'un tel utilisateur. Elle définit une chaîne secrète. Si +cette directive n'est pas définie, Apache renverra une alerte +UNKNOWN_PSK_IDENTITY aux clients qui fournissent un nom d'utilisateur +inconnu. +
+
+SSLSRPUnknownUserSeed "secret"
+
| Description: | Chemin du fichier de vérification SRP |
|---|---|
| Syntaxe: | SSLSRPVerifierFile file-path |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible depuis la version 2.4.4 du serveur HTTP +Apache, si la version 1.0.1 ou supérieure d'OpenSSL est utilisée. |
+Cette directive permet d'activer TLS-SRP et de définir le chemin du +fichier de vérification OpenSSL SRP (Mot de passe distant sécurisé) +contenant les noms d'utilisateurs TLS-SRP, les vérificateurs, les +"grains de sel" (salts), ainsi que les paramètres de groupe.
+
+SSLSRPVerifierFile "/path/to/file.srpv"
+
+Le fichier de vérification peut être créé via l'utilitaire en ligne de
+commande openssl :
+openssl srp -srpvfile passwd.srpv -userinfo "some info" -add username
+
La valeur affectée au paramètre optionnel -userinfo est
+enregistrée dans la variable d'environnement
+SSL_SRP_USERINFO.
| Description: | Configuration du cache pour l'agrafage OCSP |
|---|---|
| Syntaxe: | SSLStaplingCache type |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Si SSLUseStapling est à "on",
+cette directive permet de configurer le cache destiné à stocker les
+réponses OCSP incluses dans la négociation TLS. La configuration d'un
+cache est obligatoire pour pouvoir utiliser l'agrafage OCSP. A
+l'exception de none et nonenotnull, cette
+directive supporte les mêmes types de stockage que la directive
+SSLSessionCache.
| Description: | Durée de vie des réponses invalides dans le cache pour +agrafage OCSP |
|---|---|
| Syntaxe: | SSLStaplingErrorCacheTimeout secondes |
| Défaut: | SSLStaplingErrorCacheTimeout 600 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet de définir la durée de vie des réponses
+invalides dans le cache pour agrafage OCSP configuré via la
+directive SSLStaplingCache. Pour
+définir la durée de vie des réponses valides, voir la directive
+SSLStaplingStandardCacheTimeout.
| Description: | Génère une réponse "tryLater" pour les requêtes OCSP échouées |
|---|---|
| Syntaxe: | SSLStaplingFakeTryLater on|off |
| Défaut: | SSLStaplingFakeTryLater on |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Lorsque cette directive est activée, et si une requête vers un
+serveur OCSP à des fins d'inclusion dans une négociation TLS échoue,
+mod_ssl va générer une réponse "tryLater" pour le client (SSLStaplingReturnResponderErrors doit être
+activée).
| Description: | Remplace l'URI du serveur OCSP spécifié dans l'extension +AIA du certificat |
|---|---|
| Syntaxe: | SSLStaplingForceURL uri |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet de remplacer l'URI du serveur OCSP extraite de +l'extension authorityInfoAccess (AIA) du certificat. Elle peut s'avérer +utile lorsqu'on passe par un mandataire
+ +| Description: | Temps d'attente maximum pour les requêtes vers les serveurs +OCSP |
|---|---|
| Syntaxe: | SSLStaplingResponderTimeout secondes |
| Défaut: | SSLStaplingResponderTimeout 10 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet de définir le temps d'attente maximum lorsque
+mod_ssl envoie une requête vers un serveur OCSP afin d'obtenir une
+réponse destinée à être incluse dans les négociations TLS avec les
+clients (SSLUseStapling doit
+avoir été activée au préalable).
| Description: | Age maximum autorisé des réponses OCSP incluses dans la +négociation TLS |
|---|---|
| Syntaxe: | SSLStaplingResponseMaxAge secondes |
| Défaut: | SSLStaplingResponseMaxAge -1 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet de définir l'âge maximum autorisé
+("fraîcheur") des réponses OCSP incluses dans la négociation TLS
+(SSLUseStapling doit
+avoir été activée au préalable). La valeur par défaut (-1)
+ne définit aucun âge maximum, ce qui signifie que les réponses OCSP sont
+considérées comme valides à partir du moment où le contenu de leur champ
+nextUpdate se trouve dans le futur.
| Description: | Durée de vie maximale autorisée des réponses OCSP incluses dans la +négociation TLS |
|---|---|
| Syntaxe: | SSLStaplingResponseTimeSkew secondes |
| Défaut: | SSLStaplingResponseTimeSkew 300 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet de spécifier l'intervalle de temps maximum que
+mod_ssl va calculer en faisant la différence entre les contenus des
+champs nextUpdate et thisUpdate des réponses
+OCSP incluses dans la négociation TLS. Pour pouvoir utiliser cette
+directive, SSLUseStapling doit
+être à "on".
| Description: | Transmet au client les erreurs survenues lors des requêtes +OCSP |
|---|---|
| Syntaxe: | SSLStaplingReturnResponderErrors on|off |
| Défaut: | SSLStaplingReturnResponderErrors on |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Lorsque cette directive est activée, mod_ssl va transmettre au client les
+réponses concernant les requêtes OCSP
+échouées (comme les réponses avec un statut général autre que
+"successful", les réponses avec un statut de certificat autre que
+"good", les réponses arrivées à expiration, etc...).
+Lorsqu'elle est à off, seules les réponses avec un
+statut de certificat égal à "good" seront incluses dans la négociation
+TLS.
| Description: | Durée de vie des réponses OCSP dans le cache |
|---|---|
| Syntaxe: | SSLStaplingStandardCacheTimeout secondes |
| Défaut: | SSLStaplingStandardCacheTimeout 3600 |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet de définir la durée de vie des réponses OCSP
+dans le cache configuré via la directive SSLStaplingCache. Elle ne s'applique qu'aux
+réponse valides, alors que la directive SSLStaplingErrorCacheTimeout s'applique aux
+réponses invalides ou non disponibles.
+
| Description: | Contrôle de l'accès des clients non-SNI à un serveur virtuel à +base de nom. + |
|---|---|
| Syntaxe: | SSLStrictSNIVHostCheck on|off |
| Défaut: | SSLStrictSNIVHostCheck off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible depuis la version 2.2.12 d'Apache |
+Cette directive permet de contrôler l'accès des clients non-SNI à un serveur
+virtuel à base de nom. Si elle est définie à on dans le
+serveur virtuel à base de nom par défaut, les
+clients non-SNI ne seront autorisés à accéder à aucun serveur virtuel
+appartenant à cette combinaison IP/port. Par
+contre, si elle est définie à on dans un serveur virtuel
+quelconque, les clients non-SNI ne se verront interdire l'accès qu'à ce
+serveur.
+
+Cette option n'est disponible que si httpd a été compilé avec une +version d'OpenSSL supportant SNI. +
SSLStrictSNIVHostCheck on+
| Description: | Nom de la variable servant à déterminer le nom de +l'utilisateur |
|---|---|
| Syntaxe: | SSLUserName nom-var |
| Contexte: | configuration globale, répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette variable permet de définir le champ "user" de l'objet de la
+requête Apache. Ce champ est utilisé par des modules de plus bas niveau
+pour identifier l'utilisateur avec une chaîne de caractères. En
+particulier, l'utilisation de cette directive peut provoquer la
+définition de la variable d'environnement REMOTE_USER.
+La valeur de l'argument nom-var peut correspondre à toute variable d'environnement SSL.
Notez que cette directive est sans effet si l'option
+FakeBasicAuth est utilisée (voir SSLOptions).
SSLUserName SSL_CLIENT_S_DN_CN+
| Description: | Active l'ajout des réponses OCSP à la négociation TLS |
|---|---|
| Syntaxe: | SSLUseStapling on|off |
| Défaut: | SSLUseStapling off |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_ssl |
| Compatibilité: | Disponible si on utilise OpenSSL version 0.9.8h ou supérieure |
Cette directive permet d'activer l'"Agrafage OCSP" (OCSP stapling)
+selon la définition de l'extension TLS "Certificate Status Request"
+fournie dans la RFC 6066. Si elle est activée et si le client le
+demande, mod_ssl va inclure une réponse OCSP à propos de son propre
+certificat dans la négociation TLS. Pour pouvoir activer l'Agrafage
+OCSP, il est nécessaire de configurer un SSLStaplingCache.
L'agrafage OCSP dispense le client de requérir le serveur OCSP
+directement ; il faut cependant noter que selon les spécifications de la
+RFC 6066, la réponse CertificateStatus du serveur ne peut
+inclure une réponse OCSP que pour un seul certificat. Pour les
+certificats de serveur comportant des certificats de CA intermédiaires
+dans leur chaîne (c'est un cas typique de nos jours), l'implémentation
+actuelle de l'agrafage OCSP n'atteint que partiellement l'objectif d'
+"économie en questions/réponse et en ressources". Pour plus de détails,
+voir la RFC 6961 (TLS
+Multiple Certificate Status Extension).
+
Lorsque l'agrafage OCSP est activé, le mutex
+ssl-stapling contrôle l'accès au cache de l'agrafage OCSP
+afin de prévenir toute corruption, et le mutex
+sss-stapling-refresh contrôle le raffraîchissement des
+réponses OCSP. Ces mutex peuvent être configurés via la directive
+Mutex.
+
| Description: | Niveau de vérification du certificat client |
|---|---|
| Syntaxe: | SSLVerifyClient niveau |
| Défaut: | SSLVerifyClient none |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de définir le niveau de vérification du +certificat pour l'authentification du client. Notez que cette directive +peut être utilisée à la fois dans les contextes du serveur principal et +du répertoire. Dans le contexte du serveur principal, elle s'applique au +processus d'authentification du client utilisé au cours de la +négociation SSL standard lors de l'établissement d'une connexion. Dans +un contexte de répertoire, elle force une renégociation SSL avec le +niveau de vérification du client spécifié, après la lecture d'une +requête HTTP, mais avant l'envoi de la réponse HTTP.
++Les valeurs de niveau disponibles sont les suivantes :
+SSLVerifyClient require+
| Description: | Profondeur maximale des certificats de CA pour la +vérification des certificats clients |
|---|---|
| Syntaxe: | SSLVerifyDepth nombre |
| Défaut: | SSLVerifyDepth 1 |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | AuthConfig |
| Statut: | Extension |
| Module: | mod_ssl |
+Cette directive permet de spécifier la profondeur maximale à laquelle +mod_ssl va effectuer sa vérification avant de décider que le client ne +possède pas de certificat valide. Notez que cette directive peut être +utilisée à la fois dans les contextes du serveur principal et de +répertoire. Dans le contexte du serveur principal, elle s'applique au +processus d'authentification du client utilisé au cours de la +négociation SSL standard lors de l'établissement d'une connexion. Dans +un contexte de répertoire, elle force une renégociation SSL avec le +client selon la nouvelle profondeur spécifiée, après la lecture d'une +requête HTTP, mais avant l'envoi de la réponse HTTP.
+
+La profondeur correspond au nombre maximum de fournisseurs de
+certificats intermédiaires, c'est à dire le nombre maximum de
+certificats de CA que l'on est autorisé à suivre lors de la vérification
+du certificat du client. Une profondeur de 0 signifie que seuls les
+certificats clients auto-signés sont acceptés ; la profondeur par défaut
+de 1 signifie que le certificat client peut être soit auto-signé, soit
+signé par une CA connue directement du serveur (c'est à dire que le
+certificat de la CA doit être référencé par la directive SSLCACertificatePath), etc...
SSLVerifyDepth 10+
Serveur HTTP Apache Version 2.4
+| Description: | Fournit des informations sur les performances et l'activité +du serveur |
|---|---|
| Statut: | Base |
| Identificateur de Module: | status_module |
| Fichier Source: | mod_status.c |
Le module Status permet à un administrateur de déterminer le + niveau de performances de son serveur. Les statistiques instantanées + du serveur sont présentées dans une page HTML sous une forme + aisément lisible. Si nécessaire, cette page peut être configurée + pour être automatiquement actualisée (sous réserve de + compatibilité du navigateur). Une autre page fournit l'état + instantané du serveur sous la forme d'une simple liste lisible par + une machine.
+ +Les détails fournis sont :
+ +Les lignes se terminant par "(*)" ne sont disponibles que si la
+ directive ExtendedStatus
+ est définie à On. Depuis la version
+ 2.3.6, le chargement de mod_status définit automatiquement
+ ExtendedStatus à On.
Activation du rapport d'état Actualisation automatique Fichier d'état lisible par une machine Utilisation de server-status pour la recherche de défauts de
+ fonctionnementCe module ne fournit aucune directive.
+Pour n'activer les rapports d'état que pour les navigateurs
+ appartenent au domaine example.com, ajoutez ces lignes à votre
+ fichier de configuration httpd.conf :
<Location "/etat-serveur"> + SetHandler server-status + Require host example.com +</Location>+ + +
Il est alors possible d'obtenir les statistiques du serveur en
+ utilisant un navigateur web et en accédant à la page
+ http://votre.serveur/etat-serveur.
Vous pouvez faire en sorte que cette page d'état s'actualise
+ elle-même automatiquement si votre navigateur supporte "refresh".
+ Pour ce faire, accédez à la page
+ http://votre.serveur/etat-serveur?refresh=N, pour que
+ cette dernière soit actualisée toutes les N secondes.
La page http://votre.serveur/etat-serveur?auto
+ permet d'obtenir une version du fichier d'état lisible par une
+ machine. Ceci s'avère intéressant dans le cadre d'une exécution
+ automatique : voir le programme en Perl
+ log_server_status situé dans le répertoire
+ /support de votre distribution du serveur HTTP Apache.
mod_status a été
+ chargé dans le serveur, son gestionnaire sera disponible dans
+ tous les fichiers de configuration, y compris les
+ fichiers de configuration de niveau répertoire (par
+ exemple .htaccess), ce qui peut avoir des
+ répercutions quant à la sécurité de votre site.
+ La page server-status peut servir de point de départ
+ à la recherche de défauts de fonctionnement lorsque votre serveur
+ mobilise toutes les ressources disponibles (CPU ou mémoire), pour
+ identifier quels clients ou requêtes sont la cause du problème.
Tout d'abord, assurez-vous que la directive ExtendedStatus est bien définie à on, de
+ façon à ce que vous puissiez avoir accès à toutes les informations à
+ propos de la requête et du client pour chaque processus enfant ou
+ thread.
Consultez ensuite la liste des processus en cours (à l'aide de
+ top, ou d'un utilitaire de listage des processus
+ similaire), afin d'identifier les processus coupables. Triez
+ l'affichage de top par utilisation CPU ou mémoire, en
+ fonction du problème rencontré.
Rechargez la page server-status et recherchez
+ les identifiants des processus trouvés précédemment ; vous pourrez
+ alors déterminer quelle requête est traitée par ces processus, pour
+ quel client. Les requêtes peuvent apparaître de manière fugitive, et
+ il se peut que vous deviez effectuer plusieurs essais avant de
+ parvenir à les prendre en flagrant délit, pour ainsi dire.
Cette procédure devrait vous permettre de cerner quel + client, ou type de requête, sont à l'origine de vos problèmes de + charge. Il est probable que vous identifiiez une application web au + comportement anormal, ou un client en train d'attaquer votre site.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Effectue des opérations de recherche/remplacement sur les +corps de réponses |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | substitute_module |
| Fichier Source: | mod_substitute.c |
| Compatibilité: | Disponible depuis la version 2.2.7 +du serveur HTTP Apache |
mod_substitute fournit un mécanisme permettant
+ d'effectuer des substitutions de chaînes fixes ou d'expressions
+ rationnelles sur les corps de réponses.
| Description: | Modèle de substition dans le contenu de la +réponse |
|---|---|
| Syntaxe: | Substitute s/modèle/substitution/[infq] |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_substitute |
La directive Substitute permet de
+ spécifier un modèle de recherche/remplacement à appliquer au corps
+ de la réponse.
La signification du modèle peut être modifiée via toute + combinaison de ces drapeaux :
+ +inn force le traitement du
+ modèle en tant que chaîne fixe.ff, mod_substitute met à plat le
+ résultat d'une substitution (les conteneurs ou buckets ne sont
+ pas dissociés), ce qui permet à d'éventuelles substitutions
+ ultérieures de s'effectuer sur cette dernière. C'est le
+ comportement par défaut.qq, mod_substitute dissocie les
+ conteneurs (ou buckets) après chaque substitution. Ceci peut
+ améliorer la rapidité de la réponse et diminuer la quantité de
+ mémoire utilisée, mais ne doit être utilisé que s'il n'existe
+ aucune possibilité pour que le résultat d'une substitution ne
+ corresponde au modèle ou à l'expression rationnelle d'une
+ substitution ultérieure.substitution peut contenir du texte et des références arrières + d'expressions rationnelles.
+ +<Location "/> + AddOutputFilterByType SUBSTITUTE text/html + Substitute "s/foo/bar/ni" +</Location>+
Le caractère utilisé pour séparer (ou "délimiter") les différentes partie + de la valeur de substitution est référencé sous le nom de "délimiteur", et + il s'agit le plus souvent d'un "slash".
+ +Si le modèle ou la chaîne de substitution contient un caractère + slash '/', il est possible d'utiliser un autre délimiteur afin de rendre la + directive plus lisible :
+ +<Location "/"> + AddOutputFilterByType SUBSTITUTE text/html + Substitute "s|<BR */?>|<br />|i" +</Location>+
Lorsqu'on utilise des expressions rationnelles, on peut insérer + des références arrières dans les opérations de comparaison et de + substitution, comme illustré dans l'exemple suivant :
+<Location "/"> + AddOutputFilterByType SUBSTITUTE text/html + # "foo=k,bar=k" -> "foo/bar=k" + Substitute "s|foo=(\w+),bar=\1|foo/bar=$1|" +</Location>+
Un scénario courant d'utilisation de mod_substitute
+ est la situation où un serveur frontal mandate des requêtes pour un
+ serveur d'arrière-plan qui renvoie des documents HTML contenant des
+ URLs intégrées codées en dur qui font référence à ce serveur
+ d'arrière-plan. Ces URLs ne fonctionnent pas pour l'utilisateur
+ final car le serveur d'arrière-plan est hors d'atteinte.
On peut, dans ce cas, utiliser mod_substitute pour
+ réécrire ces URLs afin qu'elles soit utilisables dans la partie
+ située derrière le mandataire :
ProxyPass "/blog/" "http://internal.blog.example.com/" +ProxyPassReverse "/blog/" "http://internal.blog.example.com/" + +Substitute "s|http://internal.blog.example.com/|http://www.example.com/blog/|i"+
La directive ProxyPassReverse modifie tout en-tête
+ Location (redirection) envoyé par le serveur
+ d'arrière-plan et, dans cet exemple, la directive
+ Substitute se charge à son tour de la modification de
+ la réponse HTML.
| Description: | Modifie l'ordre de fusion des modèles hérités |
|---|---|
| Syntaxe: | SubstituteInheritBefore on|off |
| Défaut: | SubstituteInheritBefore on |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_substitute |
| Compatibilité: | Disponible à partir de la version 2.4.17 du serveur HTTP +Apache |
Cette directive permet de définir si l'on applique les modèles
+Substitute hérités en premier
+(valeur on), ou après ceux du
+contexte courant (valeur off). La valeur de la directive
+SubstituteInheritBefore est
+elle-même héritée, et les contextes qui en héritent (ceux qui ne
+définissent pas explicitement leur propre directive
+SubstituteInheritBefore) appliqueront donc
+l'ordre de fusion défini le plus proche.
| Description: | Définit la longueur de ligne maximale |
|---|---|
| Syntaxe: | SubstituteMaxLineLength octets(b|B|k|K|m|M|g|G) |
| Défaut: | SubstituteMaxLineLength 1m |
| Contexte: | répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_substitute |
| Compatibilité: | Disponible à partir de la version 2.4.11 du serveur HTTP +Apache |
La taille de la ligne traitée par mod_substitute
+ est limitée afin de restreindre l'utilisation des ressources
+ mémoire. La directive SubstituteMaxLineLength
+ permet de définir cette limite. La valeur de la limite peut être
+ spécifiée sous la forme d'un nombre d'octets, et peut être suffixée
+ par une des lettres b, B, k,
+ K, m, M, g ou
+ G pour fournir une valeur respectivement en octets,
+ kiloOctets, mégaOctets ou gigaOctets.
<Location "/"> + AddOutputFilterByType SUBSTITUTE text/html + SubstituteMaxLineLength 10m + Substitute "s/foo/bar/ni" +</Location>+
Serveur HTTP Apache Version 2.4
+| Description: | Permet l'exécution des scripts CGI sous l'utilisateur et +le groupe spécifiés |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | suexec_module |
| Fichier Source: | mod_suexec.c |
Ce module, en combinaison avec son programme support
+ suexec, permet l'exécution des scripts CGI sous
+ l'utilisateur et le groupe spécifiés.
| Description: | L'utilisateur et le groupe sous lesquels les programmes CGI +doivent s'exécuter |
|---|---|
| Syntaxe: | SuexecUserGroup Utilisateur Groupe |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_suexec |
La directive SuexecUserGroup permet de
+ spécifier l'utilisateur et le groupe sous lesquels les programmes
+ CGI doivent s'exécuter. Les requêtes non CGI seront toujours
+ traitées avec l'utilisateur spécifié par la directive User.
SuexecUserGroup nobody nogroup+
Le démarrage échouera si cette + directive est spécifiée et si la fonctionnalité suEXEC est + désactivée.
+ + +SuexecServeur HTTP Apache Version 2.4
+| Description: | Fournit une variable d'environnement contenant un +identifiant unique pour chaque requête |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | unique_id_module |
| Fichier Source: | mod_unique_id.c |
Ce module fournit un identifiant dont l'unicité est garantie
+ parmi "toutes" les requêtes sous des conditions très précises.
+ L'identifiant unique le sera aussi parmi plusieurs machines
+ appartenant à un cluster correctement configuré. L'identifiant est
+ affecté à la variable d'environnement UNIQUE_ID pour
+ chaque requête. Les identifiants uniques sont utiles pour diverses
+ raisons dont la nature se situe au delà de la portée de ce
+ document.
ThéorieCe module ne fournit aucune directive.
+Tout d'abord un bref rappel de la manière dont le serveur Apache + fonctionne sous Unix (cette fonctionnalité n'étant actuellement pas + supportée sous Windows NT). Sous Unix, Apache crée plusieurs + processus enfants, ces derniers traitant les requêtes une par une. + Chaque processus enfant peut traiter plusieurs requêtes pendant sa + durée de vie. Dans le cadre de cette discussion, nous supposerons + que les différents processus enfants ne s'échangent pas de données + entre eux. Nous nous référerons aux processus enfants sous le nom de + processus httpd.
+ +Votre site web est réparti entre une ou plusieurs machines dont + vous êtes l'administrateur, et que nous nommerons cluster de + serveurs. Chaque serveur peut exécuter plusieurs instances d'Apache. + L'ensemble de ces dernières sera considéré comme "l'Univers", et + sous certaines hypothèses, nous montrerons qu'il est possible dans + cet univers, de générer des identifiants uniques pour chaque + requête, sans pour autant nécessiter une communication importante + entre les différents serveurs du cluster.
+ +Les machines de votre cluster doivent satisfaire ces conditions + (même si le cluster ne comporte qu'une machine, vous devez + synchroniser son horloge avec NTP) :
+ +Au vu des caractéristiques actuelles du système d'exploitation, + nous supposerons que les pids (identifiants processus) sont codés + sur 32 bits. Si le système d'exploitation utilise plus de 32 bits + pour un pid, la correction est triviale mais doit être effectuée + dans le code.
+ +Ces hypothèses posées, à un instant donné, nous pouvons + distinguer tout processus httpd sur toute machine du cluster de tous + les autres processus httpd. Pour ce faire, il suffit d'utiliser + l'adresse IP de la machine et le pid du processus httpd. Un + processus httpd peut traiter plusieurs requêtes simultanément si + vous utilisez un module MPM multi-threadé. Pour identifier les + threads, Apache httpd utilise en interne un index de threads. Ainsi, + afin de générer des identifiants uniques pour chaque requête, il + suffit d'effectuer une distinction en fonction du temps.
+ +Pour déterminer le temps, nous utiliserons un repère de temps + Unix (les secondes écoulées depuis le 1er janvier 1970 UTC), et un + compteur 16 bits. La précision du repère de temps n'étant que d'une + seconde, le compteur va représenter 65536 valeurs par seconde. Le + quadruplet (adresse IP, pid, repère de temps, compteur) est + en mesure de distinguer 65536 requêtes par seconde par processus + httpd. Il peut cependant arriver que le même pid soit réutilisé au + cours du temps, et le compteur est là pour pallier cet + inconvénient.
+ +Lorsqu'un processus enfant httpd est créé, le compteur est + initialisé avec (nombre de microsecondes actuel divisé par 10) + modulo 65536 (cette formule a été choisie pour éliminer certains + problème de variance avec les bits de poids faibles du compteur de + microsecondes sur certains systèmes). Lorsqu'un identifiant unique + est généré, le repère de temps utilisé est le moment où la requête + arrive sur le serveur web. Le compteur est incrémenté à chaque + création d'identifiant (et peut repasser à 0 lorsqu'il a atteint sa + valeur maximale).
+ +Le noyau génère un pid pour chaque processus lors de sa création, + et le compteur de pid est réinitialisé à une certaine valeur + lorsqu'il a atteint sa valeur maximale (les pid sont codés sur 16 + bits sous de nombreux Unixes, mais les systèmes les plus récents les + ont étendus à 32 bits). La même valeur de pid pourra donc être + réutilisée au cours du temps. Cependant, tant qu'elle n'est pas + réutilisée dans la même seconde, elle ne remet pas en cause + l'unicité de notre quadruplet. Nous supposerons donc que le système + ne créera pas plus de 65536 processus en une seconde (ce nombre peut + être de 32768 sous certains Unixes, mais même dans ce cas, on est en + général loin de cette situation).
+ +Il est possible que le temps se répète pour une raison + quelconque. + Supposons par exemple que l'horloge système soit retardée et repasse + par un temps passé (ou bien, comme elle avançait, elle a été remise + à l'heure, et elle repasse par un temps futur). Dans ce cas, il peut + être facilement démontré que le couple pid/repère de temps peut être + réutilisé. Le choix de la formule d'initialisation du compteur a + été effectué dans l'intention de pallier ce problème. Notez qu'un + nombre vraiment aléatoire serait souhaitable pour initialiser le + compteur, mais il n'existe pas de tel nombre directement lisible sur + la plupart des systèmes (c'est à dire que vous ne pouvez pas + utiliser rand() car vous devez déclencher le générateur avec une + valeur unique, et vous ne pouvez pas utiliser le temps à cet effet + car celui-ci , au moins à la seconde près, s'est répété). Il ne + s'agit donc pas d'une défense parfaite.
+ +Même si elle n'est pas parfaite, quel est le degré d'efficacité + de cette défense ? Supposons + qu'une de vos machines serve au plus 500 requêtes par seconde (ce + qui constitue une limite supérieure très raisonnable au moment où ce + document est écrit, car les systèmes ne se contentent en général pas + de débiter des fichiers statiques). Pour y parvenir, un certain nombre + de processus enfants sera nécessaire, qui dépendra du nombre de + clients simultanés présents. Mais soyons pessimiste et supposons + qu'un seul processus enfant soit capable de servir 500 requêtes par + secondes. + Il existe 1000 valeurs de démarrage possibles du compteur pour + lesquelles deux séquences de 500 requêtes puissent se recouvrir. Il + y a donc 1,5% de chance que le processus enfant répète une valeur de + compteur si le temps se répète (avec une résolution d'une seconde), + et l'unicité sera alors remise en cause. C'est cependant un exemple + très pessimiste, et avec les valeurs du monde réel, il y a bien + moins de chances que cela ne se produise. Si vous estimez que ceci a + tout de même quelque chances de se produire sur votre système, vous + pouvez migrer vers un compteur à 32 bits (en modifiant le code).
+ +On pourrait supposer que ceci a plus de chance de se produire + lors du passage à l'heure d'hiver où l'horloge est "retardée". Cela + ne constitue cependant pas un problème car les temps pris en compte + ici sont des temps UTC, qui vont "toujours" de l'avant. Notez que + les Unixes à base de processeur x86 peuvent nécessiter une + configuration particulière pour que ceci soit vrai -- il doivent + être configurés pour assumer que l'horloge système est en UTC et + compenser de manière appropriée. Mais même dans ce cas, si vous + utilisez NTP, votre temps UTC sera correct peu après le + redémarrage.
+ + +La variable d'environnement UNIQUE_ID est construite
+ par codage du quadruplet de 144 bits (adresse IP sur 32 bits, pid
+ sur 32 bits, repère de temps sur 32 bits, compteur 16 bits et index
+ de threads sur 32 bits) en
+ utilisant l'alphabet [A-Za-z0-9@-] d'une manière
+ similaire à celle du codage MIME base64, et sa valeur se présente
+ sous la forme d'une chaîne de 24 caractères. L'alphabet MIME base64
+ est en fait [A-Za-z0-9+/] ; cependant, les caractères
+ + et / nécessitent un codage particulier
+ dans les URLs, ce qui rend leur utilisation peu commode. Toutes les
+ valeurs sont codées dans l'ordre des octets d'une adresse réseau de
+ façon à ce
+ que le codage soit comparable entre des architectures où l'ordre des
+ octets est différent. L'ordre réel de codage est : repère de temps,
+ adresse IP, pid, compteur. Cet ordre de codage possède un but
+ précis, mais il faut souligner que les applications n'ont aucun
+ intérêt à entrer dans les détails de ce codage. Les applications
+ doivent se contenter de traiter la variable UNIQUE_ID
+ comme un symbole opaque, qui peut être comparé avec d'autres
+ UNIQUE_IDs en ne testant que leur égalité.
L'ordre a été choisi de façon à ce qu'il soit possible de
+ modifier le codage dans le futur sans avoir à se préoccuper de
+ conflits éventuels avec une base de données de
+ UNIQUE_IDs existante. Les nouveaux codages doivent
+ conserver le repère de temps comme premier élément, et pour le
+ reste, utiliser les même alphabet et longueur en bits. Comme les
+ repères de temps constituent essentiellement un séquence croissante,
+ il suffit que toutes les machines du cluster arrêtent de traiter
+ toute requête dans la même seconde repère, et n'utilisent
+ alors plus l'ancien format de codage. Ensuite, elles peuvent
+ reprendre le traitement des requêtes en utilisant les nouveaux
+ codages.
Nous pensons que ceci apporte une solution relativement portable + au problème. Les + identifiants générés possèdent une durée de vie pratiquement infinie + car les identifiants futurs pourront être allongés selon les + besoins. Pratiquement aucune communication n'est requise entre les + machines du cluster (seule la synchronisation NTP est requise, ce + qui représente une charge très faible), et aucune communication + entre les processus httpd n'est nécessaire (la communication est + implicite et incluse dans le pid assigné par le noyau). Dans des + situations très spécifiques, l'identifiant peut être raccourci, mais + dans ce cas, d'avantage d'informations doivent être admises (par + exemple, les 32 bits de l'adresse IP sont excessifs pour la plupart + des sites, mais il n'existe pas de valeur de remplacement portable + plus courte).
+Serveur HTTP Apache Version 2.4
+| Description: | Sécurité de base (nécessaire) pour les plates-formes de la +famille Unix. |
|---|---|
| Statut: | Base |
| Identificateur de Module: | unixd_module |
| Fichier Source: | mod_unixd.c |
| Description: | Répertoire dans lequel Apache doit se positionner au +démarrage après avoir effectué un chroot(8). |
|---|---|
| Syntaxe: | ChrootDir chemin-répertoire |
| Défaut: | Non défini |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_unixd |
| Compatibilité: | Disponible depuis la version 2.2.10 d'Apache |
Cette directive fait en sorte que le serveur effectue un + chroot(8) vers le répertoire spécifié après le démarrage, + mais avant d'accepter les requêtes en provenance du réseau.
+Notez que l'exécution du serveur dans un environnement chroot + n'est pas simple et nécessite une configuration particulière, en + particulier si vous utilisez des scripts CGI ou PHP. Il est + conseillé de se familiariser avec l'opération chroot avant d'essayer + d'utiliser cette fonctionnalité.
+ +| Description: | Groupe sous lequel le serveur va traiter les +requêtes |
|---|---|
| Syntaxe: | Group groupe unix |
| Défaut: | Group #-1 |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_unixd |
La directive Group permet de définir le
+ groupe sous lequel le serveur va traiter les requêtes. Pour
+ utiliser cette directive, le serveur doit avoir été démarré par
+ root. Si vous démarrez le serveur en tant
+ qu'utilisateur non root, celui-ci ne pourra pas adopter le groupe
+ spécifié comme groupe d'exécution, et continuera à s'exécuter sous
+ le groupe de l'utilisateur qui l'aura lancé. groupe unix
+ peut se présenter sous la forme :
# suivi d'un numéro de groupe.Group www-group+
Il est conseillé de créer un groupe dédié à l'exécution du
+ serveur. Certains administrateurs utilisent l'utilisateur
+ nobody, mais ce n'est pas toujours souhaitable ou même
+ possible.
Ne définissez pas la directive Group (ou
+ User) à
+ root à moins de savoir exactement ce que vous faites
+ ainsi que les dangers encourus.
| Description: | Active ou désactive la fonctionnalité suEXEC |
|---|---|
| Syntaxe: | Suexec On|Off |
| Défaut: | On si le binaire suexec existe avec les mode et propriétaire
+appropriés, Off dans le cas contraire |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_unixd |
Lorsque cette directive est définie à On, le démarrage échouera si + le binaire suexec n'existe pas, ou possède un propriétaire ou mode + fichier invalide.
+Lorsque cette directive est définie à Off, suEXEC sera désactivé, + même si le binaire suexec existe et possède un propriétaire et mode + fichier valides.
+ +| Description: | L'utilisateur sous lequel le serveur va traiter les +requêtes |
|---|---|
| Syntaxe: | User utilisateur unix |
| Défaut: | User #-1 |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_unixd |
La directive User permet de définir
+ l'utilisateur sous lequel le serveur va traiter les requêtes. Pour
+ utiliser cette directive, le serveur doit avoir été démarré
+ par root. Si vous démarrez le serveur en tant
+ qu'utilisateur non root, celui-ci ne pourra pas adopter
+ l'utilisateur avec privilèges restreints comme utilisateur
+ d'exécution, et continuera à s'exécuter sous
+ l'utilisateur qui l'aura lancé. Si vous démarrez le serveur en tant
+ que root, il est normal que le processus parent
+ continue à s'exécuter sous root. utilisateur unix peut se
+ présenter sous la forme :
L'utilisateur ne doit pas posséder de privilèges qui lui
+ permettraient d'accéder à des fichiers non destinés au
+ monde extérieur, et parallèlement, l'utilisateur ne doit pas
+ exécuter de code dont l'usage soit destiné à un usage autre que les
+ requêtes HTTP. Il est conseillé de créer un utilisateur et un groupe
+ dédiés à l'exécution du serveur. Certains administrateurs utilisent
+ l'utilisateur nobody, mais ce n'est pas toujours
+ souhaitable, car l'utilisateur nobody peut avoir
+ diverses utilisations dans le système.
Ne définissez pas la directive Group (ou
+ User) à
+ root à moins de savoir exactement ce que vous faites
+ ainsi que les dangers encourus.
Serveur HTTP Apache Version 2.4
+| Description: | Répertoires propres à un utilisateur |
|---|---|
| Statut: | Base |
| Identificateur de Module: | userdir_module |
| Fichier Source: | mod_userdir.c |
Ce module permet l'accès aux répertoires propres à un utilisateur en
+utilisant la syntaxe http://example.com/~utilisateur/.
| Description: | Chemin des répertoires propres à un +utilisateur |
|---|---|
| Syntaxe: | UserDir nom-répertoire [nom-répertoire] ...
+ |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Base |
| Module: | mod_userdir |
La directive UserDir permet de définir le
+ répertoire réel du répertoire home d'un utilisateur à utiliser à la
+ réception d'une requête pour un document de cet utilisateur.
+ nom-répertoire peut se présenter sous la forme suivante
+ :
disabled. Toutes les
+ traductions nom d'utilisateur vers répertoire sont alors
+ désactivées, à l'exception de celles comportant le mot-clé
+ enabled (voir ci-dessous).disabled suivi d'une liste de noms
+ d'utilisateurs séparés par des espaces. Les noms d'utilisateurs
+ apparaissant dans une telle liste ne feront jamais
+ l'objet d'une traduction vers un répertoire, même dans le cas où
+ ils apparaîtront dans une clause enabled.enabled suivi d'une liste de noms
+ d'utilisateurs séparés par des espaces. Les noms d'utilisateurs
+ apparaissant dans une telle liste seront traduits en répertoires
+ même dans le cas où une clause disable globale est active, mais
+ pas s'ils apparaissent aussi dans une clause
+ disabled.Si aucun mot-clé enabled ou disabled
+ n'apparait dans la directive Userdir, l'argument est
+ traité en tant que modèle de fichier, et utilisé pour traduire le
+ nom d'utilisateur en une spécification de répertoire. Une requête
+ pour http://www.example.com/~bob/un/deux.html sera
+ traduite en :
| Directive Userdir utilisée | +Chemin traduit |
|---|---|
| UserDir public_html | +~bob/public_html/un/deux.html |
| UserDir /usr/web | +/usr/web/bob/un/deux.html |
| UserDir /home/*/www | +/home/bob/www/un/deux.html |
Les directives suivantes vont envoyer des redirections au client + :
+ +| Directive Userdir utilisée | +Chemin traduit |
|---|---|
| UserDir http://www.example.com/utilisateurs | +http://www.example.com/utilisateurs/bob/un/deux.html |
| UserDir http://www.example.com/*/usr | +http://www.example.com/bob/usr/un/deux.html |
| UserDir http://www.example.com/~*/ | +http://www.example.com/~bob/un/deux.html |
"UserDir ./" ferait correspondre
+ "/~root" à "/" - ce qui n'est
+ probablement pas souhaité. Il est fortement recommandé d'inclure
+ une déclaration "UserDir disabled root" dans votre
+ configuration. Voir aussi la directive Directory et la page Conseils en matière de
+ sécurité pour plus d'informations.
+ Exemples supplémentaires :
+ +Pour permettre à quelques utilisateurs et seulement à ceux-ci de
+ posséder des répertoires UserDir, utilisez la
+ configuration suivante :
UserDir disabled +UserDir enabled user1 user2 user3+ + +
Pour permettre à la plupart des utilisateurs de posséder des
+ répertoires UserDir, mais l'interdire à quelques uns,
+ utilisez la configuration suivante :
UserDir disabled utilisateur4 utilisateur5 utilisateur6+ + +
Il est aussi possible de spécifier des répertoires utilisateurs + alternatifs. Si vous utilisez une commande comme :
+ +UserDir "public_html" "/usr/web" "http://www.example.com/"+ + +
Avec une requête pour
+ http://www.example.com/~bob/un/deux.html, le serveur
+ tentera tout d'abord de trouver la page à
+ ~bob/public_html/un/deux.html, puis à
+ /usr/web/bob/un/deux.html, et enfin il enverra une
+ redirection vers
+ http://www.example.com/bob/un/deux.html.
Si vous spécifiez une redirection, elle doit être la dernière + alternative de la liste. Apache httpd ne pouvant pas déterminer si la + redirection a réussi, si cette dernière ne se trouve pas en fin de + liste, c'est cette alternative qui sera toujours utilisée.
+ +La substitution de répertoire utilisateur n'est pas activée par
+ défaut depuis la version 2.1.4. Dans les versions précédentes,
+ UserDir public_html était sous-entendu si aucune
+ directive UserDir
+ n'était présente.
Lorsqu'on passe du contexte global au contexte de serveur + virtuel, les listes d'utilisateurs spécifiques activés ou désactivés + sont remplacées par les listes du contexte, et non fusionnées.
Serveur HTTP Apache Version 2.4
+| Description: | +Journalisation Clickstream des liens parcourus par un +utilisateur sur un site + |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | usertrack_module |
| Fichier Source: | mod_usertrack.c |
Ce module permet de suivre le parcours d'un utilisateur à travers + votre site web en faisant appel aux cookies de navigateur.
+ Journalisation CookieDomain CookieExpires CookieName CookieStyle CookieTrackingmod_usertrack définit un cookie qui peut être
+ journalisé via les formats configurables du module
+ mod_log_config :
LogFormat "%{Apache}n %r %t" usertrack
+CustomLog "logs/clickstream.log" usertrack
+
+
+
+| Description: | Le domaine auquel le cookie traceur +s'applique |
|---|---|
| Syntaxe: | CookieDomain domaine |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_usertrack |
Cette directive permet de définir le domaine auquel le cookie + traceur s'applique. Si elle n'est pas présente, aucun domaine n'est + inclus dans le champ d'en-tête cookie.
+ +La chaîne dommaine doit commencer par un point,
+ et doit comporter au moins un point entouré
+ d'autres caractères. Par exemple, .example.com est
+ une chaîne valide, mais www.example.com et
+ .com ne le sont pas.
.co.uk, bien qu'un tel domaine remplisse les
+ conditions de validité décrites ci-dessus..com, et autoriser de tels cookies peut constituer un
+ risque en matière de sécurité. Ainsi, si vous vous situez sous un
+ domaine racine de deux niveaux, vous devez encore utiliser votre
+ domaine véritable, comme vous le feriez avec tout autre domaine
+ racine (par exemple .example.co.uk).
+ CookieDomain .example.com+ + +
| Description: | Durée avant expiration du cookie traceur |
|---|---|
| Syntaxe: | CookieExpires durée |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_usertrack |
Lorsqu'elle est utilisée, cette directive définit une durée avant + l'expiration du cookie généré par le module usertrack. La + durée peut être spécifiée sous la forme d'un nombre de + secondes, ou sous une forme du + style "2 weeks 3 days 7 hours". les termes valides sont : years, + months, weeks, days, hours, minutes et seconds. Si la durée est + spécifiée dans un format autre qu'un nombre de secondes, elle doit + être entourée de guillemets.
+ +Si cette directive est absente, la durée de vie des cookies est + limitée à la session actuelle du navigateur.
+ +CookieExpires "3 weeks"+ + +
| Description: | Nom du cookie traceur |
|---|---|
| Syntaxe: | CookieName symbole |
| Défaut: | CookieName Apache |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_usertrack |
Cette directive vous permet de modifier le nom du cookie que ce
+ module utilise pour sa journalisation. Le nom par défaut du cookie
+ est "Apache".
Vous devez spécifier un nom de cookie valide ; les résultats sont + imprévisibles si vous utilisez un nom contenant des caractères + inhabituels. Les caractères valides font partie des intervales A-Z, + a-z, 0-9, "_", et "-".
+ +CookieName clicktrack+ + +
| Description: | Format du champ d'en-tête cookie |
|---|---|
| Syntaxe: | CookieStyle
+ Netscape|Cookie|Cookie2|RFC2109|RFC2965 |
| Défaut: | CookieStyle Netscape |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_usertrack |
Cette directive permet de contrôler le format du champ d'en-tête + cookie. Les trois formats autorisés sont :
+ +Tous les clients ne supportent pas l'ensemble de ces formats,
+ mais il est conseillé d'utiliser le plus récent qui sera en général
+ supporté par le navigateur utilisé par vos utilisateurs. A l'heure où ce
+ document est écrit, la plupart des navigateurs supportent ces trois
+ formats, Cookie2 étant le format recommandé.
CookieStyle Cookie2+ + +
| Description: | Active le cookie traceur |
|---|---|
| Syntaxe: | CookieTracking on|off |
| Défaut: | CookieTracking off |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | FileInfo |
| Statut: | Extension |
| Module: | mod_usertrack |
Lorsque le module mod_usertrack est chargé, et
+ si CookieTracking on est définie, Apache enverra un
+ cookie traceur pour toute nouvelle requête. Cette directive peut
+ être utilisée pour activer ou désactiver ce comportement pour un
+ serveur virtuel ou un répertoire. Par défaut, l'activation de
+ mod_usertrack ne suffit pas pour
+ activer les cookies.
CookieTracking on+ + + +
Serveur HTTP Apache Version 2.4
+| Description: | Configuration dépendant de la version |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | version_module |
| Fichier Source: | mod_version.c |
Ce module a été conçu pour être utilisé dans les suites de tests
+ et les grands réseaux qui doivent prendre en compte différentes
+ versions de httpd et différentes configurations. Il fournit un
+ nouveau conteneur -- <IfVersion>, qui apporte une grande
+ souplesse dans la vérification de version en permettant une
+ comparaison numérique et l'utilisation d'expressions
+ rationnelles.
<IfVersion 2.4.2> + # la version actuelle de httpd est exactement 2.4.2 +</IfVersion> + +<IfVersion >= 2.5> + # utilise vraiment les nouvelles fonctionnalités :-) +</IfVersion>+
Voir ci-dessous pour d'autres exemples.
+| Description: | Contient des portions de configuration dépendantes de la +version |
|---|---|
| Syntaxe: | <IfVersion [[!]opérateur] version> ...
+</IfVersion> |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_version |
La section <IfVersion>
+ rassemble des directives de configuration qui ne sont exécutées que
+ si la version de httpd satisfait aux critères spécifiés. Pour une
+ comparaison normale (numérique), l'argument version doit
+ être spécifié sous le format
+ majeur[.mineur[.patch]],
+ comme par exemple 2.1.0 ou 2.2.
+ mineur et patch sont optionnels. Si ces
+ numéros sont absents, il se voient affectée implicitement la valeur
+ 0. Les opérateurs numériques suivants sont autorisés
+ :
| opérateur | description |
|---|---|
= ou == |
+ La version de httpd est égale à la valeur + spécifiée |
> |
+ La version de httpd est supérieure à la valeur + spécifiée |
>= |
+ La version de httpd est supérieure ou égale à la valeur + spécifiée |
< |
+ La version de httpd est inférieure à la valeur + spécifiée |
<= |
+ La version de httpd est inférieure ou égale à la valeur + spécifiée |
<IfVersion >= 2.3> + # la condition n'est satisfaite que pour les versions de httpd + # supérieures ou égales à 2.3 +</IfVersion>+
En plus d'une comparaison numérique, il est possible de comparer + la version de httpd avec une expression + rationnelle. Il existe deux méthodes pour spécifier cette + dernière :
+ +| opérateur | description |
|---|---|
= ou == |
+ version est de la forme
+ /regex/ |
~ |
+ version est de la forme
+ regex |
<IfVersion = /^2.4.[01234]$/> + # exemple de contournement pour les versions boguées +</IfVersion>+
Pour inverser la condition, tous les opérateurs peuvent être
+ préfixés par un point d'exclamation (!) :
<IfVersion !~ ^2.4.[01234]$> + # pas pour ces versions +</IfVersion>+
Si opérateur est absent, sa valeur implicite est
+ =.
Serveur HTTP Apache Version 2.4
+| Description: | Permet de configurer dynamiquement l'hébergement virtuel de +masse |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | vhost_alias_module |
| Fichier Source: | mod_vhost_alias.c |
Ce module permet de créer des serveurs virtuels configurés
+ dynamiquement, en autorisant l'utilisation de l'adresse IP et/ou de
+ l'en-tête Host: de la requête HTTP comme partie du nom
+ de chemin afin de déterminer les fichiers à servir. Ceci facilite la
+ gestion d'un grand nombre de serveurs virtuels possèdant des
+ configurations similaires.
Si les modules mod_alias ou
+ mod_userdir sont utilisés pour traduire les URIs
+ en noms de fichiers, ils l'emportent sur les directives du module
+ mod_vhost_alias décrites ci-dessous. Par
+ exemple, la configuration suivante fera correspondre
+ /cgi-bin/script.pl à
+ /usr/local/apache2/cgi-bin/script.pl dans tous les cas :
ScriptAlias "/cgi-bin/" "/usr/local/apache2/cgi-bin/" +VirtualScriptAlias "/never/found/%0/cgi-bin/"+ +
Toutes les directives de ce module insèrent une chaîne dans un
+ nom de chemin. La chaîne insérée (que nous appellerons maintenant le
+ "nom") peut être soit le nom du serveur (voir la directive
+ UseCanonicalName pour les
+ détails sur la manière dont il est déterminé), soit l'adresse IP du
+ serveur virtuel hébergé par le serveur sous la forme d'un quadruplet
+ d'octets séparés par des points. L'insertion est contrôlée par des
+ spécificateurs inspirés de printf et possèdant de
+ nombreux formats :
%% |
+insère un % |
%p |
+insère le numéro de port du serveur virtuel |
%N.M |
+insère le nom (en partie) |
N et M permettent de spécifier des
+ sous-chaînes du nom. N sélectionne un des composants du
+ nom séparés par des points, et M sélectionne des
+ caractères à l'intérieur de ce que N a sélectionné.
+ M est optionnel et sa valeur par défaut est 0 s'il
+ n'est pas spécifié ; le point doit être présent si et seulement si
+ M l'est aussi. Les modes d'insertion sont les suivants
+ :
0 |
+ le nom en entier |
1 |
+ la première partie |
2 |
+ la seconde partie |
-1 |
+ la dernière partie |
-2 |
+ l'avant-dernière partie |
2+ |
+ toutes les parties à partir de la seconde |
-2+ |
+ toutes les parties jusqu'à l'avant-dernière |
1+ et -1+ |
+ identique à 0 |
Si N ou M est plus grand que le nombre
+ de parties disponibles, seul un caractère de soulignement est
+ inséré.
Pour des serveurs virtuels simples à base de nom, utilisez les + directives suivantes dans le fichier de configuration de votre + serveur :
+ +UseCanonicalName Off +VirtualDocumentRoot "/usr/local/apache/vhosts/%0"+ + +
Une requête pour
+ http://www.example.com/repertoire/fichier.html
+ concernera alors la ressource
+ /usr/local/apache/vhosts/www.example.com/repertoire/fichier.html.
+
Pour un très grand nombre de serveurs virtuels, il est avantageux
+ d'organiser les fichiers de façon à réduire la taille du répertoire
+ vhosts. Pour ce faire, insérez les lignes suivantes
+ dans votre fichier de configuration :
UseCanonicalName Off +VirtualDocumentRoot "/usr/local/apache/vhosts/%3+/%2.1/%2.2/%2.3/%2"+ + +
Une requête pour
+ http://www.domaine.example.com/repertoire/fichier.html
+ concernera alors la ressource
+ /usr/local/apache/vhosts/example.com/d/o/m/domaine/repertoire/fichier.html.
Une répartition plus régulière des fichiers peut être obtenue en + partant de la fin d'un composant du nom, comme dans l'exemple + suivant :
+ +VirtualDocumentRoot "/usr/local/apache/vhosts/%3+/%2.-1/%2.-2/%2.-3/%2"+ + +
La requête précédente concernerait alors
+ /usr/local/apache/vhosts/example.com/e/n/i/domaine/repertoire/fichier.html.
Vous pouvez également utiliser :
+ +VirtualDocumentRoot "/usr/local/apache/vhosts/%3+/%2.1/%2.2/%2.3/%2.4+"+ + +
La requête précédente concernerait alors
+ /usr/local/apache/vhosts/example.com/d/o/m/aine/repertoire/fichier.html.
Une demande très courante des utilisateurs concerne la possibilité de
+ faire correspondre plusieurs racines de documents à plusieurs
+ domaines, sans avoir à se préoccuper de la longueur ou du nombre de
+ parties du nom d'hôte faisant partie de la requête. Si le nom d'hôte
+ de la requête est sub.www.domain.example.com au lieu de
+ simplement www.domain.example.com, alors en utilisant
+ %3+, la racine des documents sera
+ /usr/local/apache/vhosts/domain.example.com/... au
+ lieu du répertoire example.com attendu. Dans ce genre
+ de situation, il peut s'avérer préférable d'utiliser la combinaison
+ %-2.0.%-1.0 qui fournira toujours le nom de domaine et
+ le tld, par exemple example.com sans tenir compte du
+ nombre de sous-domaines ajoutés au nom d'hôte. Dans ces conditions,
+ il est possible d'élaborer une configuration qui associera les
+ sous-domaines de premier, second et troisième niveau au même
+ répertoire :
+
VirtualDocumentRoot "/usr/local/apache/vhosts/%-2.0.%-1.0"+ +
+Dans l'exemple ci-dessus, www.example.com,
+www.sub.example.com ou example.com
+correspondront tous au répertoire
+/usr/local/apache/vhosts/example.com.
+
Pour l'hébergement virtuel à base d'adresse IP, vous pouvez + insérer les lignes suivantes dans votre fichier de configuration + :
+ +UseCanonicalName DNS +VirtualDocumentRootIP "/usr/local/apache/vhosts/%1/%2/%3/%4/docs" +VirtualScriptAliasIP "/usr/local/apache/vhosts/%1/%2/%3/%4/cgi-bin"+ + +
Si l'adresse IP de www.domaine.example.com est
+ 10.20.30.40, une requête pour
+ http://www.domaine.example.com/repertoire/fichier.html
+ concernera la ressource
+ /usr/local/apache/vhosts/10/20/30/40/docs/repertoire/fichier.html.
+ Une requête pour
+ http://www.domaine.example.com/cgi-bin/script.pl
+ concernera la ressource
+ /usr/local/apache/vhosts/10/20/30/40/cgi-bin/script.pl.
Si vous voulez insérer le caractère . dans une
+ directive VirtualDocumentRoot, et si cela crée un
+ conflit avec un spécificateur %, vous pouvez contourner
+ le problème de la manière suivante :
VirtualDocumentRoot "/usr/local/apache/vhosts/%2.0.%3.0"+ + +
Une requête pour
+ http://www.domaine.example.com/repertoire/fichier.html
+ concernera alors la ressource
+ /usr/local/apache/vhosts/domaine.exemple/repertoire/fichier.html.
Les spécificateurs de format %V et %A
+ de la directive LogFormat s'avèrent très utiles
+ lorsqu'ils sont utilisés en conjonction avec ce module.
| Description: | Permet une configuration dynamique de la racine des +documents d'un serveur virtuel donné |
|---|---|
| Syntaxe: | VirtualDocumentRoot répertoire-interpolé|none |
| Défaut: | VirtualDocumentRoot none |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_vhost_alias |
La directive VirtualDocumentRoot vous
+ permet de spécifier où le serveur HTTP Apache pourra trouver vos
+ documents en se basant
+ sur le nom du serveur. Le résultat de l'expansion du
+ répertoire-interpolé est utilisé comme racine de
+ l'arborescence des documents d'une manière similaire à l'argument de
+ la directive DocumentRoot. Si
+ répertoire-interpolé a pour valeur none, la
+ directive VirtualDocumentRoot est désactivée.
+ Cette directive ne peut pas être utilisée dans le même contexte que
+ la directive VirtualDocumentRootIP.
VirtualDocumentRoot l'emporte sur
+toute directive DocumentRoot
+définie dans le même contexte ou dans des contextes enfants. Le fait de
+définir une directive VirtualDocumentRoot dans le
+contexte du serveur principal va effectivement l'emporter sur toute
+directive DocumentRoot définie dans
+un serveur virtuel quelconque, si vous n'avez pas défini
+VirtualDocumentRoot à None dans ce
+serveur virtuel.
+| Description: | Configuration dynamique de la racine des documents pour un +serveur virtuel donné |
|---|---|
| Syntaxe: | VirtualDocumentRootIP répertoire-interpolé|none |
| Défaut: | VirtualDocumentRootIP none |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_vhost_alias |
La directive VirtualDocumentRootIP est
+identique à la directive VirtualDocumentRoot à l'exception
+près qu'elle utilise l'adresse IP du serveur virtuel pour
+l'interpolation du répertoire à la place du nom du serveur.
| Description: | Configuration dynamique du répertoire des scripts CGI pour +un serveur virtuel donné |
|---|---|
| Syntaxe: | VirtualScriptAlias répertoire-interpolé|none |
| Défaut: | VirtualScriptAlias none |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_vhost_alias |
La directive VirtualScriptAlias vous
+ permet de spécifier où Apache httpd pourra trouver les scripts CGI selon une
+ méthode similaire à celle qu'utilise la directive VirtualDocumentRoot pour les
+ autres documents. Elle recherche des requêtes dont l'URI commence
+ par /cgi-bin/, comme le ferait la directive ScriptAlias.
| Description: | Configuration dynamique du répertoire des scripts CGI pour +un serveur virtuel donné |
|---|---|
| Syntaxe: | VirtualScriptAliasIP répertoire-interpolé|none |
| Défaut: | VirtualScriptAliasIP none |
| Contexte: | configuration globale, serveur virtuel |
| Statut: | Extension |
| Module: | mod_vhost_alias |
La directive VirtualScriptAliasIP est
+ identique à la directive VirtualScriptAlias à
+ l'exception près qu'elle utilise l'adresse IP du serveur virtuel
+ pour l'interpolation du répertoire à la place du nom du serveur.
Serveur HTTP Apache Version 2.4
+| Description: | Fournit une infrastructure permettant à d'autres modules +d'exécuter des tâches périodiques. |
|---|---|
| Statut: | Base |
| Identificateur de Module: | watchdog_module |
| Fichier Source: | mod_watchdog.c |
| Compatibilité: | Disponible à partir de la version 2.3 du serveur HTTP +Apache |
Le module mod_watchdog définit des
+branchements (hooks) programmés pour permettre à d'autres modules
+d'exécuter des tâches périodiques. Ces modules peuvent enregistrer des
+gestionnaires (handlers) pour les branchements de
+mod_watchdog. Actuellement, seuls les modules suivants
+de la distribution Apache utilisent cette fonctionnalité :
mod_watchdog, ce dernier doit être lié statiquement
+avec le serveur httpd ; s'il a été lié dynamiquement, il doit être
+chargé avant l'appel au module qui doit utiliser sa fonctionnalité.
+| Description: | Intervalle Watchdog en secondes |
|---|---|
| Syntaxe: | WatchdogInterval time-interval[s] |
| Défaut: | WatchdogInterval 1 |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_watchdog |
Cette directive permet de définir l'intervalle entre chaque exécution +du branchement watchdog. La valeur par défaut est de 1 seconde.
+ +Serveur HTTP Apache Version 2.4
+| Description: | Support avancé de l'internationalisation et des jeux de +caractères pour les modules de filtrage basés sur libxml2 |
|---|---|
| Statut: | Base |
| Identificateur de Module: | xml2enc_module |
| Fichier Source: | mod_xml2enc.c |
| Compatibilité: | Disponible depuis la version 2.4 du serveur HTTP Apache. +Disponible en tant que module tiers dans les versions 2.2.x |
Ce module fournit un support avancé de l'internationalisation
+ pour les modules de filtrage supportant les balises (markup-aware)
+ comme mod_proxy_html. Il est capable de détecter
+ automatiquement l'encodage des données en entrée et de s'assurer
+ qu'elle sont traitées correctement par l'interpréteur libxml2, y compris la conversion en
+ Unicode (UTF-8) si nécessaire. Il peut aussi convertir les données
+ dans l'encodage de votre choix après le traitement des balises, et
+ s'assurera que le jeu de caractères approprié sera défini
+ dans l'en-tête HTTP Content-Type.
Utilisation API de programmation Détection et encodage Codage en sortie Codages non supportés xml2EncAlias xml2EncDefault xml2StartParseIl existe deux scénarios d'utilisation : le cas des modules + programmés pour travailler avec mod_xml2enc ; et les autres :
+Les modules comme mod_proxy_html versions 3.1 et
+ supérieures utilisent la fonction optionnelle
+ xml2enc_charset pour déterminer la valeur de l'argument
+ "jeu de caractères" à transmettre à l'interpréteur libxml2, et
+ disposent de la fonction optionnelle xml2enc_filter
+ pour effectuer un encodage ultérieur éventuel. L'utilisation de
+ mod_xml2enc avec un module préprogrammé à cet effet ne nécessite
+ aucune configuration : ce dernier configurera mod_xml2enc pour vous
+ (sachant que vous pouvez tout de même le personnaliser via les
+ directives de configuration ci-dessous).
Pour utiliser mod_xml2enc avec un module basé sur libxml2 qui n'a + pas été explicitement programmé pour mod_xml2enc, vous devrez + configurer la chaîne de filtrage vous-même. Ainsi, pour utiliser + mod_xml2enc avec un filtre foo fourni par un module + mod_foo et pour + améliorer le support i18n de ce dernier avec HTML et XML, vous + pouvez utiliser les directives suivantes :
+
+ FilterProvider iconv xml2enc Content-Type $text/html
+ FilterProvider iconv xml2enc Content-Type $xml
+ FilterProvider markup foo Content-Type $text/html
+ FilterProvider markup foo Content-Type $xml
+ FilterChain iconv markup
+ mod_foo supportera alors tout jeu de caractère supporté soit par + libxml2, soit par apr_xlate/iconv, soit par les deux.
+Les programmeurs de modules de filtrage basés sur libxml2 sont
+ encouragés à les préprogrammer pour mod_xml2enc, afin de fournir un
+ support i18n solide aux utilisateurs sans avoir à réinventer la
+ roue. L'API de programmation est décrite dans
+ mod_xml2enc.h, et mod_proxy_html est un
+ exemple de son utilisation.
A la différence de mod_charset_lite, mod_xml2enc
+ est conçu pour travailler avec des données dont l'encodage ne peut
+ pas être connu, et donc configuré, à l'avance. Il utilise donc les
+ techniques de 'reniflage' suivantes pour détecter le type d'encodage
+ des données HTTP :
<META>, c'est ce dernier qui sera utilisé.xml2EncDefault qui sera utilisée.Les conditions sont testées dans cet ordre . Dès qu'une règle + s'applique, elle est utilisée et la détection est terminée.
+libxml2 utilise toujours UTF-8 +(Unicode) en interne, et les modules de filtrage basés sur libxml2 +utiliseront cet encodage en sortie par défaut. mod_xml2enc peut modifier +l'encodage en sortie via l'API, mais il n'y a actuellement aucun moyen de le +configurer directement.
+La modification de l'encodage en sortie ne devrait (du moins en théorie) +jamais être nécessaire, et est même déconseillée à cause de la charge de +traitement supplémentaire imposée au serveur par une conversion non +nécessaire.
+Si vous travaillez avec des encodages non supportés par aucune des
+méthodes de conversion disponibles sur votre plateforme, vous pouvez
+tout de même leur associer un alias vers un code supporté via la
+directive xml2EncAlias.
| Description: | Définit des alias pour les valeurs d'encodage |
|---|---|
| Syntaxe: | xml2EncAlias jeu-de-caractères alias [alias ...] |
| Contexte: | configuration globale |
| Statut: | Base |
| Module: | mod_xml2enc |
Cette directive de niveau serveur permet de définir un ou + plusieurs alias pour un encodage. Elle permet au support d'encodage de + libxml2 de traiter en interne des encodages non reconnus par libxml2 + en utilisant la table de conversion pour un encodage reconnu. Elle + permet d'atteindre deux objectifs : supporter des jeux (ou noms) de + caractères non reconnus par libxml2 ou iconv, et éviter une + conversion pour un encodage lorsque cela n'est pas nécessaire.
+ +| Description: | Définit un encodage par défaut à utiliser lorsqu'aucune +information ne peut être automatiquement détectée |
|---|---|
| Syntaxe: | xml2EncDefault nom |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Base |
| Module: | mod_xml2enc |
| Compatibilité: | Disponible depuis la version 2.4.0 du serveur HTTP Apache +; disponible depuis un module tiers dans les versions antérieures. |
Si vous traitez des données dont l'encodage est connu, mais ne + contenant aucune information à propos de ce dernier, vous pouvez + définir une valeur par défaut afin d'aider mod_xml2enc à traiter + correctement les données. Par exemple, pour définir la valeur par + défaut Latin1 (iso-8859-1 specifiée dans HTTP/1.0), + utilisez :
+xml2EncDefault iso-8859-1+ + +
| Description: | Indique à l'interpréteur à partir de quelle balise il doit +commencer son traitement. |
|---|---|
| Syntaxe: | xml2StartParse élément [élément ...] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Statut: | Base |
| Module: | mod_xml2enc |
Cette directive permet de spécifier à partir de quelle balise, + parmi les éléments spécifiés, l'interpréteur de balise doit + commencer son traitement. Ccei permet de contourner le problème des + serveurs d'arrière-plan qui insèrent des éléments non conformes en + début de données, ce qui a pour effet de perturber l'interpréteur (voir un exemple ici).
+Elle ne doit être utilisée ni pour les documents XML, ni pour les + documents HTML correctement formatés.
+ +Serveur HTTP Apache Version 2.4
+Ce document décrit les termes utilisés pour décrire chaque module Apache.
+Une brève description des fonctions du module.
+Ce terme indique le degré de rapprochement du module par rapport + au coeur du serveur web Apache ; en d'autres termes, vous pouvez + être amené à recompiler le serveur pour pouvoir accéder au module et + à ses fonctionnalités. Les valeurs possibles de cet attribut sont + :
+ +Il s'agit tout simplement de la liste des noms des fichiers
+ source qui contiennent le code du module. C'est aussi le nom utilisé
+ par la directive <IfModule>.
C'est une chaîne permettant d'identifier le module à utiliser
+ dans la directive LoadModule
+ pour le chargement dynamique des modules. En particulier, c'est le
+ nom de la variable externe de type module dans le fichier
+ source.
Si le module ne faisait pas partie de la distribution originale + d'Apache version 2, la version à partir de laquelle il est + disponible est indiquée ici. En outre, si le module n'est disponible + que sur certaines plates-formes, cela sera mentionné ici.
+Serveur HTTP Apache Version 2.4
+| Description: | Une série de directives implémentées par plusieurs +modules multi-processus (MPM) |
|---|---|
| Statut: | MPM |
CoreDumpDirectory EnableExceptionHook GracefulShutdownTimeout Listen ListenBackLog ListenCoresBucketsRatio MaxConnectionsPerChild MaxMemFree MaxRequestWorkers MaxSpareThreads MinSpareThreads PidFile ReceiveBufferSize ScoreBoardFile SendBufferSize ServerLimit StartServers StartThreads ThreadLimit ThreadsPerChild ThreadStackSize| Description: | Le répertoire dans lequel le serveur HTTP Apache va tenter de se +positionner avant d'effectuer un vidage mémoire |
|---|---|
| Syntaxe: | CoreDumpDirectory répertoire |
| Défaut: | Voir ci-dessous pour le répertoire par défaut |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork |
Cette directive permet de définir le répertoire dans lequel
+ Apache httpd va tenter de se positionner avant d'effectuer un vidage
+ mémoire sur disque.
+ Si votre système d'exploitation est configuré pour créer des
+ fichiers de vidage mémoire dans le répertoire de travail des
+ processus qui se sont crashés,
+ CoreDumpDirectory est nécessaire pour
+ définir un répertoire de travail autre que le répertoire par défaut
+ ServerRoot, ce répertoire de
+ travail ne devant pas être accessible en écriture par l'utilisateur sous
+ lequel le serveur s'exécute.
Si vous avez besoin d'un vidage mémoire pour le débogage, vous + pouvez utiliser cette directive pour le placer à un endroit + différent. Cette directive n'a aucun effet si votre système + d'exploitation n'est pas configuré pour créer des + fichiers de vidage mémoire dans le répertoire de travail des + processus qui se sont crashés.
+ +Si Apache httpd est démarré sous l'utilisateur root puis bascule vers
+ un autre utilisateur, le noyau Linux désactive les
+ vidages mémoire, même si le répertoire est accessible en écriture au
+ processus. Apache httpd (versions 2.0.46 et supérieures) réactive les
+ vidages mémoire sous Linux 2.4 et au delà, mais seulement si vous
+ définissez une directive CoreDumpDirectory.
Pour activer le vidage mémoire des exécutables suid sur les
+ systèmes de style BSD (comme FreeBSD), définissez
+ kern.sugid_coredump à 1.
+
CoreDumpDirectory n'est traité qu'à la
+ reception d'un certain nombre de signaux , SIGFPE, SIGILL, SIGABORT,
+ SIGSEGV, et SIGBUS.
+ Sur certains systèmes d'exploitation, SIGQUIT provoque aussi un
+ vidage mémoire, mais n'est pas traité par les directives
+ CoreDumpDirectory ou
+ EnableExceptionHook, si bien que la
+ définition du répertoire d'enregistrement du vidage mémoire est
+ entièrement dévolue au système d'exploitation.
| Description: | Active un hook ("point d'accrochage logiciel") qui exécute des +gestionnaires d'exception après un crash |
|---|---|
| Syntaxe: | EnableExceptionHook On|Off |
| Défaut: | EnableExceptionHook Off |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork |
Pour des raisons de sécurité, cette directive n'est disponible
+ que si la compilation du serveur a été configurée avec l'option
+ --enable-exception-hook. Elle permet d'activer un hook
+ ("point d'accrochage logiciel")
+ qui autorise certains modules externes à effectuer un branchement et
+ accomplir telle ou telle action après le crash d'un processus
+ enfant.
Deux modules, mod_whatkilledus et
+ mod_backtrace utilisent ce hook. Veuillez vous
+ référer à la page EnableExceptionHook de Jeff Trawick pour plus
+ d'informations à leur sujet.
| Description: | Spécifie le délai maximum après lequel le serveur va +s'arrêter dans le cas d'un arrêt "en douceur" |
|---|---|
| Syntaxe: | GracefulShutdownTimeout seconds |
| Défaut: | GracefulShutdownTimeout 0 |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork |
| Compatibilité: | Disponible dans les versions 2.2 et supérieures |
La directive GracefulShutdownTimeout
+ permet de spécifier le temps, en secondes, pendant lequel le serveur
+ va continuer à fonctionner après avoir reçu un signal
+ "graceful-stop" ("Arrêt en douceur"), afin de terminer le traitement
+ des connexions en cours.
Définir cette valeur à zéro signifie au serveur d'attendre + jusqu'à ce que toutes les requêtes en cours aient été traitées.
+ +| Description: | Les adresses IP et ports sur lesquels le serveur écoute |
|---|---|
| Syntaxe: | Listen [adresse IP:]numéro port
+[protocole] |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork, mpm_winnt, mpm_netware, mpmt_os2 |
| Compatibilité: | L'argument protocole est supporté depuis la version +2.1.5 |
La directive Listen permet de signifier à
+ Apache httpd de ne se mettre à l'écoute que sur les adresses IP et ports spécifiés ; par
+ défaut, le serveur répond aux requêtes en provenance de toutes les
+ interfaces réseau. La directive Listen est
+ dorénavant requise, et si elle est absente du fichier de
+ configuration, le serveur refusera de démarrer. Ceci constitue un
+ changement par rapport aux versions précédentes d'Apache httpd.
La directive Listen signifie au serveur de
+ n'accepter les requêtes entrantes que vers le port ou le couple
+ adresse-port spécifié. Si seulement un port est spécifié, le serveur
+ se met à l'écoute sur ce port sur toutes les interfaces réseau. Si une adresse IP
+ et un port sont spécifiés, le serveur va se mettre à l'écoute sur ce port sur
+ l'interface réseau correspondant à l'adresse IP.
On peut utiliser autant de directives
+ Listen que nécessaire pour spécifier
+ plusieurs adresses et/ou ports à écouter. Le serveur répondra aux
+ requêtes vers tous les adresses et ports spécifiés.
Par exemple, pour que le serveur accepte les connexions sur les + ports 80 et 8000, utilisez :
+ +Listen 80 +Listen 8000+ + +
Pour que le serveur accepte les connexions sur deux interfaces et + ports particuliers, spécifiez :
+ +Listen 192.170.2.1:80 +Listen 192.170.2.5:8000+ + +
Les adressee IPv6 doivent être entourées de crochets, comme dans + l'exemple suivant :
+ +Listen [2001:db8::a00:20ff:fea7:ccea]:80+ + +
L'argument optionnel protocole n'est pas nécessaire
+ dans la plupart des configurations. S'il est absent,
+ https est la valeur par défaut pour le port 443 et
+ http l'est pour tous les autres ports. L'argument
+ protocole sert à déterminer quel module doit traiter une requête, et
+ à appliquer des optimisations spécifiques à certains protocoles à
+ l'aide de la directive AcceptFilter.
La spécification d'un protocole n'est nécessaire que si vous
+ utilisez des ports non standards. Par exemple, pour configurer un
+ site en https sur le port 8443 :
Listen 192.170.2.1:8443 https+ + +
Listen pour les mêmes
+ adresse IP/port vont provoquer l'envoi d'un message d'erreur
+ Address already in use.
+ | Description: | Longueur maximale de la liste d'attente des +connexions |
|---|---|
| Syntaxe: | ListenBacklog backlog |
| Défaut: | ListenBacklog 511 |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork, mpm_winnt, mpm_netware, mpmt_os2 |
La longueur maximale de la liste d'attente des connexions. En
+ général, aucune modification n'est nécessaire, ni même souhaitable ;
+ cependant, sur certains systèmes, il peut être nécessaire
+ d'en augmenter la valeur en cas d'attaque TCP SYN flood (envoi en
+ masse de requêtes SYN pour saturer le serveur). Voir le paramètre
+ backlog de l'appel système listen(2).
En fait, l'argument backlog sera souvent limité à une valeur + inférieure en fonction du système d'exploitation. Notez aussi que de + nombreux systèmes d'exploitation ne tiennent pas vraiment compte de + la valeur spécifiée pour l'argument backlog, mais s'en inspirent + seulement (et choisissent en général une valeur supérieure).
+ +| Description: | Rapport entre le nombre de coeurs de processeur activés et +le nombre de segments d'écoute |
|---|---|
| Syntaxe: | ListenCoresBucketsRatio ratio |
| Défaut: | ListenCoresBucketsRatio 0 (disabled) |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork |
| Compatibilité: | Disponible à partir de la version 2.4.13 du serveur HTTP
+Apache, avec un noyau supportant l'option de socket
+SO_REUSEPORT, et distribuant uniformément les nouvelles
+connexions aux sockets d'écoute des processus (ou threads) qui
+l'utilisent (par exemple Linux versions 3.9 et ultérieures, mais pas
+l'implémentation courante de SO_REUSEPORT par les
+plateformes de type BSD. |
Vous pouvez utiliser la directive
+ ListenCoresBucketsRatio pour spécifier un
+ ratio entre le nombre de coeurs de CPU activés et le
+ nombre de segments d'écoute (listeners' buckets) souhaités ; le
+ serveur HTTP Apache va alors créernum_cpu_cores / ratio
+ segments d'écoute, chacun contenant son propre socket d'écoute
+ Listen sur le ou les mêmes ports ; chaque
+ processus enfant sera associé à un seul segment d'écoute (avec une
+ distribution de type round-robin des segments à la création des
+ processus enfants).
Sous Linux et BSD, un coeur de CPU peut être activé ou désactivé si Hotplug
+ a été configuré ; la directive
+ ListenCoresBucketsRatio doit donc tenir compte de ce
+ paramètre pour calculer le nombre de segments d'écoute à créer.
La directive ListenCoresBucketsRatio peut
+ améliorer le support de la montée en charge lorsque l'arrivée de
+ nouvelles connexions est/devient un goulot d'étranglement. Le test
+ de cette fonctionnalité avec des machines possédant un nombre de
+ coeurs de CPU important a permit de constater une amélioration des
+ performances significative et des temps de réponse plus courts.
Pour que cette fonctionnalité soit activée, le nombre de coeurs
+ de CPU doit être égal au moins au double du ratio
+ spécifié. Si vous spécifiez la valeur recommandée pour
+ ratio, à savoir 8, le nombre minimum de
+ coeurs de processeurs disponibles sera alors de 16. La valeur
+ optimale de ratio permettant d'obtenir des performances maximales
+ doit être calculée pour chaque système cible, en testant plusieurs valeurs
+ et en observant les résultats.
Cette directive influence le calcul des valeurs limites inférieures de
+ MinSpareThreads et MaxSpareThreads. En effet, pour accepter les
+ connexions de manière optimale, le nombre de processus enfants doit être un
+ multiple du nombre de segments d'écoute.
Listeners ou serveurs HTTP
+ Apache partagent la même adresse IP et portLa définition de l'option SO_REUSEPORT pour les sockets
+ d'écoute permet à plusieurs processus (partageant le même EUID,
+ par exemple root) de se rattacher à la même adresse IP et port,
+ sans obtenir l'erreur de rattachement que le système génère habituellement
+ lorsque ce cas se produit.
Cela signifie aussi que plusieurs instances d'Apache httpd configurées
+ avec le même IP:port et avec une valeur
+ ListenCoresBucketsRatio positive pourraient démarrer
+ sans erreur, et fonctionner ensuite avec une répartition uniforme des
+ connexions entrantes sur ces différentes instances (ce n'est PAS une
+ recommandation et ne constitue pas un usage approprié à tous les cas, mais
+ juste un avertissement sur le fait qu'un véritable problème de rattachement
+ multiple à un IP:port pourrait alors être occulté).
Au sein d'une même instance, Apache httpd vérifie la présence de
+ directives Listen multiples avec la même adresse IP
+ (ou nom d'hôte) et le même port, et refuse de démarrer si c'est le cas, ce
+ qui permet d'éviter la création de segments d'écoute dupliqués qui seraient
+ du coup inutiles et affecteraient les performances. Cependant, il ne peut
+ pas (et n'essaiera pas de le faire) intercepter tous les cas possibles de
+ recouvrement (comme un nom d'hôte correspondant à une adresse IP utilisée
+ quelque part ailleurs).
| Description: | Limite le nombre de connexions qu'un processus enfant va +traiter au cours de son fonctionnement |
|---|---|
| Syntaxe: | MaxConnectionsPerChild number |
| Défaut: | MaxConnectionsPerChild 0 |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork, mpm_winnt, mpm_netware, mpmt_os2 |
| Compatibilité: | Disponible depuis la version 2.3.9 du serveur HTTP
+Apache. L'ancien nom MaxRequestsPerChild est encore
+supporté. |
La directive MaxConnectionsPerChild permet de
+ définir le nombre maximum de connexions qu'un processus enfant va
+ pouvoir traiter au cours de son fonctionnement. Lorsqu'il a traité
+ MaxConnectionsPerChild connexions, le processus
+ enfant est arrêté. Si MaxConnectionsPerChild est
+ définie à 0, il n'y a plus aucune limite sur le nombre
+ de connexions que le processus pourra traiter.
Définir MaxConnectionsPerChild à une valeur
+ non nulle limite la quantité de mémoire qu'un processus peut
+ consommer à cause de fuites (accidentelles) de mémoire.
| Description: | Quantité maximale de mémoire que l'allocateur principal est
+autorisé à conserver sans appeler free() |
|---|---|
| Syntaxe: | MaxMemFree KOctets |
| Défaut: | MaxMemFree 2048 |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork, mpm_winnt, mpm_netware |
La directive MaxMemFree permet de définir
+ le nombre maximum de KOctets libres que tout allocateur est
+ autorisé à conserver sans appeler free(). Dans les MPMs
+ threadés, chaque thread possède son propre allocateur. Si elle est
+ définie à 0, la quantité de mémoire libre que peut conserver un
+ allocateur est illimitée.
| Description: | Nombre maximum de connexions pouvant être traitées +simultanément |
|---|---|
| Syntaxe: | MaxRequestWorkers nombre |
| Défaut: | Voir ci-dessous pour plus de détails |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork |
La directive MaxRequestWorkers permet de fixer le
+ nombre maximum de requêtes pouvant être traitées simultanément.
+ Si la limite MaxRequestWorkers est atteinte, toute
+ tentative de connexion sera normalement mise dans une file
+ d'attente, et ceci jusqu'à un certain nombre dépendant de la
+ directive ListenBacklog.
+ Lorsqu'un processus enfant se libèrera suite à la fin du traitement
+ d'une requête, la connexion en attente pourra être traitée à son
+ tour.
Pour les serveurs non threadés (c'est à dire utilisant
+ prefork), la directive
+ MaxRequestWorkers définit alors le nombre maximum de
+ processus enfants qui pourront être lancés simultanément pour
+ traiter les requêtes. La valeur par défaut est 256 ; si
+ vous l'augmentez, vous devez aussi augmenter la valeur de la
+ directive ServerLimit.
Pour les serveur threadés et hybrides (utilisant par
+ exemple event ou worker),
+ MaxRequestWorkers définit alors le nombre total de
+ threads qui seront disponibles pour servir les clients. Dans le
+ cas des MPMs hybrides, la valeur par défaut est 16
+ (directive ServerLimit) multiplié par la valeur
+ 25 (directive ThreadsPerChild). Par conséquent, pour affecter à la
+ directive MaxRequestWorkers une valeur qui requiert
+ plus de 16 processus, vous devez aussi augmenter la valeur de la
+ directive ServerLimit.
Le nom de la directive MaxRequestWorkers
+ était MaxClients avant la version 2.3.13. Cet
+ ancien nom est encore supporté.
| Description: | Nombre maximum de threads inactifs |
|---|---|
| Syntaxe: | MaxSpareThreads nombre |
| Défaut: | Voir ci-dessous pour plus de détails |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, mpm_netware, mpmt_os2 |
C'est le nombre maximum de threads inactifs. Les MPMs utilisent + cette directive de différentes manières.
+ +Pour worker et event, la définition par défaut est
+ MaxSpareThreads 250. Ce MPM gère les threads inactifs
+ au niveau du serveur. Si le serveur possède trop de threads
+ inactifs, des processus enfants seront arrêtés jusqu'à ce que le
+ nombre de threads inactifs repasse en dessous de cette limite. Des
+ processus/threads supplémentaires sont susceptibles d'être créés si
+ ListenCoresBucketsRatio est
+ activée.
Pour mpm_netware, la définition par défaut est
+ MaxSpareThreads 100. Comme ce MPM n'exécute qu'un seul
+ processus, le nombre de processus inactifs est surveillé au
+ niveau du serveur.
mpmt_os2 fonctionne de manière similaire à
+ mpm_netware. Pour mpmt_os2, la
+ valeur par défaut est 10.
La gamme de valeurs pour MaxSpareThreads
+ est limitée. Apache httpd corrigera automatiquement cette valeur selon
+ les règles suivantes :
mpm_netware, MaxSpareThreads doit être supérieure à MinSpareThreads.worker et event, MaxSpareThreads
+ doit être supérieure ou égale à la somme de MinSpareThreads et ThreadsPerChild.| Description: | Nombre minimum de threads inactifs qui seront disponibles +pour pouvoir traiter les pics de requêtes |
|---|---|
| Syntaxe: | MinSpareThreads nombre |
| Défaut: | Voir ci-dessous pour plus de détails |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, mpm_netware, mpmt_os2 |
C'est le nombre minimum de threads inactifs pour être en mesure + de traiter les pics de requêtes. Les MPMs utilisent cette directive + de différentes manières.
+ +Avec worker et event, la définition par défaut est
+ MinSpareThreads 75, et le nombre de threads inactifs
+ est surveillé au niveau du serveur. Si le serveur ne possède pas
+ assez de threads inactifs, des processus enfants sont créés jusqu'à
+ ce que le nombre de threads inactifs repasse au dessus de
+ nombre. Des processus/threads supplémentaires peuvent
+ être créés si ListenCoresBucketsRatio est activée.
Avec mpm_netware, la définition par défaut est
+ MinSpareThreads 10 et, comme ce MPM n'exécute qu'un
+ seul processus, le nombre de threads est surveillé au niveau du
+ serveur.
mpmt_os2 fonctionne de manière similaire à
+ mpm_netware. Pour mpmt_os2, la
+ valeur par défaut est 5.
| Description: | Ficher dans lequel le serveur enregistre l'identificateur +de processus du démon |
|---|---|
| Syntaxe: | PidFile nom fichier |
| Défaut: | PidFile logs/httpd.pid |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork, mpm_winnt, mpmt_os2 |
La directive PidFile permet de définir le
+ ficher dans lequel le serveur
+ enregistre l'identificateur de processus du démon. Si le chemin du
+ fichier n'est pas absolu, il est considéré comme relatif au chemin
+ défini par la directive ServerRoot.
PidFile /var/run/apache.pid+
Il est souvent utile de pouvoir envoyer un signal au
+ serveur afin qu'il ferme et ouvre à nouveau ses journaux
+ d'erreur et de transfert, et recharge son
+ fichier de configuration. Pour ce faire, on envoie un signal SIGHUP
+ (kill -1) à l'identificateur de processus enregistré dans le fichier
+ défini par la directive PidFile.
La directive PidFile fait l'objet des
+ mêmes avertissements que ceux concernant le chemin d'enregistrement
+ des fichiers journaux et la sécurité.
Depuis la version 2 du serveur HTTP Apache, nous recommandons de n'utiliser
+ que le script apachectl, ou le script de
+ démarrage fourni avec votre système d'exploitation pour (re)démarrer ou
+ arrêter le serveur.
| Description: | Taille du tampon TCP en entrée |
|---|---|
| Syntaxe: | ReceiveBufferSize octets |
| Défaut: | ReceiveBufferSize 0 |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork, mpm_winnt, mpm_netware, mpmt_os2 |
Le serveur va fixer la taille du tampon TCP en entrée au + nombre d'octets spécifié.
+ +Si la directive est définie à 0, le serveur va
+ utiliser la valeur par défaut adoptée par le système
+ d'exploitation.
| Description: | Chemin du fichier où sont stockées les données concernant +la coordination des processus enfants |
|---|---|
| Syntaxe: | ScoreBoardFile chemin fichier |
| Défaut: | ScoreBoardFile logs/apache_runtime_status |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork, mpm_winnt |
Le serveur HTTP Apache utilise un tableau de bord pour la + communication entre le processus parent et les processus enfants. + Pour faciliter cette communication, certaines architectures + nécessitent un fichier. En l'absence de cette directive, donc si + aucun nom de fichier n'est spécifié, Apache httpd tentera tout + d'abord de créer un tableau uniquement en mémoire (en utilisant la + mémoire partagée anonyme) ; et si il n'y parvient pas, il tentera de + créer un fichier sur disque (en utilisant la mémoire partagée à base + de fichier). Si cette directive est utilisée, Apache httpd créera + systématiquement un fichier sur disque.
+ +ScoreBoardFile /var/run/apache_runtime_status+
Une mémoire partagée sous forme de fichier est utile pour les + applications tierces qui nécessitent un accès direct au tableau de + bord des processus.
+ +Si vous utilisez un ScoreBoardFile, vous
+ pourrez constater une amélioration des performances en le plaçant
+ sur un disque virtuel en RAM. Assurez-vous cependant de tenir compte
+ des mêmes avertissements que ceux concernant le chemin du fichier
+ journal et la sécurité.
| Description: | Taille du tampon TCP en sortie |
|---|---|
| Syntaxe: | SendBufferSize octets |
| Défaut: | SendBufferSize 0 |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork, mpm_winnt, mpm_netware, mpmt_os2 |
Définit la taille du tampon TCP en sortie avec le nombre + d'octets spécifié. Ceci s'avère souvent très utile pour augmenter les + valeurs par défaut standards du passé des systèmes d'exploitation + pour les transmissions à grande vitesse et haute densité (c'est + à dire de l'ordre de 100ms comme sur les liaisons rapides + transcontinentales).
+ +Si la directive est définie à 0, le serveur va
+ utiliser la valeur par défaut adoptée par le système
+ d'exploitation.
L'amélioration des performances des connexions à grande vitesse + et à temps de latence élevé, peut nécessiter + une intervention au niveau de la configuration de votre système + d'exploitation.
+ +Sous certains systèmes d'exploitation, la modification du
+ comportement TCP via une augmentation de la valeur de
+ SendBufferSize risque de ne pas être
+ perceptible, si la directive EnableSendfile n'est pas définie à OFF.
+ Cette interaction ne s'applique qu'aux fichiers statiques.
| Description: | Limite supérieure de la définition du nombre de +processus |
|---|---|
| Syntaxe: | ServerLimit nombre |
| Défaut: | Voir ci-dessous pour plus de détails |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork |
Avec le MPM prefork, cette directive définit le
+ nombre maximum que l'on peut affecter à la directive MaxRequestWorkers, et ceci pour la
+ durée de vie du processus Apache httpd. Avec les
+ MPMs worker et event, cette directive, en combinaison avec
+ ThreadLimit, définit le
+ nombre maximum que l'on peut affecter à MaxRequestWorkers, et ceci pour la durée de
+ vie du processus Apache httpd. Avec le MPM event, cette
+ directive permet aussi de définir le nombre de processus anciens du serveur
+ pouvant continuer à s'exécuter pour terminer le traitement des connexions
+ ouvertes. Au cours d'un redémarrage, vous pouvez
+ modifier la valeur de la directive MaxRequestWorkers, alors que toute
+ tentative de modification de la valeur de la directive ServerLimit sera ignorée.
Cette directive doit être utilisée avec précaution. Si
+ ServerLimit est définie à une valeur beaucoup
+ plus grande que nécessaire, de la mémoire partagée supplémentaire
+ sera inutilement allouée. Si à la fois
+ ServerLimit et MaxRequestWorkers possèdent des valeurs
+ supérieures à ce que le système peut supporter, ce dernier peut
+ devenir instable ou Apache httpd peut tout simplement refuser de démarrer.
Avec les MPMs prefork et event, n'utilisez cette directive
+ que si vous devez définir MaxRequestWorkers à une valeur supérieure à
+ 256 (valeur par défaut). N'affectez pas à la directive ServerLimit une valeur supérieure à
+ celle que vous avez prévu d'affecter à la directive MaxRequestWorkers.
Avec worker, n'utilisez cette directive que si
+ la définition de vos directives MaxRequestWorkers et ThreadsPerChild nécessitent plus de
+ 16 processus serveurs (valeur par défaut). N'affectez pas à la
+ directive ServerLimit une
+ valeur supérieure au nombre de processus requis pour la définition
+ des directives MaxRequestWorkers
+ et ThreadsPerChild.
Il existe une limite de ServerLimit 20000 codée en
+ dur dans le serveur (200000 pour le MPM prefork).
+ Ceci est censé éviter les effets désastreux que pourrait provoquer
+ une faute de frappe. Pour dépasser cette limite, vous devez
+ modifier la valeur de MAX_SERVER_LIMIT dans le fichier source du
+ mpm et recompiler le serveur.
| Description: | Nombre de processus enfants du serveur créés au +démarrage |
|---|---|
| Syntaxe: | StartServers nombre |
| Défaut: | Voir ci-dessous pour plus de détails |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, prefork, mpmt_os2 |
La directive StartServers permet de
+ définir le nombre de processus enfants du serveur créés au
+ démarrage. Comme le nombre de processus est contrôlé dynamiquement
+ en fonction de la charge (voir MinSpareThreads, MaxSpareThreads, MinSpareServers, MaxSpareServers), il n'est en général
+ pas nécessaire d'ajuster ce paramètre.
La valeur par défaut diffère d'un MPM à l'autre. Pour
+ worker et event, la définition par défaut est
+ StartServers 3 ; la valeur par défaut est
+ 5 pour prefork et 2
+ pour mpmt_os2.
| Description: | Nombre de threads créés au démarrage |
|---|---|
| Syntaxe: | StartThreads nombre |
| Défaut: | Voir ci-dessous pour plus de détails |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | mpm_netware |
C'est le nombre de threads créés au démarrage du serveur. Comme
+ le nombre de threads est contrôlé dynamiquement
+ en fonction de la charge (voir MinSpareThreads, MaxSpareThreads, MinSpareServers, MaxSpareServers), il n'est en général
+ pas nécessaire d'ajuster ce paramètre.
Pour mpm_netware, la définition par défaut est
+ StartThreads 50 et, comme il n'y a qu'un processus, il
+ s'agit du nombre total de threads créés au démarrage pour servir les
+ requêtes.
| Description: | Le nombre de threads maximum que l'on peut définir par +processus enfant |
|---|---|
| Syntaxe: | ThreadLimit nombre |
| Défaut: | Voir ci-dessous pour plus de détails |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, mpm_winnt |
Cette directive permet de définir le nombre maximum que l'on peut
+ affecter à la directive ThreadsPerChild pour la durée de vie
+ du processus Apache httpd. La directive ThreadsPerChild peut être modifiée
+ au cours d'un redémarrage jusqu'à la valeur de la directive ThreadLimit, mais toute tentative
+ de modification de la directive ThreadLimit au cours d'un
+ redémarrage sera ignorée.
L'utilisation de cette directive doit faire l'objet de
+ précautions particulières. Si ThreadLimit est
+ définie à une valeur très supérieure à la directive ThreadsPerChild, de la mémoire
+ partagée supplémentaire sera inutilement allouée. Si les directives
+ ThreadLimit et ThreadsPerChild sont définies à des
+ valeurs supérieures à ce que le système peut supporter, ce dernier
+ peut devenir instable, ou Apache httpd peut tout simplement refuser de
+ démarrer. Ne définissez pas cette directive à une valeur supérieure
+ à la valeur maximale que vous pensez affecter à la directive ThreadsPerChild pour le processus
+ Apache httpd en cours d'exécution.
La valeur par défaut de la directive
+ ThreadLimit est 1920 avec
+ mpm_winnt, et 64 avec les autres
+ MPMs.
Il existe une limite de ThreadLimit 20000 (ou
+ ThreadLimit 100000 avec event,
+ ThreadLimit 15000 avec mpm_winnt)
+ codée en dur dans le serveur. Ceci est censé éviter les effets
+ désastreux que pourrait provoquer une faute de frappe. Pour
+ dépasser cette limite, vous devez modifier la valeur de
+ MAX_THREAD_LIMIT dans le fichier source du mpm et recompiler le
+ serveur.
| Description: | Nombre de threads créés par chaque processus +enfant |
|---|---|
| Syntaxe: | ThreadsPerChild nombre |
| Défaut: | Voir ci-dessous pour plus de détails |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, mpm_winnt |
Cette directive permet de définir le nombre de threads que va
+ créer chaque processus enfant. Un processus enfant crée ces threads
+ au démarrage et n'en crée plus d'autres par la suite. Si l'on
+ utilise un MPM comme mpm_winnt qui ne lance qu'un
+ processus enfant, ce nombre doit être suffisamment grand pour
+ supporter la charge du serveur. Avec un MPM comme
+ worker qui lance plusieurs processus enfants, c'est
+ le nombre total de threads qui doit être suffisamment grand
+ pour supporter la charge du serveur.
La valeur par défaut de la directive
+ ThreadsPerChild est 64 avec
+ mpm_winnt, et 25 avec les autres
+ MPMs.
| Description: | La taille en octets de la pile qu'utilisent les threads qui +traitent les connexions clients |
|---|---|
| Syntaxe: | ThreadStackSize taille |
| Défaut: | 65536 sous NetWare; varie en fonction des autres systèmes
+d'exploitation |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | event, worker, mpm_winnt, mpm_netware, mpmt_os2 |
| Compatibilité: | Disponible dans les versions 2.1 et supérieures +du serveur HTTP Apache |
La directive ThreadStackSize permet de
+ définir la taille de la pile (pour les données propres) qu'utilisent
+ les threads qui traitent les connexions clients en faisant appel à
+ des modules. Dans la plupart des cas, la valeur par défaut de la
+ taille de la pile du système d'exploitation convient, mais il existe
+ certaines situations où il peut s'avérer nécessaire de l'ajuster
+ :
ThreadStackSize à une
+ valeur supérieure à la valeur par défaut du système
+ d'exploitation. Ce type d'ajustement n'est nécessaire que si le
+ fournisseur du module tiers en fait mention, ou si le diagnostic
+ d'un crash d'Apache httpd indique que la taille de la pile était trop
+ petite.ThreadStackSize est définie à une valeur
+ inférieure à la valeur par défaut du système d'exploitation.
+ Cependant, ce
+ type d'ajustement ne doit être effectué que dans un environnement
+ de test permettant de qualifier le serveur web au maximum de ses
+ possibilités, car il peut arriver, dans de rares cas, que des
+ requêtes nécessitent une taille de pile supérieure pour pouvoir
+ être traitées. La taille minimale requise pour la pile dépend
+ fortement des modules utilisés, mais toute modification dans la
+ configuration du serveur web peut invalider la définition courante
+ de la directive ThreadStackSize.ulimit -s (8Mo si aucune limite) qui est
+ utilisée comme taille de pile par défaut.ThreadStackSize, à moins qu'un grand nombre
+ de threads par processus enfant ne soit nécessaire. Sur certaines
+ plates-formes (y compris Linux), une valeur de 128000 est déjà trop
+ basse et provoque des crashes avec certains modules courants.Serveur HTTP Apache Version 2.4
+| Description: | Module multi-processus implémentant un serveur web basé +exclusivement sur les threads et optimisé pour Novell +NetWare |
|---|---|
| Statut: | MPM |
| Identificateur de Module: | mpm_netware_module |
| Fichier Source: | mpm_netware.c |
Ce module multi-processus (MPM) implémente un serveur web basé + exclusivement sur les threads et optimisé pour Novell NetWare.
+ +Le thread maître est chargé du lancement de threads esclaves qui + attendent les connexions et les traitent au fur et à mesure de leur + arrivée. Le serveur HTTP Apache essaie toujours de maintenir + plusieurs threads + esclaves en spare (en réserve) ou inactifs. De cette + façon, les clients n'ont pas besoin d'attendre le lancement d'un + nouveau thread enfant pour que leurs requêtes soient traitées.
+ +Les directives StartThreads, MinSpareThreads, MaxSpareThreads, et MaxThreads contrôlent
+ la manière dont le thread maître crée les threads esclaves afin de
+ traiter les requêtes. En général, Apache httpd s'auto-régule correctement,
+ et la plupart des sites ne nécessitent aucune modification des
+ valeurs par défaut de ces directives. Pour les sites dont le serveur
+ est limité en mémoire, il peut s'avérer nécessaire de diminuer la
+ valeur de la directive MaxThreads afin d'éviter une
+ hyper-activité du serveur (arrêts de threads inactifs et lancement incessant
+ de nouveau threads). Vous trouverez plus d'informations à
+ propos du contrôle de la création de processus dans le document conseils en matière de
+ performances.
La directive MaxRequestsPerChild
+ contrôle la fréquence à laquelle le serveur recycle ses processus
+ en arrêtant les anciens et en en lançant de nouveaux. Sous le
+ système d'exploitation NetWare, il est vivement recommandé de
+ laisser cette directive à 0, ce qui permet aux threads esclaves de
+ continuer à traiter les requêtes indéfiniment.
Listen ListenBacklog MaxConnectionsPerChild MaxMemFree MaxSpareThreads MaxThreads MinSpareThreads ReceiveBufferSize SendBufferSize StartThreads ThreadStackSize| Description: | Définit le nombre maximum de threads esclaves |
|---|---|
| Syntaxe: | MaxThreads nombre |
| Défaut: | MaxThreads 2048 |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | mpm_netware |
La directive MaxThreads définit
+ le nombre maximum de threads esclaves que l'on désire autoriser. La
+ valeur par défaut correspondant à la valeur codée en dur à la
+ compilation, la valeur de cette directive ne peut donc qu'être
+ diminuée, comme dans l'exemple suivant :
+ MaxThreads 512
+
Serveur HTTP Apache Version 2.4
+| Description: | Module multi-processus optimisé pour Windows +NT. |
|---|---|
| Statut: | MPM |
| Identificateur de Module: | mpm_winnt_module |
| Fichier Source: | mpm_winnt.c |
Ce module multi-processus (MPM) est le module par défaut pour les + systèmes d'exploitation de style Windows NT. Il consiste en un + processus de contrôle unique qui lance un processus enfant unique, + ce dernier créant à son tour des threads pour traiter les + requêtes.
+ +La directive ThreadsPerChild définit le
+ nombre maximal de connexions clientes simultanées.
Ce MPM utilise par défaut les APIs Windows avancées pour accepter + les nouvelles connexions des clients. Avec certaines configurations, + des produits tiers peuvent interférer avec cette implémentation, et + provoquer l'enregistrement des messages suivants dans les journaux + du serveur :
+ +
+ Child: Encountered too many AcceptEx faults accepting client connections.
+ winnt_mpm: falling back to 'AcceptFilter none'.
+
Le MPM se rabat sur une implémentation plus sûre, mais certaines
+ requêtes n'ont pas été traitées correctement. Pour éviter cette
+ erreur, définissez la directive AcceptFilter à none.
AcceptFilter http none +AcceptFilter https none+ + +
Avec les versions 2.0 et 2.2 d'Apache httpd, c'est la directive
+ Win32DisableAcceptEx qui était utilisée à cet
+ effet.
Le MPM WinNT diffère des autres MPMs Unix comme worker et event + à bien des égards :
+ +MaxConnectionsPerChild est
+ atteinte, les requêtes en cours de traitement par ce processus en
+ cours d'arrêt n'ont que TimeOut secondes pour s'exécuter avant
+ l'arrêt du processus. Les autres types de redémarrage ou arrêt ne
+ sont pas implémentés.MaxConnectionsPerChild, tout
+ changement survenu entre temps dans la configuration sera alors
+ pris en compte dans le processus enfant, et parent et enfant
+ utiliseront une configuration différente. Si des modifications
+ planifiées de la configuration ont été partiellement effectuées,
+ et si la configuration courante n'est pas interprétable, le
+ processus enfant de remplacement ne pourra pas démarrer, et le
+ serveur s'arrêtera. En conséquence, toute modification des
+ fichiers de configuration doit être accompagnée d'un redémarrage
+ du serveur.monitor et fatal_exception
+ ne sont pas encore implémentés.AcceptFilter est
+ implémentée par le MPM et fournit un type de contrôle différent
+ sur le traitement des nouvelles connexions (Voir la documentation
+ de la directive AcceptFilter
+ pour plus de détails). AcceptFilter CoreDumpDirectory Listen ListenBacklog MaxConnectionsPerChild MaxMemFree PidFile ReceiveBufferSize ScoreBoardFile SendBufferSize ThreadLimit ThreadsPerChild ThreadStackSizeServeur HTTP Apache Version 2.4
+| Description: | MPM hybride multi-processus, multi-thread pour +OS/2 |
|---|---|
| Statut: | MPM |
| Identificateur de Module: | mpm_mpmt_os2_module |
| Fichier Source: | mpmt_os2.c |
Le serveur se compose d'un processus principal parent, et d'un + petit nombre fixe de processus enfants.
+ +La tâche du processus parent consiste à gérer les processus
+ enfants, c'est à dire lancer ces processus de manière à ce
+ qu'il y en ait toujours un nombre égal à la valeur de la directive
+ StartServers pour traiter
+ les connexions.
Chaque processus enfant comporte un jeu de threads esclaves et un
+ thread maître qui accepte les connexions et les distribue aux
+ esclaves via une file de travail. Le jeu de threads esclaves est
+ dynamique et géré par un thread de maintenance de façon à ce que le
+ nombre de threads inactifs soit maintenu entre MinSpareThreads et MaxSpareThreads.
Group Listen ListenBacklog MaxConnectionsPerChild MaxSpareThreads MinSpareThreads PidFile ReceiveBufferSize SendBufferSize StartServers UserServeur HTTP Apache Version 2.4
+| Description: | Implémente un serveur web avec démarrage anticipé de +processus, sans thread |
|---|---|
| Statut: | MPM |
| Identificateur de Module: | mpm_prefork_module |
| Fichier Source: | prefork.c |
Ce module multi-processus (MPM) implémente un serveur web avec + démarrage anticipé de processus. Chaque processus du serveur peut + répondre aux requêtes entrantes, et un processus parent contrôle la + taille du jeu de processus enfants. Il est particulièrement indiqué pour les + sites qui ne doivent pas utiliser les threads afin de maintenir une + compatibilité avec certaines bibliothèques non sûres du point de vue + des threads. C'est également le MPM le plus approprié si l'on veut + isoler les requêtes les unes des autres, de façon à ce qu'un + problème concernant une requête n'affecte pas les autres.
+ +Ce MPM s'auto-contrôle de manière efficace, de sorte qu'il est
+ rarement nécessaire d'ajuster ses directives de configuration. Le
+ plus important est la définition de la directive MaxRequestWorkers ; sa valeur doit être
+ assez grande pour pouvoir traiter autant de requêtes simultanées que
+ vous pensez recevoir, mais assez petite pour conserver suffisamment
+ de mémoire RAM pour tous les processus.
CoreDumpDirectory EnableExceptionHook Group Listen ListenBacklog MaxConnectionsPerChild MaxMemFree MaxRequestWorkers MaxSpareServers MinSpareServers PidFile ReceiveBufferSize ScoreBoardFile SendBufferSize ServerLimit StartServers UserUn processus de contrôle unique a pour tâche de lancer les + processus enfants qui attendent les connexions et les traitent au + fur et à mesure qu'elles arrivent. Apache httpd essaie toujours de + maintenir plusieurs processus serveurs inactifs ou en + réserve, afin de pouvoir traiter les requêtes entrantes. De + cette façon, les clients n'ont pas besoin d'attendre le démarrage + d'un nouveau processus enfant pour que leurs requêtes puissent être + traitées.
+ +Les directives StartServers, MinSpareServers, MaxSpareServers et MaxRequestWorkers permettent de contrôler
+ la manière dont le processus parent crée les processus enfants pour
+ traiter les requêtes. En général, Apache httpd s'auto-contrôle de manière
+ efficace, de sorte que la plupart des sites peuvent conserver les
+ valeurs par défaut des directives. Les sites qui doivent traiter
+ plus de 256 requêtes simultanées doivent augmenter la valeur de
+ MaxRequestWorkers, alors que les
+ sites dont la ressource mémoire est limitée doivent la diminuer afin
+ d'éviter une hyperactivité du serveur (utilisation excessive de la
+ mémoire virtuelle sur disque). Vous trouverez plus d'informations à
+ propos du contrôle de la création de processus dans le document conseils en matière de
+ performances
Alors que le processus parent est en général démarré en tant que
+ root sous Unix afin de pouvoir se mettre à l'écoute sur le port 80, les
+ processus enfants sont lancés par Apache httpd sous un utilisateur avec
+ privilèges restreints. On peut contrôler les privilèges accordés aux
+ processus enfants d'Apache httpd à l'aide des directives User et Group. Les processus enfants doivent
+ être en mesure de lire tous les contenus destinés à être servis,
+ mais leurs privilèges doivent être aussi bas que possible.
La directive MaxConnectionsPerChild permet de
+ contrôler la fréquence à laquelle le serveur recycle ses processus
+ en arrêtant les plus anciens et en en lançant de nouveaux.
Ce module MPM utilise le mutex mpm-accept pour
+ sérialiser l'accès aux connexions entrantes lorsque peut se
+ présenter un problème d'afflux de requêtes (en général quand il y a
+ plusieurs sockets en écoute). Les aspects de l'implémentation de ce
+ mutex peuvent être configurés via la directive Mutex. Vous trouverez des informations
+ supplémentaires à propos de ce mutex dans la documentation à propos
+ des conseils en matière de
+ performances
| Description: | Nombre maximum de processus serveurs enfants +inactifs |
|---|---|
| Syntaxe: | MaxSpareServers nombre |
| Défaut: | MaxSpareServers 10 |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | prefork |
La directive MaxSpareServers permet de
+ définir le nombre maximum souhaité de processus serveurs enfants
+ inactifs. Un processus inactif est un processus qui ne
+ traite pas de requête. S'il y a plus de
+ MaxSpareServers processus inactifs, le
+ processus parent arrêtera les processus excédentaires.
La modification de ce paramètre n'est nécessaire que
+ dans le cas de sites très sollicités. Définir ce paramètre à une
+ valeur très grande est cependant dans la plupart des cas une
+ mauvaise idée. Si vous essayez d'affecter à ce paramètre une valeur
+ égale ou inférieure à la valeur de MinSpareServers, le serveur HTTP Apache
+ l'ajustera automatiquement à la valeur de
+ MinSpareServers + 1.
| Description: | Nombre minimum de processus serveurs enfants +inactifs |
|---|---|
| Syntaxe: | MinSpareServers nombre |
| Défaut: | MinSpareServers 5 |
| Contexte: | configuration globale |
| Statut: | MPM |
| Module: | prefork |
La directive MinSpareServers permet de
+ définir le nombre minimum désiré de processus serveurs enfants
+ inactifs. Un processus inactif est un processus qui ne
+ traite pas de requête. S'il y a moins de
+ MinSpareServers processus inactifs, le
+ processus parent va créer de nouveaux enfants de la manière suivante
+ : il en crée un, attend une seconde, il en crée deux, attend une
+ seconde, il en crée quatre, puis continue ainsi exponentiellement
+ jusu'à ce que son taux de création de processus enfants soit de 32
+ par seconde. Il ne s'arrête que lorsque le nombre de processus
+ enfants correspond à la définition de la directive
+ MinSpareServers.
La modification de ce paramètre n'est nécessaire que + dans le cas de sites très sollicités. Définir ce paramètre à une + valeur très grande est dans la plupart des cas une mauvaise + idée.
+ +Serveur HTTP Apache Version 2.4
+Le document de référence rapide des directives montre l'usage, + les valeurs par défaut, le statut, + et le contexte de chaque directive de configuration d'Apache. Pour plus + d'informations sur chacun de ces termes, voir le Dictionnaire des directives.
+ +La première colonne donne le nom de la directive et son usage. + Si la directive possède une valeur par défaut, elle est indiquée dans la + deuxième colonne. + Si la valeur par défaut est trop grande pour pouvoir être affichée, + elle sera tronquée et suivie d'un "+".
+ +La troisième colonne énumère les contextes dans + lesquels la directive est applicable, et la quatrième indique son statut en accord avec le + tableau des légendes ci-dessous.
+| A | B | C | D | E | F | G | H | I | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | +
|
+
|
| AcceptFilter protocole filtre +d'acceptation | s | C | |
| Permet d'optimiser la configuration d'une socket pour +l'écoute d'un protocole | |||
| AcceptPathInfo On|Off|Default | Default | svdh | C |
| Les ressources acceptent des informations sous forme d'un +nom de chemin en fin de requête. | |||
| AccessFileName nom-du-fichier +[nom-du-fichier] ... | .htaccess | sv | C |
| Nom du fichier de configuration distribué | |||
| Action type d'action script cgi +[virtual] | svdh | B | |
| Active un script CGI pour un gestionnaire ou un type de +contenu particulier | |||
| AddAlt texte fichier [fichier] ... | svdh | B | |
| Texte optionnel à afficher à la place d'un icône pour un +fichier en fonction de son nom | |||
| AddAltByEncoding texte codage MIME +[codage MIME] ... | svdh | B | |
| Texte optionnel à afficher à la place d'un icône pour un +fichier en fonction de son codage MIME | |||
| AddAltByType texte type MIME +[type MIME] ... | svdh | B | |
| Texte optionnel à afficher à la place d'un icône pour un +fichier en fonction de son type MIME | |||
| AddCharset jeu-car extension +[extension] ... | svdh | B | |
| Associe les extensions de noms de fichiers spécifiées au +jeu de caractères spécifié | |||
| AddDefaultCharset On|Off|jeu de caractères | Off | svdh | C |
Paramètre jeu de caractères par défaut à ajouter quand le
+type de contenu d'une réponse est text/plain ou
+text/html | |||
| AddDescription texte [fichier] ... | svdh | B | |
| Afficher la description d'un fichier | |||
| AddEncoding codage extension +[extension] ... | svdh | B | |
| Associe les extensions de noms de fichiers données au type +de codage spécifié | |||
| AddHandler nom-gestionnaire extension +[extension] ... | svdh | B | |
| Associe les extensions de noms de fichiers données au +gestionnaire spécifié | |||
| AddIcon icône nom [nom] +... | svdh | B | |
| Icône à afficher pour un fichier en fonction de son +nom | |||
| AddIconByEncoding icône codage MIME +[codage MIME] ... | svdh | B | |
| Icône à afficher à côté d'un fichier en fonction de son +codage MIME | |||
| AddIconByType icône type MIME +[type MIME] ... | svdh | B | |
| Icône à afficher à côté d'un fichier en fonction de son +type MIME | |||
| AddInputFilter filtre[;filtre...] +extension [extension] ... | svdh | B | |
| Associe les extensions de noms de fichiers aux +filtres spécifiés qui traiteront les requêtes clients | |||
| AddLanguage symbole-langue extension +[extension] ... | svdh | B | |
| Associe l'extension de nom de fichier donnée à la langue +spécifié | |||
| AddModuleInfo nom-module chaîne | sv | E | |
| Ajoute des données supplémentaires aux informations de +module affichées par le gestionnaire server-info | |||
| AddOutputFilter filtre[;filtre...] +extension [extension] ... | svdh | B | |
| Associe les extensions de noms de fichiers aux +filtres spécifiés qui traiteront les réponses en provenance du +serveur | |||
| AddOutputFilterByType filtre[;filtre...] +type_de_média [type_de_média] ... | svdh | B | |
| assigne un filtre en sortie pour un type de média +particulier | |||
| AddType type-médium extension +[extension] ... | svdh | B | |
| Associe les extensions de noms de fichiers au type de +contenu spécifié | |||
| Alias [chemin URL] +chemin fichier|chemin répertoire | sv | B | |
| Met en correspondance des URLs avec des chemins du système +de fichiers | |||
| AliasMatch regex +chemin fichier|chemin répertoire | sv | B | |
| Met en correspondance des URLs avec le système de fichiers +en faisant intervenir les expressions rationnelles | |||
| Allow from all|hôte|env=[!]variable +d'environnement +[hôte|env=[!]variable d'environnement] ... | dh | E | |
| Spécifie quels hôtes peuvent accéder à une certaine zone du +serveur | |||
| AllowCONNECT port[-port] +[port[-port]] ... | 443 563 | sv | E |
Ports autorisés à se CONNECTer à travers le
+mandataire | |||
| AllowEncodedSlashes On|Off|NoDecode | Off | sv | C |
| Détermine si les séparateurs de chemin encodés sont +autorisés à transiter dans les URLs tels quels | |||
| AllowMethods reset|HTTP-method +[HTTP-method]... | reset | d | X |
| Restreint l'accès aux méthodes HTTP spécifiées | |||
| AllowOverride All|None|type directive +[type directive] ... | None à partir de la + | d | C |
Types de directives autorisées dans les fichiers
+.htaccess | |||
| AllowOverrideList None|directive +[directive-type] ... | None | d | C |
Directives autorisées dans les fichiers .htaccess | |||
| Anonymous utilisateur [utilisateur] +... | dh | E | |
| Définit la liste des identifiants utilisateur autorisés à +accéder sans vérification du mot de passe | |||
| Anonymous_LogEmail On|Off | On | dh | E |
| Détermine si le mot de passe fourni sera enregistré dans le +journal des erreurs | |||
| Anonymous_MustGiveEmail On|Off | On | dh | E |
| Détermine si l'abscence de mot de passe est +autorisée | |||
| Anonymous_NoUserID On|Off | Off | dh | E |
| Détermine si le champ identifiant peut être +vide | |||
| Anonymous_VerifyEmail On|Off | Off | dh | E |
| Détermine s'il faut vérifier que le format de l'adresse +email fournie comme mot de passe est correct | |||
| AsyncRequestWorkerFactor facteur | s | M | |
| Limite le nombre de connexions simultanées par thread | |||
| AuthBasicAuthoritative On|Off | On | dh | B |
| Définit si les processus d'autorisation et +d'authentification peuvent être confiés à des modules de plus bas +niveau | |||
| AuthBasicFake off|username [password] | dh | B | |
| Authentification de base simulée à l'aide des nom +d'utilisateur et mot de passe fournis | |||
| AuthBasicProvider nom fournisseur +[nom fournisseur] ... | file | dh | B |
| Définit le(les) fournisseur(s) d'authentification pour +cette zone du site web | |||
| AuthBasicUseDigestAlgorithm MD5|Off | Off | dh | B |
| Vérifie les mots de passe auprès des fournisseurs +d'authentification à la manière de l'authentification de type Digest. + | |||
| AuthDBDUserPWQuery requête | d | E | |
| Requête SQL servant à vérifier le mot de passe d'un +utilisateur | |||
| AuthDBDUserRealmQuery requête | d | E | |
| Requête SQL servant à vérifier une empreinte de mot de +passe pour un utilisateur et un identifiant d'authentification. + | |||
| AuthDBMGroupFile chemin-fichier | dh | E | |
| Définit le nom du fichier de base de données contenant la +liste des groupes d'utilisateurs permettant de définir les +autorisations des utilisateurs | |||
| AuthDBMType default|SDBM|GDBM|NDBM|DB | default | dh | E |
| Définit le type de fichier de base de données utilisé pour +stocker les mots de passe | |||
| AuthDBMUserFile chemin-fichier | dh | E | |
| Définit le nom d'un fichier de base de données pour +l'authentification contenant la liste +des utilisateurs et de leurs mots de passe | |||
| AuthDigestAlgorithm MD5|MD5-sess | MD5 | dh | E |
| Sélectionne l'algorithme utilisé pour calculer les +condensés du défit et de sa réponse | |||
| AuthDigestDomain URI [URI] ... | dh | E | |
| Les URIs qui se trouvent dans le même espace de protection +concernant l'authentification à base de condensés | |||
| AuthDigestNonceLifetime secondes | 300 | dh | E |
| Durée de validité du nombre à valeur unique du +serveur (nonce) | |||
| AuthDigestProvider nom fournisseur +[nom fournisseur] ... | file | dh | E |
| Définit le(s) fournisseurs(s) d'authentification pour la +zone du site web concernée | |||
| AuthDigestQop none|auth|auth-int [auth|auth-int] | auth | dh | E |
| Détermine le niveau de protection fourni par +l'authentification à base de condensé | |||
| AuthDigestShmemSize taille | 1000 | s | E |
| La quantité de mémoire partagée à allouer afin de conserver +les informations à propos des clients | |||
| AuthFormAuthoritative On|Off | On | dh | B |
| Détermine si l'autorisation et l'authentification sont confiés à +des modules de plus bas niveau | |||
| AuthFormBody nom du champ | d | B | |
| Le nom du champ de formulaire contenant le corps de la +requête à effectuer en cas de connexion réussie | |||
| AuthFormDisableNoStore On|Off | Off | d | B |
| Désactive l'en-tête CacheControl no-store sur la page de +connexion | |||
| AuthFormFakeBasicAuth On|Off | Off | d | B |
| Simule une en-tête d'authentification de base | |||
| AuthFormLocation nom du champ | d | B | |
| Le nom du champ de formulaire qui contiendra l'URL vers +laquelle l'utilisateur sera redirigé en cas de connexion +réussie | |||
| AuthFormLoginRequiredLocation url | d | B | |
| L'URL de la page vers laquelle on doit être redirigé si une +authentification est requise | |||
| AuthFormLoginSuccessLocation url | d | B | |
| L'URL de la page vers laquelle on doit être redirigé en cas +de connexion réussie | |||
| AuthFormLogoutLocation uri | d | B | |
| L'URL vers laquelle un utilisateur devra être redirigé +après s'être déconnecté | |||
| AuthFormMethod nom du champ | d | B | |
| Le nom du champ de formulaire contenant la méthode de la +requête à effectuer en cas de connexion réussie | |||
| AuthFormMimetype nom du champ | d | B | |
| Le nom du champ de formulaire contenant le type MIME du +corps de la requête à effectuer en cas de connexion +réussie | |||
| AuthFormPassword nom du champ | d | B | |
| Le nom du champ de formulaire qui contient le mot de passe +de connexion | |||
| AuthFormProvider nom fournisseur +[nom fournisseur] ... | file | dh | B |
| Définit le(s) fournisseur(s) d'authentification pour la +zone concernée | |||
| AuthFormSitePassphrase secret | d | B | |
| Court-circuite l'authentification pour les sites à fort +trafic | |||
| AuthFormSize taille | d | B | |
| La taille maximale en octets du formulaire dont seront +extraites les informations de connexion | |||
| AuthFormUsername nom du champ | d | B | |
| Le nom du champ de formulaire qui contient le nom de +connexion | |||
| AuthGroupFile chemin-fichier | dh | B | |
| Définit le nom d'un fichier texte contenant la liste des +groupes d'utilisateurs permettant de définir les autorisations des +utilisateurs | |||
| AuthLDAPAuthorizePrefix préfixe | AUTHORIZE_ | dh | E |
| Spécifie le préfixe ajouté aux variables d'environnement +durant la phase d'autorisation | |||
| AuthLDAPBindAuthoritative off|on | on | dh | E |
| Détermine si l'on doit utiliser d'autres fournisseurs +d'authentification lorsque le serveur ne peut pas valider les données +d'authentification de l'utilisateur, alors que ce dernier possède un +DN. | |||
| AuthLDAPBindDN dn | dh | E | |
| Un DN optionnel pour se connecter au serveur +LDAP | |||
| AuthLDAPBindPassword mot-de-passe | dh | E | |
| Mot de passe à utiliser en conjonction avec le DN de +connexion | |||
| AuthLDAPCharsetConfig chemin-fichier | s | E | |
| Chemin du fichier de configuration de la correspondance +langage/jeu de caractères | |||
| AuthLDAPCompareAsUser on|off | off | dh | E |
| Utilisation des données d'authentification de l'utilisateur +pour effectuer les comparaisons pour l'attribution des autorisations | |||
| AuthLDAPCompareDNOnServer on|off | on | dh | E |
| Utilise le serveur LDAP pour comparer les DNs | |||
| AuthLDAPDereferenceAliases never|searching|finding|always | always | dh | E |
| À quel moment le module va déréférencer les +alias | |||
| AuthLDAPGroupAttribute attribut | member uniquemember + | dh | E |
| L'attribut LDAP utilisé pour vérifier l'appartenance d'un +utilisateur à un groupe. | |||
| AuthLDAPGroupAttributeIsDN on|off | on | dh | E |
| Utilise le DN de l'utilisateur pour vérifier son +appartenance à un groupe | |||
| AuthLDAPInitialBindAsUser off|on | off | dh | E |
| Détermine si le serveur effectue la recherche initiale du +DN en utilisant le nom propre de l'utilisateur pour l'authentification +de base +et non de manière anonyme, ou en utilisant des données d'authentification +codées en dur pour le serveur | |||
| AuthLDAPInitialBindPattern regex substitution | (.*) $1 (nom de l'u + | dh | E |
| Spécifie la modification a apporter au nom d'utilisateur +pour l'authentification de base lors de l'authentification auprès du +serveur LDAP pour effectuer une recherche de DN | |||
| AuthLDAPMaxSubGroupDepth Nombre | 10 | dh | E |
| Spécifie la profondeur d'imbrication des sous-groupes +maximale prise en compte avant l'abandon de la recherche de +l'utilisateur. | |||
| AuthLDAPRemoteUserAttribute uid | dh | E | |
| Spécifie l'attribut dont la valeur renvoyée au cours de la +requête de l'utilisateur sera utilisée pour définir la variable +d'environnement REMOTE_USER | |||
| AuthLDAPRemoteUserIsDN on|off | off | dh | E |
| Utilise le DN de l'utilisateur pour définir la variable +d'environnement REMOTE_USER | |||
| AuthLDAPSearchAsUser on|off | off | dh | E |
| Utilise les données d'authentification de l'utilisateur +pour la recherche des autorisations | |||
| AuthLDAPSubGroupAttribute attribut | dh | E | |
| Spécifie les noms d'attribut, un par directive, utilisés +pour différencier les membres du groupe courant qui sont eux-mêmes des +groupes. | |||
| AuthLDAPSubGroupClass ObjectClass-LDAP | groupOfNames groupO + | dh | E |
| Spécifie quelles valeurs d'objectClass LDAP identifient les +objets de l'annuaire qui sont des groupes au cours du traitement des +sous-groupes. | |||
| AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS] | dh | E | |
| L'URL permettant de spécifier les paramètres de la +recherche LDAP | |||
| AuthMerging Off | And | Or | Off | dh | B |
| Définit la manière dont chaque logique d'autorisation des +sections de configuration se combine avec celles des sections de +configuration précédentes. | |||
| AuthName domaine d'autorisation | dh | B | |
| L'identifiant de l'autorisation à utiliser avec +l'authentification HTTP | |||
| AuthnCacheContext directory|server|chaîne-personnalisée | d | B | |
| Spécifie une chaîne de contexte à utiliser dans la clé du +cache | |||
| AuthnCacheEnable | s | B | |
| Active la mise en cache de l'authentification en tout +endroit | |||
| AuthnCacheProvideFor fournisseur-authn [...] | dh | B | |
| Spécifie le fournisseur pour lequel on veut effectuer une +mise en cache | |||
| AuthnCacheSOCache nom-fournisseur[:arguments-fournisseur] | s | B | |
| Sélectionne le fournisseur socache d'arrière-plan à +utiliser | |||
| AuthnCacheTimeout durée-de-vie (secondes) | dh | B | |
| Définit une durée de vie pour les entrées du cache | |||
| <AuthnProviderAlias alias-fournisseur> +... </AuthnProviderAlias> | s | B | |
| Regroupe un ensemble de directives qui constituent une +extension d'un fournisseur d'authentification de base et lui attribue +l'alias spécifié | |||
AuthnzFcgiCheckAuthnProvider provider-name|None
+option ... | d | E | |
| Permet à une application FastCGI de gérer l'accroche +d'authentification check_authn. | |||
| AuthnzFcgiDefineProvider type provider-name +backend-address | s | E | |
| Définit une application FastCGI en tant que fournisseur +d'authentification et/ou autorisation | |||
| AuthType None|Basic|Digest|Form | dh | B | |
| Type d'authentification utilisateur | |||
| AuthUserFile chemin-fichier | dh | B | |
| Définit le nom d'un fichier texte pour l'authentification +contenant la liste des utilisateurs et de leurs mots de +passe | |||
| AuthzDBDLoginToReferer On|Off | Off | d | E |
Définit si le client doit être redirigé vers la page
+d'origine en cas de connexion ou de déconnexion réussie si un en-tête
+de requête Referer est présent | |||
| AuthzDBDQuery requête | d | E | |
| Définit la requête SQL pour l'opération requise | |||
| AuthzDBDRedirectQuery requête | d | E | |
| Définit une requête pour rechercher une page vers laquelle +rediriger l'utilisateur après une connexion réussie | |||
| AuthzDBMType default|SDBM|GDBM|NDBM|DB | default | dh | E |
| Définit le type de fichier de base de données contenant +la liste des groupes d'utilisateurs | |||
| <AuthzProviderAlias fournisseur-de-base Alias +Paramètres-Require> +... </AuthzProviderAlias> + | s | B | |
| Regroupe des directives représentant une extension d'un +fournisseur d'autorisation de base qui pourra être référencée à l'aide +de l'alias spécifié | |||
| AuthzSendForbiddenOnFailure On|Off | Off | dh | B |
| Envoie '403 FORBIDDEN' au lieu de '401 UNAUTHORIZED' si +l'authentification réussit et si l'autorisation a été refusée. + | |||
| BalancerGrowth # | 5 | sv | E |
| Nombre de membres supplémentaires pouvant être ajoutés +après la configuration initiale | |||
| BalancerInherit On|Off | On | sv | E |
| Héritage des membres du groupes de répartition de + charge du mandataire définis au niveau du serveur principal | |||
| BalancerMember [balancerurl] url [clé=valeur [clé=valeur ...]] | d | E | |
| Ajoute un membre à un groupe de répartition de +charge | |||
| BalancerPersist On|Off | Off | sv | E |
| Tente de conserver les changements effectués par le + gestionnaire de répartition de charge après un redémarrage du + serveur. | |||
| BrotliAlterETag AddSuffix|NoChange|Remove | AddSuffix | sv | E |
| Comment l'en-tête de réponse ETag doit être modifié au cours de la +compression | |||
| BrotliCompressionMaxInputBlock value | sv | E | |
| Taille maximale du bloc de données en entrée | |||
| BrotliCompressionQuality value | 5 | sv | E |
| Qualité de la compression | |||
| BrotliCompressionWindow value | 18 | sv | E |
| Taille de la fenêtre de compression glissante brotli | |||
| BrotliFilterNote [type] notename | sv | E | |
| Enregistre le taux de compression dans une note à des fins de +journalisation | |||
| BrowserMatch regex [!]env-variable[=valeur] +[[!]env-variable[=valeur]] ... | svdh | B | |
| Définit des variables d'environnement en fonction du +contenu de l'en-tête HTTP User-Agent | |||
| BrowserMatchNoCase regex [!]env-variable[=valeur] + [[!]env-variable[=valeur]] ... | svdh | B | |
| Définit des variables d'environnement en fonction du +contenu de l'en-tête HTTP User-Agent sans tenir compte de la +casse | |||
| BufferedLogs On|Off | Off | s | B |
| Enregistre les entrées du journal dans un tampon en mémoire +avant de les écrire sur disque | |||
| BufferSize entier | 131072 | svdh | E |
| Taille maximale en octets du filtre par tampon | |||
| CacheDefaultExpire secondes | 3600 (une heure) | svdh | E |
| La durée par défaut de mise en cache d'un document +lorsqu'aucune date d'expiration n'a été spécifiée. | |||
| CacheDetailHeader on|off | off | svdh | E |
| Ajoute un en-tête X-Cache-Detail à la réponse. | |||
| CacheDirLength longueur | 2 | sv | E |
| Le nombre de caractères des noms des +sous-répertoires | |||
| CacheDirLevels niveaux | 2 | sv | E |
| Le nombre de niveaux de sous-répertoires que comportera le +cache. | |||
| CacheDisable chaîne-url | on | svdh | E | |
| Désactive la mise en cache des URLs +spécifiées | |||
| CacheEnable type de cache [chaîne +URL] | svd | E | |
| Active la mise en cache des URLs spécifiées en utilisant le +gestionnaire de stockage précisé | |||
| CacheFile chemin fichier [chemin fichier] ... | s | X | |
| Met en cache une liste de gestionnaires de fichiers au +démarrage | |||
| CacheHeader on|off | off | svdh | E |
| Ajoute un en-tête X-Cache à la réponse. | |||
| CacheIgnoreCacheControl On|Off | Off | sv | E |
| Ignore les en-têtes de requête enjoignant de ne pas servir +le contenu au client depuis le cache | |||
| CacheIgnoreHeaders en-tête [en-tête] ... | None | sv | E |
| Ne pas stocker le(s) en-tête(s) spécifié(s) dans le cache. + | |||
| CacheIgnoreNoLastMod On|Off | Off | svdh | E |
| Ignore le fait qu'une réponse ne possède pas d'en-tête Last +Modified. | |||
| CacheIgnoreQueryString On|Off | Off | sv | E |
| Ignore la chaîne de paramètres lors de la mise en +cache | |||
| CacheIgnoreURLSessionIdentifiers identifiant +[identifiant] ... | None | sv | E |
| Ignore les identifiants de session définis encodés dans +l'URL lors de la mise en cache + | |||
| CacheKeyBaseURL URL | http://example.com | sv | E |
| Remplace l'URL de base des clés du cache mandatées en +inverse | |||
| CacheLastModifiedFactor flottant | 0.1 | svdh | E |
| Le facteur utilisé pour générer une date d'expiration en +fonction de la date de dernière modification. | |||
| CacheLock on|off | off | sv | E |
| Active la protection contre les tempêtes de requêtes. | |||
| CacheLockMaxAge entier | 5 | sv | E |
| Définit la durée de vie maximale d'un verrou de cache. | |||
| CacheLockPath répertoire | /tmp/mod_cache-lock + | sv | E |
| Définit le répertoire des verrous. | |||
| CacheMaxExpire secondes | 86400 (une journée) + | svdh | E |
| La durée maximale en secondes de mise en cache d'un +document | |||
| CacheMaxFileSize octets | 1000000 | svdh | E |
| >La taille maximale (en octets) d'un document pour pouvoir +être stocké dans le cache | |||
| CacheMinExpire secondes | 0 | svdh | E |
| La durée minimale en secondes de mise en cache d'un +document | |||
| CacheMinFileSize octets | 1 | svdh | E |
| La taille minimale (en octets) d'un document pour pouvoir +être stocké dans le cache | |||
| CacheNegotiatedDocs On|Off | Off | sv | B |
| Permet la mise en cache au niveau des serveurs mandataires +des documents dont le contenu a été négocié | |||
| CacheQuickHandler on|off | on | sv | E |
| Exécute le cache à partir d'un gestionnaire rapide. | |||
| CacheReadSize octets | 0 | svdh | E |
| La quantité minimale (en octets) de données à lire et à +mettre en cache avant de les envoyer au client | |||
| CacheReadTime millisecondes | 0 | svdh | E |
| Le temps minimum (en millisecondes) qui doit s'écouler +avant d'envoyer les données au client | |||
| CacheRoot répertoire | sv | E | |
| La racine du répertoire dans lequel les fichiers du cache +seront stockés | |||
| CacheSocache type[:args] | sv | E | |
| Implémentation du cache d'objets partagés à utiliser | |||
| CacheSocacheMaxSize octets | 102400 | svdh | E |
| La taille maximale d'une entrée pouvant être placée dans le +cache | |||
| CacheSocacheMaxTime secondes | 86400 | svdh | E |
| La durée maximale de stockage d'un document dans le cache +avant péremption | |||
| CacheSocacheMinTime seconds | 600 | svdh | E |
| La durée minimale de stockage d'un document dans le cache | |||
| CacheSocacheReadSize octets | 0 | svdh | E |
| La quantité minimale de données du document à lire et +mettre en cache avant envoi au client | |||
| CacheSocacheReadTime millisecondes | 0 | svdh | E |
| La durée minimale de lecture avant l'envoi des données | |||
| CacheStaleOnError on|off | on | svdh | E |
| Sert du contenu non à jour à la place de réponses 5xx. | |||
| CacheStoreExpired On|Off | Off | svdh | E |
| Tente de mettre en cache les réponses que le serveur +considère comme arrivées à expiration | |||
| CacheStoreNoStore On|Off | Off | svdh | E |
| Tente de mettre en cache les requêtes ou réponses dont +l'entête Cache-Control: a pour valeur no-store. | |||
| CacheStorePrivate On|Off | Off | svdh | E |
| Tente de mettre en cache des réponses que le serveur a +marquées comme privées | |||
| CGIDScriptTimeout time[s|ms] | svdh | B | |
| Durée maximale d'attente de la prochaine sortie du +programme CGI | |||
| CGIMapExtension chemin CGI .extension | dh | C | |
| Technique permettant de localiser l'interpréteur des +scripts CGI | |||
| CGIPassAuth On|Off | Off | dh | C |
| Active la transmission d'en-têtes d'autorisation HTTP aux scripts en +tant que variables CGI | |||
| CGIVar variable rule | dh | C | |
| Contrôle la manière dont certaines variables CGI sont définies | |||
| CharsetDefault jeu de caractères | svdh | E | |
| Jeu de caractère vers lequel la traduction doit +s'effectuer | |||
| CharsetOptions option [option] ... | ImplicitAdd | svdh | E |
| Précise les détails de la traduction du jeu de +caractères | |||
| CharsetSourceEnc jeu de caractères | svdh | E | |
| Jeu de caractères source des fichiers | |||
| CheckCaseOnly on|off | Off | svdh | E |
| Limite l'action du module aux corrections de +majuscules | |||
| CheckSpelling on|off | Off | svdh | E |
| Active le module de correction | |||
| ChrootDir chemin-répertoire | s | B | |
| Répertoire dans lequel Apache doit se positionner au +démarrage après avoir effectué un chroot(8). | |||
| ContentDigest On|Off | Off | svdh | C |
Active la génération d'un en-tête Content-MD5
+dans la réponse HTTP | |||
| CookieDomain domaine | svdh | E | |
| Le domaine auquel le cookie traceur +s'applique | |||
| CookieExpires durée | svdh | E | |
| Durée avant expiration du cookie traceur | |||
| CookieName symbole | Apache | svdh | E |
| Nom du cookie traceur | |||
| CookieStyle + Netscape|Cookie|Cookie2|RFC2109|RFC2965 | Netscape | svdh | E |
| Format du champ d'en-tête cookie | |||
| CookieTracking on|off | off | svdh | E |
| Active le cookie traceur | |||
| CoreDumpDirectory répertoire | s | M | |
| Le répertoire dans lequel le serveur HTTP Apache va tenter de se +positionner avant d'effectuer un vidage mémoire | |||
| CustomLog fichier|pipe +format|alias +[env=[!]variable-environnement| +expr=expression] | sv | B | |
| Définit le nom et le format du fichier +journal | |||
| Dav On|Off|nom fournisseur | Off | d | E |
| Active les méthodes HTTP WebDAV | |||
| DavDepthInfinity on|off | off | svd | E |
| Autorise les requêtes PROPFIND avec en-tête Depth: +Infinity | |||
| DavGenericLockDB chemin fichier | svd | E | |
| Chemin de la base de données des verrous DAV | |||
| DavLockDB chemin fichier | sv | E | |
| Chemin de la base de données des verrous DAV | |||
| DavMinTimeout secondes | 0 | svd | E |
| Durée minimale pendant laquelle le serveur maintient un +verrou sur une ressource DAV | |||
| DBDExptime durée en secondes | 300 | sv | E |
| Durée de vie des connexions inactives | |||
| DBDInitSQL "instruction SQL" | sv | E | |
| Exécute une instruction SQL après connexion à une base de +données | |||
| DBDKeep nombre | 2 | sv | E |
| Nombre maximum de connexions maintenues | |||
| DBDMax nombre | 10 | sv | E |
| Nombre maximum de connexions | |||
| DBDMin nombre | 1 | sv | E |
| Nombre minimum de connexions | |||
| DBDParams +param1=valeur1[,param2=valeur2] | sv | E | |
| Paramètres de la connexion à la base de +données | |||
| DBDPersist On|Off | sv | E | |
| Utiliser ou non des connexions persistentes | |||
| DBDPrepareSQL "requête SQL" étiquette | sv | E | |
| Définit une requête SQL préparée | |||
| DBDriver nom | sv | E | |
| Spécifie un pilote SQL | |||
| DefaultIcon chemin URL | svdh | B | |
| Icône à afficher par défaut lorsqu'aucun icône spécifique +n'est précisé | |||
| DefaultLanguage symbole-langue | svdh | B | |
| Définit un symbole de langue par défaut à affecter au champ +d'en-tête Content-Language pour toutes les ressources dans le contexte +courant auxquelles aucun symbole de langue n'a été +associé. | |||
| DefaultRuntimeDir chemin-répertoire | DEFAULT_REL_RUNTIME + | s | C |
| Répertoire de base des fichiers créés au cours de l'exécution du serveur | |||
| DefaultType type média|none | none | svdh | C |
Les seuls effets de cette directive sont des émissions
+d'avertissements si sa valeur est différente de none. Dans
+les versions précédentes, DefaultType permettait de spécifier un type de
+média à assigner par défaut au contenu d'une réponse pour lequel aucun
+autre type de média n'avait été trouvé.
+ | |||
| Define nom-paramètre [valeur-paramètre] | svd | C | |
| Permet de définir une variable | |||
| DeflateBufferSize valeur | 8096 | sv | E |
| Taille du fragment que zlib devra comprimer en une seule +fois | |||
| DeflateCompressionLevel valeur | sv | E | |
| Le niveau de compression que nous appliquons à la +sortie | |||
| DeflateFilterNote [type] nom de la note | sv | E | |
| Enregistre le taux de compression sous la forme d'une note +à des fins de journalisation | |||
| DeflateInflateLimitRequestBodyvalue | svdh | E | |
| Taille maximale des corps de requête décompressés | |||
| DeflateInflateRatioBurst value | svdh | E | |
| Nombre maximal de fois que le ratio de décompression d'un +corps de requête peut être dépassé | |||
| DeflateInflateRatioLimit value | svdh | E | |
| Ratio de décompression maximum pour les corps de requêtes | |||
| DeflateMemLevel valeur | 9 | sv | E |
| La quantité de mémoire utilisable par zlib pour la +compression | |||
| DeflateWindowSize valeur | 15 | sv | E |
| Taille de la fenêtre de compression zlib | |||
| Deny from all|hôte|env=[!]variable +d'environnement +[hôte|env=[!]variable d'environnement] ... | dh | E | |
| Définit quels hôtes ne sont pas autorisés à accéder au +serveur | |||
| <Directory chemin répertoire> +... </Directory> | sv | C | |
| Regroupe un ensemble de directives qui ne s'appliquent +qu'au répertoire concerné du système de fichiers, à ses +sous-répertoires, et à leur contenu. | |||
| DirectoryCheckHandler On|Off | Off | svdh | B |
| Définit la réponse de ce module lorsqu'un autre +gestionnaire est utilisé | |||
| DirectoryIndex + disabled | url locale [url locale] ... | index.html | svdh | B |
| Liste des fichiers ressources à rechercher lorsque le +client envoie une requête pour un répertoire | |||
| DirectoryIndexRedirect on | off | permanent | temp | seeother | +3xx-code + | off | svdh | B |
| Définit une redirection externe pour les index de +répertoires. + | |||
| <DirectoryMatch regex> +... </DirectoryMatch> | sv | C | |
| Regroupe des directives qui s'appliquent au contenu de répertoires +du système de fichiers correspondant à une expression rationnelle | |||
| DirectorySlash On|Off | On | svdh | B |
| Activation/Désactivation de la redirection "slash de +fin" | |||
| DocumentRoot chemin répertoire | "/usr/local/apache/ + | sv | C |
| Racine principale de l'arborescence des documents visible +depuis Internet | |||
| DTracePrivileges On|Off | Off | s | X |
| Détermine si les privilèges requis par dtrace sont +activés. | |||
| DumpIOInput On|Off | Off | s | E |
| Enregistre toutes les entrées dans le journal des +erreurs | |||
| DumpIOOutput On|Off | Off | s | E |
| Enregistre toutes les sorties dans le journal des +erreurs | |||
| <Else> ... </Else> | svdh | C | |
Contient des directives qui ne s'appliquent que si la
+condition correspondant à la section <If> ou <ElseIf> précédente n'est pas satisfaite par la
+requête à l'exécution | |||
| <ElseIf expression> ... </ElseIf> | svdh | C | |
Contient des directives qui ne s'appliquent que si la
+condition correspondante est satisfaite par une requête à l'exécution,
+alors que la condition correspondant à la section <If> ou <ElseIf> précédente ne l'était pas. | |||
| EnableExceptionHook On|Off | Off | s | M |
| Active un hook ("point d'accrochage logiciel") qui exécute des +gestionnaires d'exception après un crash | |||
| EnableMMAP On|Off | On | svdh | C |
| Utilise la projection en mémoire (Memory-Mapping) pour +lire les fichiers pendant qu'ils sont servis | |||
| EnableSendfile On|Off | Off | svdh | C |
| Utilise le support sendfile du noyau pour servir les +fichiers aux clients | |||
| Error message | svdh | C | |
| Interrompt la lecture de la configuration avec un message +d'erreur personnalisé | |||
| ErrorDocument code erreur document | svdh | C | |
| Document que le serveur renvoie au client en cas +d'erreur | |||
| ErrorLog file-path|syslog[:[facility][:tag]] | logs/error_log (Uni + | sv | C |
| Définition du chemin du journal des erreurs | |||
| ErrorLogFormat [connection|request] format | sv | C | |
| Spécification du format des entrées du journal des erreurs | |||
| Example | svdh | X | |
| Directive de démonstration pour illustrer l'API des modules +Apache | |||
| ExpiresActive On|Off | Off | svdh | E |
Active la génération d'en-têtes
+Expires | |||
| ExpiresByType type MIME +<code>secondes | svdh | E | |
Définition de la valeur de l'en-tête Expires
+en fonction du type MIME | |||
| ExpiresDefault <code>secondes | svdh | E | |
| Mode de calcul par défaut de la date +d'expiration | |||
| ExtendedStatus On|Off | Off | s | C |
| Extrait des informations d'état étendues pour chaque +requête | |||
| ExtFilterDefine nom_filtre paramètres | s | E | |
| Définit un filtre externe | |||
| ExtFilterOptions option [option] ... | NoLogStderr | d | E |
Configure les options de
+mod_ext_filter | |||
| FallbackResource disabled | url-locale | svdh | B | |
| Définit une URL par défaut pour les requêtes qui ne ciblent +aucun fichier | |||
| FileETag composant ... | MTime Size | svdh | C |
| Caractéristiques de fichier utilisées lors de la génération +de l'en-tête de réponse HTTP ETag pour les fichiers statiques | |||
| <Files nom fichier> ... </Files> | svdh | C | |
| Contient des directives qui s'appliquent aux fichiers +précisés | |||
| <FilesMatch expression rationnelle> ... +</FilesMatch> | svdh | C | |
| Contient des directives qui s'appliquent à des fichiers +spécifiés sous la forme d'expressions rationnelles | |||
| FilterChain [+=-@!]nom_filtre ... | svdh | B | |
| Configure la chaîne de filtrage | |||
| FilterDeclare nom_filtre [type] | svdh | B | |
| Déclare un filtre intelligent | |||
| FilterProtocol nom_filtre [nom_fournisseur] + drapeaux_protocole | svdh | B | |
| Vérifie le respect du protocole HTTP | |||
| FilterProvider nom_filtre nom_fournisseur + expression | svdh | B | |
| Enregistre un filtre de contenu | |||
| FilterTrace nom_filtre niveau | svd | B | |
Obtention d'informations de débogage/diagnostique en
+provenance de mod_filter | |||
| ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback] | Prefer | svdh | B |
| Action à entreprendre si un document acceptable unique +n'est pas trouvé | |||
| ForceType type médium|None | dh | C | |
| Force le type de médium spécifié dans le champ d'en-tête +HTTP Content-Type pour les fichiers correspondants | |||
| ForensicLog nom-fichier|pipe | sv | E | |
| Définit le nom de fichier du journal légal | |||
| GlobalLogfile|pipe +format|nickname +[env=[!]environment-variable| +expr=expression] | s | B | |
| Définit le nom et le format du fichier journal | |||
| GprofDir /tmp/gprof/|/tmp/gprof/% | sv | C | |
| Répertoire dans lequel écrire les données de profiling +gmon.out. | |||
| GracefulShutdownTimeout seconds | 0 | s | M |
| Spécifie le délai maximum après lequel le serveur va +s'arrêter dans le cas d'un arrêt "en douceur" | |||
| Group groupe unix | #-1 | s | B |
| Groupe sous lequel le serveur va traiter les +requêtes | |||
| H2CopyFiles on|off | off | svdh | E |
| Contrôle la gestion des fichiers dans les réponses | |||
| H2Direct on|off | on pour h2c, off po + | sv | E |
| Activation du protocole H2 Direct | |||
| H2EarlyHints on|off | off | sv | E |
| Contrôle l'envoi de codes d'état 103 | |||
| H2MaxSessionStreams n | 100 | sv | E |
| Nombre maximal de flux actifs par session HTTP/2. | |||
| H2MaxWorkerIdleSeconds n | 600 | s | E |
| Nombre maximal de secondes pendant lequel une unité de + traitement h2 pourra rester inactive sans être arrêtée. | |||
| H2MaxWorkers n | s | E | |
| Nombre maximal de threads à utiliser pour chaque processus + enfant. | |||
| H2MinWorkers n | s | E | |
| Nombre minimal de threads à utiliser pour chaque processus + enfant. | |||
| H2ModernTLSOnly on|off | on | sv | E |
| Impose les connexions HTTP/2 en mode "TLS moderne" + seulement | |||
| H2Push on|off | on | sv | E |
| Activation/désactivation du server push H2 | |||
| H2PushDiarySize n | 256 | sv | E |
| Taille du journal des Pushes H2 | |||
| H2PushPriority mime-type [after|before|interleaved] [weight] | * After 16 | sv | E |
| Priorité des pushes H2 | |||
| H2PushResource [add] path [critical] | svdh | E | |
| Déclare des ressources à proposer ("pusher") au client | |||
| H2SerializeHeaders on|off | off | sv | E |
| Active/désactive la sérialisation du traitement des + requêtes/réponses | |||
| H2StreamMaxMemSize bytes | 65536 | sv | E |
| Quantité maximale de données en sortie mises en tampon par + flux. | |||
| H2TLSCoolDownSecs seconds | 1 | sv | E |
| - | |||
| H2TLSWarmUpSize amount | 1048576 | sv | E |
| - | |||
| H2Upgrade on|off | on pour h2c, off po + | sv | E |
| Activation/Désactivation du protocole de mise à jour H2 | |||
| H2WindowSize bytes | 65535 | sv | E |
| Taille maximale des paquets de données pour les transmissions client + vers serveur. | |||
| Header [condition] add|append|echo|edit|edit*|merge|set|setifempty|unset|note +en-tête [[expr=]valeur +[remplacement] +[early|env=[!]variable|expr=expression]] + | svdh | E | |
| Configure les en-têtes d'une réponse HTTP | |||
| HeaderName nom fichier | svdh | B | |
| Nom du fichier qui sera inséré au début de la page +contenant l'index | |||
| HeartbeatAddress addr:port | s | X | |
| Adresse multicast à laquelle envoyer les requêtes +heartbeat | |||
| HeartbeatListen addr:port | s | X | |
| Adresse multicast d'écoute des requêtes entrantes heartbeat | |||
| HeartbeatMaxServers nombre-de-serveurs | 10 | s | X |
| Spécifie le nombre maximal de serveurs qui pourront envoyer +des requêtes heartbeat à ce serveur. | |||
| HeartbeatStorage chemin fichier | logs/hb.dat | s | X |
| Chemin vers le stockage des données heartbeat | |||
| HeartbeatStorage chemin-fichier | logs/hb.dat | s | X |
| Indique le chemin permettant de lire les données +heartbeat | |||
| HostnameLookups On|Off|Double | Off | svd | C |
| Active la recherche DNS sur les adresses IP des +clients | |||
| HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods] + [Allow0.9|Require1.0] | Strict LenientMetho + | sv | C |
| Modifie les contraintes sur les messages des requêtes HTTP | |||
| IdentityCheck On|Off | Off | svd | E |
| Active la journalisation de l'identité RFC 1413 de +l'utilisateur distant | |||
| IdentityCheckTimeout secondes | 30 | svd | E |
| Détermine le délai d'attente pour les requêtes +ident | |||
| <If expression> ... </If> | svdh | C | |
| Contient des directives qui ne s'appliquent que si une +condition est satisfaite au cours du traitement d'une +requête | |||
| <IfDefine [!]paramètre> ... + </IfDefine> | svdh | C | |
| Contient des directives qui ne s'appliqueront que si un +test retourne "vrai" au démarrage du serveur | |||
| <IfDirective [!]directive-name> ... + </IfDirective> | svdh | C | |
| Regroupe des directives dont le traitement est conditionné par la +présence ou l'absence d'une directive particulière | |||
| <IfFile [!]filename> ... + </IfFile> | svdh | C | |
| Regroupe des directives qui ne seront traitées que si un fichier +existe au démarrage | |||
| <IfModule [!]fichier module|identificateur +module> ... </IfModule> | svdh | C | |
| Contient des directives qui ne s'appliquent qu'en fonction +de la présence ou de l'absence d'un module spécifique | |||
| <IfSection [!]section-name> ... + </IfSection> | svdh | C | |
| Regroupe des directives dont le traitement est conditionné par la +présence ou l'absence d'une section particulière | |||
| <IfVersion [[!]opérateur] version> ... +</IfVersion> | svdh | E | |
| Contient des portions de configuration dépendantes de la +version | |||
| ImapBase map|referer|URL | http://nom_serveur/ + | svdh | B |
Valeur par défaut de la directive base des
+fichiers imagemap | |||
| ImapDefault error|nocontent|map|referer|URL | nocontent | svdh | B |
| Action à entreprendre par défaut lorsqu'un fichier imagemap +est invoqué avec des coordonnées qui ne correspondent à aucune +cible | |||
| ImapMenu none|formatted|semiformatted|unformatted | formatted | svdh | B |
| Action à entreprendre si aucune coordonnée n'est fournie +lorsqu'on invoque un fichier imagemap | |||
| Include chemin-fichier|chemin-répertoire|wildcard | svd | C | |
| Inclut d'autres fichiers de configuration dans un des +fichiers de configuration du serveur | |||
| IncludeOptional +file-path|directory-path|wildcard | svd | C | |
| Inclusion de fichiers dans le fichier de configuration | |||
| IndexHeadInsert "marque ..." | svdh | B | |
| Insère du texte dans la section HEAD de la page +d'index. | |||
| IndexIgnore fichier [fichier] ... | "." | svdh | B |
| Ajouts à la liste des fichiers à cacher lors de l'affichage +de l'index d'un répertoire | |||
| IndexIgnoreReset ON|OFF | svdh | B | |
| Vide la liste des fichiers à cacher lors de l'affichage du +contenu d'un répertoire | |||
| IndexOptions [+|-]option [[+|-]option] +... | svdh | B | |
| Diverses options de configuration pour l'indexation d'un +répertoire | |||
| IndexOrderDefault Ascending|Descending +Name|Date|Size|Description | Ascending Name | svdh | B |
| Définit l'ordre d'affichage par défaut d'un index de +répertoire | |||
| IndexStyleSheet chemin-url | svdh | B | |
| Ajoute une feuille de style CSS à l'index du +répertoire | |||
| InputSed commande-sed | dh | ||
Commande sed à exécuter pour le filtrage des données d'une
+requête (en général des données POST) | |||
| ISAPIAppendLogToErrors on|off | off | svdh | B |
Enregistrement des requêtes
+HSE_APPEND_LOG_PARAMETER de la part des extensions ISAPI
+dans le journal des erreurs | |||
| ISAPIAppendLogToQuery on|off | on | svdh | B |
Enregistre les requêtes
+HSE_APPEND_LOG_PARAMETER de la part des extensions ISAPI
+dans la partie arguments de la requête | |||
| ISAPICacheFile chemin-fichier +[chemin-fichier] +... | sv | B | |
| Fichiers .dll ISAPI devant être chargés au +démarrage | |||
| ISAPIFakeAsync on|off | off | svdh | B |
| Emulation du support des entrées/sorties asynchrones pour +les appels ISAPI | |||
| ISAPILogNotSupported on|off | off | svdh | B |
| Journalisation des demandes de fonctionnalités non +supportées de la part des extensions ISAPI | |||
| ISAPIReadAheadBuffer taille | 49152 | svdh | B |
| Taille du tampon de lecture anticipée envoyé aux extensions +ISAPI | |||
| KeepAlive On|Off | On | sv | C |
| Active les connexions HTTP persistantes | |||
| KeepAliveTimeout nombre[ms] | 5 | sv | C |
| Durée pendant laquelle le serveur va attendre une requête +avant de fermer une connexion persistante | |||
| KeptBodySize taille maximale en octets | 0 | d | B |
| Conserve le corps de la requête à concurrence de la taille +maximale spécifiée, pour une utilisation éventuelle par des filtres +comme mod_include. | |||
| LanguagePriority langage-MIME [langage-MIME] +... | svdh | B | |
| L'ordre de priorité des variantes de langages pour les +cas où le client n'a pas formulé de préférences | |||
| LDAPCacheEntries nombre | 1024 | s | E |
| Nombre maximum d'entrées dans le cache LDAP +primaire | |||
| LDAPCacheTTL secondes | 600 | s | E |
| Durée pendant laquelle les entrées du cache restent +valides. | |||
| LDAPConnectionPoolTTL n | -1 | sv | E |
| Désactive les connexions d'arrière-plan qui sont restées +inactives trop longtemps au sein du jeu de connexions. | |||
| LDAPConnectionTimeout secondes | s | E | |
| Spécifie le délai d'attente en secondes de la socket de +connexion | |||
| LDAPLibraryDebug 7 | s | E | |
| Active le débogage dans le SDK LDAP | |||
| LDAPOpCacheEntries nombre | 1024 | s | E |
| Nombre d'entrées utilisées pour mettre en cache les +opérations de comparaison LDAP | |||
| LDAPOpCacheTTL secondes | 600 | s | E |
| Durée pendant laquelle les entrées du cache d'opérations +restent valides | |||
| LDAPReferralHopLimit nombre | dh | E | |
| Le nombre maximum de redirections vers des serveurs +alternatifs (referrals) avant l'abandon de la requête +LDAP. | |||
| LDAPReferrals On|Off|default | On | dh | E |
| Active la redirection vers des serveurs alternatifs au +cours des requêtes vers le serveur LDAP. | |||
| LDAPRetries nombre d'essais | 3 | s | E |
| Définit le nombre maximum de tentatives de connexions au +serveur LDAP. | |||
| LDAPRetryDelay secondes | 0 | s | E |
| Définit le temps d'attente avant un autre essai de connexion au +serveur LDAP. | |||
| LDAPSharedCacheFile chemin/fichier | s | E | |
| Définit le fichier du cache en mémoire +partagée | |||
| LDAPSharedCacheSize octets | 500000 | s | E |
| Taille en octets du cache en mémoire partagée | |||
| LDAPTimeout secondes | 60 | s | E |
| Spécifie le délai d'attente pour les opérations de +recherche et d'identification LDAP en secondes | |||
| LDAPTrustedClientCert type +chemin/nom-fichier/alias [mot de passe] | svdh | E | |
| Définit le nom de fichier contenant un certificat client ou +un alias renvoyant vers un certificat client spécifique à une connexion. +Tous les SDK LDAP ne supportent pas les certificats clients par +connexion. | |||
| LDAPTrustedGlobalCert type +chemin/nom-fichier [mot de passe] | s | E | |
| Définit le nom de fichier ou la base de données contenant +les Autorités de Certification de confiance globales ou les certificats +clients globaux | |||
| LDAPTrustedMode type | sv | E | |
| Spécifie le mode (SSL ou TLS) à utiliser lors de la +connexion à un serveur LDAP. | |||
| LDAPVerifyServerCert On|Off | On | s | E |
| Force la vérification du certificat du +serveur | |||
| <Limit méthode [méthode] ... > ... + </Limit> | dh | C | |
| Limite les contrôles d'accès que la section contient à +certaines méthodes HTTP | |||
| <LimitExcept méthode [méthode] ... > ... + </LimitExcept> | dh | C | |
| Applique les contrôles d'accès à toutes les méthodes HTTP, +sauf celles qui sont spécifiées | |||
| LimitInternalRecursion nombre [nombre] | 10 | sv | C |
| Détermine le nombre maximal de redirections internes et de +sous-requêtes imbriquées | |||
| LimitRequestBody octets | 0 | svdh | C |
| limite la taille maximale du corps de la requête HTTP +envoyée par le client | |||
| LimitRequestFields nombre | 100 | sv | C |
| Limite le nombre de champs d'en-tête autorisés dans une +requête HTTP | |||
| LimitRequestFieldSize octets | 8190 | sv | C |
| Dédinit la taille maximale autorisée d'un en-tête de +requête HTTP | |||
| LimitRequestLine octets | 8190 | sv | C |
| Définit la taille maximale d'une ligne de requête +HTTP | |||
| LimitXMLRequestBody octets | 1000000 | svdh | C |
| Définit la taille maximale du corps d'une requête au format +XML | |||
| Listen [adresse IP:]numéro port +[protocole] | s | M | |
| Les adresses IP et ports sur lesquels le serveur écoute | |||
| ListenBacklog backlog | s | M | |
| Longueur maximale de la liste d'attente des +connexions | |||
| ListenCoresBucketsRatio ratio | 0 (disabled) | s | M |
| Rapport entre le nombre de coeurs de processeur activés et +le nombre de segments d'écoute | |||
| LoadFile nom-fichier [nom-fichier] ... | sv | E | |
| Liaison du fichier objet ou de la bibliothèque +spécifié | |||
| LoadModule module nom-fichier | sv | E | |
| Liaison avec le serveur du fichier objet ou de la +bibliothèque spécifié, et ajout de ce dernier à la liste des modules +actifs | |||
| <Location + chemin URL|URL> ... </Location> | sv | C | |
| N'applique les directives contenues qu'aux URLs +spécifiées | |||
| <LocationMatch + regex> ... </LocationMatch> | sv | C | |
| N'applique les directives contenues qu'aux URLs +correspondant à une expression rationnelle | |||
| LogFormat format|alias +[alias] | "%h %l %u %t \"%r\" + | sv | B |
| Décrit un format utilisable dans un fichier +journal | |||
| LogIOTrackTTFB ON|OFF | OFF | svdh | E |
| Permet d'enregistrer le délai avant le premier octet (time +to first byte - TTFB) | |||
| LogLevel [module:]niveau + [module:niveau] ... + | warn | svd | C |
| Contrôle la verbosité du journal des erreurs | |||
| LogMessage message +[hook=hook] [expr=expression] + | d | X | |
| Enregistre des messages personnalisés dans le journal des +erreurs | |||
| LuaAuthzProvider provider_name /path/to/lua/script.lua function_name | s | X | |
Branche une fonction fournisseur d'autorisation dans mod_authz_core
+ | |||
| LuaCodeCache stat|forever|never | stat | svdh | X |
| Configure le cache de code compilé. | |||
| LuaHookAccessChecker /chemin/vers/lua/script.lua hook_function_name [early|late] | svdh | X | |
| Fournit un point d'entrée pour la phase access_checker du +traitement de la requête | |||
| LuaHookAuthChecker /chemin/vers/lua/script.lua hook_function_name [early|late] | svdh | X | |
| Fournit un point d'entrée pour la phase auth_checker du +traitement de la requête | |||
| LuaHookCheckUserID /chemin/vers/lua/script.lua hook_function_name [early|late] | svdh | X | |
| Fournit un point d'entrée pour la phase check_user_id du +traitement de la requête | |||
| LuaHookFixups /chemin/vers/lua/script.lua hook_function_name | svdh | X | |
| Fournit un point d'entrée pour la phase de correction du +traitement de la requête | |||
| LuaHookInsertFilter /chemin/vers/lua/script.lua hook_function_name | svdh | X | |
| Fournit un point d'entrée pour la phase insert_filter du +traitement de la requête | |||
| LuaHookLog /path/to/lua/script.lua log_function_name | svdh | X | |
| Permet une insertion dans la phase de journalisation du +traitement d'une requête | |||
| LuaHookMapToStorage /chemin/vers/lua/script.lua hook_function_name | svdh | X | |
| Fournit un point d'entrée pour la phase map_to_storage du +traitement de la requête | |||
| LuaHookTranslateName /chemin/vers/lua/script.lua nom_fonction_hook [early|late] | sv | X | |
| Fournit un point d'entrée à la phase du nom de +traduction du traitement de la requête | |||
| LuaHookTypeChecker /chemin/vers/lua/script.lua hook_function_name | svdh | X | |
| Fournit un point d'entrée pour la phase type_checker du +traitement de la requête | |||
| LuaInherit none|parent-first|parent-last | parent-first | svdh | X |
| Contrôle la manière dont les sections de configuration +parentes sont fusionnées dans les enfants | |||
| LuaInputFilter filter_name /path/to/lua/script.lua function_name | s | X | |
| Fournit une fonction Lua pour le filtrage en entrée | |||
| LuaMapHandler modele-uri /chemin/vers/lua/script.lua +[nom-fonction] | svdh | X | |
| Met en correspondance un chemin avec un gestionnaire lua | |||
| LuaOutputFilter filter_name /path/to/lua/script.lua function_name | s | X | |
| Fournit une fonction Lua pour le filtrage de contenu en +sortie | |||
| LuaPackageCPath /chemin/vers/include/?.soa | svdh | X | |
| Ajoute un répertoire au package.cpath de lua | |||
| LuaPackagePath /chemin/vers/include/?.lua | svdh | X | |
| Ajoute un répertoire au package.path de lua | |||
| LuaQuickHandler /path/to/script.lua hook_function_name | svdh | X | |
| Fournit un point d'entrée pour la gestion rapide du +traitement de la requête | |||
| LuaRoot /chemin/vers/un/répertoire | svdh | X | |
| Spécifie le chemin de base pour la résolution des chemins +relatifs dans les directives de mod_lua | |||
| LuaScope once|request|conn|thread|server [min] [max] | once | svdh | X |
| Une valeur parmi once, request, conn, thread -- la valeur par défaut est once | |||
| +<Macro nom [par1 .. parN]> +... </Macro> | svd | B | |
| Définition d'une macro dans un fichier de configuration | |||
| MaxConnectionsPerChild number | 0 | s | M |
| Limite le nombre de connexions qu'un processus enfant va +traiter au cours de son fonctionnement | |||
| MaxKeepAliveRequests nombre | 100 | sv | C |
| Nombre de requêtes permises pour une connexion +persistante | |||
| MaxMemFree KOctets | 2048 | s | M |
Quantité maximale de mémoire que l'allocateur principal est
+autorisé à conserver sans appeler free() | |||
| MaxRangeOverlaps default | unlimited | none | nombre de + chevauchements | 20 | svd | C |
Nombre de chevauchements de segments de données autorisé
+ (par exemple 100-200,150-300) avant le renvoi de la
+ ressource complète | |||
| MaxRangeReversals default | unlimited | none | nombre + d'inversions | 20 | svd | C |
Nombre d'inversions d'ordre autorisé dans la spécification des
+ segments de données (par exemple 100-200,50-70) avant le renvoi de la
+ ressource complète | |||
| MaxRanges default | unlimited | none | nombre de segments | 200 | svd | C |
| Nombre de segments de données autorisé avant le renvoi de +l'intégralité de la ressource | |||
| MaxRequestWorkers nombre | s | M | |
| Nombre maximum de connexions pouvant être traitées +simultanément | |||
| MaxSpareServers nombre | 10 | s | M |
| Nombre maximum de processus serveurs enfants +inactifs | |||
| MaxSpareThreads nombre | s | M | |
| Nombre maximum de threads inactifs | |||
| MaxThreads nombre | 2048 | s | M |
| Définit le nombre maximum de threads esclaves | |||
| MDBaseServer on|off | off | s | E |
| Control if base server may be managed or only virtual hosts. | |||
| MDCAChallenges name [ name ... ] | tls-sni-01 http-01 | s | E |
| Type of ACME challenge used to prove domain ownership. | |||
| MDCertificateAgreement url-of-terms-of-service | s | E | |
| The URL of the Terms-of-Service document, that the CA server requires you to accept. | |||
| MDCertificateAuthority url | https://acme-v01.ap + | s | E |
| The URL of the ACME Certificate Authority service. | |||
| MDCertificateProtocol protocol | ACME | s | E |
| The protocol to use with the Certificate Authority. | |||
| MDDriveMode always|auto|manual | auto | s | E |
| Control when it is allowed to obtain/renew certificates. | |||
| MDHttpProxy url | s | E | |
| Define a proxy for outgoing connections. | |||
| MDMember hostname | s | E | |
| Additional hostname for the managed domain. | |||
| MDMembers auto|manual | auto | s | E |
| Control if the alias domain names are automatically added. | |||
| MDMustStaple on|off | off | s | E |
| Control if new certificates carry the OCSP Must Staple flag. | |||
| MDNotifyCmd path [ args ] | s | E | |
| Run a program when Managed Domain are ready. | |||
| MDomain dns-name [ other-dns-name... ] [auto|manual] | s | E | |
| Define list of domain names that belong to one group. | |||
| <MDomainSet dns-name [ other-dns-name... ]>...</MDomainSet> | s | E | |
| Container for directives applied to the same managed domains. | |||
| MDPortMap map1 [ map2 ] | 80:80 443:443 | s | E |
| Map external to internal ports for domain ownership verification. | |||
| MDPrivateKeys type [ params... ] | RSA 2048 | s | E |
| Set type and size of the private keys generated. | |||
| MDRenewWindow duration | 33% | s | E |
| Control when a certificate will be renewed. | |||
| MDRequireHttps off|temporary|permanent | off | s | E |
| Redirects http: traffic to https: for Managed Domains. | |||
| MDStoreDir path | md | s | E |
| Path on the local file system to store the Managed Domains data. | |||
| MemcacheConnTTL num[units] | 15s | sv | E |
| Durée de conservation des connexions inactives | |||
| MergeTrailers [on|off] | off | sv | C |
| Détermine si les données supplémentaires (trailers) sont +fusionnées avec les en-têtes | |||
| MetaDir répertoire | .web | svdh | E |
| Le nom du répertoire où trouver les fichiers de +métainformations dans le style du CERN | |||
| MetaFiles on|off | off | svdh | E |
| Active le traitement des métafichiers du CERN | |||
| MetaSuffix suffixe | .meta | svdh | E |
| Suffixe du fichier contenant les métainformations dans le +style du CERN | |||
| MimeMagicFile chemin-fichier | sv | E | |
| Active la détermination du type MIME en se basant sur le +contenu du fichier et en utilisant le fichier magique +spécifié | |||
| MinSpareServers nombre | 5 | s | M |
| Nombre minimum de processus serveurs enfants +inactifs | |||
| MinSpareThreads nombre | s | M | |
| Nombre minimum de threads inactifs qui seront disponibles +pour pouvoir traiter les pics de requêtes | |||
| MMapFile chemin fichier [chemin fichier] ... | s | X | |
| Charge au démarrage une liste de fichiers en mémoire | |||
| ModemStandard V.21|V.26bis|V.32|V.34|V.92 | d | X | |
| Standard de modem à simuler | |||
| ModMimeUsePathInfo On|Off | Off | d | B |
Indique à mod_mime de traiter les éléments
+de path_info en tant que parties du nom de
+fichier | |||
| MultiviewsMatch Any|NegotiatedOnly|Filters|Handlers +[Handlers|Filters] | NegotiatedOnly | svdh | B |
| Les types de fichiers qui seront inclus lors d'une +recherche de correspondance de fichier avec les vues multiples +(MultiViews) | |||
| Mutex mécanisme [default|nom-mutex] ... [OmitPID] | default | s | C |
| Définit les mécanismes de mutex et le repertoire du fichier +verrou pour tous les mutex ou seulement les mutex spécifiés | |||
| NameVirtualHost adresse[:port] | s | C | |
| OBSOLETE : Définit une adresse IP pour les serveurs virtuels à base de +nom | |||
| NoProxy domaine [domaine] ... | sv | E | |
| Serveurs, domaines ou réseaux auquels on se connectera +directement | |||
| NWSSLTrustedCerts nom-fichier +[nom-fichier] ... | s | B | |
| Liste de certificats clients supplémentaires | |||
| NWSSLUpgradeable [adresse-IP:]num-port | s | B | |
| Permet de promouvoir une connexion non SSL au statut de +connexion SSL à la demande | |||
| Options + [+|-]option [[+|-]option] ... | FollowSymlinks | svdh | C |
| Définit les fonctionnalités disponibles pour un répertoire +particulier | |||
| Order ordre | Deny,Allow | dh | E |
Définit le statut d'accès par défaut et l'ordre dans lequel
+les directives Allow et
+Deny sont évaluées. | |||
| OutputSed commande-sed | dh | ||
| Commande sed pour le filtrage des contenus de type +réponse | |||
| PassEnv var-env [var-env] +... | svdh | B | |
| Transmet des variables d'environnement depuis le +shell | |||
| PidFile nom fichier | logs/httpd.pid | s | M |
| Ficher dans lequel le serveur enregistre l'identificateur +de processus du démon | |||
| PrivilegesMode FAST|SECURE|SELECTIVE | FAST | svd | X |
| Fait un compromis entre d'une part l'efficacité et la +vitesse de traitement et d'autre part la sécurité à l'encontre des codes +malicieux supportant les privilèges. | |||
| Protocol protocole | sv | C | |
| Protocole pour une socket d'écoute | |||
| ProtocolEcho On|Off | Off | sv | X |
| Active ou désactive le serveur d'écho | |||
| Protocols protocole ... | http/1.1 | sv | C |
| Protocoles disponibles pour un serveur virtuel ou non | |||
| ProtocolsHonorOrder On|Off | On | sv | C |
| Détermine qui du client ou du serveur détermine l'ordre + des protocoles au cours de la négociation de la connexion | |||
| <Proxy url-avec-jokers> ...</Proxy> | sv | E | |
| Conteneur de directives s'appliquant à des ressources +mandatées | |||
| ProxyAddHeaders Off|On | On | svd | E |
| Ajoute des informations à propos du mandataire aux +en-têtes X-Forwarded-* | |||
| ProxyBadHeader IsError|Ignore|StartBody | IsError | sv | E |
| Détermine la manière de traiter les lignes d'en-tête +incorrectes d'une réponse | |||
| ProxyBlock *|terme|serveur|domaine +[terme|serveur|domaine] ... | sv | E | |
| Termes, serveurs ou domaines bloqués par le +mandataire | |||
| ProxyDomain Domaine | sv | E | |
| Nom de domaine par défaut pour les requêtes +mandatées | |||
| ProxyErrorOverride On|Off | Off | svd | E |
| Outrepasser les pages d'erreur pour les contenus +mandatés | |||
| ProxyExpressDBMFile <chemin> | sv | E | |
| Chemin du fichier DBM. | |||
| ProxyExpressDBMFile <type> | sv | E | |
| Type de fichier DBM. | |||
| ProxyExpressEnable [on|off] | sv | E | |
| Active la fonctionnalité du module. | |||
| ProxyFCGIBackendType FPM|GENERIC | FPM | svdh | E |
| Spécifie le type de l'application FastCGI d'arrière-plan | |||
| ProxyFCGISetEnvIf conditional-expression + [!]environment-variable-name + [value-expression] | svdh | E | |
| Permet d'adapter la valeur des variables envoyées aux serveurs +FastCGI | |||
| ProxyFtpDirCharset character_set | ISO-8859-1 | svd | E |
| Définit le jeu de caractères des listings FTP +mandatés | |||
| ProxyFtpEscapeWildcards on|off | on | svd | E |
| Les caractères génériques dans les noms de fichiers +doivent-ils être échappés lorsqu'ils sont envoyés au serveur FTP ? | |||
| ProxyFtpListOnWildcard on|off | on | svd | E |
| Les caractères génériques dans les noms de fichiers +demandés doivent-ils déclencher l'affichage d'un listing ? | |||
| ProxyHCExpr name {ap_expr expression} | sv | E | |
| Crée et nomme une expression conditionnelle à utiliser pour +déterminer la santé d'un serveur d'arrière-plan en fonction de sa valeur | |||
| ProxyHCTemplate name parameter=setting [...] | sv | E | |
| Crée et nomme un modèle permettant de définir différents +paramètres de check up | |||
| ProxyHCTPsize size | 16 | s | E |
| Définit la taille totale, pour l'ensemble du +serveur, du jeu de threads utilisé pour le check up des +équipiers | |||
| ProxyHTMLBufSize nb-octets | 8192 | svd | B |
| Définit l'incrément de la taille du tampon, ainsi que sa +taille initiale, pour la mise en +tampon des scripts en ligne et des feuilles de style. | |||
| ProxyHTMLCharsetOut jeu-de-caractères | * | svd | B | |
| Spécifie un jeu de caractères pour la sortie de +mod_proxy_html. | |||
| ProxyHTMLDocType HTML|XHTML [Legacy] OR + ProxyHTMLDocType fpi [SGML|XML] | svd | B | |
| Définit une déclaration de type de document HTML ou XHTML. | |||
| ProxyHTMLEnable On|Off | Off | svd | B |
| Permet d'activer/désactiver le filtre proxy_html. | |||
| ProxyHTMLEvents attribut [attribut ...] | svd | B | |
| Spécifie les attributs à traiter comme des évènements de +type scripting. | |||
| ProxyHTMLExtended On|Off | Off | svd | B |
| Détermine si l'on doit corriger les liens dans les scripts +en ligne, les feuilles de style et les évènements de type scripting. | |||
| ProxyHTMLFixups [lowercase] [dospath] [reset] | svd | B | |
| Corrige les erreurs HTML simples. | |||
| ProxyHTMLInterp On|Off | Off | svd | B |
Active la réinterprétation des règles
+ProxyHTMLURLMap pour chaque requête. | |||
| ProxyHTMLLinks élément attribut [attribut2 ...] | svd | B | |
| Spécifie les éléments HTML dont les attributs d'URL doivent +être réécrits. | |||
| ProxyHTMLMeta On|Off | Off | svd | B |
Active ou désactive une préinterprétation supplémentaire
+des métadonnées dans les sections HTML <head>. | |||
| ProxyHTMLStripComments On|Off | Off | svd | B |
| Détermine si les commentaires HTML doivent être supprimés. | |||
| ProxyHTMLURLMap modèle-source modèle-cible [drapeaux] [cond] | svd | B | |
| Définit une règle de réécriture des liens HTML | |||
| ProxyIOBufferSize octets | 8192 | sv | E |
| Détermine la taille du tampon interne de transfert de +données | |||
| <ProxyMatch regex> ...</ProxyMatch> | sv | E | |
| Conteneur de directives s'appliquant à des ressources +mandatées correspondant à une expression rationnelle | |||
| ProxyMaxForwards nombre | -1 | sv | E |
| Nombre maximum de mandataires à travers lesquelles une +requête peut être redirigée | |||
| ProxyPass [chemin] !|url [clé=valeur + [clé=valeur ...]] [nocanon] [interpolate] [noquery] | svd | E | |
| Référencer des serveurs distants depuis +l'espace d'URLs du serveur local | |||
| ProxyPassInherit On|Off | On | sv | E |
| Héritage des directives ProxyPass définies au niveau du +serveur principal | |||
| ProxyPassInterpolateEnv On|Off | Off | svd | E |
| Active l'interpolation des variables d'environnement dans +les configurations de mandataires inverses | |||
| ProxyPassMatch [regex] !|url +[clé=valeur + [clé=valeur ...]] | svd | E | |
| Fait correspondre des serveurs distants dans l'espace d'URL +du serveur local en utilisant des expressions rationnelles | |||
| ProxyPassReverse [chemin] url +[interpolate] | svd | E | |
| Ajuste l'URL dans les en-têtes de la réponse HTTP envoyée +par un serveur mandaté en inverse | |||
| ProxyPassReverseCookieDomain domaine-interne +domaine-public [interpolate] | svd | E | |
| Ajuste la chaîne correspondant au domaine dans les en-têtes +Set-Cookie en provenance d'un serveur mandaté | |||
| ProxyPassReverseCookiePath chemin-interne +chemin-public [interpolate] | svd | E | |
| Ajuste la chaîne correspondant au chemin dans les en-têtes +Set-Cookie en provenance d'un serveur mandaté | |||
| ProxyPreserveHost On|Off | Off | svd | E |
| Utilise l'en-tête de requête entrante Host pour la requête +du mandataire | |||
| ProxyReceiveBufferSize octets | 0 | sv | E |
| Taille du tampon réseau pour les connexions mandatées HTTP +et FTP | |||
| ProxyRemote comparaison serveur-distant | sv | E | |
| Mandataire distant à utiliser pour traiter certaines +requêtes | |||
| ProxyRemoteMatch regex serveur-distant | sv | E | |
| Le mandataire distant à utiliser pour traiter les requêtes +correspondant à une expression rationnelle | |||
| ProxyRequests On|Off | Off | sv | E |
| Active la fonctionnalité (standard) de mandataire +direct | |||
| ProxySCGIInternalRedirect On|Off|Headername | On | svd | E |
| Active ou désactive les réponses de redirection interne en +provenance du serveur cible. | |||
| ProxySCGISendfile On|Off|nom-en-tête | Off | svd | E |
| Active l'évaluation du pseudo en-tête de réponse +X-Sendfile | |||
| ProxySet url clé=valeur [clé=valeur ...] | svd | E | |
| Définit différents paramètres relatifs à la répartition de +charge des mandataires et aux membres des groupes de répartition de +charge | |||
| ProxySourceAddress adresse | sv | E | |
| Définit l'adresse IP locale pour les connexions mandatées +sortantes | |||
| ProxyStatus Off|On|Full | Off | sv | E |
| Affiche l'état du répartiteur de charge du mandataire dans +mod_status | |||
| ProxyTimeout secondes | sv | E | |
| Délai d'attente réseau pour les requêtes +mandatées | |||
| ProxyVia On|Off|Full|Block | Off | sv | E |
Information fournie dans l'en-tête de réponse HTTP
+Via pour les requêtes mandatées | |||
| QualifyRedirectURL ON|OFF | OFF | svd | C |
| Vérifie si la variable d'environnement REDIRECT_URL est +pleinement qualifiée | |||
| ReadmeName nom-fichier | svdh | B | |
| Nom du fichier dont le contenu sera inséré à la fin de +l'index | |||
| ReceiveBufferSize octets | 0 | s | M |
| Taille du tampon TCP en entrée | |||
| Redirect [état] [URL-path] +URL | svdh | B | |
| Envoie une redirection externe demandant au client +d'effectuer une autre requête avec une URL différente | |||
| RedirectMatch [état] regex +URL | svdh | B | |
| Envoie une redirection externe faisant appel aux +expressions rationnelles pour la mise en correspondance de l'URL +courante | |||
| RedirectPermanent chemin URL URL | svdh | B | |
| Envoie une redirection externe permanente demandant au +client d'effectuer une nouvelle requête avec une URL +différente | |||
| RedirectTemp chemin URL URL | svdh | B | |
| Envoie une redirection externe temporaire demandant au +client d'effectuer une nouvelle requête avec une URL +différente | |||
| ReflectorHeader en-tête-entrée [en-tête-sortie] | svdh | B | |
| Renvoie un en-tête d'entrée dans les en-têtes de sortie | |||
| RegexDefaultOptions [none] [+|-]option [[+|-]option] ... | DOLLAR_ENDONLY | s | C |
| Configuration des options globales par défaut pour les + expressions rationnelles | |||
| RegisterHttpMethod méthode [méthode [...]] | s | C | |
| Enregistrement de méthodes HTTP non standards | |||
| RemoteIPHeader en-tête | sv | B | |
| Définit le champ d'en-tête qui contiendra les adresses IP +du client | |||
| RemoteIPInternalProxy +ip-mandataire|ip-mandataire/sous-réseau|nom-hôte ... | sv | B | |
| Déclare les adresses IP intranet clients comme dignes de +confiance pour présenter la valeur RemoteIPHeader | |||
| RemoteIPInternalProxyList nom-fichier | sv | B | |
| Déclare les adresses IP intranet clients comme dignes de +confiance pour présenter la valeur RemoteIPHeader | |||
| RemoteIPProxiesHeader Nom_en-tête | sv | B | |
| Déclare le champ d'en-tête qui contiendra toutes les +adresses IP intermédiaires | |||
| RemoteIPProxyProtocol On|Off | sv | B | |
| Active ou désactive la gestion du protocole PROXY | |||
| RemoteIPProxyProtocolExceptions host|range [host|range] [host|range] | sv | B | |
| Désactive la prise en compte de l'en-tête PROXY pour certains hôtes +ou réseaux | |||
| RemoteIPTrustedProxy +ip-mandataire|ip-mandataire/sous-réseau|nom-hôte ... | sv | B | |
| Déclare les adresses IP clientes de l'intranet dignes de +confiance pour présenter la valeur RemoteIPHeader | |||
| RemoteIPTrustedProxyList nom-fichier | sv | B | |
| Déclare les adresses IP intranet clients comme dignes de +confiance pour présenter la valeur RemoteIPHeader | |||
| RemoveCharset extension [extension] +... | vdh | B | |
| Supprime toute association de jeu de caractères pour un +ensemble d'extensions de noms de fichiers | |||
| RemoveEncoding extension [extension] +... | vdh | B | |
| Supprime toute association de codage de contenu pour un +ensemble d'extensions de noms de fichiers | |||
| RemoveHandler extension [extension] +... | vdh | B | |
| Supprime toute association de gestionnaire à un ensemble +d'extensions de noms de fichiers | |||
| RemoveInputFilter extension [extension] +... | vdh | B | |
| Supprime toute association de filtre en entrée à un +ensemble d'extensions de noms de fichiers | |||
| RemoveLanguage extension [extension] +... | vdh | B | |
| Supprime toute association de langue à un ensemble +d'extensions de noms de fichiers | |||
| RemoveOutputFilter extension [extension] +... | vdh | B | |
| Supprime toute association de filtre en sortie à un +ensemble d'extensions de noms de fichiers | |||
| RemoveType extension [extension] +... | vdh | B | |
| Supprime toute association de type de contenu à un ensemble +d'extensions de noms de fichiers | |||
| RequestHeader add|append|edit|edit*|merge|set|setifempty|unset +en-tête [[expr=]valeur +[remplacement] +[early|env=[!]variable|expr=expression]] + | svdh | E | |
| Configure les en-têtes d'une requête HTTP | |||
| RequestReadTimeout +[header=délai[-délai-maxi][,MinRate=taux-mini] +[body=délai[-délai-maxi][,MinRate=taux-mini] + | sv | E | |
| Définit des délais maximums pour la réception des en-têtes +et corps des requêtes en provenance du client. + | |||
| Require [not] nom-entité [nom-entité] +... | dh | B | |
| Vérifie si un utilisateur authentifié a une +autorisation d'accès accordée par un fournisseur +d'autorisation. | |||
| <RequireAll> ... </RequireAll> | dh | B | |
| Regroupe plusieurs directives d'autorisation dont aucune ne +doit échouer et dont au moins une doit retourner un résultat positif +pour que la directive globale retourne elle-même un résultat +positif. | |||
| <RequireAny> ... </RequireAny> | dh | B | |
| Regroupe des directives d'autorisation dont au moins une +doit retourner un résultat positif pour que la directive globale +retourne elle-même un résultat positif. | |||
| <RequireNone> ... </RequireNone> | dh | B | |
| Regroupe des directives d'autorisation dont aucune ne doit +retourner un résultat positif pour que la directive globale n'échoue +pas. | |||
| RewriteBase chemin_URL | dh | E | |
| Définit l'URL de base pour les réécritures au niveau +répertoire | |||
| RewriteCond + chaîne_de_test expression_de_comparaison [drapeaux] | svdh | E | |
| Définit une condition qui devra être satisfaite pour que +la réécriture soit effectuée + | |||
| RewriteEngine on|off | off | svdh | E |
| Active ou désactive l'exécution du +moteur de réécriture | |||
| RewriteMap MapName MapType:MapSource [MapTypeOptions] + | sv | E | |
| Définit une fonction de mise en correspondance pour la +recherche de mots-clés | |||
| RewriteOptions Options | svdh | E | |
| Configure certaines options spéciales +pour le moteur de réécriture | |||
| RewriteRule + Modèle Substitution [drapeaux] | svdh | E | |
| Définit les règles pour le moteur de réécriture | |||
| RLimitCPU secondes|max [secondes|max] | svdh | C | |
| Limite le temps CPU alloué aux processus initiés par les +processus enfants d'Apache httpd | |||
| RLimitMEM octets|max [octets|max] | svdh | C | |
| Limite la mémoire allouée aux processus initiés par les +processus enfants d'Apache httpd | |||
| RLimitNPROC nombre|max [nombre|max] | svdh | C | |
| Limite le nombre de processus qui peuvent être initiés par +les processus initiés par les processus enfants d'Apache httpd | |||
| Satisfy Any|All | All | dh | E |
| Interaction entre le contrôle d'accès en fonction de l'hôte +et l'authentification utilisateur | |||
| ScoreBoardFile chemin fichier | logs/apache_runtime + | s | M |
| Chemin du fichier où sont stockées les données concernant +la coordination des processus enfants | |||
| Script méthode script cgi | svd | B | |
| Active un script CGI dans le cas d'une méthode de requête +particulière. | |||
| ScriptAlias [chemin URL] +chemin fichier|chemin répertoire | svd | B | |
| Fait correspondre une URL à une zone du système de fichiers +et désigne la cible comme script CGI | |||
| ScriptAliasMatch regex +chemin fichier|chemin répertoire | sv | B | |
| Fait correspondre une URL à une zone du système de fichiers +en faisant appel aux expressions rationnelles et en désignant la cible +comme un script CGI | |||
| ScriptInterpreterSource Registry|Registry-Strict|Script | Script | svdh | C |
| Permet de localiser l'interpréteur des scripts +CGI | |||
| ScriptLog chemin fichier | sv | B | |
| Chemin du fichier journal des erreurs du script +CGI | |||
| ScriptLogBuffer octets | 1024 | sv | B |
| Taille maximale des requêtes PUT ou POST qui seront +enregistrées dans le journal du script | |||
| ScriptLogLength octets | 10385760 | sv | B |
| Taille maximale du fichier journal des scripts +CGI | |||
| ScriptSock chemin fichier | cgisock | s | B |
| Le préfixe du nom de fichier du socket à utiliser pour +communiquer avec le démon CGI | |||
| SecureListen [adresse-IP:]num-port +nom-certificat [MUTUAL] | s | B | |
| Active le chiffrement SSL pour le port +spécifié | |||
| SeeRequestTail On|Off | Off | s | C |
| Détermine si mod_status affiche les 63 premiers caractères +d'une requête ou les 63 derniers, en supposant que la requête +elle-même possède plus de 63 caractères. | |||
| SendBufferSize octets | 0 | s | M |
| Taille du tampon TCP en sortie | |||
| ServerAdmin adresse électronique|URL | sv | C | |
| L'adresse électronique que le serveur inclut dans les +messages d'erreur envoyés au client | |||
| ServerAlias nom serveur [nom serveur] +... | v | C | |
| Autres noms d'un serveur utilisables pour atteindre des +serveurs virtuels à base de nom | |||
| ServerLimit nombre | s | M | |
| Limite supérieure de la définition du nombre de +processus | |||
| ServerName +[protocole://]nom-de-domaine|adresse-ip[:port] | sv | C | |
| Nom d'hôte et port que le serveur utilise pour +s'authentifier lui-même | |||
| ServerPath chemin d'URL | v | C | |
| Nom de chemin d'URL hérité pour un serveur virtuel à base +de nom accédé par un navigateur incompatible | |||
| ServerRoot chemin de répertoire | /usr/local/apache | s | C |
| Racine du répertoire d'installation du +serveur | |||
| ServerSignature On|Off|EMail | Off | svdh | C |
| Définit un pied de page pour les documents générés par le +serveur | |||
| ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full | Full | s | C |
Configure l'en-tête Server de la réponse
+HTTP | |||
| Session On|Off | Off | svdh | E |
| Ouvre une session pour le contexte courant | |||
| SessionCookieName nom attributs | svdh | E | |
| Nom et attributs du cookie RFC2109 dans lequel la session +est stockée | |||
| SessionCookieName2 nom attributs | svdh | E | |
| Nom et attributs pour le cookie RFC2965 dans lequel est +stockée la session | |||
| SessionCookieRemove On|Off | Off | svdh | E |
| Détermine si les cookies de session doivent être supprimés +des en-têtes HTTP entrants | |||
| SessionCryptoCipher algorithme | svdh | X | |
| L'algorithme à utiliser pour le chiffrement de la session | |||
| SessionCryptoDriver nom [param[=valeur]] | s | X | |
| Le pilote de chiffrement à utiliser pour chiffrer les +sessions | |||
| SessionCryptoPassphrase secret [ secret ... ] | svdh | X | |
| La clé utilisée pour chiffrer la session | |||
| SessionCryptoPassphraseFile nom-fichier | svd | X | |
| Le fichier contenant les clés utilisées pour chiffrer la +session | |||
| SessionDBDCookieName nom attributs | svdh | E | |
| Nom et attributs du cookie RFC2109 qui contient +l'identifiant de session | |||
| SessionDBDCookieName2 nom attributs | svdh | E | |
| Nom et attributs du cookie RFC2965 qui contient +l'identifiant de session | |||
| SessionDBDCookieRemove On|Off | On | svdh | E |
| Détermine si les cookies de session doivent être supprimés +des en-têtes HTTP entrants | |||
| SessionDBDDeleteLabel étiquette | deletesession | svdh | E |
| La requête SQL à utiliser pour supprimer des sessions de la +base de données | |||
| SessionDBDInsertLabel étiquette | insertsession | svdh | E |
| La requête SQL à utiliser pour insérer des sessions dans la +base de données | |||
| SessionDBDPerUser On|Off | Off | svdh | E |
| Active une session propre à un utilisateur | |||
| SessionDBDSelectLabel étiquette | selectsession | svdh | E |
| La requête SQL à utiliser pour sélectionner des sessions +dans la base de données | |||
| SessionDBDUpdateLabel étiquette | updatesession | svdh | E |
| La requête SQL à utiliser pour mettre à jour des sessions +préexistantes dans la base de données | |||
| SessionEnv On|Off | Off | svdh | E |
| Définit si le contenu de la session doit être enregistré +dans la variable d'environnement HTTP_SESSION | |||
| SessionExclude chemin | svdh | E | |
| Définit les préfixes d'URLs pour lesquels une session sera +ignorée | |||
| SessionHeader en-tête | svdh | E | |
| Importation des mises à jour de session depuis l'en-tête de +réponse HTTP spécifié | |||
| SessionInclude chemin | svdh | E | |
| Définit les préfixes d'URL pour lesquels une session est +valide | |||
| SessionMaxAge durée de vie maximale | 0 | svdh | E |
| Définit une durée de vie maximale pour la session en +secondes | |||
| SetEnv var-env [valeur] | svdh | B | |
| Définit des variables d'environnement | |||
| SetEnvIf attribut + regex [!]env-variable[=valeur] + [[!]env-variable[=valeur]] ... | svdh | B | |
| Définit des variables d'environnement en fonction des +attributs de la requête | |||
| SetEnvIfExpr expr + [!]env-variable[=valeur] + [[!]env-variable[=valeur]] ... | svdh | B | |
| Définit des variables d'environnement en fonction d'une expression ap_expr | |||
| SetEnvIfNoCase attribut regex + [!]env-variable[=valeur] + [[!]env-variable[=valeur]] ... | svdh | B | |
| Définit des variables d'environnement en fonction des +attributs de la requête sans tenir compte de la casse | |||
| SetHandler handler-name|none|expression | svdh | C | |
| Force le traitement des fichiers spécifiés par un +gestionnaire particulier | |||
| SetInputFilter filtre[;filtre...] | svdh | C | |
| Définit les filtres par lesquels vont passer les requêtes +client et les données POST | |||
| SetOutputFilter filtre[;filtre...] | svdh | C | |
| Définit les filtres par lesquels vont passer les réponses +du serveur | |||
| SSIEndTag tag | "-->" | sv | B |
| Chaîne qui termine l'élément include | |||
| SSIErrorMsg message | "[an error occurred + | svdh | B |
| Message d'erreur affiché lorsqu'une erreur SSI +survient | |||
| SSIETag on|off | off | dh | B |
| Définit si des en-têtes ETags sont générés par le serveur. | |||
| SSILastModified on|off | off | dh | B |
Définit si des en-têtes Last-Modified sont
+générés par le serveur. | |||
| SSILegacyExprParser on|off | off | dh | B |
| Active le mode de compatibilité pour les expressions +conditionnelles. | |||
| SSIStartTag tag | "<!--#" | sv | B |
| Chaîne qui marque le début d'un élément +include | |||
| SSITimeFormat chaîne de formatage | "%A, %d-%b-%Y %H:%M + | svdh | B |
| Configuration du format d'affichage des dates | |||
| SSIUndefinedEcho chaîne | "(none)" | svdh | B |
| Chaîne à afficher lorsqu'on tente d'extraire le contenu +d'une variable non définie | |||
| SSLCACertificateFile chemin-fichier | sv | E | |
| Fichier contenant une concaténation des certificats de CA +codés en PEM pour l'authentification des clients | |||
| SSLCACertificatePath chemin-répertoire | sv | E | |
| Répertoire des certificats de CA codés en PEM pour +l'authentification des clients | |||
| SSLCADNRequestFile chemin-fichier | sv | E | |
| Fichier contenant la concaténation des certificats de CA +codés en PEM pour la définition de noms de CA acceptables | |||
| SSLCADNRequestPath chemin-répertoire | sv | E | |
| Répertoire contenant des fichiers de certificats de CA +codés en PEM pour la définition de noms de CA acceptables | |||
| SSLCARevocationCheck chain|leaf|none flags | none | sv | E |
| Active la vérification des révocations basée sur les CRL | |||
| SSLCARevocationFile chemin-fichier | sv | E | |
| Fichier contenant la concaténation des CRLs des CA codés en +PEM pour l'authentification des clients | |||
| SSLCARevocationPath chemin-répertoire | sv | E | |
| Répertoire des CRLs de CA codés en PEM pour +l'authentification des clients | |||
| SSLCertificateChainFile chemin-fichier | sv | E | |
| Fichier contenant les certificats de CA du serveur codés en +PEM | |||
| SSLCertificateFile chemin-fichier | sv | E | |
| Fichier de données contenant le certificat X.509 du serveur codé en +PEM | |||
| SSLCertificateKeyFile chemin-fichier | sv | E | |
| Fichier contenant la clé privée du serveur codée en +PEM | |||
| SSLCipherSuite [protocol] cipher-spec | DEFAULT (dépend de + | svdh | E |
| Algorithmes de chiffrement disponibles pour la négociation +au cours de l'initialisation de la connexion SSL | |||
| SSLCompression on|off | off | sv | E |
| Permet d'activer la compression au niveau SSL | |||
| SSLCryptoDevice moteur | builtin | s | E |
| Active l'utilisation d'un accélérateur matériel de +chiffrement | |||
| SSLEngine on|off|optional | off | sv | E |
| Interrupteur marche/arrêt du moteur SSL | |||
| SSLFIPS on|off | off | s | E |
| Coimmutateur du mode SSL FIPS | |||
| SSLHonorCipherOrder on|off | off | sv | E |
| Option permettant de classer les algorithmes de chiffrement +du serveur par ordre de préférence | |||
| SSLInsecureRenegotiation on|off | off | sv | E |
| Option permettant d'activer le support de la renégociation +non sécurisée | |||
| SSLOCSDefaultResponder uri | sv | E | |
| Définit l'URI du répondeur par défaut pour la validation +OCSP | |||
| SSLOCSPEnable on|leaf|off | off | sv | E |
| Active la validation OCSP de la chaîne de certificats du +client | |||
| SSLOCSPNoverify On/Off | Off | sv | E |
| Evite la vérification des certificats des répondeurs OCSP | |||
| SSLOCSPOverrideResponder on|off | off | sv | E |
| Force l'utilisation de l'URI du répondeur par défaut pour +la validation OCSP | |||
| SSLOCSPProxyURL url | sv | E | |
| Adresse de mandataire à utiliser pour les requêtes OCSP | |||
| SSLOCSPResponderCertificateFile file | sv | E | |
| Fournit un jeu de certificats de confiance du répondeur OCSP avec +encodage PEM | |||
| SSLOCSPResponderTimeout secondes | 10 | sv | E |
| Délai d'attente pour les requêtes OCSP | |||
| SSLOCSPResponseMaxAge secondes | -1 | sv | E |
| Age maximum autorisé pour les réponses OCSP | |||
| SSLOCSPResponseTimeSkew secondes | 300 | sv | E |
| Dérive temporelle maximale autorisée pour la validation des +réponses OCSP | |||
| SSLOCSPUseRequestNonce on|off | on | sv | E |
| Use a nonce within OCSP queries | |||
| SSLOpenSSLConfCmd commande valeur | sv | E | |
| Configuration des paramètres d'OpenSSL via son API SSL_CONF | |||
| SSLOptions [+|-]option ... | svdh | E | |
| Configure différentes options d'exécution du moteur SSL | |||
| SSLPassPhraseDialog type | builtin | s | E |
| Méthode utilisée pour entrer le mot de passe pour les clés +privées chiffrées | |||
| SSLProtocol [+|-]protocole ... | all -SSLv3 (jusqu'à + | sv | E |
| Indique les versions du protocole SSL/TLS +disponibles | |||
| SSLProxyCACertificateFile file-path | svp | E | |
| Fichier contenant la concaténation des certificats de CA +codés en PEM pour l'authentification des serveurs distants | |||
| SSLProxyCACertificatePath chemin-répertoire | svp | E | |
| Répertoire des certificats de CA codés en PEM pour +l'authentification des serveurs distants | |||
| SSLProxyCARevocationCheck chain|leaf|none | none | svp | E |
| Active la vérification des révocations basée sur les CRLs +pour l'authentification du serveur distant | |||
| SSLProxyCARevocationFile chemin-fichier | svp | E | |
| Fichier contenant la concaténation des CRLs de CA codés en +PEM pour l'authentification des serveurs distants | |||
| SSLProxyCARevocationPath chemin-répertoire | svp | E | |
| Répertoire des CRLs de CA codés en PEM pour +l'authentification des serveurs distants | |||
| SSLProxyCheckPeerCN on|off | on | svp | E |
| Configuration de la vérification du champ CN du certificat +du serveur distant + | |||
| SSLProxyCheckPeerExpire on|off | on | svp | E |
| Configuration de la vérification de l'expiration du +certificat du serveur distant + | |||
| SSLProxyCheckPeerName on|off | on | svp | E |
| Configure la vérification du nom d'hôte dans les +certificats serveur distants + | |||
| SSLProxyCipherSuite [protocol] cipher-spec | ALL:!ADH:RC4+RSA:+H + | svp | E |
| Algorithmes de chiffrement disponibles pour la négociation +lors de l'initialisation d'une connexion SSL de mandataire | |||
| SSLProxyEngine on|off | off | svp | E |
| Interrupteur marche/arrêt du moteur de mandataire +SSL | |||
| SSLProxyMachineCertificateChainFile nom-fichier | svp | E | |
| Fichier de certificats de CA encodés PEM concaténés permettant au +mandataire de choisir un certificat | |||
| SSLProxyMachineCertificateFile chemin-fichier | svp | E | |
| Fichier contenant la concaténation des clés et certificats +clients codés en PEM que le mandataire doit utiliser | |||
| SSLProxyMachineCertificatePath chemin-répertoire | svp | E | |
| Répertoire des clés et certificats clients codés en PEM que +le mandataire doit utiliser | |||
| SSLProxyProtocol [+|-]protocole ... | all -SSLv3 (jusqu'à + | svp | E |
| Définit les protocoles SSL disponibles pour la fonction de +mandataire | |||
| SSLProxyVerify niveau | none | svp | E |
| Niveau de vérification du certificat du serveur +distant | |||
| SSLProxyVerifyDepth niveau | 1 | svp | E |
| Niveau de profondeur maximum dans les certificats de CA +lors de la vérification du certificat du serveur distant | |||
| SSLRandomSeed contexte source +[nombre] | s | E | |
| Source de déclenchement du Générateur de Nombres +Pseudo-Aléatoires (PRNG) | |||
| SSLRenegBufferSize taille | 131072 | dh | E |
| Définit la taille du tampon de renégociation +SSL | |||
| SSLRequire expression | dh | E | |
| N'autorise l'accès que lorsqu'une expression booléenne +complexe et arbitraire est vraie | |||
| SSLRequireSSL | dh | E | |
| Interdit l'accès lorsque la requête HTTP n'utilise pas +SSL | |||
| SSLSessionCache type | none | s | E |
| Type du cache de session SSL global et +inter-processus | |||
| SSLSessionCacheTimeout secondes | 300 | sv | E |
| Nombre de secondes avant l'expiration d'une session SSL +dans le cache de sessions | |||
| SSLSessionTicketKeyFile chemin-fichier | sv | E | |
| Clé de chiffrement/déchiffrement permanente pour les +tickets de session TLS | |||
| SSLSessionTickets on|off | on | sv | E |
| Active ou désactive les tickets de session TLS | |||
| SSLSRPUnknownUserSeed secret-string | sv | E | |
| Source d'aléa pour utilisateur SRP inconnu | |||
| SSLSRPVerifierFile file-path | sv | E | |
| Chemin du fichier de vérification SRP | |||
| SSLStaplingCache type | s | E | |
| Configuration du cache pour l'agrafage OCSP | |||
| SSLStaplingErrorCacheTimeout secondes | 600 | sv | E |
| Durée de vie des réponses invalides dans le cache pour +agrafage OCSP | |||
| SSLStaplingFakeTryLater on|off | on | sv | E |
| Génère une réponse "tryLater" pour les requêtes OCSP échouées | |||
| SSLStaplingForceURL uri | sv | E | |
| Remplace l'URI du serveur OCSP spécifié dans l'extension +AIA du certificat | |||
| SSLStaplingResponderTimeout secondes | 10 | sv | E |
| Temps d'attente maximum pour les requêtes vers les serveurs +OCSP | |||
| SSLStaplingResponseMaxAge secondes | -1 | sv | E |
| Age maximum autorisé des réponses OCSP incluses dans la +négociation TLS | |||
| SSLStaplingResponseTimeSkew secondes | 300 | sv | E |
| Durée de vie maximale autorisée des réponses OCSP incluses dans la +négociation TLS | |||
| SSLStaplingReturnResponderErrors on|off | on | sv | E |
| Transmet au client les erreurs survenues lors des requêtes +OCSP | |||
| SSLStaplingStandardCacheTimeout secondes | 3600 | sv | E |
| Durée de vie des réponses OCSP dans le cache | |||
| SSLStrictSNIVHostCheck on|off | off | sv | E |
| Contrôle de l'accès des clients non-SNI à un serveur virtuel à +base de nom. + | |||
| SSLUserName nom-var | sdh | E | |
| Nom de la variable servant à déterminer le nom de +l'utilisateur | |||
| SSLUseStapling on|off | off | sv | E |
| Active l'ajout des réponses OCSP à la négociation TLS | |||
| SSLVerifyClient niveau | none | svdh | E |
| Niveau de vérification du certificat client | |||
| SSLVerifyDepth nombre | 1 | svdh | E |
| Profondeur maximale des certificats de CA pour la +vérification des certificats clients | |||
| StartServers nombre | s | M | |
| Nombre de processus enfants du serveur créés au +démarrage | |||
| StartThreads nombre | s | M | |
| Nombre de threads créés au démarrage | |||
| Substitute s/modèle/substitution/[infq] | dh | E | |
| Modèle de substition dans le contenu de la +réponse | |||
| SubstituteInheritBefore on|off | on | dh | E |
| Modifie l'ordre de fusion des modèles hérités | |||
| SubstituteMaxLineLength octets(b|B|k|K|m|M|g|G) | 1m | dh | E |
| Définit la longueur de ligne maximale | |||
| Suexec On|Off | s | B | |
| Active ou désactive la fonctionnalité suEXEC | |||
| SuexecUserGroup Utilisateur Groupe | sv | E | |
| L'utilisateur et le groupe sous lesquels les programmes CGI +doivent s'exécuter | |||
| ThreadLimit nombre | s | M | |
| Le nombre de threads maximum que l'on peut définir par +processus enfant | |||
| ThreadsPerChild nombre | s | M | |
| Nombre de threads créés par chaque processus +enfant | |||
| ThreadStackSize taille | s | M | |
| La taille en octets de la pile qu'utilisent les threads qui +traitent les connexions clients | |||
| TimeOut secondes | 60 | sv | C |
| Temps pendant lequel le serveur va attendre certains +évènements avant de considérer qu'une requête a échoué | |||
| TraceEnable [on|off|extended] | on | sv | C |
Détermine le comportement des requêtes
+TRACE | |||
| TransferLog fichier|pipe | sv | B | |
| Spécifie l'emplacement d'un fichier journal | |||
| TypesConfig chemin-fichier | conf/mime.types | s | B |
Le chemin du fichier mime.types | |||
| UnDefine nom-variable | s | C | |
| Invalide la définition d'une variable | |||
| UndefMacro nom | svd | B | |
| Supprime une macro | |||
| UnsetEnv var-env [var-env] +... | svdh | B | |
| Supprime des variables de l'environnement | |||
| Use nom [valeur1 ... valeurN] + | svd | B | |
| Utilisation d'une macro | |||
| UseCanonicalName On|Off|DNS | Off | svd | C |
| Définit la manière dont le serveur détermine son propre nom +et son port | |||
| UseCanonicalPhysicalPort On|Off | Off | svd | C |
| Définit la manière dont le serveur +détermine son propre port | |||
| User utilisateur unix | #-1 | s | B |
| L'utilisateur sous lequel le serveur va traiter les +requêtes | |||
| UserDir nom-répertoire [nom-répertoire] ... + | sv | B | |
| Chemin des répertoires propres à un +utilisateur | |||
| VHostCGIMode On|Off|Secure | On | v | X |
| Détermine si le serveur virtuel peut exécuter des +sous-processus, et définit les privilèges disponibles pour ces +dernier. | |||
| VHostPrivs [+-]?nom-privilège [[+-]?nom-privilège] ... | v | X | |
| Assigne des privilèges au choix aux sous-processus créés +par un serveur virtuel. | |||
| VHostGroup identifiant-groupe-unix | v | X | |
| Définit l'identifiant du groupe sous lequel s'exécute un +serveur virtuel. | |||
| VHostPrivs [+-]?nom-privilège [[+-]?nom-privilège] ... | v | X | |
| Assigne des privilèges à un serveur virtuel. | |||
| VHostSecure On|Off | On | v | X |
| Détermine si le serveur s'exécute avec une sécurité avancée +pour les serveurs virtuels. | |||
| VHostUser identifiant-utilisateur-unix | v | X | |
| Définit l'identifiant utilisateur sous lequel s'exécute un +serveur virtuel. | |||
| VirtualDocumentRoot répertoire-interpolé|none | none | sv | E |
| Permet une configuration dynamique de la racine des +documents d'un serveur virtuel donné | |||
| VirtualDocumentRootIP répertoire-interpolé|none | none | sv | E |
| Configuration dynamique de la racine des documents pour un +serveur virtuel donné | |||
| <VirtualHost + adresse IP[:port] [adresse + IP[:port]] ...> ... + </VirtualHost> | s | C | |
| Contient des directives qui ne s'appliquent qu'à un nom +d'hôte spécifique ou à une adresse IP | |||
| VirtualScriptAlias répertoire-interpolé|none | none | sv | E |
| Configuration dynamique du répertoire des scripts CGI pour +un serveur virtuel donné | |||
| VirtualScriptAliasIP répertoire-interpolé|none | none | sv | E |
| Configuration dynamique du répertoire des scripts CGI pour +un serveur virtuel donné | |||
| WatchdogInterval time-interval[s] | 1 | s | B |
| Intervalle Watchdog en secondes | |||
| XBitHack on|off|full | off | svdh | B |
| Interprète les directives SSI dans les fichiers dont le bit +d'exécution est positionné | |||
| xml2EncAlias jeu-de-caractères alias [alias ...] | s | B | |
| Définit des alias pour les valeurs d'encodage | |||
| xml2EncDefault nom | svdh | B | |
| Définit un encodage par défaut à utiliser lorsqu'aucune +information ne peut être automatiquement détectée | |||
| xml2StartParse élément [élément ...] | svdh | B | |
| Indique à l'interpréteur à partir de quelle balise il doit +commencer son traitement. | |||
Serveur HTTP Apache Version 2.4
+| Description: | Module multi-processus implémentant un serveur web hybride +multi-processus multi-thread |
|---|---|
| Statut: | MPM |
| Identificateur de Module: | mpm_worker_module |
| Fichier Source: | worker.c |
Ce module multi-processus (MPM) implémente un serveur hybride + multi-processus multi-thread. En utilisant les threads pour servir + les requêtes, il peut en traiter un grand nombre tout en consommant + moins de ressources qu'un serveur à base de processus. Cependant, il + conserve une grande partie de la stabilité d'un serveur à base de + processus en maintenant plusieurs processus disponibles, chacun de + ces derniers possédant de nombreux threads.
+ +Les directives les plus importantes qui permettent de contrôler
+ ce MPM sont ThreadsPerChild, qui définit le
+ nombre de threads lancés par chaque processus enfant et MaxRequestWorkers, qui définit le nombre
+ global maximum de threads qui peuvent être lancés.
CoreDumpDirectory EnableExceptionHook Group Listen ListenBacklog MaxConnectionsPerChild MaxMemFree MaxRequestWorkers MaxSpareThreads MinSpareThreads PidFile ReceiveBufferSize ScoreBoardFile SendBufferSize ServerLimit StartServers ThreadLimit ThreadsPerChild ThreadStackSize UserUn processus de contrôle unique (le parent) a pour tâche de
+ lancer les processus enfants. Chaque processus enfant crée un nombre
+ fixe de threads serveurs selon la valeur de la directive ThreadsPerChild, ainsi
+ qu'un thread chargé d'attendre les connexions et de les passer à un
+ thread serveur pour traitement au fur et à mesure de leur arrivée.
Le serveur HTTP Apache essaie toujours de maintenir un jeu de
+ threads serveurs
+ inactifs ou en réserve, qui se tiennent prêts à traiter
+ les requêtes entrantes. De cette façon, les clients n'ont pas besoin
+ d'attendre la création d'un nouveau thread ou d'un nouveau processus
+ pour que leurs requêtes puissent être traitées. Le nombre de
+ processus lancés initialement est défini par la directive StartServers. En cours de
+ fonctionnement, le serveur évalue le nombre total de threads inactifs
+ dans tous les processus, et en crée ou en arrête de façon à
+ maintenir ce nombre à l'intérieur des limites définies par les
+ directives MinSpareThreads et MaxSpareThreads. Comme ce module
+ s'auto-contrôle de manière efficace, on peut en général conserver
+ les valeurs par défaut. Le nombre maximum de clients pouvant être
+ servis simultanément (c'est à dire le nombre global maximum de
+ threads pour tous les processus) est défini par la directive
+ MaxRequestWorkers. Le nombre
+ maximum de processus enfants actifs est défini par la valeur de la
+ directive MaxRequestWorkers
+ divisée par la valeur de la directive
+ ThreadsPerChild.
Deux directives permettent de fixer des limites absolues pour le
+ nombre de processus enfants actifs et le nombre de threads serveurs
+ par processus enfant, et ne peuvent être modifiées qu'en
+ arrêtant complètement le serveur et en le démarrant à nouveau.
+ La valeur de la directive ServerLimit constitue une limite
+ absolue pour le nombre de processus enfants actifs, et doit être
+ supérieure ou égale à la valeur de la directive MaxRequestWorkers divisée par la valeur de
+ la directive
+ ThreadsPerChild. La valeur de la directive ThreadLimit constitue une limite
+ absolue pour le nombre de threads par processus enfant, et doit être
+ supérieure ou égale à la valeur de la directive ThreadsPerChild.
En plus du jeu de processus enfants actifs, il peut exister
+ quelques processus enfants en cours d'arrêt, mais dont au moins un
+ thread serveur est encore en train de traiter une connexion client
+ existante. Il peut subsister en théorie jusqu'à MaxRequestWorkers processus en cours
+ d'arrêt, bien qu'en réalité, ce nombre sera en général beaucoup plus
+ petit. Ce comportement peut être évité en désactivant l'arrêt de
+ processus enfants individuels de la manière suivante :
+ MaxConnectionsPerChild à zéro
+ MaxSpareThreads à la même valeur que MaxRequestWorkersVoici un exemple typique de configuration du contrôle
+ processus-thread pour le MPM worker :
ServerLimit 16 +StartServers 2 +MaxRequestWorkers 150 +MinSpareThreads 25 +MaxSpareThreads 75 +ThreadsPerChild 25+ + +
Alors que le processus parent est en général démarré en tant que
+ root sous Unix afin de se mettre en écoute du port 80,
+ les processus enfants et les threads sont lancés par le serveur sous un
+ utilisateur avec privilèges restreints. On peut utiliser les
+ directives User et Group pour définir les privilèges
+ des processus enfants. Les processus enfants doivent pouvoir être en
+ mesure de lire tous les contenus destinés à être servis, mais
+ doivent avoir des privilèges aussi bas que possible. De plus, ces
+ directives définissent également les privilèges dont vont hériter les
+ scripts CGI (sauf si on utilise suexec).
La directive MaxConnectionsPerChild permet de
+ définir la fréquence à laquelle le serveur recycle ses processus en
+ arrêtant les plus anciens et en en lançant de nouveaux.
Ce module MPM utilise le mutex mpm-accept pour
+ sérialiser l'accès aux connexions entrantes lorsqu'un problème
+ d'afflux de requêtes peut survenir (en général, lorsqu'il y a
+ plusieurs sockets en écoute). Les différents aspects de
+ l'implémentation de ce mutex peuvent être configurés via la
+ directive Mutex. Vous
+ trouverez des informations plus détaillées à propos de ce mutex dans
+ la documentation sur les conseils en matière de
+ performances.
Serveur HTTP Apache Version 2.4
+Ce document décrit ce qu'est un Module Multi-Processus, ainsi +que la manière dont ces modules sont utilisés par le serveur HTTP Apache.
+ Introduction MPM par défaut Compiler un module MPM en tant que module
+statique Compiler un module MPM en tant que module
+DSO (Dynamic Shared Object)La conception du serveur HTTP Apache en fait un serveur web puissant et + flexible pouvant fonctionner sur une très grande variété de + plateformes et toute une gamme d'environnements différents. Plateformes + différentes et environnements différents signifient souvent fonctionnalités + différentes, ou utilisation de différentes méthodes pour + implémenter la même fonctionnalité le plus efficacement possible. + Apache httpd s'est toujours accomodé d'une grande variété d'environnements + grâce à sa conception modulaire. Cette conception autorise le webmaster + à choisir quelles fonctionnalités seront incluses + dans le serveur en sélectionnant les modules à charger soit à la + compilation, soit à l'exécution.
+ +Le serveur HTTP Apache 2.0 a étendu cette conception modulaire aux + fonctions les plus + élémentaires d'un serveur web. Le serveur est fourni avec une variété de + Modules Multi-Processus (MPMs) qui + sont responsables de l'association aux ports réseau de la machine, + acceptent les requêtes, et se chargent de répartir ces dernières + entre les différents processus enfants.
+ +L'extension de la conception modulaire à ce niveau du serveur + comporte deux avantages importants :
+ +mpm_winnt peut utiliser les fonctionnalités réseau
+ natives à la place de la couche POSIX utilisée par
+ Apache httpd 1.3. Cet avantage s'étend aussi aux systèmes d'exploitation
+ qui implémentent des MPMs spécialisés.worker ou event, tandis que les sites
+ qui privilégient la stabilité ou la compatibilité avec des logiciels
+ plus anciens peuvent utiliser un module comme
+ prefork.Du point de vue de l'utilisateur, les MPMs ne sont pas différents des + autres modules Apache httpd. La principale différence réside dans le fait qu'un + et un seul MPM à la fois doit être chargé + lorsque le serveur s'exécute. La liste des + MPMs disponibles est fournie dans l'index des + modules.
+ +La table suivante fournit la liste des MPMs par défaut pour divers +systèmes d'exploitation. Il s'agit du MPM qui sera utilisé si +vous n'en spécifiez pas un autre à la compilation.
+ +| Netware | mpm_netware |
| OS/2 | mpmt_os2 |
| Unix | prefork, worker,
+ou event, selon les possibilités de la plate-forme |
| Windows | mpm_winnt |
Ici, 'Unix' sous-entend les systèmes d'exploitation de type +Unix, comme Linux, BSD, Solaris, Mac OS X, etc...
Dans le cas des systèmes d'exploitation de type Unix, le choix du MPM +à installer est orienté par deux questions :
+1. Est-ce que le système supporte les threads ?
+2. Est-ce que le système supporte le polling thread-safe (et en +particulier les fonctions kqueue et epoll) ?
+ +Si la réponse aux deux questions est 'oui', le MPM par défaut sera
+event.
Si la réponse à la première question est 'oui', et la réponse à la
+deuxième 'non', le MPM par défaut sera worker.
Si la réponse aux deux questions est 'non', le MPM par défaut sera
+prefork.
En pratique, cela signifie que le MPM par défaut sera presque
+toujours event car tous les systèmes d'exploitation
+modernes satisfont aux deux conditions.
Les modules MPM peuvent être compilés en tant que modules +statiques sur toutes les plates-formes. A la compilation d'Apache, un +seul module MPM doit être choisi pour être compilé et lié avec le +serveur. La recompilation du serveur sera donc nécessaire si vous +souhaitez changer de module MPM.
+ +Pour choisir un module MPM autre que le MPM par défaut,
+ utiliser l'argument
+ --with-mpm=NOM du script
+ configure. NOM est le nom
+ du MPM désiré.
Une fois le serveur compilé, il est possible de savoir quel MPM
+ a été choisi à l'aide de la commande ./httpd -l.
+ Cette commande fournit la liste de tous les modules compilés
+ avec le serveur, y compris le MPM.
Sous Unix et les plates-formes similaires, les modules MPM
+ peuvent être compilés en tant que modules DSO et chargés
+ dynamiquement dans le serveur comme tout module DSO. Compiler les
+ modules MPM en tant que modules DSO permet de changer de MPM en
+ modifiant la directive LoadModule concernée, sans avoir à
+ recompiler le serveur.
LoadModule mpm_prefork_module modules/mod_mpm_prefork.so+ + +
Toute tentative de charger plusieurs modules MPM via la directive
+ LoadModule empêchera le
+ serveur de démarrer et affichera l'erreur suivante :
AH00534: httpd: Configuration error: More than one MPM
+ loaded.
Cette fonctionnalité est activée via l'option
+ --enable-mpms-shared du script
+ configure. Si on ajoute l'argument
+ all, tous les modules MPM disponibles sur la
+ plate-forme considérée seront installés. Cet argument peut aussi
+ contenir une liste de modules MPM à installer.
Le module MPM par défaut, sélectionné automatiquement ou spécifié
+ via l'option --with-mpm du script
+ configure, sera chargé via une directive
+ LoadModule du fichier de
+ configuration du serveur généré. Pour choisir un autre module MPM,
+ vous devrez donc modifier cette directive
Serveur HTTP Apache Version 2.4
+Ce document décrit les changements majeurs apportés entre les + versions 1.3 et 2.0 du serveur HTTP Apache.
+autoconf et libtool,
+ ce qui rend la compilation d'Apache httpd plus familière aux utilisateurs
+ d'autre logiciels de mème type.mod_echo illustre ces
+ possibilités.Listen,
+ NameVirtualHost et
+ VirtualHost supportent également
+ les adresses IPv6 (comme par exemple, dans "Listen[2001:db8::1]:8080").INCLUDES fourni
+ par le module mod_include. Le module
+ mod_ext_filter permet quant à lui l'utilisation comme
+ filtres de programmes externes à Apache, de la même manière
+ qu'on peut utiliser des programmes CGI comme Handlers.Port et BindAddress, souvent
+ sources d'incompréhension, ont disparus. Désormais seule la directive
+ Listen sert de liaison pour les
+ adresses IP; la directive ServerName ne
+ précise le nom du serveur et son port que pour les redirections et la
+ gestion des hôtes virtuels.mod_sslmod_davmod_deflatemod_auth_ldapmod_ldap, permet de globaliser les connexions à l'arbre LDAP
+ et de garder en mémoire cache ces accès.mod_auth_digestmod_charset_litemod_file_cachemod_mmap_static présent du serveur
+ HTTP Apache 1.3, et offre des
+ fonctions plus avancées pour la gestion du cache.mod_headersmod_proxy, et pour positionner les
+ en-têtes des réponses de manière conditionnelle.mod_proxy<Proxy>
+ donnent un contrôle plus lisible et un traitement plus rapide des requêtes
+ mandatées ; les configurations surchargées <Directory
+ "proxy:..."> ne sont pas supportées. Le module a aussi été
+ fragmenté en plusieurs modules qui gèrent chacun leur protocole :
+ proxy_connect, proxy_ftp et
+ proxy_http.mod_negotiationForceLanguagePriority a été ajoutée,
+ elle permet de garantir que le client reçoit un seul document dans tous les
+ cas, au lieu de réponses NOT ACCEPTABLE ou MULTIPLE CHOICES. Les
+ algorithmes gérant la négociation et les vues multiples (MultiViews) ont
+ été nettoyés et donnent des réponses plus logiques. Un nouveau format de
+ carte de types (map type) qui peut gérer le contenu de documents a
+ aussi été ajouté.mod_autoindexmod_include$0 à $9.mod_auth_dbmAuthDBMType.Serveur HTTP Apache Version 2.4
+Ce document décrit quelques uns des changements principaux entre + les versions 2.0 et 2.2 du serveur HTTP Apache. Pour les + nouvelles fonctionnalités ajoutées depuis la version 1.3, se + référer au document + 2.0 new features.
+ Améliorations du système de base Améliorations des modules Améliorations des programmes Changements pour le développeur de modulemod_cache, mod_cache_disk, et
+ mod_mem_cache (supprimés dans la version 2.3/2.4) ont subi de nombreuses
+ modifications, et l'on considère qu'ils ont maintenant atteint
+ un degré de qualité suffisant pour leur mise en production. Le programme
+ htcacheclean a été ajouté afin de rendre
+ plus propre la configuration du module
+ mod_cache_disk.prefork,
+ worker et event permettent
+ maintenant l'arrêt en douceur de httpd
+ au moyen du signal
+ graceful-stop.
+ La directive GracefulShutdownTimeout a été ajoutée dans le but
+ de spécifier un délai optionnel, après lequel
+ httpd s'arrêtera quel que soit le statut
+ des requêtes en cours.mod_proxy_balancer fournit
+ des services de répartition de charge (load balancing) pour le
+ module mod_proxy.
+ Le nouveau module mod_proxy_ajp ajoute le
+ support pour le
+ Protocole JServ de Apache version 1.3 qu'utilise
+ Apache Tomcat.httpd peut être configuré pour utiliser une
+ PCRE choisie en passant l'option --with-pcre au
+ script configure.mod_filter permet la configuration
+ dynamique de la chaîne de filtrage en sortie. Il permet
+ d'insérer des filtres conditionnels basés sur toute
+ requête, en-tête de réponse ou variable
+ d'environnement, et fait table rase des problèmes de dépendances
+ et d'ordonnancement rencontrés avec l'architecture 2.0.httpd supporte maintenant les fichiers d'une taille supérieure
+ à 2GB sur les systèmes 32 bits UNIX modernes. Le support des
+ corps de requête d'une taille supérieure à 2GB a aussi été
+ ajouté.event utilise un thread séparé
+ pour gérer les requêtes "Keep alive" et accepter des connexions.
+ Les requêtes "Keep alive" requéraient traditionnellement un
+ processus httpd dédié pour leur gestion. Ce processus dédié
+ ne pouvait plus être réutilisé jusqu'à ce que le délai "Keep Alive"
+ soit écoulé.mod_dbd, associé à l'environnement
+ apr_dbd, fournit le support SQL direct aux modules
+ qui en ont besoin. Supporte la mise en commun des connexions
+ dans les modules MPM threadés.mod_auth
+ est maintenant scindé en deux modules : mod_auth_basic et
+ mod_authn_file; mod_auth_dbm s'appelle maintenant
+ mod_authn_dbm; mod_access a été renommé en
+ mod_authz_host. Est également apparu le nouveau module
+ mod_authn_alias (supprimé dans la version 2.3/2.4) qui simplifie
+ certaines configurations d'authentification.
+ mod_authnz_ldapmod_auth_ldap vers la version 2.2 du framework
+ Authn/Authz.
+ Les nouvelles fonctionnalités comprennent l'utilisation des valeurs
+ d'attributs LDAP et des filtres de recherche avancés dans la
+ directive Require.mod_authz_ownermod_versionmod_info?config a été ajouté, qui permettra d'afficher
+ les directives de configuration telles qu'elles sont interprétées
+ par Apache, y compris le nom de fichier et le numéro de ligne.
+ Le module montre aussi l'ordre des points d'entrée de traitement d'une
+ requête (request hooks) ainsi que des informations de construction
+ supplémentaires, d'une manière similaire à httpd -V.mod_sslmod_imagemapmod_imap a été renommé en mod_imagemap afin
+ d'éviter une confusion pour les utilisateurs.httpd-M
+ a été ajoutée, qui fournit la liste de tous les modules chargés
+ en fonction de la configuration réelle. À la différence de l'option
+ -l, cette liste inclut les Objets Dynamiques Partagés
+ (DSOs) chargés par l'intermédiaire du module
+ mod_so.httxt2dbmRewriteMap
+ et le type de mise en correspondance dbm.APR et
+ APR-Util. Pour plus de détails, consultez le
+ site web d'APR.mod_auth_* -> Modules qui implémentent un mécanisme
+ d'authentification HTTPmod_authn_* -> Modules qui fournissent un dispositif
+ d'authentification en arrière-planmod_authz_* -> Modules qui implémentent l'autorisation (ou l'accès)mod_authnz_* -> Modules qui implémentent à la fois
+ l'authentification & l'autorisationap_log_cerror,
+ afin de pouvoir enregistrer les erreurs qui surviennent au cours de
+ la connexion du client. Une fois enregistré, le message inclut l'adresse IP du client.test_config,
+ afin d'aider les modules qui ne veulent exécuter un code spécial
+ que si l'utilisateur passe le paramètre -t à
+ httpd.ThreadStackSize
+ afin de définir la taille de la pile pour tous les modules MPM en processus légers (modules threadés).
+ Ceci s'avère nécessaire pour certains modules tiers sur des plateformes
+ dont la taille de la pile des threads par défaut est
+ trop petite.mod_filter, à l'aide des appels
+ ap_register_output_filter_protocol ou
+ ap_filter_protocol.pcreposix.h n'est plus disponible ;
+ il a été remplacé par le nouveau fichier
+ d'en-tête ap_regex.h. L'implémentation
+ POSIX.2 regex.h exposée dans l'ancien fichier d'en-tête
+ est maintenant disponible dans l'espace de nommage ap_
+ depuis ap_regex.h. Les appels à regcomp,
+ regexec, etc... peuvent être remplacés par des appels à
+ ap_regcomp, ap_regexec.Avec Apache 1.x et 2.0, les modules nécessitant un processus + SQL d'arrière-plan devaient s'en charger eux-mêmes. En dehors du fait + de réinventer la roue, ceci peut s'avérer très inefficace, par + exemple lorsque plusieurs modules maintiennent chacun leurs + propres connexions.
+Apache 2.1 et supérieur fournissent l'API ap_dbd qui
+ permet la gestion des connexions à la base de données (y compris
+ les stratégies optimisées pour les modules MPM threadés
+ et non threadés), tandis que APR 1.2 et supérieur fournissent
+ l'API apr_dbd qui permet l'interaction avec la
+ base de données.
Les nouveaux modules DEVRAIENT désormais utiliser ces APIs pour + toutes les opérations liées aux bases de données SQL. + De même, les applications existantes DEVRAIENT être mises à jour + lorsque c'est possible, que ce soit de manière transparente ou sous forme + d'une option recommandée à leurs utilisateurs.
Serveur HTTP Apache Version 2.4
+Ce document décrit les modifications majeures apportées par + la version 2.4 du serveur HTTP Apache. Pour les nouvelles fonctionnalités + ajoutées par la version 2.2, se référer au document + Nouvelles fonctionnalités + de la version 2.2.
+ Améliorations du noyau Nouveau modules Améliorations des modules Améliorations des programmes Documentation Modifications concernant les développeur de modulesLoadModule.LogLevel
+ peut maintenant être définie par module et par répertoire. Les
+ nouveaux niveaux trace1 à trace8 ont été
+ ajoutés au dessus du niveau de journalisation debug.If,
+ <ElseIf> et
+ <Else>
+ permettent de définir une configuration en fonction de critères
+ liés à la requête.SetEnvIfExpr, RewriteCond, Header,
+ <If>, etc...
+ KeepAliveTimeout en millisecondes.
+ .htaccessAllowOverrideList permet de contrôler de
+ manière plus précise la liste des directives autorisées dans les
+ fichiers .htaccess.Define
+ permet de définir des variables dans les fichiers de
+ configuration, améliorant ainsi la clareté de la présentation si
+ la même valeur est utilisée en plusieurs points de la
+ configuration.
+ mod_proxy_fcgimod_proxy.mod_proxy_scgimod_proxy.mod_proxy_expressmod_proxy la configuration dynamique
+ de mandataires inverses en masse.mod_remoteipmod_heartmonitor,
+ mod_lbmethod_heartbeatmod_proxy_balancer de répartir la
+ charge en fonction du nombre de connexions actives sur les
+ serveurs d'arrière-plan.mod_proxy_htmlmod_sedmod_substitute qui permet
+ d'éditer le corps de la réponse avec toute la puissance de la
+ commande sed.mod_auth_formmod_sessionmod_allowmethodsmod_luamod_log_debugmod_buffermod_datamod_ratelimitmod_requestmod_reflectormod_slotmem_shmmod_xml2encmod_macro (disponible à partir de la version 2.4.5)mod_proxy_wstunnel (disponible à partir de la version 2.4.5)mod_authnz_fcgi (disponible à partir de la version 2.4.10)mod_http2 (disponible à partir de la version 2.4.17)mod_proxy_hcheck (disponible à partir de la version 2.4.21)mod_sslmod_ssl peut maintenant vérifier la
+ validité des certificats clients en se connectant à
+ un serveur OCSP. Il est possible de définir un
+ répondeur par défaut, et de choisir si l'on
+ préfère le répondeur désigné
+ dans le certificat client.mod_ssl supporte maintenant
+ l'estampillage OCSP (OCSP stapling), qui permet au serveur
+ d'attester la validité de son certificat auprès du client au
+ cours de la phase de négociation de la connexion.mod_ssl peut maintenant être configuré pour
+ que celui-ci partage les données de session SSL entre les serveurs
+ via memcached.mod_proxyProxyPass est maintenant configurée
+ de manière optimale dans les sections Location ou LocationMatch, et offre un gain de
+ performances important par rapport à la syntaxe traditionnelle à
+ deux paramètres lorsqu'elle est présente en grand nombre.mod_proxy_balancermod_cachemod_cache peut être
+ inséré à un certain point de la chaîne de filtrage pour contrôler
+ plus finement la mise en cache.
+ mod_cache peut maintenant mettre en cache des
+ requêtes HEAD.mod_cache peuvent maintenant être définies au
+ niveau du répertoire, et non plus seulement au niveau du serveur
+ principal.mod_cache peut maintenant servir du contenu
+ non mis à jour lorsqu'un serveur d'arrière-plan n'est pas
+ disponible (erreur 5xx).mod_cache peut maintenant insérer
+ HIT/MISS/REVALIDATE dans un en-tête X-Cache.mod_includemod_cgi, mod_include,
+ mod_isapi, ...mod_authz_core Conteneurs de logique d'autorisationRequire et les directives de
+ conteneurs associées, comme <RequireAll>, permettent de définir une
+ logique d'autorisation avancée.mod_rewriteRewriteRule dispose maintenant
+ des drapeaux [QSD] (Query String Discard) et
+ [END] qui permettent de simplifier les scénarios de
+ réécriture courants.RewriteCond.RewriteMap.mod_ldap, mod_authnz_ldapmod_authnz_ldap ajoute le support des
+ groupes imbriqués.mod_ldap apporte les directives LDAPConnectionPoolTTL et LDAPTimeout, ainsi que d'autres
+ améliorations dans le traitement des délais. Ceci s'avère utile
+ pour les configurations où un pare-feu à mémoire d'état (stateful)
+ rejète les connexions inactives vers le serveur LDAP.mod_ldap propose la directive LDAPLibraryDebug qui permet de
+ journaliser les informations de débogage fournies par la boîte à
+ outils LDAP utilisée.mod_infomod_info est maintenant capable d'afficher la
+ configuration préinterprétée sur stdout au cours du démarrage du
+ serveur.mod_auth_basicfcgistarterhtcachecleanrotatelogshtpasswd, htdbmmod_rewrite a
+ été réorganisée et presque entièrement réécrite en mettant
+ l'accent sur les exemples et l'utilisation courante, ainsi que
+ sur l'incitation à utiliser d'autres solutions lorsque cela
+ s'avère plus approprié. Le document Rewrite
+ Guide constitue maintenant une section de premier niveau ;
+ il est mieux organisé et contient beaucoup plus de détails.mod_ssl a été
+ grandement améliorée, avec plus d'exemples et un niveau "Bien
+ démarrer" qui s'ajoutent aux détails techniques déjà présents
+ dans la précédente documentation.mod_cache, et la mise en cache
+ générique de type clé/valeur fournie par l'interface socache, mais aussi pour couvrir la mise
+ en cache spécialisée fournie par des mécanismes tels que ceux du
+ module mod_file_cache.check_config, a été ajoutée et
+ s'exécute entre les fonctions pre_config et
+ open_logs. Elle s'exécute aussi avant la fonction
+ test_config si l'option -t est passée au
+ démon httpd. La fonction check_config
+ permet aux modules de vérifier l'interdépendance des valeurs des
+ directives de configuration et d'ajuster ces valeurs, alors que les
+ messages du serveur peuvent encore être affichés sur la console.
+ L'utilisateur est ainsi averti des erreurs de configuration avant que la
+ fonction du noyau open_logs ne redirige les sorties de la
+ console vers le journal des erreurs.mod_ssl.<RequireAll>, les modules d'autorisation
+ s'enregistrent maintenant en tant
+ que fournisseur par le biais de ap_register_auth_provider().mod_ssl. Sont supportés
+ actuellement : les fournisseurs utilisant un tampon cyclique en
+ mémoire partagée, les fichiers dbm sur disque, et les caches
+ distribués de type memcache.mod_cache inclut maintenant un
+ nouveau point d'ancrage, cache_status, qui est appelé
+ lorsque la décision à propos de la mise en cache est connue. Il en
+ existe une implémentation par défaut qui ajoute les en-têtes
+ optionnels X-Cache et X-Cache-Detail à
+ la réponse.La documentation du développeur contient une liste détaillée des modifications + de l'API.
+Serveur HTTP Apache Version 2.4
+Ce document explique comment installer, configurer et + exécuter Apache 2.4 sous Microsoft Windows.
+ + +Il y a de nombreux points importants à connaître avant de se + lancer dans la compilation d'Apache. Ce document en donne la + description.
+ + +Ce document explique comment installer, configurer et + exécuter Apache 2.4 sur des systèmes qui supportent le format de + paquet RPM.
+ +Voir : Utilisation d'Apache avec les + systèmes à base de paquets RPM
+Ce document explique comment installer, configurer et + exécuter Apache 2.4 sous Novell NetWare versions 5.1 et + supérieures.
+ + +La version 1.3 du serveur HTTP Apache est la première à + avoir été portée vers une machine de type mainframe (non-ASCII) + qui utilisait le jeu de caractères EBCDIC comme jeu de + caractères natif.
+ +Serveur HTTP Apache Version 2.4
+Ce document explique l'installation, la configuration et le + lancement d'Apache 2.0 sous Novell NetWare 6.0 et les versions + ultérieures. Si vous trouvez une bogue, ou voulez tout simplement + contribuer de quelque manière que ce soit, utilisez s'il vous plait + notre page des + rapports de bogues.
+ +La page des rapports de bogues et la liste de diffusion dev-httpd + ne doivent pas être utilisées pour poser des questions à propos de + la configuration ou du lancement d'Apache. Avant de soumettre un + rapport de bogue ou une question, consultez ce document, la FAQ ou tout autre sujet de la + documentation en rapport avec votre problème. Si vous n'avez + toujours pas résolu votre problème, postez votre question dans le + newsgroup + novell.devsup.webserver, où de nombreux utilisateurs d'Apache + sont prêts à répondre à toutes les nouvelles et obscures questions à + propos de l'utilisation d'Apache sous Netware.
+ +Dans la majeure partie de ce document, vous êtes sensé avoir + installé Apache à partir d'une distribution binaire. Si vous voulez + compiler Apache vous-même (par exemple pour aider au développement, + ou pour rechercher des bogues), reportez-vous à la section traitant + de la Compilation d'Apache pour Netware + ci-dessous.
+ + Prérequis Téléchargement d'Apache pour NetWare Installation d'Apache pour NetWare Exécuter Apache pour NetWare Configuration d'Apache pour NetWare Compilation d'Apache pour NetWareApache 2.0 nécessite NetWare 6.0 service pack 3 et supérieurs + pour fonctionner. Si vous utilisez un service pack antérieur à SP3, + vous devez installer les dernières Bibliothèques + Netware pour C (LibC).
+ +Vous trouverez les service packs Netware ici.
+ +Apache 2.0 pour NetWare peut aussi fonctionner dans un + environnement NetWare 5.1, à partir du moment où le dernier service + pack ou la dernière version des Bibliothèques + Netware pour C (LibC) ont été installés. ATTENTION + : Apache 2.0 pour NetWare n'a pas été testé dans cet + environnement car il n'a pas été conçu pour ce dernier.
+ +Les informations à propos de la dernière version + d'Apache sont disponibles sur le site web d'Apache à http://www.apache.org/. Vous y + trouverez la version courante, des versions alpha ou bêta-test plus + récentes, ainsi que des sites miroirs et des sites FTP anonymes. Les + distributions binaires des dernières versions d'Apache 2.0 pour + NetWare sont disponibles ici.
+ +Il n'existe pas actuellement de programme d'installation d'Apache + pour Netware. Si vous installez Apache 2.0 pour NetWare à partir des + sources, vous devrez copier les fichiers sur le serveur + manuellement.
+ +Suivez ces instructions pour installer Apache sous Netware à
+ partir de la distribution binaire (en supposant que vous effectuez
+ l'installation dans sys:/apache2) :
SYS: (vous pouvez cependant l'installer dans
+ tout volume)httpd.conf et définissez les
+ directives ServerRoot et
+ ServerName avec les valeurs
+ correctes des chemins de fichiers qui correspondent à la
+ configuration de votre serveur.SYS:/APACHE2 au chemin de recherche, par
+ une commande du style : SEARCH ADD
+ SYS:\APACHE2
Suivez ces instructions pour installer Apache pour Netware
+ manuellement à partir de votre propre répertoire de sources (en
+ supposant que vous effectuez l'installation dans
+ sys:/apache2) :
Apache2
+ dans un volume Netware.APACHE2.NLM, APRLIB.NLM dans
+ SYS:/APACHE2.BIN dans
+ SYS:/APACHE2.HTDIGEST.NLM, HTPASSWD.NLM,
+ HTDBM.NLM, LOGRES.NLM,
+ ROTLOGS.NLM dans SYS:/APACHE2/BIN.CONF dans
+ SYS:/APACHE2.HTTPD-STD.CONF dans le
+ répertoire SYS:/APACHE2/CONF et renommez-le en
+ HTTPD.CONF.MIME.TYPES,
+ CHARSET.CONV et MAGIC dans le répertoire
+ SYS:/APACHE2/CONF.\HTTPD-2.0\DOCS\ICONS dans
+ SYS:/APACHE2/ICONS.\HTTPD-2.0\DOCS\MANUAL dans
+ SYS:/APACHE2/MANUAL.\HTTPD-2.0\DOCS\ERROR dans
+ SYS:/APACHE2/ERROR.\HTTPD-2.0\DOCS\DOCROOT dans
+ SYS:/APACHE2/HTDOCS.SYS:/APACHE2/LOGS sur le
+ serveur.SYS:/APACHE2/CGI-BIN sur le
+ serveur.SYS:/APACHE2/MODULES et
+ copiez tous les modules nlm dans le répertoire
+ modules.HTTPD.CONF, et recherchez
+ toutes les marques @@Value@@ afin de les remplacer
+ par les valeurs appropriées.SYS:/APACHE2 au chemin de recherche, par
+ une commande du style : SEARCH ADD
+ SYS:\APACHE2
Outre le volume par défaut SYS, Apache peut être
+ installé dans tout autre volume.
Au cours du processus d'installation, l'ajout du mot-clé
+ "install" à la ligne de commande du makefile va provoquer la
+ construction d'une distribution complète sous forme d'un paquetage
+ dans le sous-répertoire DIST. Vous pouvez simplement
+ installer Apache en copiant la distribution créée précédemment à la
+ racine d'un volume Netware (voir Compilation
+ d'Apache pour NetWare ci-dessous).
Pour démarrer Apache, tapez simplement apache dans
+ la console. Ceci aura pour effet de charger Apache dans l'espace
+ d'adressage du système d'exploitation. Si vous préférez charger
+ Apache dans un espace d'adressage protégé, vous pouvez spécifier cet
+ espace d'adressage à l'aide de l'instruction de chargement suivante
+ :
+ load address space = apache2 apache2
+
Cette instruction va charger Apache dans un espace d'adressage + appelé apache2. Il est possible d'exécuter plusieurs instances + simultanées d'Apache sous Netware, en chargeant chacune d'entre + elles dans son propre espace d'adressage protégé.
+ +Une fois démarré, Apache écoute le port 80 (à moins que vous
+ n'ayez modifié la directive Listen dans les fichiers de
+ configuration). Pour vous connecter au serveur et afficher la page
+ par défaut, lancez un navigateur et entrez le nom du serveur ou son
+ adresse IP. Vous devriez voir une page de bienvenue, et un lien vers
+ le manuel Apache. Si rien ne se produit, ou si vous obtenez un
+ message d'erreur, consultez le fichier error_log dans
+ le répertoire logs.
Lorsque votre installation de base fonctionne, vous devez la
+ configurer correctement en éditant les fichiers du répertoire
+ conf.
Pour arrêter une instance d'Apache s'exécutant dans l'espace + d'adressage du système d'exploitation, entrez simplement dans la + console :
+ +
+ unload apache2
+
ou
+ +
+ apache2 shutdown
+
Si Apache s'exécute dans un espace d'adressage protégé, spécifiez + cet espace d'adressage dans l'instruction d'arrêt :
+ +
+ unload address space = apache2 apache2
+
Lorsqu'on travaille avec Apache, il est important de savoir + comment il trouve ses fichiers de configuration. Vous pouvez + spécifier un fichier de configuration sur la ligne de commande de + deux manières :
+ +-f spécifie un chemin vers un fichier de
+ configuration particulier
+ apache2 -f "vol:/nom-serveur/conf/fich-conf.conf"
+
+ apache -f test/test.conf
+
Dans ces cas, la directive ServerRoot doit être correctement définie
+ dans le fichier de configuration.
Si vous ne spécifiez pas de nom de fichier de configuration avec
+ l'option -f, Apache utilisera le nom de fichier codé en
+ dur dans le serveur, en général conf/httpd.conf.
+ L'invocation d'Apache avec l'option -V indiquera ce nom
+ comme valeur de l'étiquette SERVER_CONFIG_FILE. Apache
+ va ensuite déterminer son ServerRoot en effectuant les tests
+ suivants, dans cet ordre
ServerRoot via une option
+ -C switch.-d.La racine du répertoire d'installation codée en dur dans le
+ serveur est en général sys:/apache2. L'invocation
+ d'Apache avec l'option -V indiquera ce chemin comme
+ valeur de l'étiquette HTTPD_ROOT.
Apache 2.0 pour Netware comporte un jeu d'options de ligne de
+ commande permettant d'afficher ou de modifier certaines
+ caractéristiques de l'instance du serveur web en cours d'exécution.
+ Ces options ne sont disponibles que lorsqu'Apache est en cours
+ d'exécution. Chacune de ces options doit être précédée du mot-clé
+ APACHE2.
Par défaut, ces options sont passées à l'instance d'apache + s'exécutant dans l'espace d'adressage du système d'exploitation. + Pour passer une option à une instance d'Apache spécifique + s'exécutant dans un espace d'adressage protégé, ajouter le paramètre + -p suivi du nom de l'espace d'adressage. Pour plus d'informations, + tapez "apache2 Help" sur la ligne de commande.
+ +Apache lit en général ses fichiers de configuration dans le
+ répertoire conf. Ces fichiers sont les mêmes que ceux
+ de la version Unix, mais quelques directives sont différentes sous
+ Netware. Voir la Documentation Apache pour
+ l'ensemble des directives disponibles.
Les principales différences propres à Apache pour NetWare sont + :
+ +Comme Apache pour Netware est une application multithread, + elle n'utilise pas de processus séparé pour chaque requête, + comme c'est le cas pour certaines implémentations sous Unix. Il + n'y a que des threads en cours d'exécution : un thread parent, + et plusieurs threads enfants ou worker qui traitent les + requêtes.
+ +En conséquence, les directives de gestion des "processus" + sont différentes :
+ +MaxConnectionsPerChild - comme sous
+ Unix, cette directive contrôle le nombre maximum de connexions
+ qu'un worker thread peut traiter avant de s'arrêter. Avec la
+ valeur par défaut MaxConnectionsPerChild 0,
+ le thread va pouvoir traiter un nombre illimité de requêtes.
+ Cette valeur est recommandée sous Netware, à moins que vous
+ n'ayez des raisons particulières de la modifier.
StartThreads -
+ Cette directive indique au serveur le nombre de threads qu'il
+ doit lancer au démarrage. Il est recommandé de conserver la
+ valeur par défaut StartThreads 50.
MinSpareThreads -
+ Cette directive indique au serveur le nombre de worker threads
+ additionnels qu'il doit lancer si le nombre de threads inactifs
+ tombe en dessous de cette valeur. Il est recommandé de conserver la
+ valeur par défaut MinSpareThreads 10.
MaxSpareThreads -
+ Cette directive indique au serveur qu'il doit commencer à
+ arrêter des worker threads si le nombre de threads inactifs
+ passe au dessus de cette valeur. Il est recommandé de conserver
+ la valeur par défaut MaxSpareThreads 100.
MaxThreads -
+ Cette directive impose un nombre maximum de worker threads. Il
+ est recommandé de conserver la valeur par défaut
+ ThreadsPerChild 250.
ThreadStackSize -
+ Cette directive indique au serveur la taille de la pile à
+ utiliser pour un worker thread individuel. Il est recommandé de
+ conserver la valeur par défaut ThreadStackSize
+ 65536.
Les directives qui acceptent des noms de fichiers comme
+ arguments ne doivent pas utiliser des noms de fichiers Unix,
+ mais des noms de fichiers Netware. Cependant, comme Apache
+ utilise des noms de style Unix en interne, on doit utiliser des
+ slashes et non des antislashes. Il est recommandé de préfixer
+ tous les chemins de fichiers racines par un nom de volume. Si ce
+ dernier est omis, Apache supposera que le volume est
+ SYS:, ce qui n'est pas forcément correct.
Apache pour Netware a la possibilité de charger des modules
+ en cours d'exécution, sans avoir à recompiler le serveur. Si
+ Apache est compilé avec les options par défaut, il va installer
+ de nombreux modules optionnels dans le répertoire
+ \Apache2\modules. Pour les activer, ou en activer
+ d'autres, on doit utiliser la directive LoadModule. Par exemple, pour
+ activer le module status, ajoutez la ligne suivante :
+ LoadModule status_module modules/status.nlm
+
Des informations à propos de la création de modules + chargeables sont aussi disponibles.
+CGIMapExtension -
+ Cette directive associe une extension de fichier CGI à un
+ interpréteur de script.SecureListen -
+ Cette directive active le chiffrement SSL pour un port
+ spécifique.NWSSLTrustedCerts -
+ Cette directive permet d'ajouter des certificats de confiance
+ pouvant être utilisés pour créer des connexions sécurisées vers
+ des serveurs mandataires.NWSSLUpgradeable -
+ Cette directive permet de faire passer en SSL une connexion
+ initialisée sur les adresse IP et Port spécifiés.La compilation d'Apache nécessite MetroWerks CodeWarrior 6.x ou
+ supérieur. Une fois compilé, Apache peut être installé à la racine
+ de tout volume Netware. Le répertoire d'installation par défaut est
+ sys:/Apache2.
Avant de démarrer Apache, vous devez remplir le répertoire
+ conf. Copiez le fichier HTTPD-STD.CONF
+ depuis le répertoire conf de la distribution et
+ renommez-le en HTTPD.CONF. Editez le fichier
+ HTTPD.CONF en recherchant les repères
+ @@Value@@, et remplacez ces derniers par la valeur
+ appropriée. Copiez de même les fichiers conf/magic et
+ conf/mime.types. Vous pouvez aussi construire une
+ distribution complète en ajoutant le mot-clé install
+ lors de l'invocation des makefiles.
Les outils de développement suivants sont nécessaires pour la + compilation d'Apache pour Netware :
+ +awk.exe.NOVELLLIBC avec le chemin des bibliothèques Netware
+ pour C SDK ; par exemple : Set
+ NOVELLLIBC=c:\novell\ndk\libc
METROWERKS avec le chemin de votre compilateur
+ Metrowerks CodeWarrior ; par exemple : Set
+ METROWERKS=C:\Program Files\Metrowerks\CodeWarrior
C:\Program Files\Metrowerks\CodeWarrior, vous
+ n'avez pas besoin de définir cette variable.LDAPSDK
+ avec le chemin des bibliothèques LDAP pour C ; par exemple :
+ Set
+ LDAPSDK=c:\Novell\NDK\cldapsdk\NetWare\libc
ZLIBSDK
+ avec le chemin du code source de la bibliothèque Zlib ; par
+ exemple : Set ZLIBSDK=D:\NOVELL\zlib
PCRESDK
+ avec le chemin d'installation du code source de la bibliothèque
+ PCRE ; par exemple :
+ Set PCRESDK=D:\NOVELL\pcre
AP_WORK
+ avec le chemin du code source de httpd.
+ Set AP_WORK=D:\httpd-2.0.x
APR_WORK
+ avec le chemin du code source d'apr ; en général
+ \httpd\srclib\apr, mais le projet APR peut se
+ trouver en dehors de la structure des répertoires de httpd.
+ Set APR_WORK=D:\apr-1.x.x
APU_WORK
+ avec le chemin du code source d'apr-util ; en
+ général \httpd\srclib\apr-util, mais le projet
+ APR-UTIL peut se trouver en dehors de la structure des
+ répertoires de httpd. Set
+ APU_WORK=D:\apr-util-1.x.x
gmake.exe) ont bien été inclus dans la variable
+ d'environnement système PATH.\httpd-2.0
+ et compilez les utilitaires précompilés à l'aide de la commande
+ "gmake -f nwgnumakefile prebuild". Cette cible va
+ créer le répertoire \httpd-2.0\nwprebuild, et y
+ copier tous les utilitaires nécessaires au franchissement des
+ étapes suivantes de la compilation.\httpd-2.0\nwprebuild\GENCHARS.nlm et
+ \httpd-2.0\nwprebuild\DFTABLES.nlm vers le volume
+ SYS: d'un serveur Netware et exécutez-les à l'aide
+ des commandes suivantes :
+
+ SYS:\genchars > sys:\test_char.h
+ SYS:\dftables sys:\chartables.c
+
test_char.h et
+ chartables.c vers le répertoire
+ \httpd-2.0\os\netware de la machine où s'effectue
+ la compilation.\httpd-2.0
+ et compilez Apache à l'aide de la commande "gmake -f
+ nwgnumakefile". Vous pouvez créer un répertoire pour la
+ distribution en ajoutant le paramètre install à la commande ;
+ par exemple :
+ gmake -f nwgnumakefile install
gmake -f nwgnumakefileCompile les versions
+ de distribution de tous les binaires et les copie dans un
+ répertoire \release.
gmake -f nwgnumakefile DEBUG=1Compile les versions
+ de débogage de tous les binaires et les copie dans un
+ répertoire \debug.
gmake -f nwgnumakefile installCrée une
+ distribution complète d'Apache avec les binaires, la
+ documentation et les fichiers support dans un répertoire
+ \dist\Apache2.
gmake -f nwgnumakefile prebuildCompile tous
+ les utilitaires précompilés et les copie dans le répertoire
+ \nwprebuild.
gmake -f nwgnumakefile installdevMême effet
+ que l'option install, mais en plus, les répertoires
+ \lib et \include sont créés dans le
+ répertoire de destination, et les en-têtes et fichiers d'import
+ y sont copiés.
gmake -f nwgnumakefile cleanSupprime tous
+ les fichiers objets et les binaires de la zone de compilation
+ \release.o, ou \debug.o si
+ DEBUG a été défini.
gmake -f nwgnumakefile clobber_allMême effet + que clean, mais en plus, le répertoire de la distribution est + supprimé s'il existe.
EXPERIMENTAL :
+ Set EXPERIMENTAL=1
USE_STDSOCKETS :
+ Set USE_STDSOCKETS=1
Pour fournir les services SSL, Apache pour Netware utilise par
+ défaut le module intégré mod_nw_ssl. Ce module ne
+ fournit que les services SSL implémentés par le système
+ d'exploitation Netware lui-même pour gérer tous les chiffrements
+ pour un port donné. Cependant, on peut aussi utiliser mod_ssl de
+ la même manière que sur les autres plate-formes.
Afin de pouvoir compiler mod_ssl pour la plate-forme Netware, + les bibliothèques OpenSSL doivent être disponibles. Elles peuvent + être installées de la manière suivante :
+ +NetWare/set_env.bat, et
+ effectuez toutes modifications nécessaires des chemins des
+ outils et utilitaires en fonction de votre environnement de
+ développement.
+ Netware\set_env netware-libc
+ Netware\build netware-libc
+
+ Netware\build netware-libc nw-nasm enable-mdc2 enable-md5
+
OSSLSDK avec le chemin absolu de
+ la racine du répertoire du code source d'openssl, et
+ définissez WITH_MOD_SSL à 1.
+
+ Set OSSLSDK=d:\openssl-0.9.8x
+ Set WITH_MOD_SSL=1
+
Serveur HTTP Apache Version 2.4
+Date: Wed, 05 Nov 1997 16:59:34 -0800 +From: Rick Jones <raj@cup.hp.com> +Reply-To: raj@cup.hp.com +Organization: Network Performance +Subject: HP-UX tuning tips+ +
Traduction du corps du message cité ci-dessus :
+ +Voici quelques conseils de personnalisation pour HPUX à ajouter à + la page de personnalisation.
+ +Pour HP-UX 9.X: mettre à jour vers la version 10.20
+ Pour HP-UX 10.[00|01|10]: mettre à jour vers la version 10.20
Pour HP-UX 10.20:
+ +Installez le dernier patch cumulatif à propos du transport ARPA.
+ Ceci va vous permettre de configurer la taille de la table de
+ hashage de recherche de connexion TCP. La valeur par défaut est 256
+ conteneurs et doit être une puissance de deux. À cet effet, utilisez
+ adb pour modifier l'image *disque* du noyau. Le nom de la variable
+ est tcp_hash_size. Notez qu'il est impératif d'utiliser
+ "W" pour spécifier une quantité sur 32 bits, et non
+ "w" qui indique une valeur sur 16 bits, lors de la
+ modification de l'image disque car la variable
+ tcp_hash_size est une quantité sur 32 bits.
Comment déterminer cette valeur ? Examinez la sortie de ftp://ftp.cup.hp.com/dist/networking/tools/connhist, et
+ comptez le nombre total de connexions TCP existant sur le système.
+ Il est en général souhaitable que ce nombre divisé par la taille de
+ la table de hashage soit raisonnablement petit, disons inférieur à
+ 10. Les administrateurs peuvent consulter le document SPECweb96 de
+ HP pour quelques réglages courants. On peut les trouver à http://www.specbench.org/. Si
+ un système HP-UX traite 1000 connexions SPECweb96 par seconde, une
+ valeur de temps TIME_WAIT de 60 secondes permettrait le
+ suivi de 60000 connexions TCP.
Les administrateurs peuvent tester la profondeur de leur file + d'attente d'écoute avec ftp://ftp.cup.hp.com/dist/networking/misc/listenq.
+ +Si Apache s'exécute sur un système à base de PA-8000, il est
+ conseillé de modifier l'exécutable Apache avec la commande chatr
+ afin d'utiliser une page de grande taille. La commande sera du style
+ "chatr +pi L <BINARY>". Le GID de l'exécutable en
+ cours de fonctionnement doit posséder le privilège
+ MLOCK. Pour assigner ce privilège MLOCK,
+ consultez Setprivgrp(1m). La modification peut être
+ validée en exécutant Glance et en examinant les portions de mémoire
+ du/des serveur(s) afin de s'assurer qu'elles montrent une fraction
+ non triviale du segment de texte verrouillé.
Si Apache s'exécute sur un système MP (multi-processeurs), il est
+ conseillé d'écrire un petit programme qui utilise
+ mpctl() et permettant d'associer les processus aux
+ processeurs. Un simple algorithme pid % numcpu suffira
+ probablement. Cette modification peut aussi être ajoutée dans le
+ code source.
Si l'administrateur s'intéresse au nombre de connexions
+ FIN_WAIT_2, il peut utiliser nettune pour diminuer la
+ valeur de tcp_keepstart. Il devra cependant être
+ prudent - surtout ne pas diminuer cette valeur en dessous de, disons
+ deux à quatre minutes. Si tcp_hash_size a été défini,
+ il est probablement approprié de laisser les connexions
+ FIN_WAIT_2 prendre plus de temps à expirer (peut-être
+ même la valeur par défaut de deux heures) - elles n'auront en
+ général pas un grand impact sur les performances.
On peut ajouter d'autres choses au code de base, mais elles + feront peut-être l'objet d'un autre email. N'hésitez pas à m'envoyer + un message si vous êtes intéressé.
+ +sincèrement ,
+ +rick jones
+ + + +Serveur HTTP Apache Version 2.4
+Alors que de nombreuses distributions mettent à disposition des + paquets Apache httpd supportés par le système d'exploitation + sous-jacent, il peut s'avérer nécessaire d'installer et d'utiliser + la version de base d'Apache httpd en remplacement de la version des + paquets.
+ +Bien que le projet Apache httpd ne crée pas actuellement de + paquets RPM pour les différentes distributions, il est aisé de + construire votre propre paquet RPM à partir du tarball de base + d'Apache httpd.
+ +Ce document explique comment construire, installer, configurer et + exécuter Apache httpd 2.4 sur les systèmes Unix à base de paquets + RPM.
+ + Création d'un paquet RPM source Création d'un paquet RPM Installation du serveur Configuration de l'instance par défaut d'Apache httpd Configuration d'instances d'Apache httpd supplémentaires sur
+ la même machineLe tarball d'Apache httpd peut être converti en paquet SRPM de la + manière suivante :
+ +
+ rpmbuild -ts httpd-2.4.x.tar.bz2
+
Le tarball d'Apache httpd peut être converti en paquet RPM de la + manière suivante :
+ +
+ rpmbuild -tb httpd-2.4.x.tar.bz2
+
Il sera nécessaire d'installer les paquets "-devel"
+ correspondants avant de construire les RPMs ; à cet effet, la
+ commande rpmbuild détecte automatiquement les RPMs
+ requis et en donne la liste sous forme de dépendances manquantes sur
+ votre système. Ces paquets "-devel" ne seront d'ailleurs plus
+ nécessaires une fois la création des RPMs terminée, et pourront
+ alors être supprimés sans risque.
Si tout va bien, les RPMs suivants seront créés :
+ +mod_ldap et
+ mod_authnz_ldap avec les dépendances
+ correspondantes sur openldap.mod_lua avec les dépendances
+ correspondantes sur lua.mod_proxy_html avec les
+ dépendances correspondantes sur libxml2.mod_socache_dc avec les
+ dépendances correspondantes sur distcache.mod_ssl avec les
+ dépendances correspondantes sur openssl.Le RPM httpd est le seul paquet nécessaire pour
+ obtenir un serveur de base fonctionnel. Vous pouvez l'installer
+ comme suit :
+ rpm -U httpd-2.4.x-1.i686.rpm
+
Le jeu de modules standards est inclus dans le serveur. Les + modules qui dépendent de bibliothèques externes sont fournis en tant + que paquets RPM séparés et doivent être installés si nécessaire.
+ +Les répertoires par défaut sont
+ /etc/httpd pour la configuration du serveur, et
+ /var/log/httpd pour la journalisation. L'environnement
+ par défaut du serveur web est défini dans le répertoire optionnel
+ /etc/sysconfig/httpd.
Démarrez le serveur comme suit :
+ +
+ service httpd restart
+
Il est possible d'exécuter simultanément plusieurs instances du + serveur Apache httpd sur la même machine. Chaque instance peut + posséder sa propre configuration et en fonction de cette dernière, + s'exécuter sous un utilisateur différent.
+ +Pour parvenir à ce résultat, on a fait en sorte que le script de + démarrage de httpd ait connaissance de son propre nom. Ce nom est + par la suite utilisé pour trouver le fichier d'environnement associé + au serveur, et par conséquent, la racine de l'instance du serveur + considéré.
+ +Pour créer une instance supplémentaire appelée
+ httpd-additional, suivez ces étapes :
+ ln -s /etc/rc.d/init.d/httpd /etc/rc.d/init.d/httpd-additional
+ chkconfig --add httpd-additional
+
/etc/sysconfig/httpd comme modèle :
+
+
+ # création du fichier d'environnement à partir du modèle httpd
+ cp /etc/sysconfig/httpd /etc/sysconfig/httpd-additional
+
+ # création du fichier d'environnement à partir de zéro
+ touch /etc/sysconfig/httpd-additional
+
/etc/sysconfig/httpd-additional et
+ définissez la racine de la nouvelle instance du serveur via la
+ variable d'environnement OPTIONS.
+
+
+ OPTIONS="-d /etc/httpd-additional -f conf/httpd-additional.conf"
+
/etc/httpd-additional/conf/httpd-additional.conf et
+ assurez-vous que les ports et chemins sont correctement définis.
+
+ service httpd-additional restart
+
Serveur HTTP Apache Version 2.4
+Il y a de nombreux points importants à connaître avant de + compiler Le serveur HTTP Apache pour Microsoft Windows. Avant de commencer, lisez le + document Utiliser le serveur HTTP Apache avec Microsoft + Windows.
+ +httpd peut être compilé sous Windows en utilisant une chaîne de + compilation basée sur cmake, ou à partir de fichiers projet Visual + Studio maintenus par les développeurs de httpd. La chaîne de + compilation basée sur cmake supporte directement davantage de + versions de Visual Studio, mais possède actuellement des + fonctionnalités très limitées.
+ + Prérequis Compilation à partir des sources Unix Compilation à partir de la ligne de commandes Compilation depuis l'espace de travail IDE de Developer
+ Studio Export des fichiers .mak de la ligne de commandes Installation Avertissement à propos de la compilation d'Apache à partir de
+l'arborescence de développement Compilation de httpd avec cmakePour compiler Apache, l'environnement doit satisfaire aux + conditions suivantes :
+ +Espace disque
+ +Assurez-vous de disposer d'un minimum de 200 Mo d'espace + disque disponible. Après l'installation, Apache occupe environ + 80 Mo d'espace disque, plus l'espace réservé aux journaux et au + cache, la taille de ces derniers pouvant augmenter rapidement. + Les besoins réels en espace disque dépendent étroitement de la + configuration choisie et des bibliothèques ou modules tiers + installés, en particulier lorsqu'OpenSSL est mis en oeuvre. + Comme de nombreux fichiers sont au format texte et donc + facilement compressibles, l'utilisation de la compression du + système de fichiers NTFS divise ces besoins par deux.
+Correctifs requis
+ +Le binaire httpd est compilé à l'aide de nombreux correctifs + appliqués aux paquets tiers, ce qui permet de s'assurer que le + code fourni est bien compilable et déboguable. Ces correctifs + sont disponibles à http://www.apache.org/dist/httpd/binaries/win32/patches_applied/, + et il est recommandé de les appliquer afin d'obtenir un + résultat identique aux binaires "officiels" distribués par + l'ASF.
+Microsoft Visual C++ 6.0 (Visual Studio 97) ou supérieur.
+ +Apache peut être compilé en utilisant l'outil ligne de
+ commande, ou depuis l'espace de travail IDE Visual Studio. Pour
+ la compilation depuis la ligne de commandes, l'environnement
+ doit comporter les variables the PATH,
+ INCLUDE, LIB, ainsi que d'autres
+ variables qui peuvent être définies via le script
+ vcvars32.bat :
Le SDK de la plate-forme Windows mis à jour, février 2003 ou + plus récent.
+ +Un SDK approprié pour la plate-forme Windows est inclus par + défaut dans les versions complètes (et non Express/lite) de + Visual C++ 7.1 (Visual Studio 2002) et supérieures ; les + utilisateurs peuvent ignorer ces étapes, à moins qu'ils aient + choisi d'utiliser une version plus récente ou différente du SDK.
+ +Pour pouvoir utiliser Visual C++ 6.0 or 7.0 (Studio 2000
+ .NET), l'environnement du SDK de la plate-forme doit être préparé en utilisant le
+ script setenv.bat (installé par le SDK de la plate-forme) avant de
+ lancer la compilation en ligne de commande ou l'interface GUI
+ msdev/devenv. L'installation du SDK de la plate-forme pour les
+ versions Express de Visual Studio (2003 et supérieures) devrait
+ ajuster l'environnement par défaut de manière appropriée.
+ "c:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32"
+ "c:\Program Files\Platform SDK\setenv.bat"
+
Perl et awk
+ +De nombreuses étapes recommandées ici nécessitent un + interpréteur perl durant le processus de préparation de la + compilation.
+ +Pour installer Apache à partir du système de compilation, de
+ nombreux fichiers sont modifiés via l'utilitaire
+ awk.exe. awk effectue la modification des fichiers
+ au moment de l'installation ; il a été choisi car il nécessite
+ un téléchargement de petite taille (par rapport à Perl ou
+ WSH/VB). Le site de Brian Kernighan http://www.cs.princeton.edu/~bwk/btl.mirror/ propose un
+ binaire précompilé pour Win32, http://www.cs.princeton.edu/~bwk/btl.mirror/awk95.exe, que
+ vous devez enregistrer sous le nom awk.exe (plutôt
+ que awk95.exe).
awk.exe que dans la variable PATH, ou dans le
+ chemin des exécutables spécifié par l'option de menu Tools ->
+ Options -> (Projects ->) Directories. Assurez-vous
+ qu'awk.exe est bien dans votre chemin système.gawk.exe et que le
+ fichier awk.exe est en fait un lien symbolique vers
+ le fichier gawk.exe. Le shell de commandes Windows
+ ne reconnaît pas les liens symboliques, et par conséquent la
+ compilation d'InstallBin échouera. Pour contourner le problème,
+ vous pouvez supprimer le lien awk.exe de
+ l'installation de Cygwin, et copier gawk.exe vers
+ awk.exe. Notez aussi que les portages cygwin/mingw
+ de gawk 3.0.x étaient bogués ; veuillez par conséquent effectuer
+ une mise à jour vers la version 3.1.x avant l'utilisation de
+ tout portage de gawk.[Optionnel] bibliothèque zlib (pour le module
+ mod_deflate)
Zlib doit être installée dans un sous-répertoire du
+ répertoire srclib et nommé zlib. Elle
+ doit être compilée directement à cette place. Zlib est
+ disponible à l'adresse http://www.zlib.net/ -- le
+ fonctionnement correct du module mod_deflate a
+ été vérifié avec la version 1.2.3.
+ nmake -f win32\Makefile.msc
+ nmake -f win32\Makefile.msc test
+
[Optionnel] Bibliothèques OpenSSL (pour le module
+ mod_ssl et ab.exe avec le support
+ ssl)
La configuration et la compilation d'OpenSSL nécessite + l'installation de perl.
+ +Pour pouvoir compiler mod_ssl ou le projet
+ abs.exe, qui devient ab.c avec le support SSL
+ activé, vous devez
+ télécharger OpenSSL à l'adresse http://www.openssl.org/source/,
+ et l'installer dans un sous-répertoire du répertoire
+ srclib que vous nommerez openssl. Afin
+ de préparer OpenSSL à la liaison avec le module Apache mod_ssl
+ ou abs.exe, et désactiver les fonctionnalités d'Openssl grévées
+ de brevets, vous pouvez utiliser la commande de compilation
+ suivante :
+ perl Configure no-rc5 no-idea enable-mdc2 enable-zlib VC-WIN32
+ -Ipath/to/srclib/zlib -Lpath/to/srclib/zlib
+ ms\do_masm.bat
+ nmake -f ms\ntdll.mak
+
[Optionnel] Bibliothèques de bases de données (pour
+mod_dbd et mod_authn_dbm)
La bibliothèque apr-util fournit un accès aux fonctionnalités + clients dbm (base de données à base de clés) et dbd (base de + données à base de requêtes) au serveur httpd et à certains de + ses modules, comme les modules d'authentification et + d'autorisation. Les fournisseurs sdbm dbm et odbc dbd sont + compilés automatiquement.
+ +Le support dbd inclut le paquet instantclient Oracle, MySQL, + PostgreSQL et sqlite. Par exemple, pour les compiler tous, + définissez LIB de façon à inclure le chemin des bibliothèques, + INCLUDE de façon à inclure le chemin des en-têtes, et PATH de + façon à inclure le chemin des dll et bin de chacun des quatre + SDK, et définissez la variable d'environnement DBD_LIST de façon + à indiquer au processus de compilation quels SDKs pilotes + clients du sont correctement installés ; par exemple :
+ +
+ set DBD_LIST=sqlite3 pgsql oracle mysql
+
De manière similaire, le support dbm peut être étendu avec + DBM_LIST pour compiler un fournisseur Berkeley DB (db) et/ou un + fournisseur gdbm, en configurant tout d'abord de la même manière + LIB, INCLUDE et PATH afin de s'assurer que les bibliothèques et + en-têtes de la bibliothèque client sont bien disponibles.
+ +
+ set DBM_LIST=db gdbm
+
Voir le fichier README-win32.txt pour plus d'informations à + propos de l'obtention des différents SDKs pilotes de bases de + données.
+Le projet du serveur HTTP Apache à pour politique de ne fournir + que des sources de type Unix. Les paquets source de type Windows + disponibles en téléchargement ont été élaborés par des + contributeurs, et ne seront pas forcément reconduits pour toutes les + versions. Vous pouvez cependant compiler le serveur sous Windows à + partir des sources Unix en ajoutant quelques étapes supplémentaires.
+ +
+ perl srclib\apr\build\lineends.pl
+
Vous pouvez maintenant compiler le serveur via l'environnement de + développement Visual Studio en utilisant l'IDE. Les compilations + du serveur en ligne de commande ne sont possibles avec des sources + de type Unix que si vous exportez les fichiers .mak comme indiqué + ci-dessous. +
+ +Makefile.win est le makefile principal ou racine
+ d'Apache. Pour compiler Apache sous Windows, utilisez simplement une
+ des commandes suivantes pour compiler la version
+ release ou debug :
+ nmake /f Makefile.win _apacher
+ nmake /f Makefile.win _apached
+
Ces deux commandes effectuent la compilation d'Apache. Cependant, + avec la deuxième, les fichiers résultants ne seront pas optimisés, + ce qui va faciliter l'examen pas à pas du code pour trouver des + bogues et résoudre les problèmes.
+ +Vous pouvez indiquer vos choix en matière de fournisseurs dbd et + dbm à l'aide des variables (d'environnement) additionnelles de make + DBD_LIST et DBM_LIST ; voir les commentaires à propos des + [Optionnel] Bibliothèques de bases de données ci-dessus. Consultez + les commentaires initiaux dans Makefile.win pour plus d'options + pouvant être fournies lors de la compilation.
+ +Apache peut aussi être compilé depuis l'environnement de
+ développement Visual Studio de VC++. Pour simplifier ce processus,
+ l'espace de travail Visual Studio Apache.dsw est
+ fourni. Cet espace de travail expose la liste complète des projets
+ .dsp actifs nécessaires à l'installation binaire
+ complète d'Apache. Il inclut les dépendances entre projets afin que
+ ces derniers soient compilés selon l'ordre approprié.
Ouvrez l'espace de travail Apache.dsw, et
+ sélectionnez InstallBin (compilation
+ Release ou Debug, selon vos souhaits)
+ comme Active Project. InstallBin provoque la
+ compilation de tous les projets concernés, puis invoque
+ Makefile.win pour installer les exécutables et dlls
+ compilés. Vous pouvez modifier la valeur de INSTDIR=
+ via la configuration de InstallBin, onglet Général,
+ entrée ligne de commandes de compilation. La valeur par défaut de
+ INSTDIR est le répertoire /Apache2. Si
+ vous désirez effectuer un test de compilation (sans installation),
+ sélectionnez le projet BuildBin.
Les fichiers projets .dsp sont distribués au format
+ Visual Studio 6.0 (98). Visual C++ 5.0 (97) les reconnaît. Les
+ utilisateurs de Visual Studio 2002 (.NET) et versions supérieures
+ doivent convertir Apache.dsw et les fichiers
+ .dsp en un projet Apache.sln, ainsi que
+ les fichiers .msproj ; assurez-vous de reconvertir le
+ fichier .msproj si l'un des fichiers source
+ .dsp est modifié ! Cette opération est vraiment très
+ simple, il suffit de réouvrir Apache.dsw dans l'IDE
+ VC++ 7.0 et de le reconvertir.
+ perl srclib\apr\build\cvtdsp.pl -2005
+
+ perl srclib\apr\build\cvtdsp.pl -ossl11
+
Les utilisateurs de Visual Studio 2002 (.NET) et versions
+ supérieures doivent aussi utiliser
+ la boîte de dialogue Configuration Manager du menu Build pour
+ décocher les deux versions Debug et
+ Release des modules mod_ssl
+ et mod_deflate pour abs. Ces modules
+ sont compilés
+ en invoquant nmake ou directement l'IDE avec la cible
+ BinBuild pour compiler ces modules de manière
+ conditionnelle si les sous-répertoires de srclib
+ openssl et/ou zlib existent, et en
+ fonction des définitions des variables d'environnement
+ DBD_LIST et DBM_LIST.
Les fichiers .mak exportés posent plus de problèmes,
+ mais les utilisateurs de Visual C++ 5.0 en ont besoin pour compiler
+ mod_ssl, abs (ab avec support
+ SSL) et/ou mod_deflate. Les fichiers .mak
+ supportent aussi un choix plus large de distributions de chaînes
+ d'outils C++, comme Visual Studio Express.
Vous devez tout d'abord compiler tous les projets afin de créer
+ toutes les cibles dynamiques auto-générées, de façon à ce que les
+ dépendances puissent être interprétées correctement. Compilez
+ l'ensemble du projet depuis l'IDE Visual Studio 6.0 (98), en
+ utilisant la cible BuildAll, puis utilisez le menu de
+ projet Export pour tous les makefiles (en cochant "with
+ dependencies"). Utilisez la commande suivante pour transformer les
+ chemins absolus en chemins relatifs de façon à ce que la compilation
+ puisse s'effectuer depuis n'importe quelle position dans
+ l'arborescence :
+ perl srclib\apr\build\fixwin32mak.pl
+
Vous devez exécuter cette commande depuis la racine de
+ l'arborescence des sources de httpd. Tout fichier projet
+ .mak et .dep du répertoire courant et de
+ ses sous-répertoires sera corrigé, et les repères de temps ajustés
+ en fonction des .dsp.
Vérifiez toujours le SDK de la plate-forme ou autres chemins
+ fichiers locaux, spécifiques à la machine dans les fichiers
+ .mak et .dep générés. Le répertoire
+ DevStudio\Common\MSDev98\bin\ (VC6) contient un fichier
+ sysincl.dat qui énumère toutes les exceptions. Mettez à
+ jour ce fichier (en particulier les chemins avec slashes et
+ anti-slashes, tels que sys/time.h et
+ sys\time.h) de façon à ignorer ces nouvelles
+ dépendances. Inclure les chemins d'installation locale dans un
+ fichier .mak distribué fera échouer la
+ compilation.
Si vous soumettez un patch qui modifie les fichiers projet, nous + devons valider la modification de ces fichiers projet au format + Visual Studio 6.0. Les modifications doivent êtres simples, avec un + minimum de drapeaux de compilation et d'édition de liens qui + pourront être reconnus par tous les environnements Visual + Studio.
+ +Une fois compilé, Apache doit être installé dans le répertoire
+ racine du serveur. La valeur par défaut est le répertoire
+ \Apache2, sur le même disque.
Pour compiler et installer automatiquement tous les fichiers dans
+ le répertoire rep désiré, utilisez une des commandes
+ nmake suivantes :
+ nmake /f Makefile.win installr INSTDIR=dir
+ nmake /f Makefile.win installd INSTDIR=dir
+
L'argument rep de INSTDIR permet de
+ spécifier le répertoire d'installation ; il peut être omis si Apache
+ doit être installé dans \Apache22 (du lecteur de disque
+ courant.
.dsp sont
+ maintenus d'une distribution release à l'autre. Les
+ fichiers .mak ne sont PAS régénérés, suite à
+ l'énorme perte de temps des relecteurs . Vous ne
+ pouvez donc pas utiliser les commandes NMAKE
+ ci-dessus pour compiler des fichiers de projet .dsp
+ révisés si vous n'exporter pas ensuite vous-même tous les
+ fichiers .mak du projet. Ceci n'est pas nécessaire
+ si vous effectuez la compilation depuis l'environnement
+ Microsoft Developer Studio.La documentation principale pour ce mécanisme de compilation se trouve
+ dans le fichier README.cmake situé dans l'arborescence
+ des sources. Consultez ce fichier pour des instructions détaillées.
Pour compiler httpd avec cmake, vous devez compiler APR et APR-util
+ séparément. Consultez les fichiers README.cmake de ces
+ projets pour obtenir des instructions.
Les principales limitations de la compilation basée sur cmake sont + héritées du projet APR-util et sont énumérées ci-dessous à cause de + leur impact sur httpd :
+ +mod_charset_lite et probablement
+ d'autres modules tiers.Serveur HTTP Apache Version 2.4
+Ce document décrit l'installation, la configuration et + l'exécution d'Apache 2.4 sous Microsoft Windows. Si vous avez des + questions après avoir lu la documentation, ou si vous avez rencontré + des évènements particuliers ou des rapports d'erreur, vous pouvez + consultez la liste + de diffusion de la communauté des utilisateurs.
+ +Dans ce document, nous supposons que vous installez une + distribution binaire d'Apache. Si vous voulez compiler Apache + vous-même (par exemple pour aider au développement ou pour + rechercher des bogues), référez-vous au document Compilation d'Apache pour Microsoft + Windows.
+ + Prérequis du système d'exploitation Téléchargement d'Apache pour Windows Personnaliser Apache pour Windows Exécuter Apache en tant que service Exécuter Apache depuis la console Vérification de l'installation Configuration de l'accès aux ressources réseau Personnalisation sous WindowsLa plate-forme Windows de base pour l'exécution d'Apache 2.4 est + Windows 2000 ou supérieur. Veillez à toujours vous procurer et installer le + dernier service pack afin d'éviter les bogues du système + d'exploitation.
+ +Le projet du serveur HTTP Apache proprement dit ne fournit pas de + distribution binaire mais seulement le code source. Certains membres + du projet peuvent mettre à disposition des paquets binaires + à titre individuel, mais ceux-ci n'ont pas vocation à être + distribués publiquement.
+ +Si vous n'êtes + pas en mesure de compiler le serveur HTTP Apache vous-même, vous + pouvez vous procurer un paquet binaire auprès des nombreuses + distributions disponibles sur Internet.
+ +Quelques solutions populaires pour déployer Apache httpd, et + éventuellement PHP et MySQL sous Microsoft Windows :
+La configuration d'Apache est enregistrée dans les fichiers du
+ sous-répertoire conf. Ce sont les même fichiers que
+ ceux utilisés pour configurer la version Unix, mais il y a quelques
+ directives spécifiques à Apache pour Windows. Voir l'index des directives pour la liste
+ des directives disponibles.
Les principales spécificités d'Apache pour Windows sont :
+Comme Apache pour Windows est un programme multithread, il + ne lance pas de processus séparé pour chaque requête, comme Apache + peut le faire sous Unix. En fait, il n'y a en général que deux + processus Apache en exécution : un processus parent, et un + processus enfant qui traite les requêtes. Chaque requête est + traitée par un thread séparé au sein du processus enfant.
+ +Les directives de gestion de processus diffèrent également :
+ +MaxConnectionsPerChild
+ : comme dans la version Unix, cette directive contrôle le nombre
+ de connexions qu'un
+ processus enfant particulier va traiter avant de s'arrêter.
+ Cependant, à la différence d'Unix, un processus de remplacement
+ n'est pas instantanément disponible. Utilisez la définition par
+ défaut MaxConnectionsPerChild 0, sauf si vous
+ risquez de manquer de mémoire dans des modules tiers ou dans des
+ applications in-process.
httpd.conf, le nouveau processus enfant peut ne pas
+ démarrer, ou vous pouvez obtenir des résultats
+ inattendus.ThreadsPerChild : il
+ s'agit d'une nouvelle directive. Elle indique au serveur le nombre
+ de threads qu'il doit utiliser. Elle définit le nombre maximum de
+ connexions simultanées que le serveur peut gérer ; vous devez
+ donc vous assurer que ce nombre soit suffisamment grand pour les
+ besoins de votre site. La valeur par défaut ThreadsPerChild
+ 150 est recommandée, mais doit être ajustée à la valeur
+ maximale estimée de connexions simultanées à accepter.
Les directives qui acceptent des noms de fichiers comme + arguments doivent utiliser des noms de fichiers Windows et non + Unix. Cependant, comme Apache peut interpréter les anti-slashes + comme des séquences d'échappement de caractères, vous devez + absolument utiliser des slashes dans les noms de chemins à la + place des anti-slashes.
Alors que les noms de fichiers sont en général insensibles
+ à la casse sous Windows, les URLs sont encore sensibles à la casse
+ en interne avant d'être mises en correspondance avec le système de
+ fichiers. Par exemple, les directives <Location>, Alias, et ProxyPass utilisent toutes des
+ arguments sensibles à la casse. Pour cette raison, il est
+ particulièrement recommandé d'utiliser la directive <Directory> lorsqu'on
+ désire limiter l'accès à certains contenus du système de fichiers,
+ car cette directive s'applique à tout contenu d'un répertoire,
+ sans tenir compte de la manière dont on y accède. Pour vous
+ assurer que seules des minuscules sont utilisées dans les URLs,
+ vous pouvez utiliser ceci :
RewriteEngine On
+RewriteMap lowercase int:tolower
+RewriteCond "%{REQUEST_URI}" "[A-Z]"
+RewriteRule "(.*)" "${lowercase:$1}" [R,L]
+Lors de son exécution, Apache n'a besoin d'un accès en + écriture qu'au répertoire des journaux et à toute arborescence de + répertoires de cache configurée. Suite au problème d'insensibilité + à la casse et au format de noms courts 8.3, Apache doit valider + tous les noms de chemins fournis. Cela signifie que chaque + répertoire qu'Apache évalue doit avoir les droits en lecture, + listage et parcours, et ceci depuis la racine jusqu'aux feuilles. + Si Apache2.4 est installé dans C:\Program Files, le répertoire + racine, Program Files et Apache2.4 doivent tous être visibles pour + Apache
Apache peut charger divers modules sans qu'il soit nécessaire
+ de recompiler le serveur. Si Apache est compilé
+ normalement, il va installer de nombreux modules optionnels dans
+ le répertoire \Apache2.4\modules. Pour activer ces
+ modules ou d'autres modules, on doit utiliser la
+ directive LoadModule. Par
+ exemple, pour activer le module status, ajoutez la ligne suivante
+ (en plus des directives d'activation de status dans
+ access.conf) :
LoadModule status_module modules/mod_status.so+ + +
Des informations sont aussi à votre disposition pour créer des modules + chargeables
Apache peut aussi charger des extensions ISAPI (Internet + Server Application Programming Interface), comme celles qu'utilise + Microsoft IIS et d'autres serveurs Windows. Voir ici pour plus + d'informations. Notez qu'Apache ne peut pas + charger de filtres ISAPI, et que les gestionnaires ISAPI contenant + des extensions de fonctionnalités Microsoft ne fonctionneront + pas.
Pour les scripts CGI, la méthode qu'utilise Apache pour
+ déterminer l'interpréteur du script est configurable grâce à la
+ directive ScriptInterpreterSource
Comme il est souvent difficile de gérer des fichiers avec
+ des noms du style .htaccess sous Windows, vous avez
+ tout intérêt à changer le nom de ce fichier de configuration par
+ répertoire à l'aide de la directive AccessFilename.
Toute erreur survenant au cours du processus de démarrage
+ d'Apache est enregistrée dans le journal des évènements de
+ Windows si l'on est sous Windows NT. Ce mécanisme fonctionne comme
+ une sauvegarde pour les situations où Apache n'est pas encore prêt
+ à utiliser le fichier error.log. Vous pouvez
+ consulter le journal des évènements applicatifs Windows en
+ utilisant l'observateur d'évènements : Démarrage - Paramètres -
+ Panneau de configuration - Outils d'administration - Observateur
+ d'évènements.
Apache fournit un utilitaire nommé Apache Service Monitor + (Moniteur du service Apache). Grâce à lui, vous pouvez voir et gérer + l'état de tous les services Apache installés sur toutes les machines + du réseau. Pour pouvoir gérer un service Apache avec le moniteur, + vous devez d'abord installer le service (soit automatiquement au + cours de l'installation, soit manuellement).
+ +Vous pouvez installer Apache en tant que service Windows NT à
+ partir de la ligne de commandes et depuis le sous-répertoire Apache
+ bin comme suit :
+ httpd.exe -k install
+
Si vous avez installé plusieurs services Apache sur votre + ordinateur, vous devrez spécifier le nom du service que vous voulez + installer en utilisant la commande suivante (notez que si vous + spécifiez un nom durant l'installation, vous devrez aussi le + spécifier pour toute opération comportant l'option -k) :
+ +
+ httpd.exe -k install -n "Nom-service"
+
Si un service doit utiliser un fichier de configuration + spécifique, utilisez ceci :
+ +
+ httpd.exe -k install -n "Nom-service" -f "c:\fichiers\Nom-service.conf"
+
Si vous utilisez la première commande sans paramètre particulier,
+ excepté -k install, le service aura pour nom
+ Apache2.4 et le fichier de configuration sera censé
+ être conf\httpd.conf.
Supprimer un service Apache est très simple. Utilisez + simplement :
+ +
+ httpd.exe -k uninstall
+
On peut spécifier un service Apache particulier en utilisant + :
+ +
+ httpd.exe -k uninstall -n "Nom service"
+
Normalement, le démarrage, le redémarrage et l'arrêt d'un
+ service Apache s'effectuent via le Moniteur de Service Apache, ou en
+ utilisant des commandes telles que NET START Apache2.4 et
+ NET STOP Apache2.4, ou encore via le gestionnaire de
+ services standard de Windows. Avant de démarrer Apache en tant que
+ service dans quelque but que ce soit, vous devez tester le fichier
+ de configuration du service en utilisant :
+ httpd.exe -n "Nom-service" -t
+
Vous pouvez aussi contrôler un service Apache à l'aide de ses + options de ligne de commande. Avec cette méthode, pour démarrer un + service Apache installé, vous utiliserez :
+ +
+ httpd.exe -k start -n "Nom-Service"
+
Pour arrêter un service Apache via les options de lignes de + commande, utilisez ceci :
+ +
+ httpd.exe -k stop -n "Nom-Service"
+
ou
+ +
+ httpd.exe -k shutdown -n "Nom-Service"
+
Vous pouvez aussi redémarrer un service en exécution et le forcer + à relire son fichier de configuration en utilisant :
+ +
+ httpd.exe -k restart -n "Nom-Service"
+
Par défaut, tous les services Apache sont configurés pour
+ s'exécuter sous l'utilisateur system (le compte
+ LocalSystem). Le compte LocalSystem n'a
+ pas de privilèges sur votre réseau, que ce soit via un mécanisme
+ sécurisé de Windows, y compris le système de fichiers, des tubes
+ nommés, DCOM ou des RPC sécurisés. Il a cependant des privilèges
+ élevés en local.
LocalSystem ! Si Apache doit pouvoir accéder
+ à des ressources réseau, créez un compte séparé pour Apache comme
+ indiqué ci-dessous.Il est fortement fortement conseillé aux utilisateurs de créer un + compte séparé pour exécuter le(s) service(s) Apache, et même + obligatoire si vous devez accéder à des ressources réseau via + Apache.
+ +Log on as a service et Act as part of the
+ operating system. Sous Windows NT 4.0, ces privilèges sont
+ accordés via le Gestionnaire des utilisateurs du Domaine, mais
+ sous Windows 2000 et XP, vous aurez plutôt intérêt à utiliser une
+ GPO pour propager ces configurations. Vous pouvez aussi effectuer
+ ces réglages via la Politique de Sécurité Locale intégrée à la
+ MMC.htdocs
+ et cgi-bin par exemple), et aussi sur l'exécutable
+ binaire httpd.exe.logs.logs, sur lequel l'utilisateur doit
+ avoir au moins les droits de modification (RWXD).Si vous permettez à ce compte de se connecter en tant + qu'utilisateur et service, vous pouvez ouvrir une session sous ce + compte et vérifier s'il a bien le droit d'exécuter les scripts, de + lire les pages web, et si vous pouvez démarrer Apache à partir d'une + console Windows. Si tout fonctionne, et si vous avez suivi les + étapes ci-dessus, Apache devrait s'exécuter en tant que service sans + problème.
+ +Lorsqu'Apache démarre en tant que service, il se peut que vous + obteniez un message d'erreur du Gestionnaire de Services Windows. + Par exemple, si vous essayez de démarrer Apache en utilisant + l'applet Services du Panneau de configuration de Windows, vous + pouvez obtenir le message suivant :
+ +
+ Could not start the Apache2.4 service on \\COMPUTER
+ Error 1067; The process terminated unexpectedly.
+
Vous obtiendrez cette erreur à caractère général pour tout + problème survenant au cours du démarrage du service Apache. Afin de + déterminer exactement la cause du problème, vous devez suivre les + instructions permettant d'exécuter Apache pour Windows depuis la + ligne de commande.
+ +Si vous rencontrez des problèmes avec le service, il est + conseillé de suivre les instructions ci-dessous afin d'essayer de + démarrer httpd.exe depuis une console, et d'analyser les erreurs + plutôt que vous démener à essayer de démarrer le service.
+ +Il est en général recommandé d'exécuter Apache en tant que + service, mais il est parfois plus simple d'utiliser la ligne de + commande, en particulier au cours de la configuration initiale et + les tests.
+ +Pour exécuter Apache depuis la ligne de commande et en tant + qu'application de console, utilisez la commande suivante :
+ +
+ httpd.exe
+
Apache va démarrer, et continuera son exécution jusqu'à ce qu'on + l'arrête en tapant Ctrl-C.
+ +Vous pouvez également démarrer Apache via le raccourci "Démarrer
+ Apache dans une console" placé dans Démarrer -->
+ Programmes --> Apache HTTP Server 2.4.xx --> Control Apache
+ Server au cours de l'installation. Ceci va
+ ouvrir une console Windows, et y démarrer Apache.
+ Si vous n'avez pas installé Apache en tant que service, la
+ fenêtre Windows restera ouverte jusqu'à ce que vous arrêtiez Apache
+ en tapant Ctrl-C dans cette fenêtre. Le serveur va alors s'arrêter
+ au bout de quelques secondes. Cependant, si vous avez installé
+ Apache en tant que service, c'est ce dernier que le raccourci
+ ci-dessus va lancer. Si le service Apache est déjà en cours
+ d'exécution, le raccourci va rester sans effet.
Si Apache s'exécute en tant que service, vous pouvez l'arrêter en + ouvrant une autre console et en entrant :
+ +
+ httpd.exe -k shutdown
+
Plutôt que de lancer Apache à partir d'une console, il est + préférable de l'exécuter en tant que service car dans ce cas, il + termine proprement les opérations en cours avant de s'éteindre.
+ +Si le serveur a été lancé depuis une console, vous ne pouvez + l'arrêter qu'en pressant la combinaison de touches Ctrl-C dans la + même fenêtre.
+ +Vous pouvez aussi redémarrer Apache. Ceci le force à recharger + son fichier de configuration. Toute opération en cours peut être + achevée sans interruption. Pour redémarrer Apache, vous pouvez soit + taper Control-Break dans la fenêtre de console que vous avez + utilisée pour le démarrer, soit entrer :
+ +
+ httpd.exe -k restart
+
si le serveur s'exécute en tant que service.
+ +kill -TERM pid et
+ kill -USR1 pid. L'option de ligne de commande
+ -k a été choisie à titre de rapprochement avec la
+ commande kill utilisée sous Unix.Si la fenêtre de la console Apache se ferme immédiatement ou
+ inopinément après le démarrage d'Apache, ouvrez une console Windows
+ depuis le menu Démarrer --> Programmes. Placez-vous dans le
+ répertoire d'installation d'Apache, tapez la commande
+ httpd.exe, et observez le message d'erreur. Allez
+ ensuite dans le répertoire des journaux, et visualisez le fichier
+ error.log pour détecter d'éventuelles erreurs de
+ configuration. Si Apache a été installé dans C:\Program
+ Files\Apache Software Foundation\Apache2.4\, vous
+ pouvez entrer ce qui suit :
+ c:
+ cd "\Program Files\Apache Software Foundation\Apache2.4\bin"
+ httpd.exe
+
Attendez ensuite qu'Apache s'arrête ou tapez Ctrl-C. Entrez alors + la commande suivante :
+ +
+ cd ..\logs
+ more < error.log
+
Lorsqu'on travaille avec Apache, il est important de comprendre + comment ce dernier trouve son fichier de configuration. Vous pouvez + spécifier un fichier de configuration à partir de la ligne de + commande de deux façons :
+ +L'option -f permet de spécifier un chemin
+ absolu ou relatif vers un fichier de configuration particulier
+ :
+ httpd.exe -f "c:\fichiers-de-mon-serveur\autre-config.conf"
+
ou
+ +
+ httpd.exe -f fichiers-de-mon-serveur\autre-config.conf
+
L'option -n permet de spécifier le service
+ Apache installé dont le fichier de configuration doit être utilisé
+ :
+ httpd.exe -n "Nom-service"
+
Dans les deux cas, la directive ServerRoot doit être correctement définie
+ dans le fichier de configuration.
Si vous ne spécifiez aucun fichier de configuration à l'aide des
+ options -f ou -n, Apache utilisera le nom
+ du fichier de configuration compilé dans le serveur, en général
+ conf\httpd.conf. Ce chemin codé en dur est relatif au
+ répertoire d'installation. Vous pouvez vérifier ce chemin à partir
+ de la valeur de l'étiquette SERVER_CONFIG_FILE en
+ invoquant Apache avec l'option -V, comme ceci :
+ httpd.exe -V
+
Apache va ensuite essayer de déterminer la valeur de son
+ ServerRoot en effectuant les
+ recherches suivantes, dans cet ordre :
ServerRoot
+ via l'option de ligne de commande -C.-d.DocumentRoot) codée en dur
+ dans le serveur. Elle
+ correspond par défaut à /apache, et vous pouvez le
+ vérifier en tapant httpd.exe -V et en recherchant
+ l'étiquette HTTPD_ROOT.Si vous n'avez pas effectué d'installation binaire, dans certains + scénarios, Apache va signaler l'absence de cette clé de registre. + On peut passer outre cet avertissement si le serveur a été en mesure + de trouver son fichier de configuration d'une autre manière.
+ +La valeur de cette clé correspond au répertoire ServerRoot qui contient lui-même le
+ sous-répertoire conf. Lors de son démarrage, Apache lit
+ le fichier httpd.conf à partir de ce répertoire. Si ce
+ fichier contient une directive ServerRoot qui spécifie un répertoire
+ différent de celui que contient la clé de registre ci-dessus, Apache
+ oubliera la clé de registre, et utilisera le répertoire spécifié par
+ le fichier de configuration. Si vous déplacez le répertoire Apache
+ ou ses fichiers de configuration, il est vital de mettre à jour la
+ directive ServerRoot dans
+ httpd.conf afin de refléter la nouvelle
+ localisation.
Une fois Apache démarré (soit à partir d'une console Windows,
+ soit en tant que service), ce dernier va se mettre à l'écoute sur
+ le port 80 (à moins que vous ayiez modifié la directive Listen dans les fichiers de
+ configuration ou que vous ayiez installé Apache pour l'utilisateur
+ courant seulement). Pour vous connecter au serveur et accéder à la
+ page par défaut, lancez un navigateur et entrez cette URL :
+ http://localhost/
+
Apache devrait renvoyer une page de bienvenue et vous devriez
+ voir s'afficher "It Works!". Si rien ne se passe ou si vous obtenez
+ une erreur, consultez le fichier error.log dans le
+ sous-répertoire logs. Si votre serveur n'est pas
+ connecté au réseau, ou si vous avez de sérieux problèmes avec la
+ configuration de votre DNS (Domain Name Service), vous devez
+ utiliser cette URL :
+ http://127.0.0.1/
+
Si Apache écoute un port non standard, vous devez le préciser + explicitement dans l'URL :
+ +
+ http://127.0.0.1:8080/
+
Après que votre installation de base fonctionne, vous devez la
+ configurer correctement en éditant les fichiers du sous-répertoire
+ conf. Encore une fois, si vous modifiez la
+ configuration du service Apache sous Windows NT, essayez d'abord de
+ redémarrer le service depuis la ligne de commande afin de vous
+ assurer de l'absence d'erreur.
Comme Apache ne peut pas partager le même port + avec d'autres applications TCP/IP, il se peut que vous soyez amené à + arrêter, désinstaller ou reconfigurer certains services avant de + démarrer Apache. Ces services entrant en conflit avec Apache + comprennent les autres serveurs WWW, certaines implémentations de + pare-feu, et même certaines applications client (comme Skype) qui + utilisent le port 80 afin de contourner les pare-feu.
+ +L'accès à des fichiers par le réseau peut être spécifié via deux + mécanismes fournis par Windows :
+ +Alias "/images/" "Z:/"Alias "/images/" "//imagehost/www/images/"L'association de lettres de lecteur permet à l'administrateur de + maintenir une correspondance avec une certaine machine et un certain + chemin en dehors de la configuration d'Apache httpd. Cependant, ces + associations ne sont possibles que dans le cadre des sessions + interactives, et ne sont pas directement disponibles pour Apache httpd + lorsqu'il est démarré en tant que service. N'utilisez par + conséquent que des + chemins UNC pour les ressources réseau dans httpd.conf, de + façon à ce que les ressources soient accessibles quelle que soit la + manière dont Apache httpd a été démarré (des procédures exotiques et + probablement sujettes aux erreurs peuvent permettre de contourner la + restriction due aux associations de lettres de lecteur, mais leur + utilisation est déconseillée).
+ +DocumentRoot "//dochost/www/html/"+
DocumentRoot "//192.168.1.50/docs/"+
Alias "/images/" "//imagehost/www/images/" + +<Directory "//imagehost/www/images/"> +#... +<Directory>+
Lorsqu'Apache s'exécute en tant que service, vous devez créer un + compte spécifique afin de pouvoir accéder aux ressources réseau, comme + décrit ci-dessus.
+Si on utilise un grand nombre de redirections de journaux + via des pipes, il est souvent nécessaire d'augmenter la + taille de la mémoire du bureau ("desktop heap"). Pour une information plus + détaillée, veuillez vous reporter à la documentation sur les redirections de journaux.
Serveur HTTP Apache Version 2.4
+ab est un utilitaire qui vous permet de tester les
+ performances de votre serveur HTTP Apache. Il a été conçu pour vous
+ donner une idée du degré de performances de votre installation
+ d'Apache. Il vous permet en particulier de déterminer le nombre de
+ réquêtes que votre installation d'Apache est capable de servir par
+ seconde.
ab
+ [ -A nom-utilisateur:mot-de-passe ]
+ [ -b taille-tampon ]
+ [ -B adresse-locale ]
+ [ -c simultanéité ]
+ [ -C nom-cookie=valeur ]
+ [ -d ]
+ [ -e fichier-csv ]
+ [ -E fichier du certificat client ]
+ [ -f protocole ]
+ [ -g fichier-gnuplot ]
+ [ -h ]
+ [ -H en-tête-personnalisé ]
+ [ -i ]
+ [ -k ]
+ [ -l ]
+ [ -m HTTP-method ]
+ [ -n requêtes ]
+ [ -p fichier-POST ]
+ [ -P
+ nom-utilisateur-mandataire:mot-de-passe ]
+ [ -q ]
+ [ -r ]
+ [ -s timeout ]
+ [ -S ]
+ [ -t limite-de-durée ]
+ [ -T type-de-contenu ]
+ [ -u fichier PUT ]
+ [ -v verbosité]
+ [ -V ]
+ [ -w ]
+ [ -x <table>-attributs ]
+ [ -X mandataire[:port] ]
+ [ -y <tr>-attributs ]
+ [ -z <td>-attributs ]
+ [ -Z algorithme-chiffrement ]
+ [http[s]://]nom-serveur[:port]/chemin
-A nom-utilisateur:mot-de-passe: et transmis sous forme codée base64.
+ La chaîne est envoyée que le serveur en ait besoin ou non (qu'il ait
+ renvoyé un code "401 authentication needed" ou non).-b taille-tampon-B adresse-locale-c simultanéité-C nom-cookie=valeurCookie: à la requête. L'argument
+ se présente en général sous la forme d'une
+ paire nom=valeur. Ce champ peut
+ être répété.-d-e fichier-csv-E fichier du certificat client-f protocole-g fichier-gnuplot-h-H en-tête-personnalisé"Accept-Encoding: zip/zop;8bit").-iHEAD plutôt que
+ GET.-k-l-m HTTP-method-n requêtes-p fichier-POST-T.-P nom-utilisateur-mandataire:mot-de-passe: et envoyés sur le
+ réseau codés en base64. La chaîne est envoyée, que le mandataire en
+ ait besoin ou non (qu'il ait renvoyé un code "407 proxy
+ authentication needed" ou non).-qab
+ affiche la progression du traitement sur stderr tous
+ les 10% du nombre total ou toutes les 100 requêtes. Le drapeau
+ -q permet de supprimer ces messages.-r-s timeout-S-t limite-durée-n 50000 en interne. Utilisez cette option
+ si vous souhaitez tester les performances du serveur pendant une
+ durée fixée à l'avance. Par défaut, il n'y a pas de limite de
+ durée.-T type-contenuapplication/x-www-form-urlencoded.
+ La valeur par défaut est text/plain.-u fichier PUT-T.-v verbosité4 et
+ supérieurs permettent d'afficher des informations à propos des
+ en-têtes, les niveaux 3 et supérieurs les codes de
+ réponse (404, 200, etc...), et les niveaux 2 et
+ supérieurs les messages d'avertissement et d'information.-V-w-x <table>-attributs<table>. Les attributs sont insérés
+ <table ici >.-X mandataire[:port]-y <tr>-attributs<tr>.-z <td>-attributs<td>.-Z algorithme-chiffrementVous touverez dans ce qui suit la liste des valeurs retournées
+ par ab :
+
concurrency *
+ timetaken * 1000 / done, alors que la seconde valeur est
+ calculée selon la formule timetaken * 1000 / done.totalread / 1024 / timetaken.De nombreux tampons de taille fixe sont déclarés statiquement. + Combiné avec l'interprétation poussive des arguments de la ligne de + commande, les en-têtes de réponse du serveur et autres entrées + externes, ceci peut vous affecter.
+ +HTTP/1.x n'est pas complètement implémenté ; seules certaines
+ formes de réponses 'attendues' sont acceptées. L'utilisation
+ relativement intense de strstr(3) provoque un affichage
+ en tête de profil, ce qui peut faire croire à un problème de
+ performances ; en d'autres termes, vous mesurez les performances de
+ ab plutôt que celles du serveur.
Serveur HTTP Apache Version 2.4
+apachectl est un frontal pour le serveur HTTP
+ Apache. Il a été conçu pour aider l'administrateur à contrôler le
+ fonctionnement du démon Apache httpd.
Le script apachectl possède deux modes de
+ fonctionnement. Il peut fonctionner en tant que simple frontal
+ de la commande httpd et ne fait alors que
+ définir toute variable d'environnement nécessaire, puis invoque
+ httpd en lui passant tout argument de ligne de
+ commande souhaité. Il peut aussi fonctionner en tant que script
+ d'initialisation SysV n'acceptant qu'un seul argument tel que
+ start, restart et stop, et
+ traduisant ce dernier en signaux appropriés pour le démon
+ httpd.
Si votre installation d'Apache utilise des chemins non
+ standards, vous devrez éditer le script apachectl afin
+ de définir les chemins appropriés pour le binaire
+ httpd. Vous pouvez aussi spécifier tout argument
+ de ligne de commande de httpd nécessaire. Voir
+ les commentaires dans le script pour plus de détails.
Le script apachectl renvoie une valeur égale à 0 en
+ cas de succès, et une valeur supérieure à 0 en cas de problème.
+ Voir les commentaires dans le script pour plus de détails.
En mode frontal (pass-through), apachectl peut spécifier
+tous les arguments qu'accepte le binaire httpd.
apachectl [ argument-httpd ]
En mode script d'initialisation SysV, apachectl
+n'accepte qu'un seul des arguments définis ci-dessous.
apachectl commande
Seules les options du style initialisation SysV sont décrites ici.
+Les autres arguments sont décrits dans la page de manuel de
+httpd.
starthttpd. Renvoie une erreur
+s'il est déjà en cours d'exécution. Équivalent à apachectl -k
+start.stophttpd. Équivalent à
+apachectl -k stop.restarthttpd. Si le démon
+n'est pas en cours d'exécution, il est démarré. Cette option vérifie
+automatiquement les fichiers de configuration (de la même manière que
+l'option configtest ) avant de lancer le redémarrage, afin
+d'être sûr que le fonctionnement du démon ne sera pas compromis.
+Equivalent à apachectl -k restart.fullstatusmod_status. Pour que ceci fonctionne,
+mod_status doit être activé dans votre serveur et vous
+devez disposer d'un navigateur en mode texte tel que lynx
+sur votre système. L'URL utilisée pour accéder au rapport d'état peut
+être modifiée en définissant la variable STATUSURL dans le
+script.statusfullstatus, excepté que la liste des requêtes en cours de
+traitement est omise.gracefulhttpd en douceur. Si le
+démon n'est pas en cours d'exécution, il est démarré. À la différence
+d'un redémarrage normal, les connexions en cours ne sont pas fermées.
+Comme effet de bord, les anciens fichiers journaux ne seront pas fermés
+immédiatement. Cela signifie que si l'on utilise un script de rotation
+des journaux, un délai suffisant sera nécessaire afin d'être sûr que les
+fichiers journaux seront bien fermés avant leur traitement par le script
+de rotation. Cette option vérifie
+automatiquement les fichiers de configuration (de la même manière que
+l'option configtest ) avant de lancer le redémarrage, afin
+d'être sûr que le fonctionnement du démon ne sera pas compromis.
+Équivalent à apachectl -k graceful.graceful-stophttpd en douceur. À la
+différence d'un arrêt normal, les connexions en cours ne sont pas
+fermées. Comme effet de bord, les anciens fichiers journaux ne seront
+pas fermés immédiatement. Équivalent à apachectl -k
+graceful-stop.configtestSyntax Ok, soit des informations détaillées à
+propos des éventuelles erreurs de syntaxe. Equivalent à apachectl
+-t.Les options suivantes étaient disponibles dans les anciennes versions +et ont été supprimées.
+ +startsslhttpd avec le support SSL, vous
+devez éditer votre fichier de configuration et y inclure les
+directives appropriées, puis utiliser la commande de démarrage normale
+apachectl start.Serveur HTTP Apache Version 2.4
+apxs est un utilitaire permettant de compiler et
+ d'installer des modules en tant qu'extensions du serveur HTTP
+ Apache. A cet effet, un objet dynamique partagé (DSO) est compilé à
+ partir d'un ou plusieurs fichiers sources ou objets et
+ peut être chargé pendant l'exécution du serveur Apache via la
+ directive LoadModule du
+ module mod_so.
Pour pouvoir utiliser ce mécanisme d'extensions, votre
+ plate-forme doit supporter la fonctionnalité DSO, et votre binaire
+ httpd Apache doit être compilé avec le module
+ mod_so. Si ce n'est pas le cas, l'utilitaire
+ apxs vous le signalera. Vous pouvez aussi vérifier
+ vous-même ces prérequis en exécutant manuellement la commande :
+ $ httpd -l
+
Le module mod_so doit faire partie de la liste
+ des modules affichée. Si ces prérequis sont présents, vous pouvez
+ facilement étendre les fonctionnalités de votre serveur Apache en
+ installant vos propres modules à l'aide de l'utilitaire
+ apxs, via le mécanisme DSO :
+ $ apxs -i -a -c mod_foo.c
+ gcc -fpic -DSHARED_MODULE -I/chemin/vers/apache/include -c mod_foo.c
+ ld -Bshareable -o mod_foo.so mod_foo.o
+ cp mod_foo.so /chemin/vers/apache/modules/mod_foo.so
+ chmod 755 /chemin/vers/apache/modules/mod_foo.so
+ [activation du module `foo' dans /chemin/vers/apache/etc/httpd.conf]
+ $ apachectl restart
+ /chemin/vers/apache/sbin/apachectl restart: httpd not running, trying to start
+ [Tue Mar 31 11:27:55 1998] [debug] mod_so.c(303): loaded module foo_module
+ /chemin/vers/apache/sbin/apachectl restart: httpd started
+ $ _
+
Les arguments fichiers peuvent correspondre à un
+ fichier source C (.c), un fichier objet (.o) ou même une archive de
+ bibliothèques (.a). L'utilitaire apxs reconnaît
+ automatiquement ces extensions et utilise automatiquement les
+ fichiers source C pour la compilation, et les fichiers objets et
+ archives pour l'édition de liens. Cependant, si vous utilisez des
+ fichiers objets précompilés, assurez-vous que leur code soit
+ indépendant de la position (PIC), afin de pouvoir les utiliser avec
+ un objet partagé chargé dynamiquement. Avec GCC, par exemple, il
+ vous suffit de toujours utiliser l'option de compilation
+ -fpic. Pour les autres compilateurs C, consultez leur
+ page de manuel, ou vérifiez les drapeaux qu'apxs
+ utilise pour compiler les fichiers objets.
Pour plus de détails à propos du support DSO dans Apache, lire la
+ documentation du module mod_so, ou même, consultez
+ le fichier source src/modules/standard/mod_so.c.
apxs -g
+ [ -S nom=valeur ]
+ -n nom-module
apxs -q
+ [ -v ]
+ [ -S nom=valeur ]
+ requête ...
apxs -c
+ [ -S nom=valeur ]
+ [ -o fichier-dso ]
+ [ -I répertoire-inc ]
+ [ -D nom=valeur ]
+ [ -L répertoire-lib ]
+ [ -l nom-bibliothèque ]
+ [ -Wc,options-compilation ]
+ [ -Wl,options-edition-liens ]
+ fichiers ...
apxs -i
+ [ -S nom=valeur ]
+ [ -n nom-module ]
+ [ -a ]
+ [ -A ]
+ fichier-dso ...
apxs -e
+ [ -S nom=valeur ]
+ [ -n nom-module ]
+ [ -a ]
+ [ -A ]
+ fichier-dso ...
-n nom-module-i (install) et -g (génération de
+ modèles). Utilisez cette option pour spécifier de manière
+ explicite le nom du module. Pour l'option -g, cette
+ option est nécessaire ; pour l'option -i,
+ l'utilitaire apxs tente de déterminer le nom du
+ module à partir des sources, ou (à défaut) en le déduisant du nom
+ de fichier.-qhttpd.
+ Lorsqu'elle est invoquée sans paramètre requête, cette
+ option affiche toutes les variables connues, ainsi que leurs
+ valeurs. Le paramètre optionnel -v formate la liste
+ affichée.
+
+ Utilisez cette option pour déterminer manuellement les options
+ utilisées pour compiler le binaire httpd qui chargera
+ votre module. Ajoutez par exemple
+ INC=-I`apxs -q INCLUDEDIR`
+
dans vos propres Makefiles si vous devez accéder manuellement + aux fichiers d'en-têtes C d'Apache.
-S nom=valeur-g-n) contenant deux
+ fichiers : le premier fichier est un exemple de fichier source de
+ module nommé mod_nom.c que l'on peut
+ utiliser comme modèle pour créer ses propres modules, ou comme
+ point de départ pour se familiariser avec le mécanisme apxs ; le
+ second fichier est le Makefile correspondant
+ facilitant la compilation et l'installation de ce module.-c-o
+ n'est pas spécifiée, le nom du fichier résultant est déduit du
+ premier nom de fichier spécifié par fichiers, et ainsi
+ prend en général pour valeur par défaut
+ mod_nom.so.-o fichier-dsomod_unknown.so qui sera utilisé.-D nom=valeur-I répertoire-incinclude au processus de
+ compilation.-L répertoire-lib-l nom-bibliothèque-Wc,options-compilationlibtool
+ --mode=compile. Vous pouvez l'utiliser pour ajouter des
+ options locales spécifiques au compilateur.-Wl,options-edition-lienslibtool
+ --mode=link. Vous pouvez l'utiliser pour ajouter des
+ options locales spécifiques à l'éditeur de liens.-p-i-aLoadModule
+ correspondante au fichier de configuration d'Apache
+ httpd.conf, ou en l'activant s'il existe déjà.-A-a, à la différence que la
+ directive LoadModule créée
+ est préfixée par un caractère dièse (#) ; le module
+ est ainsi préparé pour une activation ultérieure, mais est
+ désactivé dans un premier temps.-e-a et -A
+ de la même manière qu'au cours de l'opération d'installation pour
+ éditer le fichier de configuration d'Apache
+ httpd.conf, sans toutefois installer le module.Supposons que vous disposiez d'un module Apache nommé
+ mod_foo.c et destiné à étendre les fonctionnalités du
+ serveur. Pour ce faire, vous devez tout d'abord compiler le fichier
+ source C en un objet partagé pouvant être chargé dans le serveur
+ Apache à l'exécution, via la commande suivante :
+ $ apxs -c mod_foo.c
+ /chemin/vers/libtool --mode=compile gcc ... -c mod_foo.c
+ /chemin/vers/libtool --mode=link gcc ... -o mod_foo.la mod_foo.slo
+ $ _
+
Vous devez ensuite vérifier la configuration d'Apache en vous
+ assurant qu'une directive LoadModule est bien présente pour
+ charger cet objet partagé. Pour simplifier cette étape,
+ apxs propose une méthode automatique d'installation de
+ l'objet partagé dans son répertoire "modules", et de mise à jour du
+ fichier httpd.conf en conséquence. Pour bénéficier de
+ cette automatisation, utilisez la commande suivante :
+ $ apxs -i -a mod_foo.la
+ /chemin/vers/instdso.sh mod_foo.la /chemin/vers/apache/modules
+ /chemin/vers/libtool --mode=install cp mod_foo.la /chemin/vers/apache/modules
+ ...
+ chmod 755 /chemin/vers/apache/modules/mod_foo.so
+ [activation du module `foo' dans /chemin/vers/apache/conf/httpd.conf]
+ $ _
+
Une ligne contenant
+ +
+ LoadModule foo_module modules/mod_foo.so
+
est alors ajoutée au fichier de configuration si ce n'est pas
+ déjà fait. Si vous voulez que le module soit désactivé par défaut,
+ utilisez l'option -A comme suit :
+ $ apxs -i -A mod_foo.c
+
Pour un test rapide du mécanisme apxs, vous pouvez créer un + exemple de modèle de module Apache, ainsi que le Makefile + correspondant via :
+ +
+ $ apxs -g -n foo
+ Creating [DIR] foo
+ Creating [FILE] foo/Makefile
+ Creating [FILE] foo/modules.mk
+ Creating [FILE] foo/mod_foo.c
+ Creating [FILE] foo/.deps
+ $ _
+
Vous pouvez ensuite compiler immédiatement ce module exemple en + objet partagé et le charger dans le serveur Apache :
+ +
+ $ cd foo
+ $ make all reload
+ apxs -c mod_foo.c
+ /chemin/vers/libtool --mode=compile gcc ... -c mod_foo.c
+ /chemin/vers/libtool --mode=link gcc ... -o mod_foo.la mod_foo.slo
+ apxs -i -a -n "foo" mod_foo.la
+ /chemin/vers/instdso.sh mod_foo.la /chemin/vers/apache/modules
+ /chemin/vers/libtool --mode=install cp mod_foo.la /chemin/vers/apache/modules
+ ...
+ chmod 755 /chemin/vers/apache/modules/mod_foo.so
+ [activation du module `foo' dans /chemin/vers/apache/conf/httpd.conf]
+ apachectl restart
+ /chemin/vers/apache/sbin/apachectl restart: httpd not running, trying to start
+ [Tue Mar 31 11:27:55 1998] [debug] mod_so.c(303): loaded module foo_module
+ /chemin/vers/apache/sbin/apachectl restart: httpd started
+ $ _
+
Serveur HTTP Apache Version 2.4
+Le script configure permet de configurer
+ l'arborescence des sources afin de compiler et installer le serveur
+ HTTP Apache sur votre plate-forme spécifique. De nombreuses options
+ vous permettent de compiler un serveur correspondant à vos propres
+ besoins.
Ce script, situé dans le répertoire racine de la distribution des + sources, ne concerne que la compilation sur les systèmes Unix et + apparentés. Pour les autres plates-formes, voir la documentation spécifique de ces + dernières.
+Vous devez appeler le script configure depuis le
+ répertoire racine de la distribution.
./configure [OPTION]...
+ [VARIABLE=VALEUR]...
Pour définir des variables d'environnement (par exemple
+ CC,CFLAGS, etc...), utilisez la clause
+ VARIABLE=VALEUR. Voir ci-dessous pour la description de quelques variables
+ usuelles.
Les options suivantes affectent le comportement du script
+ configure.
-C--config-cache--cache-file=config.cache--cache-file=FICHIER-h--help [short|recursive]short, seules les options spécifiques à ce paquet
+ seront affichées. L'argument recursive permet
+ d'afficher l'aide de tous les paquets inclus.-n--no-createconfigure s'exécute normalement, mais
+ ne crée pas les fichiers résultants. Ceci permet de vérifier les
+ résultats des tests avant de générer les fichiers makefile pour la
+ compilation.-q--quietchecking ... ne sont pas affichés au
+ cours du processus de configuration.--srcdir=DIRconfigure, ou le répertoire parent.--silent--quietCes options permettent de spécifier le répertoire d'installation. + L'arborescence de l'installation dépend de l'organisation (layout) + sélectionnée.
+ +--prefix=PREFIX/usr/local/apache2.--exec-prefix=EPREFIXPar défaut, make install va installer tous les
+ fichiers dans /usr/local/apache2/bin,
+ /usr/local/apache2/lib, etc... Vous pouvez cependant
+ spécifier un préfixe d'installation autre que
+ /usr/local/apache2 en utilisant l'option
+ --prefix (par exemple --prefix=$HOME).
--enable-layout=LAYOUTconfig.layout contient de nombreux exemples de
+ configurations, et vous pouvez créer vos propres configurations
+ personnalisées en vous basant sur ces exemples. Les différentes
+ organisations contenues dans ce fichier sont enregistrées sous
+ forme de sections <Layout
+ FOO>...</Layout> et référencées dans ce cas par
+ le nom FOO. L'organisation par défaut
+ est Apache.Pour une définition plus précise des répertoires
+ d'installation, utilisez les options ci-dessous. Notez que les
+ répertoires par défaut sont définis par autoconf, et
+ que leurs valeurs sont écrasées par les valeurs correspondantes
+ définies lors du choix de l'organisation des répertoires
+ (layout).
--bindir=DIRhtpasswd, dbmmanage,
+ etc..., et destinés aux administrateurs du site. Par défaut,
+ DIR est défini à
+ EPREFIX/bin.--datadir=DIRdatadir est défini à
+ PREFIX/share. Cette option est fournie
+ par autoconf et actuellement inutilisée.--includedir=DIRincludedir est défini à
+ EPREFIX/include.--infodir=DIRinfodir est défini à
+ PREFIX/info. Cette option est
+ actuellement inutilisée.--libdir=DIRlibdir est défini à
+ EPREFIX/lib.--libexecdir=DIRlibexecdir est défini à
+ EPREFIX/modules.--localstatedir=DIRlocalstatedir est
+ défini à PREFIX/var. Cette option est
+ fournie par autoconf et est actuellement
+ inutilisée.--mandir=DIRmandir est défini à
+ EPREFIX/man.--oldincludedir=DIRoldincludedir est défini à
+ /usr/include. Cette option est fournie par
+ autoconf et est actuellement inutilisée.--sbindir=DIRhttpd, apachectl,
+ suexec, etc..., qui sont nécessaires à
+ l'exécution du serveur HTTP Apache. Par défaut,
+ sbindir est défini à
+ EPREFIX/sbin.--sharedstatedir=DIRsharedstatedir est défini à
+ PREFIX/com. Cette option est fournie par
+ autoconf et est actuellement inutilisée.--sysconfdir=DIRhttpd.conf, mime.types, etc... dans
+ DIR. Par défaut, sysconfdir est défini à
+ PREFIX/conf.Ces options sont utilisées pour la cross-compilation du serveur + HTTP Apache afin de pouvoir l'utiliser sur un autre système. Dans le + cas général où la compilation et l'exécution du serveur ont lieu sur + le même système, ces options ne sont pas utilisées.
+ +--build=BUILDconfig.guess.--host=HOST--target=TARGETautoconf et n'est pas requise par le serveur HTTP
+ Apache.Ces options vous permettent de configurer avec précision les + fonctionnalités de votre futur serveur HTTP.
+ +D'une manière générale, vous pouvez utiliser la syntaxe + suivante pour activer ou désactiver une fonctionnalité :
+ +--disable-FONCTIONNALITE--enable-FONCTIONNALITE=no.--enable-FONCTIONNALITE[=ARG]yes.--enable-MODULE=shared--enable-MODULE=static--enable-foo, et si
+ foo n'existe pas, configure ne le
+ signalera pas ; vous devez donc prendre soin de taper les
+ options correctement.
+ La plupart des modules sont compilés par défaut et ils doivent être
+ désactivés de manière explicite ou via le mots-clé few (voir
+ ci-dessous --enable-modules,
+ --enable-mods-shared et --enable-mods-static
+ pour une explication plus détaillée), ou
+ --enable-modules=none pour les désactiver tous.
Par défaut, les autres modules ne sont pas compilés et doivent
+ être activés explicitement, ou en utilisant les mots-clés
+ all ou reallyall pour être disponibles.
Pour déterminer quels modules sont compilés par défaut,
+ exécutez la commande ./configure -h ou
+ ./configure --help, et consultez les Optional
+ Features. Par exemple, supposons que vous soyez intéressé
+ par les modules mod_example1 et
+ mod_example2, et que vous voyiez ceci :
Optional Features: + ... + --disable-example1 example module 1 + --enable-example2 example module 2 + ...
Le module mod_example1 est ici activé par
+ défaut, et vous devez spécifier --disable-example1
+ si vous ne voulez pas le compiler. Par contre, le module
+ mod_example2 est désactivé par défaut, et vous
+ devez spécifier --enable-example2 si vous voulez le
+ compiler.
Les Modules Multi-Processus, ou MPMs, + constituent le coeur du serveur. Un seul MPM doit être actif pour + que le serveur puisse fonctionner. Vous trouverez la liste des + MPMs disponibles à module index page.
+ +Les MPMs peuvent être compilés en tant que modules DSO pour un + chargement dynamique, ou liés statiquement avec le serveur, et + sont activés via les options suivantes :
+ +--with-mpm=MPMSélectionne le MPM par défaut pour votre serveur. Si les
+ MPMs sont compilés en tant que modules DSO (voir
+ --enable-mpms-shared), cette option spécifie le
+ MPM qui sera chargé par défaut selon le fichier de
+ configuration. Dans le cas contraire, cette option spécifie le
+ seul MPM disponible qui sera lié statiquement avec le
+ serveur.
Si cette option est omise, c'est le MPM par défaut pour votre + système d'exploitation qui sera utilisé.
+--enable-mpms-shared=Liste de MPMDéfinit une liste de MPMs à compiler en tant que modules
+ dynamiquement partagés (DSO). Un de ces modules doit être
+ chargé dynamiquement via la directive LoadModule.
Liste de MPM est une liste, entourée + d'apostrophes, de noms de MPM séparés par des espaces. Par + exemple :
+
+ --enable-mpms-shared='prefork worker'
+
Vous pouvez aussi utiliser le mot-clé all, ce
+ qui aura pour effet de spécifier tous les MPMs qui supportent
+ le chargement dynamique sur la plate-forme considérée, et de
+ les compiler en tant que modules DSO. Par exemple :
+ --enable-mpms-shared=all
+
Pour ajouter des modules tiers, utilisez les options suivantes + :
+ +--with-module=type-module:fichier-module[,
+ type-module:fichier-module]Ajoute un ou plusieurs modules tiers à la liste des
+ modules liés statiquement. Le fichier source du module
+ fichier-module sera recherché dans le sous-répertoire
+ type-module de l'arborescence des sources de votre
+ serveur HTTP Apache. S'il ne l'y trouve pas,
+ configure considèrera fichier-module
+ comme un chemin de fichier absolu et essaiera de copier le
+ fichier source dans le sous-répertoire type-module.
+ Si ce sous-répertoire n'existe pas, il sera créé et un fichier
+ Makefile.in standard y sera enregistré.
Cette option est conçue pour ajouter de petits modules + externes ne comportant qu'un seul fichier source. Pour des + modules plus complexes, vous devrez lire la documentation du + fournisseur du module.
+apxs.--enable-maintainer-mode--enable-mods-shared=LISTE-MODULESDéfinit une liste de modules à activer et à compiler en
+ tant que modules dynamiques partagés. Cela signifie que ces
+ modules doivent être chargés dynamiquement en utilisant la
+ directive LoadModule.
LISTE-MODULES est une liste, entourée
+ d'apostrophes, de noms de modules
+ séparés par des espaces. Les noms
+ des modules sont spécifiés sans le préfixe mod_.
+ Par exemple :
+ --enable-mods-shared='headers rewrite dav'
+
Vous pouvez aussi utiliser les mots-clés reallyall,
+ all, most et few. Par
+ exemple,
+ --enable-mods-shared=most
+
va compiler la plupart des modules en tant que modules DSO,
+
+ --enable-mods-shared=few
+
ne compilera qu'un jeu de modules de base.
+Le jeu par défaut correspond au mot-clé most.
Les directives LoadModule correspondant aux
+ différents modules choisis sont automatiquement générées dans
+ le fichier de configuration principal. Par défaut, toutes ces
+ directives sont mises en commentaire, sauf pour les modules
+ requis ou ceux explicitement sélectionnés par un argument
+ --enable-nom-module du script configure. Vous
+ pouvez modifier le jeu de modules chargé en activant ou
+ désactivant les directives LoadModule dans le fichier
+ httpd.conf. En outre, les directives LoadModule peuvent être activées
+ pour tous les modules compilés via l'option
+ --enable-load-all-modules du script configure.
--enable-mods-static=MODULE-LIST--enable-mods-shared, à l'exception que les modules
+ seront liés statiquement. Cela signifie que les modules
+ spécifiés seront toujours disponibles au cours du fonctionnement
+ de httpd. Ils n'ont pas besoin d'être chargés
+ via la directive LoadModule.--enable-modules=MODULE-LIST--enable-mods-shared, et va aussi lier les modules
+ concernés dynamiquement. Le mot-clé spécial none
+ désactive la compilation de tous les modules.--enable-v4-mapped--with-port=PORThttpd va écouter. Ce numéro de port est
+ utilisé lors de la génération du fichier de configuration
+ httpd.conf. Sa valeur par défaut est 80.--with-program-namehttpd.Ces options permettent de définir des paquets optionnels.
+ +D'une manière générale, vous pouvez utiliser la syntaxe + suivante pour définir un paquet optionnel :
+ +--with-PAQUET[=ARG]yes.--without-PAQUET--with-PAQUET=no. Elle est
+ fournie par autoconf mais n'est pas très utile pour
+ le serveur HTTP Apache.--with-apr=REP|FICHIERconfigure le chemin du script
+ apr-config. Vous pouvez spécifier le chemin absolu
+ et le nom ou le répertoire d'installation de l'APR.
+ apr-config doit se trouver dans ce répertoire ou
+ dans le sous-repertoire bin.--with-apr-util=REP|FICHIERconfigure le chemin du script
+ apu-config. Vous pouvez spécifier le chemin absolu
+ et le nom ou le répertoire d'installation des APU.
+ apu-config doit se trouver dans ce répertoire ou
+ dans le sous-repertoire bin.--with-ssl=REPmod_ssl a été activé,
+ configure recherche une installation d'OpenSSL.
+ Vous pouvez définir le répertoire de la boîte à outils SSL/TLS à
+ la place.--with-z=REPconfigure recherche automatiquement une
+ bibliothèque zlib installée si la configuration de
+ vos sources en nécessite une (par exemple lorsque
+ mod_deflate est activé). Vous pouvez définir le
+ répertoire de la bibliothèque de compression à la place.De nombreuses fonctionnalités du serveur HTTP Apache, y compris
+ les directives RewriteMap DBM de
+ mod_rewrite et mod_authn_dbm
+ utilisent une base de données simple
+ de la forme clé/valeur pour une recherche rapide d'informations.
+ SDBM, inclus dans les APU, est donc toujours disponible. Si vous
+ souhaitez utiliser d'autres types de bases de données, utilisez
+ les options suivantes afin de les activer :
--with-gdbm[=chemin]configure va rechercher les fichiers d'en-têtes et
+ les bibliothèques d'une installation DBM GNU dans les chemins
+ standards. Avec un chemin explicite,
+ configure recherchera les fichiers concernés dans
+ chemin/lib et
+ chemin/include. En fait,
+ chemin permet de spécifier plusieurs chemins
+ d'en-têtes et bibliothèques spécifiques en les séparant par des
+ caractères ':'.--with-ndbm[=chemin]--with-gdbm, mais recherche une
+ installation de New DBM.--with-berkeley-db[=chemin]--with-gdbm, mais recherche une
+ installation de Berkeley DB.Les options DBM sont fournies par les APU et passées en
+ paramètres à son script de configuration. Elles sont inutiles
+ lorsqu'on utilise des APU déjà installés définis par
+ --with-apr-util.
Vous pouvez utiliser plusieurs implémentations DBM avec votre + serveur HTTP. Le type DBM approprié sera choisi au cours de la + configuration de l'exécution à chaque démarrage.
+--enable-static-support--enable-suexecsuexec, qui vous permet de définir un uid et un
+ gid pour les processus lancés. N'utilisez cette option que
+ si vous maîtrisez toutes les implications en matière de sécurité
+ de l'exécution d'un binaire suid sur votre serveur.
+ D'autres options permettent de configurer
+ suexec comme décrit ci-dessous.Il est possible de lier statiquement le binaire d'un programme + support particulier en utilisant les options suivantes :
+ +--enable-static-abab.--enable-static-checkgidcheckgid.--enable-static-htdbmhtdbm.--enable-static-htdigesthtdigest.--enable-static-htpasswdhtpasswd.--enable-static-logresolvelogresolve.--enable-static-rotatelogsrotatelogs.suexecLes options suivantes permettent de définir avec précision le
+ comportement du programme suexec. Voir Configurer et installer suEXEC
+ pour plus de détails.
--with-suexec-binsuexec. La
+ valeur par défaut est --sbindir (voir Définition précise des répertoires
+ d'installation).--with-suexec-callersuexec. Il est en général souhaitable que ce
+ soit le même que celui sous lequel httpd
+ s'exécute.--with-suexec-docrootsuexec est
+ autorisé. La valeur par défaut est
+ --datadir/htdocs.--with-suexec-gidminsuexec. La valeur par
+ défaut est 100.--with-suexec-logfilesuexec. La valeur par défaut est
+ --logfiledir/suexec_log.--with-suexec-safepathPATH pour les processus lancés par
+ suexec. La valeur par défaut est
+ /usr/local/bin:/usr/bin:/bin.--with-suexec-userdirsuexec. Cette option est nécessaire si vous
+ souhaitez utiliser suexec avec des
+ répertoires utilisateurs (définis via
+ mod_userdir). La valeur par défaut est
+ public_html.--with-suexec-uidminsuexec. La valeur par
+ défaut est 100.--with-suexec-umaskumask pour les
+ processus lancés par suexec. Il correspond
+ par défaut au masque défini par la configuration de votre
+ système.Certaines variables d'environnement permettent de modifier les
+ choix effectués par configure, ou d'aider ce dernier à
+ trouver les bibliothèques et programmes possédant des noms et chemins
+ non standards.
CCCFLAGSCPPCPPFLAGS-Irépertoire-include, si certains de vos
+ fichiers d'en-têtes se trouvent dans le répertoire non standard
+ répertoire-include.LDFLAGS-Lrépertoire-lib, si certaines de vos
+ bibliothèques se trouvent dans le répertoire non standard
+ répertoire-lib.Serveur HTTP Apache Version 2.4
+dbmmanage permet de créer et de maintenir les
+ fichiers au format DBM où sont stockés les noms d'utilisateurs et
+ mots de passe à des fins d'authentification de base des utilisateurs
+ HTTP via le module mod_authn_dbm. Il est possible
+ de restreindre l'accès aux ressources disponibles sur le serveur
+ HTTP Apache aux seuls utilisateurs spécifiés dans les fichiers créés
+ par dbmmanage. Ce programme ne peut être utilisé
+ qu'avec des fichiers d'utilisateurs au format DBM. Pour
+ l'utilisation de fichiers textes, voir le programme
+ htpasswd.
Le programme htdbm est aussi un utilitaire
+ permettant de maintenir une base de données de mots de passe DBM.
Cette page de manuel ne décrit que les arguments de la ligne de
+ commande. Pour plus de détails à propos des directives nécessaires
+ pour configurer l'authentification des utilisateurs dans
+ httpd, voir le manuel httpd qui est fourni avec
+ la distribution d'Apache, ou peut être consulté à http://httpd.apache.org/.
dbmmanage [ codage ]
+ nom-fichier add|adduser|check|delete|update
+ nom-utilisateur
+ [ mot-de-passe-chiffré
+ [ groupe[,groupe...]
+ [ commentaire ] ] ]
dbmmanage nom-fichier
+ view [ nom-utilisateur ]
dbmmanage nom-fichierimport
nom-fichier.db, .pag, ou .dir.nom-utilisateur:.mot-de-passe-chiffréupdate et add. Vous pouvez
+ utiliser un tiret (-) si vous voulez que le mot de
+ passe vous soit demandé, mais remplissez les champs par la suite. En
+ outre, avec la commande update, un point
+ (.) permet de conserver le mot de passe original.groupe:). Vous pouvez
+ utiliser un tiret (-) si vous ne voulez pas associer
+ l'utilisateur à un groupe, mais remplissez le champ commentaire. En
+ outre, avec la commande update, un point
+ (.) permet de conserver le groupe original.commentaire-d-m-s-padddbmmanage passwords.dat add rbowen foKntnEF3KSXA
adduserdbmmanage passwords.dat adduser krietz
checkdbmmanage passwords.dat check rbowen
deletedbmmanage passwords.dat delete rbowen
importnom-utilisateur:mot-de-passe
+ (une par ligne) depuis STDIN, et les ajoute à
+ nom-fichier. Les mots de passe doivent être déjà
+ chiffrés.updateadduser, à l'exception
+ que la présence de nom-utilisateur dans
+ nom-fichier est vérifiée.
+
+ dbmmanage passwords.dat update rbowen
viewdbmmanage passwords.dat view
Vous devez garder à l'esprit qu'il existe de nombreux formats de
+ fichiers DBM différents, et que selon toute vraisemblance, des
+ bibliothèques pour plus d'un format sont présentes sur votre
+ système. Les trois exemples de base sont SDBM, NDBM, le projet GNU
+ GDBM, et Berkeley DB 2. Malheureusement, toutes ces bibliothèques
+ utilisent des formats de fichiers différents, et vous devez vous
+ assurer que le format de fichier utilisé par nom-fichier
+ correspond au format attendu par dbmmanage.
+ Actuellement, dbmmanage n'a aucun moyen de savoir à
+ quel type de fichier DBM il a à faire. S'il est utilisé avec un
+ format inapproprié, il ne renverra rien, ou pourra créer un fichier
+ DBM différent avec un nom différent, ou au pire, va corrompre le
+ fichier DBM si vous avez tenté de le modifier.
dbmmanage possède une liste de préférences en
+ matière de formats DBM, définies dans le tableau
+ @AnyDBM::ISA au début du programme. Comme nous
+ préférons le format de fichier Berkeley DB 2, l'ordre dans lequel
+ dbmmanage va rechercher les bibliothèques système est
+ Berkeley DB 2, puis NDBM, GDBM et enfin SDBM. La première
+ bibliothèque trouvée sera celle que dbmmanage tentera
+ d'utiliser pour toutes les opérations sur les fichiers DBM. Cette
+ ordre est sensiblement différent de l'ordre standard de Perl
+ @AnyDBM::ISA, et de l'ordre utilisé par l'appel
+ dbmopen() de Perl ; si vous utilisez un autre
+ utilitaire pour gérer vos fichiers DBM, il doit donc se conformer à
+ l'ordre de préférence indiqué précédemment. Vous devez prêter la
+ même attention si vous utilisez des programmes écrits dans d'autres
+ langages, comme C, pour accéder à ces fichiers.
Vous pouvez utiliser le programme file fourni par la
+ plupart des systèmes Unix pour déterminer le format d'un fichier
+ DBM.
Serveur HTTP Apache Version 2.4
+Ne fonctionne actuellement que sur les systèmes de type Unix.
+fcgistarter
+ -c commande
+ -p port
+ [ -i interface ]
+ -N nombre
+
-c commande-p port-i interface-N nombreServeur HTTP Apache Version 2.4
+htcacheclean permet de maintenir la taille de
+ l'espace de stockage réservé à mod_disk_cache en
+ dessous d'une limite de taille donnée ou d'inodes utilisés. Cet
+ utilitaire peut s'exécuter
+ soit manuellement, soit en mode démon. Lorsqu'il fonctionne en mode
+ démon, il se met en attente en arrière-plan et recherche à
+ intervalles réguliers dans le répertoire du cache les contenus à
+ supprimer. Pour arrêter proprement le démon, vous pouvez lui envoyer
+ un signal TERM ou INT. Lorsqu'il est lancé manuellement, une
+ recherche des contenus du cache qui peuvent être supprimés est
+ effectuée une seule fois. Si une ou plusieurs URLs sont spécifiées,
+ chacune d'entre elles sera supprimée du cache, si elle est présente.
Syntaxe Options Suppression d'une URL particulière Affichage des URLs présentes dans le cache Valeur renvoyéehtcacheclean
+ [ -D ]
+ [ -v ]
+ [ -t ]
+ [ -r ]
+ [ -n ]
+ [ -Rarrondi ]
+ -pchemin
+ [-llimite|
+ -Llimite]
htcacheclean
+ [ -n ]
+ [ -t ]
+ [ -i ]
+ [ -Pfichier-pid ]
+ [ -Rarrondi ]
+ -dintervalle
+ -pchemin
+ [-llimite|
+ -Llimite]
htcacheclean
+ [ -v ]
+ [ -Rarrondi ]
+ -pchemin
+ [ -a ]
+ [ -A ]
htcacheclean
+ [ -D ]
+ [ -v ]
+ [ -t ]
+ [ -Rarrondi ]
+ -pchemin
+ url
-dintervalle-D, -v et -r s'excluent
+ mutuellement. Pour arrêter le démon proprement, il suffit de lui
+ envoyer un signal SIGTERM ou SIGINT.-D-d s'excluent mutuellement. Si ce mode
+ est combiné avec la suppression des répertoires avec
+ -t, les inodes signalés comme supprimés dans les
+ statistiques ne peuvent pas prendre en compte les répertoires
+ supprimés, et seront marqués en tant qu'estimation.-v-d s'excluent mutuellement.-r-t et s'exclue
+ mutuellement avec l'option -d.-nhtcacheclean s'interrompt
+ de temps en temps de façon à ce que a) les entrées/sorties disque
+ soient retardées et b) que le noyau puisse mettre ce temps
+ processeur à disposition des autres processus.-t-pcheminCacheRoot.-Pfichier-pid-Rround-llimiteB à la valeur). Ajoutez le suffixe
+ K pour KOctets ou M pour MOctets.-Llimite-i-d.-a-ASi une ou plusieurs URLs sont passées en argument à
+ htcacheclean, chacune d'entre elles sera supprimée du
+ cache. S'il existe plusieurs variantes de ces URLs, elles seront
+ toutes supprimées.
Lorsqu'une URL mandatée en inverse doit être supprimée, l'URL + effective est construite à partir de l'en-tête + Host, du port, du + chemin et de la requête. Notez que + le '?' doit toujours être spécifié explicitement dans l'URL, qu'une + chaîne de paramètres soit présente ou non. Par exemple, pour + supprimer le chemin / du serveur + localhost, l'URL devra être spécifiée comme suit : + http://localhost:80/?.
+ +Les options -a ou -A permettent
+ d'afficher les URLs présentes dans le cache telles qu'elles s'y
+ trouvent, une URL par ligne. L'option -A affiche
+ l'entrée du cache complète pour chaque URL, avec ses différents
+ champs dans l'ordre suivant :
htcacheclean renvoie zéro ("true") si toutes les
+ opérations se sont déroulées normalement, et 1 dans le
+ cas contraire. Si une URL est spécifiée, et si cette URL était
+ présente dans le cache et a été supprimée avec succès,
+ htcacheclean renvoie 0, et 2
+ dans le cas contraire. Si une erreur est survenue au cours de la
+ suppression de l'URL, htcacheclean renvoie
+ 1.
Serveur HTTP Apache Version 2.4
+htdbm permet de manipuler des fichiers au format DBM
+ ou sont stockés des nom d'utilisateurs et mots de passe à des fins
+ d'authentification de base des utilisateurs HTTP via le module
+ mod_authn_dbm. Voir la documentation de
+ dbmmanage pour plus de détails à propos de ces
+ fichiers DBM.
Syntaxe Options Bugs Valeur renvoyée Exemples Considérations à propos de sécurité Restrictionshtdbm
+ [ -TDBTYPE ]
+ [ -i ]
+ [ -c ]
+ [ -m |
+ -B |
+ -d |
+ -s |
+ -p ]
+ [ -C cost ]
+ [ -t ]
+ [ -v ]
+ nom-fichier nom-utilisateur
htdbm -b
+ [ -TDBTYPE ]
+ [ -c ]
+ [ -m |
+ -B |
+ -d |
+ -s |
+ -p ]
+ [ -C cost ]
+ [ -t ]
+ [ -v ]
+ nom-fichier nom-utilisateur mot-de-passe
htdbm -n
+ [ -i ]
+ [ -c ]
+ [ -m |
+ -B |
+ -d |
+ -s |
+ -p ]
+ [ -C cost ]
+ [ -t ]
+ [ -v ]
+ nom-utilisateur
htdbm -nb
+ [ -c ]
+ [ -m |
+ -B |
+ -d |
+ -s |
+ -p ]
+ [ -C cost ]
+ [ -t ]
+ [ -v ]
+ nom-utilisateur mot-de-passe
htdbm -v
+ [ -TDBTYPE ]
+ [ -i ]
+ [ -c ]
+ [ -m |
+ -B |
+ -d |
+ -s |
+ -p ]
+ [ -C cost ]
+ [ -t ]
+ [ -v ]
+ nom-fichier nom-utilisateur
htdbm -vb
+ [ -TDBTYPE ]
+ [ -c ]
+ [ -m |
+ -B |
+ -d |
+ -s |
+ -p ]
+ [ -C cost ]
+ [ -t ]
+ [ -v ]
+ nom-fichier nom-utilisateur mot-de-passe
htdbm -x
+ [ -TDBTYPE ]
+ nom-fichier nom-utilisateur
htdbm -l
+ [ -TDBTYPE ]
+
-b-i.-i-c-n.-n-c.-m-B-C-B (chiffrement bcrypt). Il permet de définir la durée
+ de traitement pour l'algorythme de chiffrement bcrypt (plus elle est
+ longue, plus la sécurité est élevée, mais la rapidité est diminuée
+ d'autant) ; la valeur par défaut est 5, les valeurs valides vont de
+ 4 à 31.-dcrypt() pour les mots de
+ passe. C'est l'option par défaut sur toutes les plates-formes, sauf
+ Windows et Netware. Bien que htdbm supporte ce
+ chiffrement sur toutes les plates-formes, il n'est pas supporté par
+ le serveur httpd sous Windows et Netware. Cet
+ algorythme est considéré comme non sûr selon les
+ standards actuels.-s-phtdbm supporte ce format sur toutes les plates-formes,
+ le démon httpd n'accepte les mots de passe au
+ format texte en clair que sous Windows et Netware.-l-v-x-tnom-fichier.db, .pag, ou .dir. Avec
+ l'option -c, le fichier DBM est mis à jour s'il existe
+ ou créé dans le cas contraire.nom-utilisateurmot-de-passe-b.-TDBTYPEVous devez garder à l'esprit qu'il existe de nombreux formats de
+ fichiers DBM différents, et que selon toute vraisemblance, des
+ bibliothèques pour plus d'un format sont présentes sur votre
+ système. Les trois exemples de base sont SDBM, NDBM, le projet GNU
+ GDBM, et Berkeley/Sleepycat DB 2/3/4. Malheureusement, toutes ces
+ bibliothèques
+ utilisent des formats de fichiers différents, et vous devez vous
+ assurer que le format de fichier utilisé par nom-fichier
+ correspond au format attendu par htdbm.
+ Actuellement, htdbm n'a aucun moyen de savoir à
+ quel type de fichier DBM il a à faire. S'il est utilisé avec un
+ format inapproprié, il ne renverra rien, ou pourra créer un fichier
+ DBM différent avec un nom différent, ou au pire, va corrompre le
+ fichier DBM si vous avez tenté de le modifier.
Vous pouvez utiliser le programme file fourni par la
+ plupart des systèmes Unix pour déterminer le format d'un fichier
+ DBM.
htdbm renvoie 0 ("true") si les nom d'utilisateur et
+ mot de passe ont été créés ou mis à jour avec succès dans le fichier
+ DBM. htdbm renvoie 1 s'il a rencontré un
+ problème d'accès aux fichiers, 2 si la ligne de
+ commande comportait une erreur de syntaxe, 3 si le mot
+ de passe a été fourni interactivement et s'il est invalide pour
+ l'entrée considérée, 4 si l'opération a été
+ interrompue, 5 si une valeur est trop longue (nom
+ utilisateur, nom fichier, mot de passe, ou l'enregistrement après
+ son élaboration), 6 si le nom d'utilisateur contient
+ des caractères illégaux (voir la section Restrictions), et 7 si le
+ fichier n'est pas un fichier de mots de passe DBM valide.
+ htdbm /usr/local/etc/apache/.utilisateurs-htdbm jsmith
+
Ajoute ou modifie le mot de passe de l'utilisateur
+ jsmith. Le mot de passe est demandé à l'opérateur. Sous
+ Windows, le mot de passe sera chiffré en utilisant l'algorithme MD5
+ Apache modifié ; dans les autres cas, c'est la routine
+ crypt() du système qui sera utilisée. Si le fichier
+ n'existe pas, htdbm s'arrêtera et renverra une
+ erreur.
+ htdbm -c /home/doe/public_html/.htdbm jane
+
Crée un nouveau fichier et y enregistre une entrée pour
+ l'utilisateur jane. Le mot de passe est demandé à
+ l'opérateur. Si le fichier existe et ne peut pas être lu, ou ne peut
+ pas être écrit, il ne sera pas modifié et
+ htdbm affichera un message et renverra un code
+ d'erreur.
+ htdbm -mb /usr/web/.htdbm-tous jones Pwd4Steve
+
Chiffre le mot de passe entré avec la ligne de commande
+ (Pwd4Steve) à l'aide de l'algorithme MD5, et
+ l'enregistre dans le fichier spécifié.
Les fichiers de mots de passe Web tels que ceux que gère
+ htdbm ne doivent pas être stockés dans
+ l'espace d'URI du serveur Web -- en d'autres termes, il ne doit pas
+ être possible d'y accéder à l'aide d'un navigateur.
L'utilisation de l'option -b est déconseillée, car
+ lorsqu'il est utilisé, le mot de passe apparaît en clair dans la
+ ligne de commande.
Notez que lorsque vous utilisez l'algorythme
+ crypt(), seuls les 8 premiers caractères du mot de
+ passe sont pris en compte. Si le mot de passe fourni est plus long,
+ les caractères supplémentaires seront ignorés sans avertissement.
L'algorythme SHA ne permet pas de spécifier une valeur
+ d'initialisation pour la génération de nombres aléatoires (salting)
+ : un mot de passe donné ne possède ainsi qu'une réprésentation
+ chiffrée. Les algorythmes crypt() et MD5 permettent quant à
+ eux des représentations chiffrées multiples en acceptant comme
+ paramètre une chaîne d'initialisation (salt), rendant les attaques à
+ base de dictionnaires contre les mots de passe plus difficiles.
Les algorythmes SHA et crypt() sont considérés comme
+ non sûrs selon les standards actuels.
Sur la plate-forme Windows, les mots de passe chiffrés avec
+ htdbm ont une taille limitée à 255
+ caractères. Si le mot de passe fourni est plus long, il sera tronqué
+ à 255 caractères.
L'algorithme MD5 utilisé par htdbm est spécifique à
+ Apache ; les mots de passe chiffrés en utilisant cet algorithme
+ seront inutilisables sur d'autres serveurs Web.
Les noms d'utilisateurs ont une taille limitée à 255
+ octets et ne doivent pas contenir de caractère :.
Serveur HTTP Apache Version 2.4
+htdigest permet de créer et maintenir les fichiers
+ textes dans lesquels sont stockés des noms d'utilisateurs, des
+ domaines de protection (realms) et des mots de passe pour
+ l'authentification à base de condensés des utilisateurs HTTP.
+ L'accès aux ressources du serveur HTTP Apache peut être limité aux
+ seuls utilisateurs enregistrés dans les fichiers créés par
+ htdigest.
Cette page de manuel ne décrit que les arguments de la ligne de
+ commande. Pour plus de détails à propos des directives nécessaires à
+ la configuration de l'authentification à base de condensés dans
+ httpd, voir le manuel Apache qui est fourni avec
+ la distribution et peut être consulté à http://httpd.apache.org/.
htdigest [ -c ]
+ fichier-mots-de-passe realm
+ nom-utilisateur
-cfichier-mots-de-passe-c est spécifiée, le fichier est
+ créé s'il n'existe pas, ou supprimé et recréé s'il existe
+ déjà.realmnom-utilisateurEn tant qu'exécutable setuid, ce programme n'est pas sûr. En + conséquence, évitez de lui attribuer des permissions setuid.
+Serveur HTTP Apache Version 2.4
+htpasswd permet de créer et de maintenir les
+ fichiers textes où sont stockés les noms d'utilisateurs et mots de
+ passe pour l'authentification de base des utilisateurs HTTP. Si
+ htpasswd rencontre un problème d'accès à un fichier,
+ que ce soit pour écrire dans le fichier de sortie, ou pour lire le
+ fichier d'entrée dans le but de le mettre à jour, il renvoie un code
+ d'erreur et n'effectue aucune modification.
Il est possible de limiter l'accès aux ressources du serveur HTTP
+ Apache aux seuls utilisateurs présents dans les fichiers créés par
+ htpasswd. Ce programme ne sait gérer les noms
+ d'utilisateurs et mots de passe que s'ils sont stockés dans des
+ fichiers textes. Il peut cependant chiffrer et afficher les mots de
+ passe à des fins d'utilisation dans d'autres types de bases de
+ données. Pour utiliser une base de données DBM, voir le programme
+ dbmmanage ou htdbm.
htpasswd chiffre les mots de passe en utilisant soit
+ bcrypt,
+ une version de MD5 modifiée pour Apache, soit SHA1, soit la routine
+ crypt() du système. Les fichiers gérés par
+ htpasswd peuvent contenir deux types de mots de passe ;
+ certaines entrées peuvent contenir des mots de passe chiffrés en
+ MD5 ou bcrypt, alors que d'autres entrées du même fichier contiendront des
+ mots de passe chiffrés avec crypt().
Cette page de manuel ne décrit que les arguments de la ligne de
+ commande. Pour plus de détails à propos des directives nécessaires à
+ la configuration de l'authentification des utilisateurs dans
+ httpd, voir le manuel Apache qui est fourni avec
+ la distribution ou peut être consulté à http://httpd.apache.org/.
Syntaxe Options Valeur renvoyée Exemples Considérations à propos de sécurité Restrictionshttpdhtdbmhtpasswd
+ [ -c ]
+ [ -i ]
+ [ -m |
+ -B |
+ -d |
+ -s |
+ -p ]
+ [ -C cost ]
+ [ -D ]
+ [ -v ] fichier-mots-de-passe nom-utilisateur
htpasswd -b
+ [ -c ]
+ [ -m |
+ -B |
+ -d |
+ -s |
+ -p ]
+ [ -C cost ]
+ [ -D ]
+ [ -v ] fichier-mots-de-passe nom-utilisateur
+ mot-de-passe
htpasswd -n
+ [ -i ]
+ [ -m |
+ -B |
+ -d |
+ -s |
+ -p ]
+ [ -C cost ] nom-utilisateur
htpasswd -nb
+ [ -m |
+ -B |
+ -d |
+ -s |
+ -p ]
+ [ -C cost ] nom-utilisateur
+ mot-de-passe
-b-i.
+ Disponible à partir de la version 2.4.4 du serveur HTTP Apache.-i-c-n.-n-c option.-m-B-C-B (chiffrement bcrypt). Il permet de définir la durée
+ de traitement pour l'algorytme bcrypt (plus elle est longue,
+ meilleure sera la sécurité, mais inférieure la rapidité). La valeur
+ par défaut est 5 et les valeurs autorisées vont de 4 à 31.-dcrypt() pour les mots de
+ passe. Cette option n'est pas supportée par le
+ serveur httpd sous Windows ou Netware. Cet
+ algorithme limite la longueur des mots de passe à 8 caractères ; il
+ est considéré comme non sur du point de vue des
+ standards actuels. C'était l'algorithme par défaut jusqu'à la
+ version 2.2.17.-s-phtpasswd supporte la création des mots de passe en
+ clair sur toutes les plates-formes, le démon
+ httpd n'accepte les mots de passe en clair que
+ sous Windows et Netware.-D-vfichier-mots-de-passe-c, le fichier est créé s'il
+ n'existe pas, ou réécrit et tronqué s'il existe déjà.nom-utilisateurmot-de-passe-b.htpasswd renvoie 0 ("true") si le nom d'utilisateur
+ et le mot de passe ont été enregistrés ou mis à jour avec succès
+ dans le fichier-mots-de-passe. htpasswd
+ renvoie 1 s'il a rencontré un problème d'accès aux
+ fichiers, 2 si la ligne de commande comportait une
+ erreur de syntaxe, 3 si le mot de passe entré
+ interactivement ne correspondait pas au nom d'utilisateur,
+ 4 si l'opération a été interrompue, 5 si
+ une valeur était trop longue (nom-utilisateur, nom-fichier,
+ mot-de-passe, ou l'enregistrement résultant), 6 si le
+ nom d'utilisateur contenait des caractères illégaux (voir la section
+ Restrictions), et 7 si le
+ fichier spécifié n'était pas un fichier de mots de passe
+ valide.
+ htpasswd /usr/local/etc/apache/.utilisateurs-htpasswd jsmith
+
Ajoute ou modifie le mot de passe de l'utilisateur
+ jsmith. Le mot de passe est demandé à l'opérateur. Le
+ mot de passe sera chiffré en utilisant l'algorithme MD5
+ modifié pour Apache. Si le fichier spécifié
+ n'existe pas, htpasswd renverra un code d'erreur.
+ htpasswd -c /home/doe/public_html/.htpasswd jane
+
Crée un nouveau fichier de mots de passe et y enregistre une
+ entrée pour l'utilisateur jane. Le mot de passe est
+ demandé à l'opérateur. Si le fichier existe et ne peut être ni lu ni
+ écrit, il n'est pas modifié et htpasswd affichera un
+ message et renverra un code d'erreur.
+ htpasswd -db /usr/web/.htpasswd-tous jones Pwd4Steve
+
Chiffre le mot de passe spécifié dans la ligne de commande
+ (Pwd4Steve) en utilisant l'algorithme
+ crypt(), et le stocke dans le fichier spécifié.
Les fichiers de mots de passe Web comme ceux que gère
+ htpasswd ne doivent pas être situés dans
+ l'espace d'URI du serveur Web -- en d'autres termes, il ne doit pas
+ être possible d'y accéder à partir d'un navigateur.
En tant qu'exécutable setuid, ce programme n'est pas sûr, et il + ne faut par conséquent pas lui attribuer de permissions + setuid.
+ +L'utilisation de l'option -b est déconseillée, car
+ avec elle, les mots de passe apparaissent en clair dans la ligne de
+ commande.
Notez qu'avec l'algorithme crypt(), seuls les huit
+ premiers caractères du mot de passe spécifié sont pris en compte. Si
+ le mot de passe spécifié est plus long, les caractères
+ supplémentaires sont ignorés.
Le format de chiffrement SHA n'utilise pas d'amorçage aléatoire
+ (salting) : à un mot de passe donné correspond une seule
+ représentation chiffrée. Les formats crypt() et MD5
+ permutent la représentation en la préfixant par une chaîne d'amorce
+ aléatoire, afin de rendre les attaques de mots de passe à base de
+ dictionnaires plus difficiles.
Les algorithmes de chiffrement SHA et crypt()
+ sont considérés comme non surs du point de vue des
+ standards actuels.
Sur les plates-formes Windows, la taille des mots de passe
+ chiffrés avec htpasswd est limitée à 255
+ caractères. Les mots de passe dont la taille est supérieure seront
+ tronqués.
L'algorithme MD5 utilisé par htpasswd est spécifique
+ à Apache ; les mots de passe chiffrés en utilisant cet algorithme
+ seront inutilisables sur d'autres serveurs Web.
La taille des noms d'utilisateurs est limitée à 255
+ octets et ceux-ci ne doivent pas contenir de caractère
+ :.
Serveur HTTP Apache Version 2.4
+httpd est le programme du serveur HTTP d'Apache. Il
+ a été conçu pour fonctionner sous forme de processus démon
+ indépendant. Lorsqu'il est utilisé ainsi, il va créer un jeu de
+ processus enfants ou de threads qui traiteront les requêtes.
En général, httpd n'est pas invoqué directement,
+ mais plutôt via apachectl sur les systèmes de
+ style Unix ou en tant que service sous
+ Windows NT, 2000 et XP et comme application de
+ console sous Windows 9x et ME.
httpd [ -d
+ racine-serveur ] [ -f config ]
+ [ -C directive ] [ -c
+ directive ] [ -D paramètre ]
+ [ -e niveau ] [ -E
+ fichier ]
+ [ -k start|restart|graceful|stop|graceful-stop ]
+ [ -h ]
+ [ -l ] [ -L ] [ -S ]
+ [ -t ] [ -v ] [ -V ]
+ [ -X ] [ -M ] [ -T ]
+
Sur les systèmes Windows, + les options additionnelles suivantes sont disponibles :
+ +httpd [ -k
+ install|config|uninstall ] [ -n nom ]
+ [ -w ]
-d racine-serveurServerRoot à racine-serveur. Cette
+valeur peut être écrasée par la directive ServerRoot du fichier de
+configuration. La valeur par défaut est
+/usr/local/apache2.-f configServerRoot. La valeur par défaut est
+conf/httpd.conf.-k start|restart|graceful|stop|graceful-stophttpd. Voir Arrêter Apache httpd pour plus d'informations.-C directive-c directive-D paramètre<IfDefine>
+des fichiers de configuration, ces dernières permettant d'exécuter ou
+non des
+commandes au démarrage ou au redémarrage du serveur. Sert aussi à
+définir certains paramètres de démarrage moins courants comme
+-DNO_DETACH (empêche le processus parent de lancer des
+processus enfants) et -DFOREGROUND (empêche le processus
+parent d'appeler setsid() et autres).-e niveauLogLevel à
+niveau pendant le démarrage du serveur. Ceci permet
+d'augmenter temporairement la verbosité des messages d'erreur afin de
+déterminer les problèmes de démarrage.-E fichier-h-lLoadModule.-L-M-S-T (disponible depuis la version 2.3.8)-t-vhttpd, and then exit.-Vhttpd, puis se termine.-XLes arguments suivants ne sont disponibles que sur la plate-forme Windows :
+ +-k install|config|uninstall-n nom-wServeur HTTP Apache Version 2.4
+httxt2dbm permet, à partir d'une entrée au format
+ texte, de générer des fichiers dbm à utiliser dans les directives
+ RewriteMap avec le type
+ de table dbm.
+
Si le fichier de sortie existe déjà, il ne sera pas tronqué. Les + nouvelles clés seront ajoutées et les clés préexistantes mises à + jour.
+httxt2dbm
+ [ -v ]
+ [ -f TYPE_DBM ]
+ -i TEXTE_SOURCE
+ -o SORTIE_DBM
+
-v-f TYPE_DBMGDBM pour les fichiers GDBM,
+ SDBM pour les fichiers SDBM,
+ DB pour les fichiers DB,
+ NDBM pour les fichiers NDBM,
+ default pour le type DBM par défaut
+ -i TEXTE_SOURCEclé valeur.
+ Voir la documentation de la directive RewriteMap pour plus de détails à
+ propos du format de ce fichier et de sa signification.
+ -o SORTIE_DBM
+ httxt2dbm -i rewritemap.txt -o rewritemap.dbm
+ httxt2dbm -f SDBM -i rewritemap.txt -o rewritemap.dbm
+
Serveur HTTP Apache Version 2.4
+Cette page documente tous les utilitaires inclus + dans le serveur HTTP Apache.
+httpdapachectlabapxsconfiguredbmmanagefcgistarterhtcachecleanhtdigesthtdbmhtpasswdhttxt2dbmlogresolverotatelogssplit-logfilesuexecServeur HTTP Apache Version 2.4
+Ce script perl a été conçu pour être exécuté à intervalles
+ réguliers via un déclencheur de type cron. Il se connecte au serveur
+ pour en extraire des informations quant à son état. Il formate ces
+ informations sous la forme d'une seule ligne qu'il enregistre dans
+ un fichier. Vous devez éditer la valeur des variables en tête de
+ script afin de définir le chemin du fichier de sortie. Pour que ce
+ script puisse fonctionner, mod_status doit au
+ préalable être chargé et configuré.
Le script contient les sections suivantes :
+ +my $wherelog = "/usr/local/apache2/logs/"; # Le fichier de sortie sera + # du style "/usr/local/apache2/logs/19960312" +my $server = "localhost"; # Nom du serveur, par exemple "www.foo.com" +my $port = "80"; # Port d'écoute du serveur +my $request = "/server-status/?auto"; # Requête à soumettre+ + +
Ces variables doivent contenir des valeurs correctes, et le
+gestionnaire /server-status doit être configuré pour le
+répertoire considéré. En outre, l'utilisateur qui exécute le script doit
+avoir les droits d'écriture sur le chemin du fichier de sortie.
L'exécution périodique du script via cron permet d'obtenir un jeu de +rapports d'état qui pourra être utilisé à des fins d'analyse +statistique.
+ +Serveur HTTP Apache Version 2.4
+logresolve est un programme agissant après
+ traitement pour résoudre les adresses IP dans les journaux d'accès
+ d'Apache. Pour minimiser la charge de votre serveur de noms,
+ logresolve possède son propre cache interne sous forme d'une table
+ de hashage. Cela implique que chaque numéro IP ne fera l'objet
+ d'une requête DNS que la première fois où il est rencontré dans le
+ fichier journal.
Le programme reçoit le fichier journal sur son entrée standard. + Les adresses IP doivent se trouver en tête de chaque ligne et + doivent être séparées du reste de la ligne par un espace.
+logresolve [ -s
+ nom-fichier ] [ -c ] <
+ access_log > access_log.new
-s nom-fichier-clogresolve effectue certaines
+vérifications DNS : après avoir trouvé le nom d'hôte correspondant à une
+adresse IP, logresolve effectue une recherche DNS sur ce
+nom d'hôte et vérifie si une des adresses IP trouvées correspond à
+l'adresse originale.Serveur HTTP Apache Version 2.4
+Cette page contenait la documentation de programmes qui possèdent + maintenant leurs propres pages de documentation. Merci de bien + vouloir mettre à jour vos liens.
+ + + +Serveur HTTP Apache Version 2.4
+rotatelogs est un programme simple à utiliser en
+ conjonction avec la fonctionnalité d'Apache de redirection dans un
+ "pipe" des fichiers journaux. Il supporte une rotation basée sur un
+ intervalle de temps ou une taille maximale du journal.
rotatelogs
+ [ -l ]
+ [ -L nom-lien ]
+ [ -p programme ]
+ [ -f ]
+ [ -D ]
+ [ -t ]
+ [ -v ]
+ [ -e ]
+ [ -c ]
+ [ -n nombre-de-fichiers ]
+ fichier-journal
+ heure-de-rotation|taille-fichier(B|K|M|G)
+ [ décalage ]
-lstrftime(3) avec une
+rotation basée sur la taille.-L nom-lientail -F
+nom-lien.-p programmerotatelogs exécutera le programme
+programme chaque fois qu'un nouveau fichier journal sera
+ouvert. Le nom du fichier nouvellement ouvert est passé comme premier
+argument au programme. Si l'exécution se produit après une rotation,
+l'ancien nom du fichier journal est passé au programme comme second
+argument. rotatelogs
+n'attend pas la fin du programme pour continuer son
+exécution, et cessera tout enregistrement de codes d'erreur lorsqu'il
+aura terminé son processus. Le programme utilise les mêmes
+canaux stdin, stdout, et stderr que rotatelogs, et hérite de son
+environnement.-frotatelogs démarre, au lieu d'attendre la lecture de la
+première entrée de journal (pour les sites peu chargés, il peut
+s'écouler un temps substantiel entre le démarrage du serveur et le
+traitement de la première requête, temps pendant lequel le fichier
+journal associé n'"existe" pas, ce qui peut causer des problèmes à
+certains utilitaires de journalisation automatiques).-Dstrftime(3) non seulement dans le nom de fichier mais aussi dans le
+chemin.-t-v-c-e-n nombre-de-fichiersfichier-journalLe chemin et le nom de base du fichier journal. Si
+fichier-journal contient des caractères '%', il est considéré
+comme une chaîne de formatage pour strftime(3). Dans le cas
+contraire, le suffixe .nnnnnnnnnn est automatiquement ajouté
+et correspond au temps en secondes (sauf si l'option -t est spécifiée).
+Les deux formats calculent le temps
+de démarrage depuis le début de la période courante. Par exemple, si un
+temps de rotation de 86400 est spécifié, les champs heure, minute et
+seconde créés à partir du format strftime(3) auront tous
+pour valeur 0, en référence au début de la période de 24 heures courante
+(minuit).
Si vous utilisez le formatage de noms de fichiers
+strftime(3), assurez-vous que le format du fichier journal
+possède une granularité suffisamment importante pour générer un nom de
+fichier différent à chaque rotation des journaux. Si ce n'est pas le
+cas, la rotation va écraser le fichier existant au lieu d'en générer un
+nouveau. Par exemple, si fichier-journal était
+/var/log/errorlog.%Y-%m-%d avec une rotation à 5
+mégaoctets, et si la limite de 5 mégaoctets a été atteinte deux fois
+dans la même journée, le même nom de fichier va être généré, et la
+rotation va écraser le fichier existant.
temps-rotationtaille-fichier(B|K|M|G)B (Octets), K (KOctets), M (MOctets)
+ou G (GOctets).
++Lorsque temps et taille sont spécifiés, la taille doit l'être après le +temps. La rotation interviendra alors aussitôt que l'une des deux limites +(temps ou taille) sera atteinte. +
+décalage-300 pour cette option. Dans la
+plupart des cas, il vaut mieux utiliser l'option -l que
+spécifier un décalage.
+ CustomLog "|bin/rotatelogs /var/log/fichier-journal 86400" common
+
Cette directive crée les fichiers /var/log/fichier-journal.nnnn + où nnnn correspond au temps système auquel la journalisation + démarre effectivement (ce temps sera toujours un multiple du temps + de rotation, si bien que vous pouvez synchroniser les scripts cron + avec lui). A la fin de chaque temps de rotation (ici après 24 + heures), une nouvelle journalisation démarre.
+ +
+ CustomLog "|bin/rotatelogs -l /var/log/fichier-journal.%Y.%m.%d 86400" common
+
Cette directive crée les fichiers + /var/log/fichier-journal.yyyy.mm.dd où yyyy correspond à l'année, + mm au mois et dd au jour du mois. La journalisation basculera vers + un nouveau fichier chaque jour à minuit, temps local.
+ +
+ CustomLog "|bin/rotatelogs /var/log/fichier-journal 5M" common
+
Cette directive va effectuer une rotation du fichier journal + chaque fois que la taille de ce dernier atteindra 5 MOctets.
+ +
+ ErrorLog "|bin/rotatelogs /var/log/journal-erreurs.%Y-%m-%d-%H_%M_%S 5M"
+
Cette directive va effectuer une rotation du fichier journal des
+ erreurs chaque fois que la taille de ce dernier atteindra 5
+ MOctets, et le nom du fichier journal se présentera sous
+ la forme journal-erreurs.YYYY-mm-dd-HH_MM_SS.
+ CustomLog "|bin/rotatelogs -t /var/log/journal 86400" common
+
Cet exemple crée le fichier /var/log/journal en le tronquant + au démarrage, puis une fois par jour. Ce scénario implique qu'un + processus séparé (tel que tail) traite le fichier en temps + réel.
+ +Les substitutions des chaînes de format du fichier journal suivantes
+doivent être supportées par toutes les implémentations de
+strftime(3) ; voir la page de manuel de
+strftime(3) pour les extensions spécifiques à une
+bibliothèque.
%A | nom du jour de la semaine en entier +(localisé) |
%a | nom du jour de la semaine sur 3 +caractères (localisé) |
%B | nom du mois en entier (localisé) |
%b | nom du mois sur 3 caractères (localisé) |
%c | date et heure (localisé) |
%d | jour du mois sur 2 chiffres |
%H | heure sur 2 chiffres (de 0 à 24h) |
%I | heure sur 2 chiffres (de 0 à 12h) |
%j | jour de l'année sur 3 chiffres |
%M | minutes sur 2 chiffres |
%m | mois sur 2 chiffres |
%p | suffixe am/pm pour l'heure de 0 à 12h +(localisé) |
%S | secondes sur 2 chiffres |
%U | semaine de l'année sur 2 chiffres +(Dimanche est le premier jour de la semaine) |
%W | semaine de l'année sur 2 chiffres +(Lundi est le premier jour de la semaine) |
%w | jour de la semaine sur 1 chiffre +(Dimanche est le premier jour de la semaine) |
%X | heure (localisée) |
%x | date (localisée) |
%Y | année sur 4 chiffres |
%y | année sur 2 chiffres |
%Z | nom de la zone de temps |
%% | caractère littéral `%' |
Serveur HTTP Apache Version 2.4
+Ce script perl permet d'extraire un journal pour chaque serveur
+ virtuel à partir d'un journal d'accès global du serveur web. Pour
+ que ce script fonctionne, le premier champ de chaque ligne du
+ journal global doit contenir l'identité du serveur virtuel ; ce
+ champ aura été ajouté à la directive LogFormat via la variable
+ "%v".
+
Création d'un fichier journal comportant l'identité du serveur + virtuel considéré :
+ +LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined_plus_vhost
+CustomLog logs/access_log combined_plus_vhost
+
+
+ Un fichier journal sera créé dans le répertoire à partir duquel
+ vous exécutez le script pour chaque serveur virtuel qui apparaît
+ dans le journal global. Ces fichiers journaux seront nommés à partir
+ du nom du serveur virtuel considéré, avec l'extension
+ .log.
Le fichier journal global est lu depuis l'entrée standard stdin. + Les entrées de ce journal sont alors ajoutées au journal du serveur + virtuel correspondant.
+ +split-logfile < access_log
Serveur HTTP Apache Version 2.4
+suexec permet au serveur HTTP Apache de changer
+ d'utilisateur avant d'exécuter un programme CGI. Pour ce faire, il
+ doit être exécuté par root. A cet effet, comme le
+ démon HTTP ne s'exécute en général pas en tant que
+ root, l'exécutable suexec doit posséder
+ le bit setuid et avoir comme propriétaire root. Seul
+ root doit en posséder les droits en écriture.
Pour plus d'informations à propos des concepts et du modèle de + sécurité du programme suexec, veuillez vous reporter à sa + documentation : http://httpd.apache.org/docs/2.4/suexec.html.
+suexec -V
-Vroot, cette option permet d'afficher les
+options de compilation du programme suexec. Pour des
+raisons de sécurité, toutes les options de configuration ne sont
+modifiables qu'à la compilation.Serveur HTTP Apache Version 2.4
+Ce document est un complément à la documentation de référence de
+mod_rewrite. Il explique comment utiliser
+mod_rewrite pour contrôler l'accès à diverses
+ressources, ainsi que d'autres techniques en rapport. Il contient de
+nombreux exemples d'utilisation courante de mod_rewrite avec une
+description détaillée de leur fonctionnement.
Blocage du référencement à chaud (Hotlinking) d'images Blocage des robots Rejet des clients contenus dans une liste noire Aiguillage basé sur l'en-tête RefererCette technique vous permet d'interdire à d'autres sites + d'inclure directement vos images dans leurs pages. On fait + souvent référence à cette pratique sous le nom de + référencement à chaud (Hotlinking) qui entraîne l'utilisation + de votre bande passante pour servir des contenus faisant + partie du site de quelqu'un d'autre.
+Cette technique repose sur la valeur de la variable
+ optionnelle HTTP_REFERER. Certaines personnes
+ pourront donc contourner cette limitation. Pour la plupart des
+ utilisateurs cependant, la requête échouera, en ce sens que
+ l'image ne sera pas affichée depuis le site tiers.
Il y a plusieurs manières de gérer cette situation.
+ +Dans le premier exemple, nous rejetons tout simplement la
+ requête si elle ne provenait pas d'une page appartenant à notre
+ site. Pour les besoins de cet exemple, nous supposons que le nom
+ de votre site est www.example.com.
RewriteCond "%{HTTP_REFERER}" "!^$"
+RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
+RewriteRule "\.(gif|jpg|png)$" "-" [F,NC]
+
+
+ Dans le second exemple, plutôt que de rejeter la requête, + nous affichons une autre image à la place.
+ +RewriteCond "%{HTTP_REFERER}" "!^$"
+RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
+RewriteRule "\.(gif|jpg|png)$" "/images/go-away.png" [R,NC]
+
+
+ Dans le troisième exemple, nous redirigeons la requête vers + une image appartenant à un autre site.
+ +RewriteCond "%{HTTP_REFERER}" "!^$"
+RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
+RewriteRule "\.(gif|jpg|png)$" "http://other.example.com/image.gif" [R,NC]
+
+
+ De tous ces exemples, les deux derniers semblent les plus + efficaces pour faire en sorte que les gens arrêtent de + référencer vos images à chaud, car il ne verront pas les images + qu'ils s'attendent à voir.
+ +Si vous ne voulez pas rediriger la requête, mais + simplement interdire l'accès à la ressource, vous pouvez y + parvenir sans utiliser mod_rewrite :
+ +SetEnvIf Referer "example\.com" localreferer +<FilesMatch "\.(jpg|png|gif)$"> + Require env localreferer +</FilesMatch>+ +
+ Dans cet exemple, nous allons discuter d'une méthode permettant + de bloquer les requêtes persistentes en provenance d'un robot + particulier, ou d'un navigateur.
+ +La méthode classique pour exclure un robot consiste à définir
+ un fichier, /robots.txt qui spécifie les parties de
+ votre site web pour lesquelles vous voulez exclure les robots.
+ Malheureusement, certains robots ne tiennent pas compte de ces
+ fichiers.
+
Notez qu'il existe des méthodes d'exclusion qui n'utilisent
+ pas mod_rewrite. Notez aussi que toute technique qui repose sur
+ le contenu de la chaîne client USER_AGENT peut être
+ contournée très facilement car cette chaîne peut être modifiée.
On utilise un jeu de règles qui spécifie le répertoire à
+ protéger, ainsi que la chaîne client USER_AGENT qui
+ identifie le robot malin ou envahissant.
Dans cet exemple, nous bloquons un robot nommé
+ Vilain_Robot pour le répertoire
+ /secret/fichiers. Si vous voulez bloquer ce client
+ seulement depuis une source particulière, vous pouvez aussi
+ spécifier un intervalle d'adresses IP.
RewriteCond "%{HTTP_USER_AGENT}" "^NameOfBadRobot"
+RewriteCond "%{REMOTE_ADDR}" "=123\.45\.67\.[8-9]"
+RewriteRule "^/secret/files/" "-" [F]
+
+ + Vous pouvez cependant parvenir au même résultat sans utiliser + mod_rewrite via la méthode alternative suivante : +
+SetEnvIfNoCase User-Agent "^NameOfBadRobot" goaway +<Location "/secret/files"> + <RequireAll> + Require all granted + Require not env goaway + </RequireAll> +</Location>+ +
+ Comme indiqué plus haut, il est aisé de contourner cette
+ technique, simplement en modifiant le contenu de l'en-tête
+ USER_AGENT. Si vous subissez une attaque en règle,
+ vous allez devoir réfléchir à un blocage à un niveau supérieur,
+ par exemple une règle de filtrage de votre pare-feu.
+
Nous voulons interdire l'accès à notre serveur aux clients
+ contenus dans une liste noire similaire à
+ hosts.deny.
RewriteEngine on
+RewriteMap hosts-deny "txt:/path/to/hosts.deny"
+RewriteCond "${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}" "!=NOT-FOUND" [OR]
+RewriteCond "${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}" "!=NOT-FOUND"
+RewriteRule "^" "-" [F]
+
+
+
+##
+## hosts.deny
+##
+## ATTENTION! Ceci est une table de correspondances, non une liste,
+## même si elle est traitée comme telle. mod_rewrite
+## l'interprète comme une liste de paires clé/valeur, et
+## chaque entrée doit au moins posséder une valeur par
+## défaut "-".
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+
+ La seconde condition RewriteCond présuppose que HostNameLookups est
+ défini à On, de façon à ce que les adresses IP des clients puissent
+ être résolues. Dans le cas contraire, vous devez supprimer la
+ seconde condition, ainsi que le drapeau [OR] de la
+ première.
+
Redirige les requêtes en fonction du Referer de provenance de + la requête, avec des cibles différentes pour chaque Referer.
+Le jeu de règles suivant utilise un fichier de correspondances pour + associer chaque Referer à une cible de redirection.
+ +RewriteMap deflector "txt:/path/to/deflector.map"
+
+RewriteCond "%{HTTP_REFERER}" !=""
+RewriteCond "${deflector:%{HTTP_REFERER}}" "=-"
+RewriteRule "^" "%{HTTP_REFERER}" [R,L]
+
+RewriteCond "%{HTTP_REFERER}" !=""
+RewriteCond "${deflector:%{HTTP_REFERER}|NOT-FOUND}" "!=NOT-FOUND"
+RewriteRule "^" "${deflector:%{HTTP_REFERER}}" [R,L]
+
+
+ Le fichier de correspondances contient les cibles de + redirection associées à chaque Referer, ou, si nous voulons + simplement rediriger les requêtes vers leur Referer, un "-" est + inscrit dans le fichier de correspondances :
+ +## +## deflector.map +## + +http://badguys.example.com/bad/index.html - +http://badguys.example.com/bad/index2.html - +http://badguys.example.com/bad/index3.html http://somewhere.example.com/+ + +
Serveur HTTP Apache Version 2.4
+Ce document complète la documentation de référence du
+ module mod_rewrite. Il présente un certain nombre
+ de techniques avancées quant à
+ l'utilisation de mod_rewrite.
Distribution de la charge entre plusieurs serveurs
+ d'arrière-plan en fonction de l'adresse IP Régéneration de contenu à la volée Répartition de charge Répertoires Home structurés Redirection des ancrages Réécriture dépendant de l'heure Définir des variables d'environnement en fonction de
+ certaines parties de l'URLLa fragmentation ou "sharding" est une technique courante de + distribution de la charge du serveur ou de l'espace de stockage. + Quand on utilise cette méthode, un serveur frontal utilise l'URL + pour répartir de manière appropriée les utilisateurs et objets + entre différents serveurs d'arrière-plan.
+On maintient une table de correspondance entre utilisateurs et + serveurs cibles dans des fichiers externes. Ces derniers se + présentent comme suit :
+ +
+utilisateur1 serveur_physique_utilisateur1
+utilisateur2 serveur_physique_utilisateur2
+: :
+
Tout ceci est enregistré dans un fichier
+ correspondances-utilisateurs-serveurs. Le but est de
+ faire correspondre
+/u/utilisateur1/chemin
+
avec
+ +
+http://serveur_physique_utilisateur1/u/utilisateur/chemin
+
il n'est ainsi pas nécessaire que tous les chemins URL soient + valides sur tous les serveurs physiques d'arrière-plan. Le jeu de + règles suivant fait tout ceci pour nous, en s'appuyant sur les + fichiers de correspondances, en supposant que serveur0 est un + serveur par défaut qui sera utilisé lorsqu'un utilisateur ne + possèdera pas d'entrée dans la table de correspondances :
+ +RewriteEngine on
+RewriteMap users-to-hosts "txt:/path/to/map.users-to-hosts"
+RewriteRule "^/u/([^/]+)/?(.*)" "http://${users-to-hosts:$1|server0}/u/$1/$2"
+
+ Voir la documentation de RewriteMap pour une description plus
+ approfondie de la syntaxe de cette directive.
Nous voulons générer du contenu de manière dynamique, mais le + conserver de manière statique lorsqu'il a été généré. La règle + suivante vérifie l'existence du fichier statique, et le génère + s'il est absent. Les fichiers statiques peuvent être supprimés + périodiquement si on le désire (par exemple via cron), et seront + régénérés à la demande.
+# Cet exemple n'est valable que dans un contexte de répertoire
+RewriteCond "%{REQUEST_URI}" "!-U"
+RewriteRule "^(.+)\.html$" "/regenerate_page.cgi" [PT,L]
+
+
+ L'opérateur -U permet de déterminer si la chaîne
+ de test (dans ce cas REQUEST_URI) est une URL valide.
+ Pour ce faire, il utilise une sous-requête. Si cette sous-requête
+ échoue, ou en d'autres termes, si la ressource demandée n'existe pas,
+ cette règle invoque le programme CGI
+ /regenerate_page.cgi qui génère la ressource
+ demandée et la sauvegarde dans le répertoire des documents, de
+ façon à ce qu'une copie statique puisse être servie lors d'une
+ demande ultérieure.
De cette façon, les documents qui ne sont pas mis à jour + régulièrement peuvent être servis sous une forme statique. Si ces + documents doivent être réactualisés, on peut les supprimer du + répertoire des documents, et ils seront ainsi régénérés à la + prochaine demande.
+Nous voulons répartir la charge de manière aléatoire entre + plusieurs serveurs en utilisant mod_rewrite.
+Pour y parvenir, nous allons utiliser la directive RewriteMap et une liste de
+ serveurs.
RewriteEngine on
+RewriteMap lb "rnd:/path/to/serverlist.txt"
+RewriteRule "^/(.*)" "http://${lb:serveurs}/$1" [P,L]
+
+
+liste-serveurs.txt contiendra la liste des serveurs :
+## liste-serveurs.txt
+
+serveurs un.example.com|deux.example.com|trois.example.com
+
Si vous voulez qu'un serveur se voit confier d'avantage de charge que +les autres, faites le figurer plusieurs fois dans la liste.
+ +Apache possède un module de répartition de charge -
+mod_proxy_balancer - beaucoup plus souple et présentant
+plus de fonctionnalités dans ce domaine que mod_rewrite.
Certains sites avec des milliers d'utilisateurs organisent
+ les répertoires utilisateurs de manière structurée, c'est à
+ dire que chaque répertoire utilisateur se trouve dans un
+ sous-répertoire dont le nom commence (par exemple) par le
+ premier caractère du nom de l'utilisateur. Ainsi,
+ /~larry/chemin correspond à
+ /home/l/larry/public_html/chemin, alors
+ que /~waldo/chemin correspond à
+ /home/w/waldo/public_html/chemin.
On utilise le jeu de règles suivant pour développer les + URLs avec tilde selon l'organisation structurée précédente.
+ +RewriteEngine on +RewriteRule "^/~(([a-z])[a-z0-9]+)(.*)" "/home/$2/$1/public_html$3"+ +
Par défaut, la redirection vers un ancrage HTML ne fonctionne
+ pas, car mod_rewrite échappe le caractère # en le
+ transformant en %23, ce qui rend la redirection
+ inopérante.
On utilise le drapeau [NE] dans la règle
+ RewriteRule. NE signifie "No Escape".
+
Nous voulons servir des contenus différents selon l'heure du + jour en utilisant mod_rewrite.
+Il existe de nombreuses variables nommées
+ TIME_xxx utilisables dans les conditions de
+ réécriture. Utilisées en conjonction avec les modèles de
+ comparaison lexicographique spéciaux <STRING,
+ >STRING et =STRING, elles
+ permettent d'effectuer des redirections dépendant de
+ l'heure :
RewriteEngine on
+RewriteCond "%{TIME_HOUR}%{TIME_MIN}" ">0700"
+RewriteCond "%{TIME_HOUR}%{TIME_MIN}" "<1900"
+RewriteRule "^foo\.html$" "foo.day.html" [L]
+RewriteRule "^foo\.html$" "foo.night.html"
+
+
+ Avec cet exemple, l'URL foo.html renvoie
+ le contenu de foo.jour.html durant le
+ créneau horaire 07:01-18:59, et le contenu de
+ foo.nuit.html le reste du temps.
mod_cache, les mandataires
+ intermédiaires et les navigateurs peuvent chacun mettre en cache
+ les réponses et ainsi afficher une des deux pages en dehors de
+ la fenêtre de temps configurée. On peut utiliser
+ mod_expires pour contourner ce problème. Il est
+ cependant bien plus commode de servir un contenu dynamique, et
+ de le personnaliser en fonction de l'heure du jour.Ici, nous voulons conserver une certaine forme de statut + lorsqu'une réécriture a eu lieu. Par exemple, vous souhaitez + consigner le fait que cette réécriture a eu lieu, et vous servir + plus tard de cette information pour déterminer si une requête sera + concernée par cette réécriture. Pour y parvenir, on peut utiliser + une variable d'environnement.
+Utiliser le drapeau [E] pour définir une variable + d'environnement.
+ +RewriteEngine on +RewriteRule "^/cheval/(.*)" "/poney/$1" [E=rewritten:1]+ + +
Plus loin dans votre jeu de règles, vous pouvez vérifier le + contenu de cette variable d'environnement via une directive + RewriteCond :
+ +RewriteCond "%{ENV:rewritten}" "=1"
+
+
+ Serveur HTTP Apache Version 2.4
+Ce document est un complément à la Documentation de référence de
+mod_rewrite. Il décrit peut-être un des concepts les
+plus importants à propos de mod_rewrite - à savoir, quand doit-on éviter
+de l'utiliser.
mod_rewrite doit être considéré comme un dernier recours,
+lorsqu'aucune alternative n'est possible. Utiliser mod_rewrite lorsqu'il
+existe des alternatives plus simples conduit à des configurations
+confuses, fragiles, et difficiles à maintenir. La compréhension des
+autres alternatives disponibles est une étape très importante sur le
+chemin de la maîtrise de mod_rewrite.
Vous devez vous attacher à comprendre le +fonctionnement des exemples, car la plupart d'entre eux ne +fonctionneront pas sur votre système si vous vous contentez de les +copier/coller dans vos fichiers de configuration.
+ +Le cas le plus courant dans lequel mod_rewrite est
+l'outil approprié est la situation où la seule solution envisageable
+nécessite l'accès aux fichiers de configuration du serveur, alors que
+cet accès ne vous est pas accordé. Certaines directives de configuration
+ne sont disponibles que dans le fichier de configuration du serveur. Si
+vous ne pouvez agir que sur les fichiers .htaccess, vous devrez donc
+vous tourner vers mod_rewrite.
Redirection simple Alias d'URL Hébergement virtuel Mandat simple Test de variables d'environnementmod_alias fournit les directives Redirect et RedirectMatch qui permettent de
+rediriger une URL vers une autre. Plutôt que d'utiliser la directive
+RewriteRule pour ce genre de
+redirection simple d'une URL ou d'une classe d'URLs vers une autre, on
+préfèrera l'utilisation de ces directives. En outre, avec
+RedirectMatch, vous pouvez inclure une expression
+rationnelle dans votre critère de redirection, ce qui vous permet de
+bénéficier de nombreux avantages de la directive
+RewriteRule.
Une utilisation courante de la directive RewriteRule est
+la redirection de toute une classe d'URLs. Par exemple, toutes les URLs
+faisant référence au répertoire /un doivent être
+redirigées vers http://un.example.com/, ou toutes les
+requêtes http doivent être redirigées vers
+https.
Pour ce faire, il est préférable d'utiliser la directive
+Redirect. Souvenez-vous que la directive
+Redirect conserve les informations relatives au chemin. En
+d'autres termes, la redirection d'une URL /un va aussi
+rediriger toutes les URLs de niveaux inférieurs comme
+/un/deux.html et /un/trois/quatre.html.
Pour rediriger les URLs sous /un vers
+http://un.example.com/, utilisez cette définition :
Redirect /one/ http://one.example.com/+ + +
Pour rediriger un nom d'hôte vers un autre nom d'hôte, par exemple
+example.com vers www.example.com, voir la
+méthode Noms d'hôtes canoniques.
Pour rediriger les URLs http vers https,
+utilisez cette définition :
<VirtualHost *:80> +ServerName www.example.com +Redirect "/" "https://www.example.com/" +</VirtualHost> + +<VirtualHost *:443> +ServerName www.example.com +# ... insérer ici la configuration SSL +</VirtualHost>+ + +
L'utilisation de la directive RewriteRule pour accomplir
+cette tâche peut se justifier s'il existe d'autres directives
+RewriteRule dans la même portée. En effet, lorsque des
+directives Redirect et RewriteRule se trouvent
+dans la même portée, les directives RewriteRule sont
+exécutées en premier, sans tenir compte de leur ordre d'apparition dans
+le fichier de configuration.
Dans le cas de la redirection http-vers-https, l'utilisation
+de règles RewriteRule se justifie si vous n'avez pas accès
+au fichier de configuration principal, et devez donc accomplir cette
+tâche au sein d'un fichier .htaccess.
La directive Alias permet
+de mettre en correspondance un URI avec un répertoire, ce dernier étant
+en général situé en dehors de l'arborescence définie par la directive
+DocumentRoot. Bien qu'il soit
+possible d'effectuer cette mise en correspondance avec
+mod_rewrite, il est préférable d'utiliser la directive
+Alias pour des raisons de simplicité
+et de performances.
Alias "/cats" "/var/www/virtualhosts/felines/htdocs"+
+Pour effectuer cette mise en correspondance, mod_rewrite
+s'impose si vous n'avez pas accès aux fichiers de configuration du
+serveur. En effet, la directive Alias ne peut pas être utilisée dans un
+fichier .htaccess, mais seulement dans un contexte de
+serveur principal ou de serveur virtuel.
+
En outre, vous pouvez arriver au même résultat avec les liens
+symboliques, pourvu que Options FollowSymLinks soit activé
+sur votre serveur.
Bien qu'il soit possible de gérer les serveurs
+virtuels avec mod_rewrite, il s'agit rarement de la bonne méthode.
+Il est pratiquement toujours préférable de créer des blocs
+<VirtualHost> individuels.
+Dans l'éventualité où vous devez gérer
+un grand nombre de serveurs virtuels, vous devez vous tourner vers
+mod_vhost_alias pour créer ces serveurs
+automatiquement.
Il est aussi possible d'utiliser des modules comme mod_macro pour
+créer un grand nombre de serveurs virtuels dynamiquement.
L'utilisation de mod_rewrite pour la création de
+serveurs virtuels peut se révéler appropriée si votre service
+d'hébergement ne vous permet pas d'accéder aux fichiers de configuration
+du serveur, et que vous soyez par conséquent obligé de passer par les
+fichiers .htaccess.
Voir le document création de serveurs virtuels +avec mod_rewrite pour plus de détails sur la manière d'y parvenir si +cela semble être tout de même la meilleure approche.
+ +La directive RewriteRule fournit
+le drapeau [P] qui permet de faire passer les URIs
+réécrits par mod_proxy.
RewriteRule "^/?images(.*)" "http://serveur-images.local/images$1" [P]+ + +
Cependant, dans les nombreux cas où aucune correspondance au modèle
+n'est vraiment nécessaire, comme dans l'exemple ci-dessus, il est
+préférable d'utiliser la directive ProxyPass. L'exemple précédent pourrait
+être remplacé par :
ProxyPass "/images/" "http://serveur-images.local/images/"+ + +
Que vous utilisiez RewriteRule ou ProxyPass, vous devrez dans tous les cas
+utiliser aussi la directive ProxyPassReverse pour intercepter les
+redirections en provenance du serveur d'arrière-plan :
ProxyPassReverse "/images/" "http://serveur-images.local/images/"+ + +
Vous devrez cependant tout de même utiliser RewriteRule
+lorsque d'autres RewriteRules se trouvent dans la même portée,
+car elles agissent en général avant les directives
+ProxyPass, et peuvent ainsi les court-circuiter.
mod_rewrite est souvent utilisé pour effectuer une
+action en fonction de la présence ou de l'absence d'une variable
+d'environnement particulière ou d'un en-tête de requête, ce qui peut
+être accompli de manière plus efficace via la directive <If>.
Considérons par exemple le scénario courant où la directive
+RewriteRule est utilisée pour forcer un nom
+d'hôte canonique, tel que www.example.com au lieu de
+example.com. Il est possible d'utiliser à la place la
+directive <If> comme
+suit :
<If "req('Host') != 'www.example.com'">
+ Redirect "/" "http://www.example.com"
+</If>
+
+
+On peut utiliser cette technique dans de nombreux scénarios courant
+pour remplacer mod_rewrite pour effectuer des actions
+en fonction d'en-têtes de requêtes ou de réponses, ou de variables
+d'environnement.
Voir en particulier la documentation sur
+l'évaluation des expressions pour une vue d'ensemble des types
+d'expressions que vous pouvez utiliser dans les sections <If>,
+ainsi que dans certaines directives.
Serveur HTTP Apache Version 2.4
+Ce document décrit les drapeaux disponibles dans la directive
+RewriteRule, en fournissant
+des explications détaillées et des exemples.
Introduction B (échappement dans les références arrières) BNP|backrefnoplus (ne pas échapper
+l'espace en +) C|chain CO|cookie DPI|discardpath E|env END F|forbidden G|gone H|handler L|last N|next NC|nocase NE|noescape NS|nosubreq P|proxy PT|passthrough QSA|qsappend QSD|qsdiscard QSL|qslast R|redirect S|skip T|typeLe comportement d'une directive RewriteRule peut être modifié par un ou
+plusieurs drapeaux. Les drapeaux sont situés en fin de règle, entourés
+de crochets, et séparés le cas échéant par des virgules.
RewriteRule pattern target [Flag1,Flag2,Flag3]+ + +
Chaque drapeau (à quelques exceptions près)
+possède une forme courte, comme CO, ainsi qu'une forme longue,
+comme cookie. Bien que
+la forme courte soit la plus couramment utilisée, nous vous recommandons
+de vous familiariser avec les drapeaux sous leur forme longue, afin de
+bien mémoriser ce que chaque drapeau est supposé faire.
+Certains drapeaux acceptent un ou plusieurs arguments. Les drapeaux ne
+sont pas sensibles à la casse.
Les drapeaux qui modifient les métadonnées associées à la requête +(T=, H=, E=) n'ont aucun effet dans un contexte de répertoire ou de +fichier htaccess, lorsqu'une substitution (autre que '-') est effectuée +au cours de la même passe du processus de réécriture. +
+ +Chaque drapeau disponible est présenté ici, avec un exemple +d'utilisation.
+Avec le drapeau [B], la directive RewriteRule échappe les caractères
+non-alphanumériques avant d'appliquer la transformation. A partir
+de la version 2.4.26, vous pouvez limiter l'échappement dans les
+références arrières à une liste de caractères que vous pouvez spécifiez comme
+dans cet exemple : [B=#?;]. Notez que l'espace peut faire
+partie de la liste des caractères à échapper, mais qu'il ne doit pas
+être le dernier caractère de cette liste.
+
mod_rewrite doit supprimer les séquences d'échappement
+des URLs avant leur
+mise en correspondance avec le système de fichiers ; les séquences
+d'échappement sont donc supprimées des références arrières au moment où
+ces dernières sont appliquées. Avec le drapeau B, les caractères
+non-alphanumériques des références arrières seront échappés. Considérons
+par exemple cette règle :
RewriteRule "^search/(.*)$" "/search.php?term=$1"+ + +
Soit le terme de recherche 'x & y/z' ; un navigateur va le coder
+en 'x%20%26%20y%2Fz', transformant la requête en
+'search/x%20%26%20y%2Fz'. Sans le drapeau B, cette règle de réécriture
+va réécrire la requête en 'search.php?term=x & y/z', ce qui ne
+correspond pas à une URL valide et cette dernière sera encodée en
+search.php?term=x%20&y%2Fz=, ce qui ne correspond pas à
+ce que l'on souhaitait.
Avec le drapeau B, les paramètres sont réencodés avant d'être passés
+à l'URL résultante, ce qui fournit une réécriture correcte en
+/search.php?term=x%20%26%20y%2Fz.
RewriteRule "^search/(.*)$" "/search.php?term=$1" [B,PT]+ + +
Notez que vous devrez peut-être aussi définir la
+directive AllowEncodedSlashes
+à On pour
+que cet exemple particulier fonctionne, car httpd ne permet pas les
+slashes encodés dans les URLs, et renvoie une erreur 404 s'il en
+rencontre un.
Ce processus d'échappement est en particulier nécessaire dans le +contexte d'un mandataire, où l'accès au serveur d'arrière-plan échouera +si on présente à ce dernier une URL non échappée.
+ +Une alternative à ce drapeau consiste à utiliser une directive
+RewriteCond pour capturer
+%{THE_REQUEST}, les chaînes capturées se présentant
+alors sous la forme codée.
Si le drapeau [BNP] est spécifié, la directive RewriteRule échappera le caractère
+espace en %20 au lieu de '+' dans les références arrières. Ceci s'avère
+utile lorsque la référence arrière est utilisée dans la partie chemin,
+et non dans les paramètres de la requête.
Ce drapeau est disponible à partir de la version 2.4.26 du serveur HTTP +Apache.
+ +Le drapeau [C] ou [chain] indique que la règle RewriteRule est chaînée avec la
+suivante. Autrement dit, si la règle s'applique, elle est traitée
+normalement et passe le contrôle à la règle suivante. Par contre, si
+elle ne s'applique pas, la règle suivante, ainsi que toutes les règles
+chaînées qui suivent, seront sautées.
Le drapeau [CO], ou [cookie], vous permet de définir un cookie
+lorsqu'une règle RewriteRule
+s'applique. Il possède trois arguments obligatoires et
+quatre arguments optionnels.
La syntaxe complète de ce drapeau, avec tous ses attributs, est la +suivante :
+ +
+[CO=NAME:VALUE:DOMAIN:lifetime:path:secure:httponly]
+
Si un caractère littéral ':' doit être insérer dans un des champs du +cookie, une autre syntaxe est disponible. Pour utiliser cette syntaxe +alternative, le contenu du champ "Name" doit être précédé du caractère +';', et les sépateurs de champs deviendront des ';'.
+ +
+[CO=;NAME;VALUE:MOREVALUE;DOMAIN;lifetime;path;secure;httponly]
+
Vous devez déclarer un nom, une valeur et un domaine pour que +le cookie puisse être défini.
+ + +www.example.com, ou un
+domaine, comme .example.com. Il doit comporter au moins
+deux parties séparées par un point. C'est à dire que vous ne pouvez pas
+utiliser les valeurs .com ou .net. En effet,
+ce style de cookie est interdit par le modèle de sécurité des cookies.Vous pouvez aussi définir les valeurs suivantes :
+ +/clients/ or
+/fichiers/telechargement/./ - c'est à dire l'ensemble du
+site web.secure,
+true, ou 1, le cookie ne pourra être transmis
+que dans le cadre d'une connexion sécurisée (https).HttpOnly,
+true, ou 1, le cookie aura son drapeau
+HttpOnly activé, ce qui signifie qu'il sera inaccessible au
+code JavaScript pour les navigateurs qui supportent cette
+fonctionnalité.Voici un exemple :
+ +RewriteEngine On +RewriteRule "^/index\.html" "-" [CO=frontdoor:yes:.example.org:1440:/]+ + +
Dans l'exemple ci-dessus, la règle ne réécrit
+pas la requête. La cible de réécriture "-"
+indique à mod_rewrite de transmettre la requête sans
+modification. Par contre, il
+définit un cookie nommé 'frontdoor' avec une valeur 'yes'. Le cookie est
+valide pour tout hôte situé dans le domaine .example.org. Sa
+durée de vie est limitée à 1440 minutes (24 heures), et il sera renvoyé
+pour tous les URIs.
Avec le drapeau DPI, la partie PATH_INFO de l'URI +réécrit est supprimée.
+Ce drapeau est disponible dans les versions 2.2.12 et supérieures.
+Dans un contexte de répertoire, l'URI mis en comparaison par chaque
+règle RewriteRule est la concaténation des
+valeurs courantes de l'URI et de PATH_INFO.
L'URI courant peut être l'URI initial tel qu'il a été fourni par le +client, le résultat d'une passe précédente du processus de réécriture, +ou le résultat de la règle précédente dans le processus courant de +réécriture.
+ +Par contre, la partie PATH_INFO ajoutée à l'URI avant chaque règle ne
+reflète que la valeur de PATH_INFO avant la passe courante du processus
+de réécriture. En conséquence, si de larges portions de l'URI
+correspondent et sont traduites via plusieurs directives
+RewriteRule, sans prendre en compte
+quelles parties de l'URI provenaient du PATH_INFO courant, l'URI final
+pourra se voir ajouter plusieurs copies de PATH_INFO.
Utilisez ce drapeau pour toute substitution où la présence du PATH_INFO qui +résultait de la mise en correspondance précédente de cette requête avec +le système de fichier n'est pas nécessaire. Avec ce drapeau, le +PATH_INFO établi avant que cette passe du processus de réécriture ne +débute est oublié. PATH_INFO ne sera pas recalculé tant que la passe +courante du processus de réécriture ne sera pas achevée. Les règles +suivantes de cette passe ne verront que le résultat direct des +substitutions, sans aucun PATH_INFO ajouté.
+Avec le drapeau [E], ou [env], vous pouvez définir la valeur d'une +variable d'environnement. Notez que certaines variables d'environnement +peuvent être définies après le traitement de la règle, annulant par +la-même ce que vous avez défini. Voir le document +sur les variables d'environnement pour plus de détails sur le +fonctionnement des variables d'environnement.
+ +La syntaxe complète pour ce drapeau est :
+ +[E=!VAR]+ + +
VAL peut comporter des références arrières
+($N ou %N) qui seront développées.
En utilisant la version courte
+ +
+[E=VAR]
+
vous pouvez définir la variable d'environnement nommée
+VAR avec une valeur vide.
La forme
+ +
+[E=!VAR]
+
permet d'annuler la définition de la variable VAR.
Les variables d'environnement s'emploient dans différents contextes, +comme les programmes CGI, d'autres directives RewriteRule, ou des +directives CustomLog.
+ +L'exemple suivant définit une variable d'environnement nommée 'image' +avec une valeur de '1' si l'URI de la requête correspond à un fichier +image. Cette variable d'environnement est ensuite utilisée pour exclure +une telle requête du journal des accès.
+ +
+RewriteRule "\.(png|gif|jpg)" "-" [E=image:1]
+CustomLog "logs/access_log" combined env=!image
+
Notez que le même effet peut être obtenu à l'aide de la directive
+SetEnvIf. Cette technique
+est présentée à titre d'exemple et non de recommandation.
L'utilisation du drapeau [END] permet non seulement de terminer le +processus de réécriture en cours (comme [L]), mais aussi d'empêcher tout +processus de réécriture ultérieur dans un contexte de répertoire +(htaccess).
+ +Ceci ne s'applique pas aux nouvelles requêtes résultant d'une +redirection externe.
+L'utilisation du drapeau [F] permet de faire envoyer par le serveur au
+client un code de statut "403 Forbidden". Le même effet peut être obtenu à
+l'aide de la directive Deny,
+mais ce drapeau offre plus de souplesse dans l'attribution d'un statut
+Forbidden.
La règle suivante va interdire la téléchargement de fichiers
+.exe depuis votre serveur.
RewriteRule "\.exe" "-" [F]+ + +
Cet exemple utilise la syntaxe "-" pour la cible de réécriture, ce +qui signifie que l'URI de la requête n'est pas modifié. Il n'y a aucune +raison de réécrire un URI, si vous avez l'intention d'interdire la +requête.
+ +Lorsqu'on utilise [F], [L] est implicite - c'est à dire que la +réponse est renvoyée immédiatement, et aucune autre règle n'est évaluée.
+ +Le drapeau [G] permet de faire envoyer par le serveur un code de statut +"410 Gone" avec la réponse. Ce code indique qu'une ressource qui était +disponible auparavant ne l'est plus actuellement.
+ +Comme dans le cas du drapeau [F], on utilise en général la syntaxe +"-" pour la cible de réécriture lorsqu'on utilise le drapeau [G] :
+ +RewriteRule "oldproduct" "-" [G,NC]+ + +
Lorsqu'on utilise [G], [L] est implicite - c'est à dire que la +réponse est renvoyée immédiatement, et aucune autre règle n'est évaluée.
+ +Force le traitement de la requête résultante par le gestionnaire +spécifié. Par exemple, on peut utiliser ce drapeau pour forcer +l'interprétation de tous les fichiers sans extension par le gestionnaire +php :
+ +RewriteRule "!\." "-" [H=application/x-httpd-php]+ + +
+L'expression rationnelle ci-dessus - !\. - correspond à
+toute requête qui ne contient pas le caractère ..
+
On peut aussi utiliser ce drapeau pour forcer l'utilisation d'un
+certain gestionnaire en fonction de certaines conditions. Par exemple,
+l'extrait suivant utilisé dans un contexte de niveau serveur permet de
+faire en sorte que les fichiers .php soient
+affichés par mod_php dans le cas où ils font
+l'objet d'une requête avec l'extension .phps :
RewriteRule "^(/source/.+\.php)s$" "$1" [H=application/x-httpd-php-source]+ + + +
L'expression rationnelle ci-dessus -
+^(/source/.+\.php)s$ - va correspondre à toute requête qui
+débutera par /source/, continuera par 1 ou n caractères
+puis par .phps. La référence arrière $1 fait référence à la
+correspondance capturée entre parenthèses de l'expression
+rationnelle.
Lorsque le drapeau [L] est présent, mod_rewrite
+arrête le traitement du jeu de règles. Cela signifie dans la plupart des
+situations que si la règle s'applique, aucune autre règle ne sera
+traitée. Ce drapeau correspond à la commande Perl last, ou
+à la commande break en C. Utilisez ce drapeau pour indiquer
+que la règle courante doit être appliquée immédiatement, sans tenir
+compte des règles ultérieures.
Si vous utilisez des règles RewriteRule dans des fichiers
+.htaccess ou des sections <Directory>, il est important d'avoir quelques
+notions sur la manière dont les règles sont traitées. Pour simplifier,
+une fois les règles traitées, la requête réécrite est passée à nouveau
+au moteur d'interprétation des URLs afin que ce dernier puisse la
+traiter. Il est possible qu'au cours du traitement de la requête
+réécrite, le fichier .htaccess ou la section <Directory> soient à nouveau
+rencontrés, entraînant un nouveau traitement du jeu de règles depuis le
+début. Cette situation se présente le plus souvent lorsqu'une des règles
+provoque une redirection - interne ou externe - ce qui réinitialise le
+traitement de la requête.
Si vous utilisez des directives RewriteRule dans un de ces contextes,
+il importe par conséquent de prévoir explicitement des étapes permettant
+d'éviter un bouclage infini sur les règles,
+et de ne pas compter seulement sur
+le drapeau [L] pour terminer l'exécution d'une série de règles, comme
+décrit ci-dessous.
Un autre drapeau, [END], permet non seulement d'interrompre le cycle +courant du processus de réécriture, mais aussi d'empêcher toute +réécriture ultérieure dans le contexte de répertoire (htaccess). Ceci ne +s'applique pas aux nouvelles requêtes résultant de redirections +externes.
+ +Dans l'exemple donné ici, toute requête est réécrite en
+index.php, la requête originale étant ajoutée comme chaîne
+de requête en argument à index.php ; cependant, la
+directive RewriteCond permet de s'assurer que si
+la requête concerne déjà index.php, la directive RewriteRule sera sautée.
RewriteBase "/"
+RewriteCond "%{REQUEST_URI}" "!=/index.php"
+RewriteRule "^(.*)" "/index.php?req=$1" [L,PT]
+
+Le drapeau [N] provoque un redémarrage du traitement des règles +depuis le début, en utilisant le résultat du jeu de règles, sous +réserve qu'il existe un point de démarrage ; à utiliser avec précautions +car il peut provoquer un bouclage infini. +
++Le drapeau [Next] peut servir, par exemple, +à remplacer de manière répétitive +une chaîne de caractère ou une lettre dans une requête. Dans l'exemple +suivant, chaque occurence de A sera remplacée par B dans la requête, et +ceci jusqu'il n'y ait plus de A à remplacer. +
+ +RewriteRule "(.*)A(.*)" "$1B$2" [N]+ + +
Vous pouvez vous représenter ce traitement comme une boucle
+while : tant que le modèle de la règle correspond (c'est à
+dire, tant que l'URI contient un A),
+effectuer la substitution (c'est à dire, remplacer le A par
+un B).
A partir de la version 2.4.8, ce module renvoie une erreur après +32000 itérations afin d'éviter les boucles infinies. Ce nombre maximum +d'itération peut être modifié via le drapeau N.
+# On veut remplacer 1 caractère à chaque itération de la boucle +RewriteRule "(.+)[><;]$" "$1" [N=64000] +# ... ou s'arrêter après 10 itérations +RewriteRule "(.+)[><;]$" "$1" [N=10]+ + +
Avec le drapeau [NC], le modèle de la règle RewriteRule est comparé à la requête de
+manière insensible à la casse. C'est à dire que cette comparaison
+s'effectue sans tenir compte des majuscules/minuscules dans l'URI
+comparé.
Dans l'exemple suivant, toute requête pour un fichier image sera
+transmise par Apache à votre serveur d'images dédié. La correspondance est
+insensible à la casse, si bien que par exemple, .jpg aussi
+bien que .JPG seront acceptés.
RewriteRule "(.*\.(jpg|gif|png))$" "http://images.example.com$1" [P,NC]+ +
Par défaut, les caractères spéciaux, comme & et
+?, sont convertis en leur équivalent
+hexadécimal. Le drapeau [NE] permet d'éviter cette conversion.
+
RewriteRule "^/anchor/(.+)" "/bigpage.html#$1" [NE,R]+ + +
+Dans l'exemple ci-dessus, /anchor/xyz est réécrit en
+/bigpage.html#xyz. En l'absence du drapeau [NE], le #
+aurait été converti en son équivalent hexadécimal, %23, ce
+qui aurait provoqué un code d'erreur "404 Not Found".
+
Le drapeau [NS] empêche la règle de s'appliquer aux sous-requêtes.
+Par exemple, une page incluse au moyen d'une SSI (Server
+Side Include) est une sous-requête, et vous ne voudrez probablement pas que
+la réécriture s'applique à ces sous-requêtes. Ainsi, lorsque
+mod_dir recherche des informations à propos des
+fichiers par défaut du répertoire (comme les fichiers
+index.html), il s'agit d'une sous-requête interne, et vous
+ne désirez en général pas que ces sous-requêtes soient réécrites. Cette
+réécriture
+n'est pas toujours utile pour les sous-requêtes, et peut même causer des
+erreurs si l'ensemble du jeu de règles est appliqué. L'utilisation de
+ce drapeau permet d'exclure les règles qui peuvent poser problème.
Comment déterminer si vous devez utiliser cette règle ou non : si +vous préfixez les URLs avec des scripts CGI, afin de forcer leur +traitement par le script CGI, vous vous exposez à des problèmes (ou du +moins à une surcharge significative) avec les sous-requêtes. Dans ces +cas, vous devez utiliser ce drapeau.
+ ++Les images, scripts java, ou fichiers css, chargés en tant que partie +d'une page html, ne sont pas des sous-requêtes - le navigateur les +appelle sous forme de requêtes HTTP à part entière. +
+L'utilisation du drapeau [P] entraîne le traitement de la requête par
+le module mod_proxy, et ceci via une requête de
+mandataire. Par exemple, si vous voulez que toutes les requêtes d'images
+soient traitées par un serveur d'images annexe, vous pouvez utiliser
+une règle de ce style :
RewriteRule "/(.*)\.(jpg|gif|png)$" "http://images.example.com/$1.$2" [P]+ + +
L'utilisation du drapeau [P] provoque aussi l'effet du drapeau [L] - +autrement dit, la requête est immédiatement envoyée au mandataire, et +toute règle ultérieure sera ignorée.
+ +
+Vous devez vous assurer que la chaîne de substitution soit un URI valide
+(commençant typiquement par http://nom-serveur)
+qui puisse être traitée par le module mod_proxy. Dans
+le cas contraire, le module mandataire vous renverra une erreur.
+L'utilisation de ce drapeau implémente de manière plus puissante la
+directive ProxyPass, pour
+faire correspondre le contenu distant à l'espace de nommage du serveur
+local.
Lors de la construction de l'URL cible de la règle, il convient + de prendre en compte l'impact en matière de sécurité qu'aura le + fait de permettre au client d'influencer le jeu d'URLs pour + lesquelles votre serveur agira en tant que mandataire. + Assurez-vous que la partie protocole://nom-serveur de l'URL soit + fixe, ou ne permette pas au client de l'influencer induement.
+Utiliser ce drapeau fait intervenir mod_proxy sans la gestion des connexions
+ persistantes, ce qui signifie que vous obtiendrez des performances meilleurs si vous utilisez
+ ProxyPass ou ProxyPassMatch.
Ceci est du au fait que ce drapeau induit l'utilisation du worker par défaut, qui + ne gère pas la mise en commun et la réutilisation des connexions.
+Partout où cela est possible, préférez l'utilisation de ces directives.
+Note: mod_proxy doit être activé pour pouvoir
+utiliser ce drapeau.
+Par défaut, la cible (ou chaîne de substitution) d'une règle
+RewriteRule est sensée être un chemin de fichier. Avec le drapeau [PT],
+par contre, elle est traitée comme un URI. Autrement dit, avec le
+drapeau [PT], le résultat de la règle RewriteRule est passé à nouveau au
+système de mise en correspondance des URLs avec le système de fichiers,
+de façon à ce que les systèmes de mise en correspondance basés sur les
+chemins de fichiers, comme la directive Alias, Redirect, ou ScriptAlias, par exemple, puissent avoir une
+chance d'accomplir leur tâche.
+
+Si par exemple, vous avez un Alias pour /icons, et une règle RewriteRule qui renvoie vers /icons,
+vous devez utiliser le drapeau [PT] pour être sûr que l'Alias sera bien évalué.
+
Alias "/icons" "/usr/local/apache/icons" +RewriteRule "/pics/(.+)\.jpg$" "/icons/$1.gif" [PT]+ + +
+Dans l'exemple précédent, en l'absence du drapeau [PT], l'Alias aurait +été ignoré, ce qui aurait provoqué une erreur 'File not found'. +
+ +Avec le drapeau PT, le drapeau L est
+implicite : la réécriture s'arrêtera afin de transmettre la requête à la
+phase suivante du traitement.
Notez que le drapeau PT est implicite dans des contextes
+de répertoire comme les sections <Directory> ou les fichiers
+.htaccess. Le seul moyen de contourner ceci consiste à
+réécrire vers -.
+Quand l'URI de remplacement contient une chaîne de requête, le
+comportement par défaut de la règle RewriteRule est de supprimer la
+query string (il s'agit des paramètres éventuellement passés dans l'URL après le
+caractère ?, usuellement pour les formulaires traités par la
+méthode HTTP GET) existante, et de la remplacer par celle nouvellement créée.
+Avec le drapeau [QSA], les chaînes de requête peuvent être combinées.
+
Considérons la règle suivante :
+ +RewriteRule "/pages/(.+)" "/page.php?page=$1" [QSA]+ + +
Avec le drapeau [QSA], une requête pour
+/pages/123?one=two sera réécrite en
+/page.php?page=123&one=two. Sans le drapeau [QSA], la
+même requête sera réécrite en /page.php?page=123 -
+autrement dit, la chaîne de requête (query string) existante sera supprimée.
+
+Lorsque l'URI de la requête contient une chaîne de paramètres, et si
+l'URI cible n'en contient pas, le comportement par défaut de la
+directive RewriteRule consiste à copier cette
+chaîne de paramètres dans l'URI cible. Avec le drapeau [QSD], la chaîne
+de paramètres est supprimée.
+
Ce drapeau est disponible dans les versions 2.4.0 et supérieures.
+ ++Lorsque les drapeaux [QSD] et [QSA] sont utilisés ensemble, c'est le +drapeau [QSD] qui l'emporte. +
+ ++Si l'URI cible possède une chaîne de paramètres, le comportement par +défaut sera respecté - c'est à dire que la chaîne de paramètres +originale sera supprimée et remplacée par la chaîne de paramètres de +l'URI cible. +
+ ++Par défaut, le premier (le plus à gauche) point d'interrogation de la +substitution sépare le chemin de la requête de sa chaîne de paramètres. Avec le +drapeau [QSL] au contraire, les deux composants seront séparés en utilisant le +dernier (le plus à droite) point d'interrogation.
+ ++Cela peut s'avérer utile lorsqu'on recherche un fichier dont le nom contient des +points d'interrogation. Si aucune chaîne de paramètre n'est présente dans la +substitution, il est alors possible d'ajouter un point d'interrogation à la fin +et d'utiliser ce drapeau.
+ +Ce drapeau est disponible à partir de la version 2.4.19 du serveur HTTP +Apache.
+ +
+L'utilisation du drapeau [R] provoque l'envoi d'une redirection au
+navigateur. Si une URL pleinement qualifiée (FQDN - fully qualified domain name)
+ est spécifiée (c'est à dire incluant http://nom-du-serveur/),
+ une redirection sera effectuée vers cette adresse. Dans le cas contraire,
+ le protocole courant, le nom du serveur et le numéro de port seront
+ utilisés pour générer l'URL envoyée avec la redirection.
+
Tout code de statut de réponse HTTP valide peut être
+spécifié, en utilisant la syntaxe [R=305], le code de statut 302 étant
+utilisé par défaut si aucun code n'est spécifié. Le code de statut
+spécifié n'est pas nécessairement un code de statut
+de redirection (3xx). Cependant, si le code de statut est en dehors de la plage des codes de
+redirection (300-399), la chaîne de substitution est entièrement
+supprimée, et la réécriture s'arrête comme si le drapeau L
+était utilisé.
En plus des codes de statut de réponse, vous pouvez spécifier les
+codes de redirection en utilisant leurs noms symboliques :
+temp (défaut), permanent, ou
+seeother.
+Vous utiliserez presque toujours [R] en conjonction avec [L] (c'est à
+dire [R,L]), car employé seul, le drapeau [R] préfixe l'URI avec
+http://cet-hôte[:ce-port], mais passe ensuite cette adresse
+à la règle suivante, ce qui provoquera le plus souvent des
+avertissements 'Invalid URI in request'.
+
Le drapeau [S] sert à sauter des règles que vous ne voulez pas voir
+exécuter. La syntaxe du drapeau [S] est [S=N], où
+N correspond au nombre de règles à sauter (sous
+réserve que la règle RewriteRule corresponde).
+Ceci peut s'interpréter comme une instruction
+goto dans votre jeu de règles de réécriture. Dans
+l'exemple suivant, nous ne voulons exécuter la règle RewriteRule que si l'URI demandé ne
+correspond pas à un fichier existant.
# La requête concerne-t-elle un fichier qui n'existe pas ?
+RewriteCond "%{REQUEST_FILENAME}" "!-f"
+RewriteCond "%{REQUEST_FILENAME}" "!-d"
+# Si c'est la cas, on saute les deux règles de réécriture suivantes
+RewriteRule ".?" "-" [S=2]
+
+RewriteRule "(.*\.gif)" "images.php?$1"
+RewriteRule "(.*\.html)" "docs.php?$1"
+
+
+
+
+Cette technique trouve son utilité dans le fait qu'une directive
+RewriteCond ne s'applique
+qu'à la règle qui la suit immédiatement. Ainsi, si vous voulez
+qu'une directive RewriteCond s'applique à plusieurs règles
+RewriteRule, une technique possible consiste à inverser ces
+conditions et ajouter une RewriteRule avec le drapeau [Skip]. Cette technique permet
+d'élaborer des pseudo-constructions if-then-else : la dernière règle du
+bloc then contiendra skip=N, où N est le nombre de règles
+contenues dans le bloc else :
# Est-ce que le fichier existe ?
+RewriteCond "%{REQUEST_FILENAME}" "!-f"
+RewriteCond "%{REQUEST_FILENAME}" "!-d"
+# Create an if-then-else construct by skipping 3 lines if we meant to go to the "else" stanza.
+RewriteRule ".?" "-" [S=3]
+
+# Si le fichier existe, alors :
+RewriteRule "(.*\.gif)" "images.php?$1"
+ RewriteRule "(.*\.html)" "docs.php?$1"
+ # Skip past the "else" stanza.
+ RewriteRule ".?" "-" [S=1]
+# ELSE...
+RewriteRule "(.*)" "404.php?file=$1
+# END
+
+
+Il est probablement plus aisé de définir ce genre de configuration
+via les directives <If>, <ElseIf>, et <Else>.
Définit le type MIME de la réponse résultante renvoyée. L'effet est
+identique à celui de la directive AddType.
Par exemple, vous pouvez utiliser la technique suivante pour servir +du code source Perl en tant que plein texte, s'il est requis d'une +certaine manière :
+ +# Sert les fichier .pl en tant que plein texte +RewriteRule "\.pl$" "-" [T=text/plain]+ + +
Ou encore, si vous possédez une caméra qui produit des fichiers +images jpeg sans extension, vous pouvez forcer le renvoi de ces images +avec le type MIME correct en se basant sur le nom du fichier :
+ +# Les fichiers dont le nom contient 'IMG' sont des images jpg. +RewriteRule "IMG" "-" [T=image/jpg]+ + +
Notez cependant qu'il s'agit d'un exemple trivial, et que le problème
+aurait pu être résolu en utilisant à la place la directive <FilesMatch>. Il faut toujours
+envisager la possibilité d'une solution alternative à un problème avant
+d'avoir recours à la réécriture, qui sera toujours moins efficace qu'une
+solution alternative.
+Dans un contexte de niveau répertoire, n'utilisez que -
+(tiret) comme substitution, dans toute la séquence de réécriture de
+mod_rewrite, sinon le type MIME défini avec ce drapeau
+sera perdu suite à un retraitement interne (y compris les séquences de
+réécriture suivantes de mod_rewrite). Dans ce contexte, vous pouvez
+utiliser le drapeau L pour terminer la séquence
+courante de réécriture de mod_rewrite.
Serveur HTTP Apache Version 2.4
+Ce document est un complément de la documentation de référence du module
+mod_rewrite. Il décrit les changements apportés aux règles
+lorsqu'on utilise mod_rewrite dans les fichiers .htaccess, et comment
+travailler avec ces changements.
Serveur HTTP Apache Version 2.4
+mod_rewrite permet de modifier les requêtes
+ entrantes dynamiquement, en fonction de règles manipulant des expressions rationnelles. Vous pouvez
+ ainsi relier des URLs arbitraires à votre propre structure d'URLs
+ interne comme vous le souhaitez.
Il fournit un + mécanisme de manipulation d'URL particulièrement souple et + puissant en supportant un nombre illimité de règles et de + conditions attachées à chaque règle. Les manipulations d'URLs + peuvent dépendre de tests variés : les URLs peuvent + être finement caractérisées en fonction de variables du serveur, + de variables d'environnement, d'en-têtes HTTP, de repères + temporels, de recherches dans des bases de données + externes, ou même de requêtes vers des bases de données externes + et de différents gestionnaires ou programmes externes.
+ +Les règles de réécriture peuvent agir sur l'ensemble des URLs (la partie chemin
+ et la chaîne de paramètres) et peuvent être utilisées dans le contexte du serveur principal
+ (httpd.conf), mais aussi dans le contexte des
+ serveurs virtuels (sections <VirtualHost>), ou dans le
+ contexte des
+ répertoires (fichiers .htaccess et blocs
+ <Directory>. Le résultat
+ réécrit peut conduire vers d'autres règles à un
+ traitement secondaire interne, une redirection vers une requête
+ externe ou même l'envoi vers un serveur mandataire, en fonction
+ des drapeaux que vous attachez aux
+ règles
mod_rewrite étant très puissant, il peut par + conséquent être très complexe. Ce document + complète la documentation de + référence du module mod_rewrite, et est sensé alléger un + peu cette complexité, et présenter des exemples largement + commentés, ainsi que des situations courantes que vous + pourrez traiter avec mod_rewrite. Mais nous voulons aussi vous + montrer des situations où vous ne devrez pas utiliser + mod_rewrite, et lui préférer d'autres + fonctionnalités standard d'Apache, évitant ainsi + d'entrer dans une complexité inutile.
+ +Serveur HTTP Apache Version 2.4
+Ce document est un complément à la documentation de référence du module
+mod_rewrite. Il décrit les concepts de base dont la
+connaissance est nécessaire pour l'utilisation de
+mod_rewrite. D'autres documents entrent d'avantage dans
+les détails, mais celui-ci devrait aider le débutant à se mouiller les
+pieds.
+
Introduction Expressions rationnelles Les bases des règles de réécriture Drapeaux de réécriture Conditions de réécriture Tables de réécriture Fichiers .htaccessLe module Apache mod_rewrite est un module puissant
+et sophistiqué qui permet la réécriture des URLs. Grâce à lui, vous
+pouvez effectuer quasiment tous les types de réécriture d'URLs dont vous
+avez besoin. Il est cependant assez complexe, et peut paraître
+intimidant au débutant. Certains ont aussi tendance à traiter les
+règles de réécriture comme des incantations magiques, et à les utiliser
+sans vraiment comprendre leur manière d'agir.
Ce document a pour ambition d'être suffisamment explicite pour +permettre la compréhension, et non la copie en aveugle, de ce qui suit. +
+ +Gardez à l'esprit que de nombreuses tâches de manipulation d'URLs
+courantes n'ont pas besoin de la puissance et de la complexité de
+mod_rewrite. Pour les tâches simples, voir
+mod_alias et la documentation sur la Mise en correspondance des URLs avec le
+système de fichiers.
Enfin, avant de procéder, assurez-vous d'avoir configuré le niveau de
+journalisation de mod_rewrite à un des niveaux de trace
+via la directive LogLevel. Bien que
+ceci risque de vous submerger sous une énorme quantité d'informations,
+le débogage des problèmes avec la configuration de
+mod_rewrite est à ce prix car vous verrez alors
+exactement comment chaque règle est traitée.
mod_rewrite utilise le vocabulaire des Expressions rationnelles compatibles Perl. +Ce document n'a pas pour prétention d'être une référence détaillée des +expressions rationnelles. A cet effet, nous recommandons les pages de manuel de PCRE, la page de manuel des +expressions rationnelles Perl, et l'ouvrage Mastering +Regular Expressions, by Jeffrey Friedl.
+ +Dans ce document, nous avons pour but de vous fournir suffisamment de
+vocabulaire des expressions rationnelles pour vous mettre le pied à
+l'étrier, sans être dépassé, en espérant que les directives RewriteRule vous apparaîtront comme des
+formules scientifiques, plutôt que comme des incantations magiques.
Vous trouverez dans ce qui suit le minimum à connaître pour être en
+mesure d'écrire des expressions rationnelles et des règles RewriteRule. Ceci ne représente
+certainement pas un vocabulaire des expressions rationnelles complet,
+mais constitue un bon point de départ, et devrait vous aider à
+déchiffrer les expressions rationnelles simples, et à écrire vos propres
+expressions.
| Motif | +Signification | +Exemple | +
|---|---|---|
. | Correspond à tout caractère unique + | c.t correspondra à cat,
+cot, cut, etc. |
+ | Répète le caractère de correspondance +précédent une ou plusieurs fois | +a+ correspond à a, aa,
+aaa, etc. |
* | Répète le caractère de correspondance +précédent zéro ou plusieurs fois | +a* correspond à tout ce à quoi correspond
+a+, mais correspond aussi à la chaîne vide. |
? | Rend la correspondance optionnelle. |
+colou?r correspondra à color et colour. |
+
^ | Appelé ancrage, correspond au début de la +chaîne | +^a correspond à une chaîne qui commence par
+a |
$ | L'autre ancrage, correspond à la fin de +la chaîne. | +a$ correspond à une chaîne qui se termine par
+a. |
( ) | Regroupe plusieurs caractères en une +seule entité, et conserve une correspondance à des fins d'utilisation +dans une référence arrière. | +(ab)+
+correspond à ababab - à savoir, le +
+s'applique au groupe.
+Pour plus de détails sur les références arrières, voir ci-dessous. |
[ ] | Une classe de caractères - correspond à +un des caractères de la classe | +c[uoa]t correspond à cut,
+cot ou cat. |
[^ ] | Négation de la classe de caractères - +correspond à tout caractère ne faisant pas partie de la classe | +c[^/]t correspond à cat ou
+c=t mais pas à c/t |
Avec mod_rewrite, le caractère ! peut
+préfixer une expression rationnelle afin d'en exprimer la négation.
+Autrement dit, une chaîne ne correspondra que si elle ne correspond pas
+à l'expression située après le !.
Vous devez vous souvenir d'une chose importante : chaque fois
+ que vous utilisez des parenthèses dans un Modèle ou dans
+ un des modèles de conditions, des références arrières
+ sont créées en interne et peuvent être rappelées via les chaînes
+ $N et %N (voir ci-dessous). Ces
+ références sont disponibles lors de la création
+ de la chaîne de substitution d'une directive
+ RewriteRule ou de la
+ chaîne de test d'une directive RewriteCond.
Les captures dans les modèles de directives RewriteRule sont paradoxalement
+ disponibles dans toutes les directives RewriteCond qui précèdent, car
+ les expressions des directives RewriteRule sont évaluées avant
+ les conditions individuelles.
La figure 1 montre à quels endroits les + références arrières sont suceptibles + d'être développées, et illustre le flux des comparaisons + effectuées par les règles RewriteRule et + RewriteCond. Dans les chapitres suivants, nous examinerons comment + utiliser ces références arrières, donc ne vous affolez pas si + elles vous paraissent un peu exotiques au premier abord.
+ +
+ 
+ Figure 1 : Le cheminement d'une référence arrière à
+ travers une règle.
+ Dans cet exemple, une requête pour /test/1234 serait
+ transformée en
+ /admin.foo?page=test&id=1234&host=admin.example.com.
+
Une règle de réécriture RewriteRule est constituée de trois
+arguments séparés par des espaces. Les arguments sont :
Le Modèle est une expression +rationnelle. Au sein de la première règle de réécriture, ou jusqu'à +ce qu'une substitution survienne, elle est comparée au chemin de +l'URL de la requête entrante (la +partie située après le nom d'hôte mais avant tout point d'interrogation +qui indique le début d'une chaîne de paramètres de +requête) ou, dans un contexte de répertoire, au chemin de la +requête relativement au répertoire pour lequel la +règle est définie. Lorsqu'une substitution a eu lieu, les +règles suivantes effectuent leurs comparaisons par rapport à la valeur +substituée.
+ +
+ 
+ Figure 2 : Syntaxe de la directive RewriteRule.
+
La chaîne de Substitution peut, quant à elle, être de +trois types :
+ +RewriteRule "^/jeux" "/usr/local/jeux/web"+ +
Ceci peut faire correspondre une requête à toute localisation voulue de
+votre système de fichiers, un peu comme la directive Alias.
RewriteRule "^/foo$" "/bar"+ +
Si la directive DocumentRoot a
+pour valeur /usr/local/apache2/htdocs, cette règle va faire
+correspondre les requêtes pour http://example.com/foo au
+chemin /usr/local/apache2/htdocs/bar.
RewriteRule "^/produits/vues$" "http://site2.example.com/voirproduits.html" [R]+ +
Ceci informe le client qu'il doit effectuer une nouvelle requête vers +l'URL spécifiée.
+La chaîne de Substitution peut aussi contenir des +références arrières vers des parties du chemin d'URL entrant +correspondant au Modèle. Considérons ce qui suit :
+RewriteRule "^/produits/(.*)/view$" "/var/web/produitsdb/$1"+ +
La variable $1 sera remplacée par tout texte
+correspondant à l'expression située entre les parenthèses dans le
+Modèle. Par exemple, une requête pour
+http://example.com/produits/r14df/vue correspondra au
+chemin /var/web/produitsdb/r14df.
S'il y a plus d'une expression entre parenthèses, elle seront
+accessibles selon leur ordre d'apparition via les variables
+$1, $2, $3, etc...
Le comportement d'une règle RewriteRule peut être modifié par la
+présence d'un ou plusieurs drapeaux en fin de règle. Par exemple, les
+conditions de correspondance d'une règle peuvent être rendues
+insensibles à la casse par la présence du drapeau [NC] :
+
RewriteRule "^puppy.html" "petitchien.html" [NC]+ + +
Pour une liste des drapeaux disponibles, leurs significations, et des +exemples, voir le document Drapeaux de +réécriture.
+ +Il est possible d'utiliser une ou plusieurs directives RewriteCond pour restreindre les types
+de requêtes auxquelles devra s'appliquer la règle RewriteRule suivante. Le premier
+argument est une variable décrivant une caractéristique de la requête,
+le second argument est une expression rationnelle
+qui doit correspondre à la variable, et un troisième argument optionnel
+est une liste de drapeaux qui modifient la manière dont la
+correspondance est évaluée.
+ 
+ Figure 3 : Syntaxe de la directive RewriteCond
+
Par exemple, pour renvoyer toutes les requêtes en provenance d'une +certaine tranche d'adresses IP vers un autre serveur, vous pouvez +utiliser :
+RewriteCond "%{REMOTE_ADDR}" "^10\.2\."
+RewriteRule "(.*)" "http://intranet.example.com$1"
+
+
+Si vous spécifiez plus d'une directive RewriteCond, ces directives
+doivent toutes être satisfaites pour que la règle RewriteRule suivante s'applique. Par exemple,
+pour interdire les requêtes qui contiennent le mot "hack" dans la chaîne
+de requête, sauf si elles contiennent aussi un cookie contenant le mot
+"go", vous pouvez utiliser :
RewriteCond "%{QUERY_STRING}" "hack"
+RewriteCond "%{HTTP_COOKIE}" "!go"
+RewriteRule "." "-" [F]
+
+Notez que le point d'exclamation indique une correspondance négative +; ainsi, la règle n'est appliquée que si le cookie ne contient pas "go"
+ +Les correspondances dans les expressions rationnelles contenues dans
+les directives RewriteCond
+peuvent constituer des parties de la chaîne de Substitution
+de la règle RewriteRule via
+les variables %1, %2, etc... Par
+exemple, ce qui suit va diriger la requête vers un répertoire différent
+en fonction du nom d'hôte utilisé pour accéder au site :
RewriteCond "%{HTTP_HOST}" "(.*)"
+RewriteRule "^/(.*)" "/sites/%1/$1"
+
+Si la requête concernait http://example.com/foo/bar,
+alors %1 contiendrait example.com et
+$1 contiendrait foo/bar.
La directive RewriteMap
+permet en quelque sorte de faire appel à une fonction externe pour
+effectuer la réécriture à votre place. Tout ceci est décrit plus en
+détails dans la Documentation
+supplémentaire sur RewriteMap.
La réécriture est en général définie au niveau de la configuration du
+serveur principal (en dehors de toute section <Directory>) ou dans une section <VirtualHost>. Il s'agit là de la
+manière la plus simple de mettre en oeuvre la réécriture et nous la
+recommandons. Il est possible, cependant, de mettre en oeuvre la
+réécriture au sein d'une section <Directory> ou d'un fichier .htaccess ; ce type de
+configuration est cependant plus complexe. Cette technique est appelée
+réécriture par répertoire.
La principale différence avec les réécritures au niveau du serveur réside
+dans le fait que le préfixe du chemin du répertoire contenant le fichier
+.htaccess est supprimé avant la mise en correspondance dans
+la règle RewriteRule. De
+plus, on doit utiliser la directive RewriteBase pour s'assurer que la
+requête est correctement mise en correspondance.
Serveur HTTP Apache Version 2.4
+Ce document est un complément de la documentation de référence du module
+mod_rewrite. Il décrit comment utiliser le drapeau [P]
+de la directive RewriteRule pour mandater un contenu vers un autre
+serveur. Plusieurs recettes décrivant des scénarios courants sont
+fournies.
+ mod_rewrite implémente le drapeau [P] qui permet de passer des URLs, + via mod_proxy, à un autre serveur. Deux exemples sont fournis ici. + Dans le premier, une URL est passée directement à un autre serveur, + et servie comme si c'était une URL locale. Dans le deuxième, nous + mandatons un contenu manquant vers un serveur d'arrière-plan.
+Pour passer une URL à un autre serveur, on utilise le drapeau + [P] comme suit :
+ +RewriteEngine on +RewriteBase "/produits/" +RewriteRule "^widget/(.*)$" "http://produits.example.com/widget/$1" [P] +ProxyPassReverse "/produits/objet/" "http://produits.example.com/objet/"+ + +
Dans le deuxième exemple, nous ne mandatons la requête que si nous + ne trouvons pas la ressource localement. Ceci peut s'avérer très + utile lorsque vous effectuez une migration d'un serveur vers un + autre, et que vous n'êtes pas certain que tout le contenu a déjà été + migré.
+ +RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+RewriteRule "^/(.*)" "http://ancien.exemple.com/$1" [P]
+ProxyPassReverse "/" "http://ancien.exemple.com/"
+
+ Dans les deux cas, on ajoute une directive ProxyPassReverse afin de s'assurer
+ que toute redirection en provenance du serveur d'arrière-plan est
+ renvoyée correctement au client.
Chaque fois que cela est possible, préférez l'utilisation de la
+ directive ProxyPass ou
+ ProxyPassMatch à
+ mod_rewrite.
Serveur HTTP Apache Version 2.4
+Ce document est un complément à la Documentation de référence de
+mod_rewrite. Il montre comment utiliser
+mod_rewrite pour rediriger et remettre en
+correspondance une requête. Il contient de
+nombreux exemples d'utilisation courante de mod_rewrite avec une
+description détaillée de leur fonctionnement.
De l'ancienne à la nouvelle URL (en interne) De l'ancien au nouveau (en externe) Ressource déplacée vers un autre serveur De statique à dynamique Compatibilité ascendante dans le cadre d'une modification
+ d'extension de nom de fichier Noms d'hôtes canoniques Recherche de pages dans plus d'un répertoire Redirection vers des serveurs géographiquement distribués Contenu dépendant du navigateur URLs canoniques Déplacement du répertoire DocumentRoot Ressource par défaut Rewrite query stringSupposons que nous ayons récemment renommé la page
+ foo.html en bar.html, et voulions
+ maintenant que l'ancienne URL soit toujours valide à des fins
+ de compatibilité ascendante. En fait, on voudrait que le
+ changement de nom soit transparent aux utilisateurs de
+ l'ancienne URL.
On réécrit l'ancienne URL en interne vers la nouvelle via + la règle suivante :
+ +RewriteEngine on +RewriteRule "^/foo\.html$" "/bar.html" [PT]+ +
Supposons toujours que nous ayons récemment renommé la page
+ foo.html en bar.html, et voulions
+ maintenant que l'ancienne URL soit toujours valide à des fins
+ de compatibilité ascendante. En revanche, nous voulons cette
+ fois que la nouvelle URL soit suggérée aux utilisateurs de
+ l'ancienne URL, c'est à dire que l'adresse vue depuis leur
+ navigateur doit également être modifiée.
On force une redirection HTTP vers la nouvelle URL, ce qui + entraîne une modification de celle du navigateur et aussi de ce + que voit l'utilisateur :
+ +RewriteEngine on +RewriteRule "^foo\.html$" "bar.html" [R]+ +
Dans l'exemple interne, on a utilisé mod_rewrite afin + de dissimuler la redirection au client. Dans cet exemple, en + revanche, on aurait pu se contenter d'une directive Redirect :
+ +Redirect "/foo.html" "/bar.html"+ + +
Si une ressource a été déplacée vers un autre serveur, vous + pouvez faire en sorte que les URLs de l'ancien serveur continuent + de fonctionner pendant un certain temps, afin de laisser au + utilisateurs le temps de modifier leurs favoris.
+Vous pouvez utiliser mod_rewrite pour
+ rediriger ces URLs vers le nouveau serveur, mais vous pouvez aussi
+ utiliser les directives Redirect ou RedirectMatch.
#Avec mod_rewrite +RewriteEngine on +RewriteRule "^/docs/(.+)" "http://nouveau.example.com/docs/$1" [R,L]+ + +
#Avec RedirectMatch +RedirectMatch "^/docs/(.*)" "http://nouveau.example.com/docs/$1"+ + +
#Avec Redirect +Redirect "/docs/" "http://nouveau.example.com/docs/"+ +
Comment transformer une page statique foo.html
+ en sa variante dynamique foo.cgi de manière
+ transparente, c'est à dire sans en avertir le
+ navigateur/utilisateur.
On réécrit simplement l'URL en script CGI et force le
+ gestionnaire de contenu à cgi-script de façon
+ à ce que le script s'exécute en tant que programme CGI.
+ Ainsi, une requête vers /~quux/foo.html conduit
+ en interne à l'invocation de
+ /~quux/foo.cgi.
RewriteEngine on +RewriteBase "/~quux/" +RewriteRule "^foo\.html$" "foo.cgi" [H=cgi-script]+ +
Comment conférer une compatibilité ascendante aux URLs
+ (existant encore virtuellement) après avoir migré
+ document.YYYY vers document.XXXX,
+ c'est à dire après avoir par exemple traduit un lot de
+ fichiers .html en fichiers .php
+ ?
On réécrit simplement le nom du fichier en son nom + de base et vérifie s'il existe aussi avec la nouvelle + extension. Si c'est le cas, on utilise ce nom, sinon on + réécrit l'URL sous sa forme originale.
+ + +# jeu de règles assurant une compatibilité ascendante en réécrivant+ +
+# document.html en document.php si et seulement si document.php
+# existe +<Directory "/var/www/htdocs"> + RewriteEngine on + RewriteBase "/var/www/htdocs" + + RewriteCond "$1.php" -f + RewriteCond "$1.html" !-f + RewriteRule "^(.*).html$" "$1.php" +</Directory>
Cet exemple utilise une fonctionnalité souvent méconnue de
+ mod_rewrite, en tirant avantage de l'ordre d'exécution du jeu de
+ règles. En particulier, mod_rewrite évalue la partie gauche des
+ règles de réécriture avant d'évaluer les directives RewriteCond. En
+ conséquence, $1 est déjà défini au moment où les directives
+ RewriteCond sont évaluées. Ceci nous permet de tester l'existence du
+ fichier original (document.html) et du fichier cible
+ (document.php) en utilisant le même nom de base.
Ce jeu de règles est conçu pour une utilisation dans un contexte
+ de répertoire (au sein d'une section <Directory> ou d'un
+ fichier .htaccess), de façon à ce que les vérifications
+ -f effectuent leurs recherches dans le bon répertoire.
+ Vous serez peut-être amené à définir une directive RewriteBase pour spécifier le
+ répertoire de base à partir duquel vous travaillez.
Pour y parvenir, il vaut mieux se passer de mod_rewrite, et utiliser
+plutôt la directive Redirect dans
+une section de serveur virtuel pour le/les noms d'hôte non canoniques.
<VirtualHost *:80> + ServerName undesired.example.com + ServerAlias example.com notthis.example.com + + Redirect "/" "http://www.example.com/" +</VirtualHost> + +<VirtualHost *:80> + ServerName www.example.com +</VirtualHost>+ + +
Vous pouvez aussi utiliser la directive <If> :
<If "%{HTTP_HOST} != 'www.example.com'">
+ Redirect "/" "http://www.example.com/"
+</If>
+
+
+Ou, par exemple, pour rediriger une portion de votre site vers HTTPS +:
+ +<If "%{SERVER_PROTOCOL} != 'HTTPS'">
+ Redirect "/admin/" "https://www.example.com/admin/"
+</If>
+
+
+Si, pour une raison particulière, vous voulez tout de même utiliser
+mod_rewrite - dans le cas, par exemple, où vous avez besoin
+d'un jeu plus important de règles de réécritures - vous pouvez utiliser
+la recette suivante :
Pour les sites écoutant sur un port autre que 80:
+RewriteCond "%{HTTP_HOST}" "!^www\.example\.com" [NC]
+RewriteCond "%{HTTP_HOST}" "!^$"
+RewriteCond "%{SERVER_PORT}" "!^80$"
+RewriteRule "^/?(.*)" "http://www.example.com:%{SERVER_PORT}/$1" [L,R,NE]
+
+
+Et pour un site écoutant sur le port 80
+RewriteCond "%{HTTP_HOST}" "!^www\.example\.com" [NC]
+RewriteCond "%{HTTP_HOST}" "!^$"
+RewriteRule "^/?(.*)" "http://www.example.com/$1" [L,R,NE]
+
+ + Si vous souhaitez que cette règle s'applique à tous les noms de + domaine - en d'autres termes, si vous voulez rediriger + example.com vers + www.example.com pour toutes les valeurs + possibles de example.com, vous pouvez utiliser + le jeu de règles suivants :
+ +RewriteCond "%{HTTP_HOST}" "!^www\." [NC]
+RewriteCond "%{HTTP_HOST}" "!^$"
+RewriteRule "^/?(.*)" "http://www.%{HTTP_HOST}/$1" [L,R,NE]
+
+
+ Vous pouvez utiliser ce jeu de règles aussi bien dans le fichier
+ de configuration de votre serveur principal que dans un fichier
+ .htaccess placé dans le répertoire défini par la
+ directive DocumentRoot du serveur.
Une ressource peut exister dans plusieurs répertoires, et nous + voulons rechercher cette ressource dans ces répertoires + lorsqu'elle fait l'objet d'une requête. Il est possible que nous + ayons récemment réorganisé la structure de notre site en + répartissant son contenu dans plusieurs répertoires.
+Le jeu de règles suivant recherche la ressource dans deux + répertoires, et s'il ne la trouve dans aucun des deux, il tentera + simplement de la servir à partir de l'adresse fournie dans la + requête.
+ +RewriteEngine on
+
+# on cherche tout d'abord dans dir1/...
+# ... et si on trouve, on est content et on arrête :
+RewriteCond "%{DOCUMENT_ROOT}/dir1/%{REQUEST_URI}" -f
+RewriteRule "^(.+)" "%{DOCUMENT_ROOT}/dir1/$1" [L]
+
+# on cherche ensuite dans dir2/...
+# ... et si on trouve, on est content et on arrête :
+RewriteCond "%{DOCUMENT_ROOT}/dir2/%{REQUEST_URI}" -f
+RewriteRule "^(.+)" "%{DOCUMENT_ROOT}/dir2/$1" [L]
+
+# sinon, on continue la recherche avec d'autres directives Alias
+# ou ScriptAlias, etc...
+RewriteRule "^" "-" [PT]
+
+ Notre site web possède de nombreux miroirs, et nous voulons + rediriger les utilisateurs vers celui qui se situe dans le pays où + ils se trouvent.
+En consultant le nom d'hôte du client demandeur, on détermine le + pays dans lequel il se trouve. S'il est impossible d'effectuer une + recherche sur leur adresse IP, on se rabat sur un serveur par + défaut.
+Nous allons utiliser une directive RewriteMap afin de construire une
+ liste des serveurs que nous voulons utiliser.
HostnameLookups on
+RewriteEngine on
+RewriteMap multiplex "txt:/path/to/map.mirrors"
+RewriteCond "%{REMOTE_HOST}" "([a-z]+)$ [NC]"
+RewriteRule "^/(.*)$" "${multiplex:%1|http://www.example.com/}$1" [R,L]
+
+
+
+## liste_miroirs -- Table de correspondance pays - serveurs
+
+de http://www.exemple.de/
+uk http://www.exemple.uk/
+com http://www.example.com/
+##EOF##
+
on de la directive HostNameLookups, ce qui peut induire une
+ baisse de performance significative.La directive RewriteCond extrait la dernière
+ partie du nom d'hôte du client demandeur - le code du pays - et la
+ règle de réécriture qui suit utilise cette valeur pour rechercher le
+ serveur miroir approprié dans le fichier de correspondances.
Nous voulons fournir des contenus différents en fonction du + navigateur (user-agent) qui effectue la requête.
+Nous devons déterminer quel contenu servir, en nous basant
+ sur l'en-tête HTTP "User-Agent". La
+ configuration suivante effectue ceci : si l'en-tête HTTP
+ "User-Agent" commence par "Mozilla/3", le nom de la page
+ foo.html est réécrit en foo.NS.html
+ et la réécriture s'arrête. Si le navigateur est "Lynx" ou
+ "Mozilla" version 1 ou 2, l'URL devient
+ foo.20.html. Tous les autres navigateurs
+ reçoivent la page foo.32.html. Tout ceci est
+ effectué par le jeu de règles suivant :
RewriteCond "%{HTTP_USER_AGENT}" "^Mozilla/3.*"
+RewriteRule "^foo\.html$" "foo.NS.html" [L]
+
+RewriteCond "%{HTTP_USER_AGENT}" "^Lynx/" [OR]
+RewriteCond "%{HTTP_USER_AGENT}" "^Mozilla/[12]"
+RewriteRule "^foo\.html$" "foo.20.html" [L]
+
+RewriteRule "^foo\.html$" "foo.32.html" [L]
+
+ Sur certains serveurs, une ressource peut posséder plusieurs + URLs. Il y a en général les URLs canoniques (celles qui sont + réellement distribuées et utilisées), et celles qui correspondent à + des raccourcis, les URLs internes, etc... Quelle que soit l'adresse + que l'utilisateur fournit dans la requête, il devrait finalement + voir l'URL canonique dans la barre d'adresse de son navigateur.
+Nous effectuons une redirection HTTP externe pour toutes les
+ URLs non canoniques afin de les corriger dans la barre d'adresse
+ du navigateur, et ceci pour toutes les requêtes futures. Dans le
+ jeu de règles suivant, nous remplaçons /matous et
+ /minettes par le canonique /chats.
RewriteRule "^/(matous|minettes)/(.*)" "/chats/$2" [R]+ +
RedirectMatch "^/(matous|minettes)/(.*)" "/chats/$2"+ +
DocumentRootEn général, le répertoire DocumentRoot du serveur web correspond à l'URL
+"/". Ce répertoire ne contient cependant pas forcément des
+ressources de première importance pour l'utilisateur. Par exemple, vous
+préférerez peut-être que le répertoire d'accueil d'un visiteur accédant
+pour la première fois à votre site soit un répertoire particulier
+/a-propos-de/. Pour y parvenir, utilisez le jeu de règles
+suivant :
On redirige l'URL / vers
+ /a-propos-de/ :
+
RewriteEngine on +RewriteRule "^/$" "/a-propos-de/" [R]+ + +
Notez que l'on peut aussi y parvenir en utilisant la directive
+RedirectMatch :
RedirectMatch "^/$" "http://example.com/a-propos-de/"+ + +
Notez aussi que cet exemple ne réécrit que l'URL racine. En d'autres
+termes, il réécrit une requête pour http://example.com/,
+mais pas pour une requête http://example.com/page.html. Si
+vous avez effectivement modifié la racine de vos documents - c'est à dire
+si tous vos contenus se trouvent dans un
+sous-répertoire, il est largement préférable de modifier simplement
+votre directive DocumentRoot, ou de
+déplacer l'ensemble du contenu vers le répertoire supérieur, plutôt que
+de réécrire les URLs.
Depuis la version 2.2.16, vous pouvez y parvenir via la directive
+FallbackResource :
<Directory "/var/www/my_blog"> + FallbackResource "index.php" +</Directory>+ + +
Cependant, si vos besoins étaient plus complexes, vous pouviez, dans +les versions plus anciennes d'Apache, utiliser un jeu de règles du style +:
+ +<Directory "/var/www/my_blog">
+ RewriteBase "/my_blog"
+
+ RewriteCond "/var/www/my_blog/%{REQUEST_FILENAME}" !-f
+ RewriteCond "/var/www/my_blog/%{REQUEST_FILENAME}" !-d
+ RewriteRule "^" "index.php" [PT]
+</Directory>
+
+
+D'autre part, si vous voulez transmettre l'URI de la requête en tant +que chaîne de paramètres à index.php, vous pouvez remplacer cette règle +de réécriture par :
+ +RewriteRule "(.*)" "index.php?$1" [PT,QSA]+ + +
Notez que l'on peut utiliser ces jeux de règles aussi bien dans un
+fichier .htaccess que dans une section
+<Directory>.
Dans la plupart des solutions de cette section, on utilise la même +condition qui stocke la valeur recherchée dans la référence arrière %2. +%1 est le début de la requête, et %3 ce qui reste. Cette condition est +un peu complexe car elle introduit de la flexibilité et évite les +doubles perluettes '&&' dans les substitutions.
+# Remove mykey=???
+RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$"
+RewriteRule "(.*)" "$1?%1%3"
+
+ # Copy from query string to PATH_INFO
+RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$"
+RewriteRule "(.*)" "$1/products/%2/?" [PT]
+
+ # Capture the value of mykey in the query string
+RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$""
+RewriteCond "%2" !=not-so-secret-value
+RewriteRule "(.*)" - [F]
+
+ # The desired URL might be /products/kitchen-sink, and the script expects +# /path?products=kitchen-sink. +RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT]+ +
Serveur HTTP Apache Version 2.4
+Ce document est un complément à la documentation de référence du
+ module mod_rewrite. Il décrit l'utilisation de la
+ directive RewriteMap, et
+ fournit des exemples pour chacun des différents types de
+ RewriteMap.
Introduction int: Fonction interne txt: tables de correspondances au format texte rnd: Fichier texte à valeurs de substitution multiples
+ choisies de manière aléatoire dbm: Fichier condensé DBM prg: Programme de réécriture externe dbd ou fastdbd: requête SQL Résumé
+ La directive RewriteMap
+ définit une fonction externe qui peut être appelée depuis une
+ directive RewriteRule ou
+ RewriteCond pour
+ accomplir une réécriture trop compliquée, ou trop spécialisée pour
+ être effectuée à partir d'expressions rationnelles. Vous trouverez
+ ci-dessous les différents types disponibles pour la source de
+ données, ceux-ci étant par ailleurs énumérés dans la documentation de
+ référence de RewriteMap.
La syntaxe de la directive RewriteMap est la suivante
+ :
RewriteMap MapName MapType:MapSource+ + +
L'argument MapName + est un nom arbitraire que vous associez à la table de + correspondances, et que vous + pourrez utilisez par la suite dans les directives de réécriture. Les + recherches dans la table de correspondance s'effectuent en + respectant cette syntaxe :
+ +
+
+ ${ nom-map :
+ clé-recherche
+ }
${ nom-map :
+ clé-recherche | DefaultValue }
+
+
Lorsque cette syntaxe est employée, la table de correspondances + nom-map est consultée et la clé clé-recherche + recherchée. Si la clé est trouvée, la fonction de recherche dans la + table de correspondance est remplacée par SubstValue, ou + par DefaultValue dans le cas contraire, ou par la chaîne + vide si aucune DefaultValue n'a été spécifiée.
+ +Par exemple, vous pouvez définir une directive
+ RewriteMap comme suit :
RewriteMap examplemap "txt:/path/to/file/map.txt"+ +
Vous pourrez par la suite utiliser cette table de correspondances
+ dans une directive RewriteRule comme suit :
RewriteRule "^/ex/(.*)" "${examplemap:$1}"
+
+
+Il est possible de spécifier une valeur par défaut qui sera utilisée +si la recherche dans la table de correspondances est infructueuse :
+ +RewriteRule "^/ex/(.*)" "${examplemap:$1|/not_found.html}"
+
+
+
+Vous ne pouvez utiliser la directive RewriteMap ni dans
+les sections <Directory>, ni dans les fichiers
+.htaccess. Vous devez déclarer la table de correspondances
+au niveau du serveur principal ou dans un contexte de serveur virtuel.
+En revanche, si vous ne pouvez pas déclarer la table dans une section
+<Directory> ou dans un fichier .htaccess, vous
+pourrez y faire référence dans ces contextes, une fois cette table
+créée.
+
Les sections suivantes décrivent les différents types de tables de +correspondances type-map disponibles, et fournissent des +exemples pour chacun d'entre eux.
+Lorsque le type-map int est spécifié, la source est
+ une des fonctions RewriteMap internes disponibles. Les développeurs
+ de modules peuvent fournir des fonctions internes supplémentaires en
+ les enregistrant via l'API ap_register_rewrite_mapfunc.
+ Les fonctions fournies par défaut sont :
+
+ Pour utiliser une de ces fonctions, créez une
+ RewriteMap faisant référence à cette fonction int, et
+ utilisez-la dans votre règle RewriteRule :
+
Redirige un URI vers son équivalent en minuscules
+RewriteMap lc int:tolower
+RewriteRule "(.*)" "${lc:$1}" [R]
+
+
+ Notez que cet exemple n'est fourni qu'à titre d'illustration,
+ et ne constitue en aucun cas une recommandation. Si vous voulez
+ rendre des URLs insensibles à la casse, vous devez plutôt vous
+ tourner vers mod_speling.
+
Lorsqu'un type-map txt est utilisé, la source-map
+ est un chemin du système de fichiers vers un fichier de
+ correspondances au format texte, contenant sur chaque ligne une
+ paire clé/valeur séparées par un espace. Il est possible d'insérer
+ des commentaires sous la forme de chaînes commençant par le caractère
+ '#'.
Voici un exemple d'entrées valides dans un fichier de + correspondances :
+ +
+ # Ligne de commentaires
+ clé valeur-substitution
+ clé valeur-substitution # commentaire
+
Lorsque la table de correspondance fait l'objet d'une recherche, + la valeur spécifiée est recherchée dans le premier champ, et si elle + est trouvée, la valeur de substitution est renvoyée.
+ +Par exemple, nous pourrions utiliser un fichier de + correspondances pour traduire des noms de produits en identifiants + produits pour obtenir des URLs plus simples à mémoriser, en + utilisant la recette suivante :
+ +Product to ID configuration
+RewriteMap product2id "txt:/etc/apache2/productmap.txt"
+RewriteRule "^/product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT]
+
+
+ Nous supposons ici que le script prods.php sait quoi
+ faire lorsqu'il reçoit un argument id=NOTFOUND, dans
+ le cas où le produit ne se trouve pas dans la table de
+ correspondances.
Le fichier /etc/apache2/map-produit.txt contient ce
+ qui suit :
+##
+## map-produit.txt - Fichier de correspondances Produit - Identifiant
+##
+
+TELEVISION 993
+STEREO 198
+CANNE-A-PECHE 043
+BALLON-BASKET 418
+TELEPHONE 328
+
Ainsi, lorsqu'une requête pour
+ http://example.com/produit/TELEVISION arrive, la directive
+ RewriteRule s'applique, et la
+ requête est transformée en interne en /prods.php?id=993.
.htaccess, vous devrez supprimer le
+ slash de début dans le modèle de réécriture afin que ce dernier
+ puisse correspondre à toute URL :
+ RewriteRule "^product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT]
+
+
+ Les clés de recherche sont mises en cache par httpd jusqu'à ce que
+ le mtime (date de modification) du fichier de
+ correspondances soit modifié, ou que le serveur httpd soit
+ redémarré, ce qui améliore les performances pour les tables de
+ correspondances consultées par de nombreuses requêtes.
+
Lorsque le type-map spécifié est rnd, la source est
+ un chemin du système de fichiers vers un fichier de correspondances
+ au format texte dont chaque ligne contient une clé, et une ou
+ plusieurs valeurs séparées par le caractère |. Si une
+ clé convient, une des valeurs correspondantes sera choisie de
+ manière aléatoire.
Par exemple, vous pouvez utiliser le fichier de correspondances + et les directives suivants pour implémenter une répartition de + charge aléatoire entre plusieurs serveurs d'arrière-plan, par + l'intermédiaire d'un mandataire inverse. Les images sont envoyées + vers un des serveurs de l'ensemble 'statique', tandis que tout le + reste est envoyé vers un des serveurs de l'ensemble 'dynamique'.
+ +
+##
+## map.txt -- table de réécriture
+##
+
+statique www1|www2|www3|www4
+dynamique www5|www6
+
Directives de configuration
+RewriteMap servers "rnd:/path/to/file/map.txt"
+
+RewriteRule "^/(.*\.(png|gif|jpg))" "http://${servers:static}/$1" [NC,P,L]
+RewriteRule "^/(.*)" "http://${servers:dynamic}/$1" [P,L]
+
+
+
+ Ainsi, lorsqu'une image est demandée et que la première règle
+ convient, RewriteMap recherche la chaîne
+ statique dans le fichier de correspondances qui
+ renvoie un des noms de serveurs spécifiés de manière aléatoire,
+ ce dernier étant utilisé dans la cible de la règle
+ RewriteRule.
Si vous voulez qu'un des serveurs soit plus souvent sollicité que + les autres (par exemple s'il possède plus de mémoire, et peut donc + traiter d'avantage de requêtes), spécifiez-le plusieurs fois dans la + liste des serveurs.
+ +
+statique www1|www1|www2|www3|www4
+
Lorsque le type-map dbm est utilisé, la source est
+ un chemin du système de fichiers vers un fichier de données DBM
+ contenant des paires clé/valeur permettant d'effectuer la
+ correspondance. Le fonctionnement est identique à celui du type-map
+ txt, mais beaucoup plus rapide car un fichier DBM est
+ indexé, alors qu'un fichier texte ne l'est pas. L'accès à la clé
+ recherchée est donc plus rapide.
Vous pouvez éventuellement spécifier un type dbm particulier :
+ +RewriteMap examplemap "dbm=sdbm:/etc/apache/mapfile.dbm"+ + +
Ce type peut être choisi parmi sdbm, gdbm,
+ ndbm ou db. Il est
+ cependant recommandé d'utiliser l'utilitaire httxt2dbm fourni avec le
+ serveur HTTP Apache, car il utilise la bibliothèque DBM appropriée,
+ à savoir celle qui a été utilisée lors de la compilation de httpd.
Pour créer un fichier dbm, créez tout d'abord un fichier de
+ correspondances au format texte comme décrit dans la section txt. Traitez ensuite ce fichier avec
+ httxt2dbm :
+$ httxt2dbm -i fichier-map.txt -o fichier-map.map
+
Vous pouvez alors faire référence au fichier obtenu dans votre
+directive RewriteMap :
RewriteMap mapname "dbm:/etc/apache/mapfile.map"+ + +
Notez qu'avec certains types dbm, plusieurs fichiers possédant le
+même nom de base sont créés. Par exemple, vous pouvez obtenir deux
+fichiers nommés fichier-map.map.dir et
+fichier-map.map.pag. Ceci est tout à fait normal, et vous
+ne devez utiliser que le nom de base fichier-map.map dans votre
+directive RewriteMap.
+ Les clés de recherche sont mises en cache par httpd jusqu'à ce que
+ le mtime (date de modification) du fichier de
+ correspondances soit modifié, ou que le serveur httpd soit
+ redémarré, ce qui améliore les performances pour les tables de
+ correspondances consultées par de nombreuses requêtes.
+
Lorque le type-map prg est spécifié, la source est
+ un chemin du système de fichiers vers un programme exécutable
+ destiné à effectuer la mise en correspondance. Il peut s'agir d'un
+ fichier binaire compilé, ou d'un programme en langage interprété
+ comme Perl ou Python.
Ce programme est lancé une fois au démarrage du serveur HTTP
+ Apache, puis communique avec le moteur de réécriture via
+ STDIN et STDOUT. En d'autres termes, pour
+ chaque recherche de correspondance, il reçoit un argument via
+ STDIN, et doit renvoyer en guise de réponse une chaîne
+ terminée par un caractère nouvelle-ligne sur STDOUT. Si
+ la recherche de correspondance est infructueuse, le programme doit
+ l'indiquer en retournant la chaîne de quatre caractères
+ "NULL".
Les programmes de réécriture externes ne sont pas lancés s'il
+ n'ont pas été définis dans un contexte où la directive RewriteEngine est définie à
+ on.
Par défaut, les programmes de réécriture externes sont lancés par
+ l'utilisateur/groupe qui a démarré httpd. Pour changer ce comportement, il
+ est possible sur les systèmes de style Unix de spécifier un autre couple
+ utilisateur/groupe via le troisième argument de la directive RewriteMap, et ceci au format
+ utilisateur:groupe.
Cette fonctionnalité utilise le mutex rewrite-map
+ nécessaire à la fiabilité des communications avec le programme. Le
+ mécanisme de mutex et le fichier verrou peuvent être définis via la
+ directive Mutex.
Voici un exemple simple qui remplace tous les tirets par des + caractères de soulignement dans l'URI de la requête.
+ +Configuration de la réécriture
+RewriteMap d2u "prg:/www/bin/dash2under.pl" apache:apache
+RewriteRule "-" "${d2u:%{REQUEST_URI}}"
+
+
+ dash2under.pl
+ #!/usr/bin/perl
+ $| = 1; # Turn off I/O buffering
+ while (<STDIN>) {
+ s/-/_/g; # Remplace tous les tirets par des caractères de soulignement
+ print $_;
+ }
+
+
+$| = 1; - La syntaxe sera bien entendu
+différente dans
+d'autres langages. Si les entrées/sorties sont mises en tampon, httpd va
+attendre une sortie, et va par conséquent se bloquer.Lorsque le type-map dbd ou fastdbd est
+ spécifié, la source est une requête SQL SELECT qui reçoit un
+ argument et renvoie une seule valeur.
Pour que cette requête puisse être exécutée,
+ mod_dbd doit être configuré pour attaquer la base
+ de données concernée.
Ce type-map existe sous deux formes. Avec le type-map
+ dbd, la requête est exécutée à chaque demande, tandis
+ qu'avec le type-map fastdbd, les recherches dans la
+ base de données sont mises en cache en interne. fastdbd
+ est donc plus efficace et donc plus rapide ; par contre, il ne
+ tiendra pas compte des modifications apportées à la base de données
+ jusqu'à ce que le serveur soit redémarré.
Si une requête renvoie plusieurs enregistrements, un de ceux-ci + sera sélectionné aléatoirement.
+ +RewriteMap ma-requete "fastdbd:SELECT destination FROM rewrite WHERE source = %s"+
Le nom de la requête est transmis au pilote de base de données en tant + que label pour une requête SQL préparée, et doit donc respecter toutes les + règles imposées par votre base de données (comme la sensibilité à la casse).
La directive RewriteMap peut apparaître
+ plusieurs fois. Utilisez une directive
+ RewriteMap pour chaque fonction de mise en
+ correspondance pour déclarer son fichier de correspondances.
Bien que l'on ne puisse pas déclarer de fonction
+ de mise en correspondance dans un contexte de répertoire (fichier
+ .htaccess ou section <Directory>), il est
+ possible d'utiliser cette fonction dans un tel contexte.
Serveur HTTP Apache Version 2.4
+Ce document passe en revue certains détails techniques à propos du +module mod_rewrite et de la mise en correspondance des URLs
+Le traitement des requêtes par le serveur HTTP Apache se + déroule en plusieurs phases. Au cours de chaque phase, un ou + plusieurs modules peuvent être appelés pour traiter la partie + concernée du cycle de vie de la requête. Les différentes phases + peuvent consister en traduction d'URL en nom de fichier, + authentification, autorisation, gestion de contenu ou journalisation (la + liste n'est pas exhaustive).
+ +mod_rewrite agit dans deux de ces phases (ou accroches - hooks - + comme on les nomme souvent) pour la réécriture des URLs.
+ +Tout d'abord, il utilise le hook traduction URL vers nom de
+ fichier qui intervient après la lecture de la requête HTTP, mais
+ avant le processus d'autorisation. Ensuite, il utilise le hook
+ Fixup, qui intervient après les phases d'autorisation, après la
+ lecture des fichiers de configuration de niveau répertoire (fichiers
+ .htaccess), mais avant l'appel du gestionnaire de
+ contenu.
Ainsi, lorsqu'une requête arrive et une fois le serveur
+ correspondant ou le serveur virtuel déterminé, le moteur de
+ réécriture commence à traiter toute directive apparaissant dans la
+ configuration de niveau serveur (autrement dit dans le
+ fichier de configuration principal du serveur et les sections
+ <Virtualhost>).
+ Tout ce processus s'exécute au cours de la phase de traduction URL
+ vers nom de fichier.
Quelques étapes plus loin, une fois les répertoires de données
+ finaux trouvés, les directives de configuration de niveau répertoire
+ (fichiers .htaccess et sections <Directory>) sont appliquées. Ce processus
+ s'exécute au cours de la phase Fixup.
Dans tous ces cas, mod_rewrite réécrit le
+ REQUEST_URI soit vers une nouvelle URL, soit vers un
+ nom de fichier.
Dans un contexte de niveau répertoire (autrement dit dans les
+ fichiers .htaccess et les sections
+ Directory), les règles de réécriture s'appliquent après
+ la traduction de l'URL en nom de fichier. C'est pourquoi le chemin
+ URL auquel mod_rewrite compare initialement les directives
+ RewriteRule est le
+ chemin complet vers le nom de fichier traduit amputé de la partie
+ répertoires (y compris le dernier slash).
Un exemple : si les règles se trouvent dans + /var/www/foo/.htaccess et si une requête pour /foo/bar/baz est + traité, une expression comme ^bar/baz$ correspondra.
+ +Si une substitution intervient dans un contexte de répertoire,
+ une nouvelle sous-requête interne est générée avec la nouvelle URL,
+ ce qui relance le traitement des phases de la requête. Si la
+ substitution est un chemin relatif, la directive RewriteBase détermine le chemin URL
+ devant préfixer cette substitution. Dans un contexte de répertoire,
+ il faut s'assurer de créer des règles qui
+ n'effectueront pas de substitution au
+ cours d'une passe ultérieure du processus de réécriture au niveau
+ répertoire afin d'éviter les bouclages . Voir Bouclage dans le
+ processus de réécriture pour une discussion plus détaillée à
+ propos de ce problème.
En conséquence de cette manipulation de l'URL , vous devrez + pensez à confectionner différemment vos règles de réécriture dans un + contexte de niveau répertoire. En particulier, rappelez-vous que le + chemin de répertoire sera absent de l'URL que vos règles de + réécriture verront. Voici quelques exemples qui permettront de + clarifier les choses :
+ +| Position de la règle | +Règle | +
|---|---|
| Section VirtualHost | +RewriteRule "^/images/(.+)\.jpg" "/images/$1.gif" | +
| Fichier .htaccess à la racine des documents | +RewriteRule "^images/(.+)\.jpg" "images/$1.gif" | +
| Fichier .htaccess dans le répertoire images | +RewriteRule "^(.+)\.jpg" "$1.gif" | +
Pour une étude plus approfondie de la manière dont mod_rewrite + manipule les URLs dans les différents contextes, vous pouvez + consulter les entrées du + journal générées au cours du processus de réécriture.
+ +Maintenant, quand mod_rewrite se lance dans ces deux phases de + l'API, il lit le jeu de règles configurées depuis la structure + contenant sa configuration (qui a été elle-même créée soit au + démarrage d'Apache pour le contexte du serveur, soit lors du + parcours des répertoires par le noyau d'Apache pour le contexte de + répertoire). Puis le moteur de réécriture est démarré avec le jeu + de règles contenu (une ou plusieurs règles associées à leurs + conditions). En lui-même, le mode opératoire du moteur de + réécriture d'URLs est exactement le même dans les deux contextes + de configuration. Seul le traitement du résultat final diffère.
+ +L'ordre dans lequel les règles sont définies est important car
+ le moteur de réécriture les traite selon une chronologie
+ particulière (et pas très évidente). Le principe est le suivant :
+ le moteur de réécriture traite les règles (les directives RewriteRule) les unes
+ à la suite des autres, et lorsqu'une règle s'applique, il parcourt
+ les éventuelles conditions (directives
+ RewriteConddirectives) associées.
+ Pour des raisons historiques, les
+ conditions précèdent les règles, si bien que le déroulement du
+ contrôle est un peu compliqué. Voir la figure 1 pour plus de
+ détails.
+ 
+ Figure 1:Déroulement du contrôle à travers le jeu de
+ règles de réécriture
+
L'URL est tout d'abord comparée au + Modèle de chaque règle. Lorsqu'une règle ne s'applique + pas, mod_rewrite stoppe immédiatement le traitement de cette règle + et passe à la règle suivante. Si l'URL correspond au + Modèle, mod_rewrite recherche la présence de conditions + correspondantes (les directives Rewritecond apparaissant dans la + configuration juste + avant les règles de réécriture). S'il n'y en a pas, mod_rewrite remplace + l'URL par une chaîne élaborée à partir de la chaîne de + Substitution, puis passe à la règle suivante. Si des + conditions sont présentes, mod_rewrite lance un bouclage + secondaire afin de les traiter selon l'ordre dans lequel elles + sont définies. La logique de traitement des conditions est + différente : on ne compare pas l'URL à un modèle. Une chaîne de + test TestString est tout d'abord élaborée en développant + des variables, des références arrières, des recherches dans des + tables de correspondances, etc..., puis cette chaîne de test est + comparée au modèle de condition CondPattern. Si le modèle + ne correspond pas, les autres conditions du jeu ne sont pas + examinées et la règle correspondante ne s'applique pas. Si le + modèle correspond, la condition suivante est examinée et ainsi de + suite jusqu'à la dernière condition. Si toutes les conditions sont + satisfaites, le traitement de la règle en cours se poursuit avec + le remplacement de l'URL par la chaîne de Substitution.
+ +Serveur HTTP Apache Version 2.4
+Ce document est un complément à la documentation de référence du module
+mod_rewrite. Il décrit comment créer des serveurs
+virtuels dynamiquement configurés en utilisant
+mod_rewrite.
Serveurs virtuels pour des noms d'hôtes arbitraires Configuration dynamique de serveurs
+virtuels via mod_rewrite Utilisation d'un fichier de configuration
+du serveur virtuel séparéNous voulons créer automatiquement un serveur virtuel pour tout + nom d'hôte qui peut être résolu dans notre domaine, sans avoir à + créer de nouvelle section VirtualHost.
+ +Dans cet exemple, nous supposons que nous utilisons le nom d'hôte
+ www.SITE.example.com pour chaque
+ utilisateur, et que nous servons leur contenu depuis
+ /home/SITE/www.
RewriteEngine on
+
+RewriteMap lowercase int:tolower
+
+RewriteCond "${lowercase:%{HTTP_HOST}}" "^www\.([^.]+)\.example\.com$"
+RewriteRule "^(.*)" "/home/%1/www$1"
+La directive RewriteMap interne tolower permet de
+s'assurer que les noms d'hôtes utilisés seront tous en minuscules, de
+façon à éviter toute ambiguité dans la structure des répertoires qui
+doit être créée.
Les contenus des parenthèses utilisées dans une directive RewriteCond sont enregistrés dans les
+références arrières %1, %2, etc..., alors que
+les contenus des parenthèses utilisées dans une directive RewriteRule le sont dans les
+références arrières $1, $2, etc...
+Comme c'est le cas pour de nombreuses techniques discutées dans ce
+document, mod_rewrite n'est vraiment pas la meilleure méthode pour
+accomplir cette tâche. Vous devez plutôt vous tourner vers
+mod_vhost_alias, car ce dernier sera bien plus à même
+de gérer tout ce qui est au delà du domaine des fichiers statiques,
+comme les contenus dynamiques et la résolution des alias.
+
mod_rewriteCet extrait du fichier httpd.conf permet d'obtenir
+ le même résultat que le premier exemple.
+ La première moitié est très similaire à la partie correspondante
+ ci-dessus, excepté quelques modifications requises à des fins de
+ compatibilité ascendante et pour faire en sorte que la partie
+ mod_rewrite fonctionne correctement ; la seconde moitié
+ configure mod_rewrite pour effectuer le travail
+ proprement dit.
Comme mod_rewrite s'exécute avant tout autre module
+ de traduction d'URI (comme mod_alias), il faut lui
+ ordonner explicitement d'ignorer toute URL susceptible d'être
+ traitée par ces autres modules. Et comme ces règles auraient sinon
+ court-circuité toute directive ScriptAlias, nous devons
+ faire en sorte que mod_rewrite déclare explicitement
+ ces correspondances.
# extrait le nom de serveur de l'en-tête Host:
+UseCanonicalName Off
+
+# journaux dissociables
+LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+<Directory "/www/hosts">
+ # ExecCGI est nécessaire ici car on ne peut pas forcer l'exécution
+ # des CGI à la manière de ScriptAlias
+ Options FollowSymLinks ExecCGI
+</Directory>
+
+RewriteEngine On
+
+# un nom de serveur extrait d'un en-tête Host: peut être dans n'importe
+# quelle casse
+RewriteMap lowercase int:tolower
+
+## on s'occupe tout d'abord des documents normaux :
+# permet à Alias "/icons/" de fonctionner - répéter pour les autres
+RewriteCond "%{REQUEST_URI}" "!^/icons/"
+# permet aux CGIs de fonctionner
+RewriteCond "%{REQUEST_URI}" "!^/cgi-bin/"
+# le coeur du traitement
+RewriteRule "^/(.*)$" "/www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1"
+
+## on s'occupe maintenant des CGIs - on doit forcer l'utilisation d'un
+# gestionnaire
+RewriteCond "%{REQUEST_URI}" "^/cgi-bin/"
+RewriteRule "^/(.*)$" "/www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1" [H=cgi-script]
+
+
+Cette construction utilise des fonctionnalités plus avancées de
+ mod_rewrite pour effectuer la traduction depuis le
+ serveur virtuel vers la racine des documents, à partir d'un fichier
+ de configuration séparé. Elle est plus souple mais nécessite une
+ configuration plus compliquée.
Le fichier vhost.map devrait ressembler à ceci :
+www.client-1.example.com /www/clients/1
+www.client-2.example.com /www/clients/2
+# ...
+www.client-N.example.com /www/clients/N
+
On doit ajouter à httpd.conf :
RewriteEngine on
+
+RewriteMap lowercase int:tolower
+
+# définit le fichier de correspondances
+RewriteMap vhost "txt:/www/conf/vhost.map"
+
+# on s'occupe des alias comme ci-dessus
+RewriteCond "%{REQUEST_URI}" "!^/icons/"
+RewriteCond "%{REQUEST_URI}" "!^/cgi-bin/"
+RewriteCond "${lowercase:%{SERVER_NAME}}" "^(.+)$"
+# on effectue ici la remise en correspondance à base de fichier
+RewriteCond "${vhost:%1}" "^(/.*)$"
+RewriteRule "^/(.*)$" "%1/docs/$1"
+
+RewriteCond "%{REQUEST_URI}" "^/cgi-bin/"
+RewriteCond "${lowercase:%{SERVER_NAME}}" "^(.+)$"
+RewriteCond "${vhost:%1}" "^(/.*)$"
+RewriteRule "^/cgi-bin/(.*)$" "%1/cgi-bin/$1" [H=cgi-script]
+
+
+Serveur HTTP Apache Version 2.4
+Les directives des fichiers de configuration peuvent s'appliquer
+au serveur dans son ensemble, ou seulement à des répertoires, fichiers, hôtes,
+ou URLs particuliers. Ce document décrit comment utiliser les conteneurs de
+sections de configuration ou les fichiers .htaccess pour
+modifier la portée des directives de configuration.
Types de conteneurs de sections de
+configuration Système de fichiers,
+arborescence du site web et expressions booléennes Hôtes virtuels Mandataire Quelles sont les directives autorisées ? Comment les sections sont combinées entre elles| Modules Apparentés | Directives Apparentées |
|---|---|
Il existe deux grands types de conteneurs. La plupart des conteneurs sont
+évalués pour chaque requête. Les directives qu'ils contiennent s'appliquent
+seulement aux requêtes qui sont concernées par le conteneur. En revanche,
+les conteneurs
+<IfDefine>, <IfModule>, et
+<IfVersion> sont
+évalués seulement au démarrage et au redémarrage du serveur.
+Si leurs conditions sont vérifiées au démarrage, les directives qu'ils contiennent
+s'appliqueront à toutes les requêtes. Si leurs conditions ne sont pas vérifiées, les
+directives qu'ils contiennent seront ignorées.
Le conteneur <IfDefine>
+contient des directives qui ne seront appliquées que si un paramètre
+approprié a été défini dans la ligne de commande de httpd.
+Par exemple,
+avec la configuration suivante, toutes les requêtes seront redirigées vers
+un autre site si le serveur est démarré en utilisant la ligne de commande :
+httpd -DClosedForNow:
<IfDefine ClosedForNow> + Redirect "/" "http://otherserver.example.com/" +</IfDefine>+ + +
Le conteneur <IfModule>
+est similaire; les directives qu'il contient ne s'appliqueront que si
+un module particulier est disponible au niveau du serveur.
+Le module doit être soit compilé statiquement dans le serveur, soit
+dynamiquement et dans ce cas, la ligne LoadModule correspondante doit apparaître
+plus haut dans le fichier de configuration. Ce conteneur ne doit être
+utilisé que dans le cas où votre fichier de configuration doit fonctionner
+indépendamment de la présence ou de l'absence de certains modules.
+Il ne doit pas contenir de directives que vous souhaitez voir s'appliquer
+systématiquement, car vous pouvez perdre ainsi de précieux messages d'erreur
+à propos de modules manquants.
Dans l'exemple suivant, la directive MimeMagicFile ne s'appliquera que si le
+module mod_mime_magic est disponible.
<IfModule mod_mime_magic.c> + MimeMagicFile "conf/magic" +</IfModule>+ + +
Le conteneur
+<IfVersion>
+est similaire aux conteneurs <IfDefine> et <IfModule>; les directives qu'il contient ne
+s'appliqueront que si une version particulière du serveur s'exécute. Ce
+conteneur a été conçu pour une utilisation dans les suites de tests
+et les grands réseaux qui doivent prendre en compte différentes versions
+et configurations de httpd.
<IfVersion >= 2.4> + # les directives situées ici ne s'appliquent que si la version+ + +
+ # est supérieure ou égale à 2.4.0. +</IfVersion>
<IfDefine>,
+<IfModule>, et
+<IfVersion>
+peuvent inverser leur test conditionnel en le faisant précéder d'un "!".
+De plus, ces sections peuvent être imbriquées afin de définir des restrictions
+plus complexes.
Les conteneurs de sections de configuration les plus couramment utilisés
+sont ceux qui modifient la configuration de points particuliers du système de
+fichiers ou de l'arborescence du site web. Tout d'abord, il est important de
+comprendre la différence entre les deux. Le système de fichiers est une vue
+de vos disques tels qu'ils sont perçus par votre système d'exploitation.
+Par exemple, avec une installation par défaut,
+Apache httpd est situé dans /usr/local/apache2 pour le système de
+fichiers UNIX, ou "c:/Program Files/Apache Group/Apache2" pour
+le système de fichiers Windows. (Notez que des slashes directs doivent
+toujours être utilisés comme séparateur de chemin
+dans les fichiers de configuration d'Apache httpd, même sous
+Windows.) Quant à
+l'arborescence du site web, il s'agit d'une vue de votre site
+tel que présenté par le
+serveur web et perçue par le client. Ainsi le chemin /dir/ dans
+l'arborescence du site web correspond au chemin
+/usr/local/apache2/htdocs/dir/ dans le système de fichiers pour
+une installation d'Apache httpd par défaut sous UNIX.
+En outre, l'arborescence du site web n'a pas besoin de correspondre en permanence au
+système de fichiers, car les pages web peuvent être générées dynamiquement
+à partir de bases de données ou d'autres emplacements.
Les conteneurs <Directory>
+et <Files>,
+ainsi que leurs équivalents acceptant les
+expressions rationnelles,
+appliquent des directives à certaines parties du système de fichiers.
+Les directives contenues dans une section <Directory> s'appliquent au répertoire
+précisé, ainsi qu'à tous ses sous-répertoires et aux fichiers que ces
+derniers contiennent.
+Le même effet peut être obtenu en utilisant les fichiers .htaccess. Par exemple, avec la
+configuration suivante, l'indexation sera activée pour le répertoire
+/var/web/dir1 et tous ses sous-répertoires.
<Directory "/var/web/dir1"> + Options +Indexes +</Directory>+ + +
Les directives contenues dans une section <Files> s'appliquent à tout fichier
+avec le nom spécifié, quel que soit le répertoire dans lequel il se trouve.
+Ainsi par exemple, les directives de configuration suivantes, si elles sont
+placées dans la section principale du fichier de configuration, vont interdire
+l'accès à tout fichier nommé private.html quel que soit
+l'endroit où il se trouve.
<Files "private.html"> + Require all denied +</Files>+ + +
Pour faire référence à des fichiers qui se trouvent en des points
+particuliers du système de fichiers, les sections
+<Files> et
+<Directory>
+peuvent être combinées. Par exemple, la configuration suivante va interdire
+l'accès à /var/web/dir1/private.html,
+/var/web/dir1/subdir2/private.html,
+/var/web/dir1/subdir3/private.html, ainsi que toute instance de
+private.html qui se trouve dans l'arborescence
+/var/web/dir1/.
<Directory "/var/web/dir1"> + <Files "private.html"> + Require all denied + </Files> +</Directory>+ + + +
le conteneur <Location>
+et son équivalent acceptant les
+expressions rationnelles, modifient quant à eux la
+configuration de parties de l'arborescence du site web. Par exemple, la
+configuration suivante interdit l'accès à toute URL dont la partie chemin
+commence par /private.
+En particulier, l'interdiction s'appliquera aux requêtes pour :
+http://yoursite.example.com/private,
+http://yoursite.example.com/private123, et
+http://yoursite.example.com/private/dir/file.html ainsi qu'à
+toute requête commençant par la chaîne de caractères /private.
<LocationMatch "^/private"> + Require all denied +</LocationMatch>+ + +
Le conteneur <Location>
+n'a pas besoin de faire référence à un élément du système de fichiers.
+Par exemple, l'exemple suivant montre comment faire référence à une URL
+particulière vers un gestionnaire interne du serveur HTTP Apache fourni par le module
+mod_status.
+Il n'est pas nécessaire de trouver un fichier nommé server-status
+dans le système de fichiers.
<Location "/server-status"> + SetHandler server-status +</Location>+ + + +
Pour contrôler deux URLs imbriquées, on doit tenir compte de l'ordre
+dans lequel certaines sections ou directives sont évaluées. Pour
+<Location>, on doit
+avoir :
<Location "/foo"> +</Location> +<Location "/foo/bar"> +</Location>+ +
Les directives <Alias>, quant à elles, sont évaluées vice-versa :
Alias "/foo/bar" "/srv/www/uncommon/bar" +Alias "/foo" "/srv/www/common/foo"+ +
Ceci est aussi vrai pour les directives ProxyPass :
ProxyPass "/special-area" "http://special.example.com" smax=5 max=10 +ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On+ + + + +
Les conteneurs
+<Directory>,
+<Files>, et
+<Location>
+peuvent utiliser des caractères de remplacement de style shell comme dans
+la fonction fnmatch de la bibliothèque C standard.
+Le caractère "*"
+correspond à toute séquence de caractères, "?" à un caractère seul,
+et "[seq]" à tout caractère contenu dans seq.
+Le caractère "/"
+ne peut pas faire l'objet d'un remplacement;
+il doit être spécifié explicitement.
Si une définition des critères de correspondance
+encore plus souple est nécessaire, chaque conteneur
+possède son équivalent acceptant les expressions rationnelles : <DirectoryMatch>, <FilesMatch>, et <LocationMatch> acceptent les
+expressions rationnelles compatibles Perl
+pour définir les critères de correspondance. Mais voyez plus loin la section
+à propos de la combinaison des sections de configuration
+pour comprendre comment l'utilisation de
+conteneurs avec des expressions rationnelles va modifier la manière
+dont les directives sont appliquées.
Un conteneur qui modifie la configuration de tous les +répertoires utilisateurs à l'aide de caractères de remplacement +mais sans utiliser +les expressions rationnelles pourrait ressembler à ceci :
+ +<Directory "/home/*/public_html"> + Options Indexes +</Directory>+ + +
Avec les conteneurs utilisant les expressions rationnelles, +on peut interdire l'accès à de nombreux types de fichiers d'images +simultanément :
++<FilesMatch "\.(?i:gif|jpe?g|png)$"> + Require all denied +</FilesMatch>+ + +
Les expressions rationnelles contenant des groupes nommés et
+des références arrières sont ajoutées à l'environnement avec
+leur nom en majuscules. Ceci permet de référencer des éléments de
+chemins de fichiers et d'URLs depuis une expression et au sein de modules comme
+mod_rewrite.
<DirectoryMatch "^/var/www/combined/(?<SITENAME>[^/]+)">
+ require ldap-group "cn=%{env:MATCH_SITENAME},ou=combined,o=Example"
+</DirectoryMatch>
+
+
+
+
+La directive <If>
+permet de modifier la configuration en fonction d'une condition qui peut
+être définie sous la forme d'une expression booléenne. Dans l'exemple
+suivant, l'accès est interdit si l'en-tête HTTP Referer ne commence pas
+par "http://www.example.com/".
<If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')">
+ Require all denied
+</If>
+
+
+
+
+Choisir entre des conteneurs de système de fichiers et des conteneurs
+d'arborescence du site web est vraiment très simple.
+Pour appliquer des directives à des objets qui résident dans le système de
+fichiers, utilisez toujours un conteneur <Directory> ou <Files>. Pour appliquer des directives à des objets
+qui ne résident pas dans le système de fichiers (comme une page web générée
+par une base de données), utilisez un conteneur <Location>.
Il ne faut jamais utiliser un conteneur <Location> pour restreindre l'accès à des
+objets du système de fichiers, car plusieurs localisations de
+l'arborescence du site web (URLs) peuvent correspondre à la même localisation
+du système de fichier, ce qui peut permettre de contourner vos restrictions.
+Par exemple, imaginez la configuration suivante :
<Location "/dir/"> + Require all denied +</Location>+ + +
Elle fonctionne correctement si la requête appelle
+http://yoursite.example.com/dir/. Mais que va-t-il se passer si
+votre système de fichiers est insensible à la casse ?
+Votre restriction va pouvoir être tout simplement contournée en envoyant une
+requête sur
+http://yoursite.example.com/DIR/. Le conteneur <Directory>, quant à lui, s'appliquera
+à tout contenu servi à partir de cette localisation,
+sans tenir compte de la manière dont il est appelé.
+(Les liens du système de fichiers constituent une exception.
+Le même répertoire peut être placé dans plusieurs parties du système de
+fichiers en utilisant des liens symboliques. Le conteneur
+<Directory> va suivre le
+lien symbolique sans modifier le nom du chemin. Par conséquent, pour plus de
+sécurité, les liens symboliques doivent être désactivés à l'aide de la
+directive
+Options appropriée.)
Si vous pensez que vous n'êtes pas concerné par ce problème
+parceque vous utilisez un système de fichiers sensible à la casse,
+gardez à l'esprit qu'il y a de nombreuses autres manières pour faire
+correspondre plusieurs localisations de l'arborescence du site web à la même
+localisation du système de fichiers. C'est pourquoi vous devez autant que
+possible toujours utiliser les conteneurs de système de fichiers.
+Il y a cependant une exception à cette règle. Placer des restrictions de
+configuration dans un conteneur <Location
+"/"> est tout à fait sans rique car ce conteneur va s'appliquer à
+toutes les requêtes sans tenir compte de l'URL spécifique.
Certains types de sections peuvent être imbriqués : d'une part, on peut
+utiliser les sections <Files>
+à l'intérieur des sections <Directory>, d'autre part, on peut utiliser les
+directives <If> à l'intérieur
+des sections <Directory>,
+<Location> et <Files> (mais pas à l'intérieur d'une
+autre section <If>). Les
+valeurs des expressions rationnelles correspondant aux sections nommées se
+comportent de manière identique.
Les sections imbriquées sont fusionnées après les sections +non-imbriquées de même type.
+ + + +Le conteneur <VirtualHost>
+contient des directives qui s'appliquent à des hôtes spécifiques.
+Ceci s'avère utile pour servir des hôtes multiples à partir de la même machine,
+chacun d'entre eux possédant une configuration différente. Pour de plus amples
+informations,
+voir la Documentation sur les hôtes virtuels.
Les conteneurs
+<Proxy>
+et <ProxyMatch>
+appliquent les directives de configuration qu'ils contiennent uniquement aux
+sites qui correspondent à l'URL spécifiée et auxquels on a
+accédé via le serveur mandataire du module mod_proxy.
+Par exemple, la configuration suivante n'autorisera qu'un sous-ensemble de
+clients à accéder au site www.example.com en passant par le serveur
+mandataire :.
<Proxy "http://www.example.com/*"> + Require host yournetwork.example.com +</Proxy>+ +
Pour déterminer quelles sont les directives autorisées pour tel type de
+section de configuration, vérifiez le Contexte de la directive.
+Tout ce qui est autorisé dans les sections
+<Directory>
+l'est aussi d'un point de vue syntaxique dans les sections
+<DirectoryMatch>,
+<Files>,
+<FilesMatch>,
+<Location>,
+<LocationMatch>,
+<Proxy>,
+et <ProxyMatch>.
+Il y a cependant quelques exceptions :
AllowOverride
+ne fonctionne que dans les sections
+<Directory>.Options FollowSymLinks et
+SymLinksIfOwnerMatch ne fonctionnent que dans les sections
+<Directory> ou les fichiers
+.htaccess.Options ne peut pas être
+utilisée dans les sections
+<Files>
+et <FilesMatch>.Les sections de configuration sont appliquées dans un ordre très particulier. +Il est important de savoir comment cet ordre est défini car il peut avoir +des effets importants sur la manière dont les directives de configuration +sont interprétées.
+ +L'ordre dans lequel les sections sont combinées est :
+ +<Directory> (à l'exception des
+ expressions rationnelles)
+ et les fichiers .htaccess sont appliqués simultanément (avec
+ la possibilité pour .htaccess, s'il y est autorisé, de
+ prévaloir sur
+ <Directory>)<DirectoryMatch>
+ (et <Directory "~">)<Files> et <FilesMatch> sont appliquées
+ simultanément<Location>
+ et <LocationMatch> sont appliquées
+ simultanément<If>
+ Quelques remarques importantes :
+<Directory>, dans chaque groupe, les sections sont
+ traitées selon
+ l'ordre dans lequel elles apparaissent dans les fichiers de configuration.
+ Par exemple, une requête pour /foo/bar correspondra à
+ <Location "/foo/bar"> et <Location
+ "/foo"> (dans ce cas le groupe 4) : les deux sections seront
+ évaluées mais selon l'ordre dans lequel elles apparaissent dans le fichier
+ de configuration..<Directory> (groupe 1 ci-dessus)
+ sont traitées dans l'ordre du répertoire le plus court vers le plus long.
+ Par exemple, <Directory "/var/web/dir"> sera
+ traité avant <Directory
+ "/var/web/dir/subdir">.<Directory> s'appliquent au même
+ répertoire, elles sont traitées selon l'ordre dans lequel elles
+ apparaissent dans le fichier de configuration.Include sont traitées comme si elles se
+ trouvaient réellement dans le fichier qui les inclut à la position de la
+ directive
+ Include.<VirtualHost>
+ sont appliquées après les sections correspondantes situées en
+ dehors de la définition de l'hôte virtuel, ce qui permet à l'hôte virtuel
+ de prévaloir sur la configuration du serveur principal.mod_proxy,
+ le conteneur <Proxy>
+ prend la place du conteneur <Directory> dans l'ordre de traitement.<Location>/<LocationMatch>
+ est réellement traitée juste avant la phase de traduction du nom
+ (où Aliases et DocumentRoots
+ sont utilisés pour faire correspondre les URLs aux noms de fichiers).
+ Les effets de cette séquence disparaissent totalement lorsque
+ la traduction est terminée.
+ Une question se pose souvent après avoir lu comment les sections de
+ configuration sont fusionnées : comment et quand les directives de modules
+ particuliers comme mod_rewrite sont-elles interprétées ? La
+ réponse n'est pas triviale et nécessite un approfondissement. Chaque module
+ httpd gère sa propre configuration, et chacune de ses directives dans
+ httpd.conf définit un élément de configuration dans un contexte particulier.
+ httpd n'exécute pas un commande au moment où elle est lue.
A l'exécution, le noyau de httpd parcours les sections de configuration + dans l'ordre décrit ci-dessus afin de déterminer lesquelles s'appliquent à + la requête courante. Lorsqu'une première section s'applique, elle est + considérée comme la configuration courante pour cette requête. Si une + section suivante s'applique aussi, chaque module qui possède des directives + dans chacune de ces sections a la possibilité de fusionner sa configuration + entre ces deux sections. Il en résulte une troisième configuration et le + processus de fusion se poursuit jusqu'à ce que toutes les sections de + configuration aient été évaluées.
+Après l'étape précédente, le traitement proprement dit de la requête HTTP + peut commencer : chaque module peut effectuer toute tâche qui lui incombe, + et pour déterminer de quelle manière dont il doit agir, il peut s'appuyer + sur le noyau de httpd pour retrouver sa configuration globale issue de la + fusion précédente.
+Un exemple permet de mieux visualiser l'ensemble du processus. la
+ configuration suivante utilise la directive Header du module
+ mod_headers pour définir un en-tête HTTP spécifique. Quelle
+ valeur httpd va-t-il affecter à l'en-tête CustomHeaderName pour
+ une requête vers /example/index.html ?
+
<Directory "/"> + Header set CustomHeaderName one + <FilesMatch ".*"> + Header set CustomHeaderName three + </FilesMatch> +</Directory> + +<Directory "/example"> + Header set CustomHeaderName two +</Directory>+ +
Directory "/" s'applique, et une configuration
+ initiale est créée qui définit l'en-tête CustomHeaderName
+ avec la valeur one.Directory "/example" s'applique, et comme
+ mod_headers spécifie dans son code que
+ la valeur d'un en-tête doit être écrasée si ce dernier est défini à
+ nouveau, une nouvelle configuration est créée qui définit l'en-tête
+ CustomHeaderName avec la valeur two.FilesMatch ".*" s'applique, une nouvelle
+ opportunité de fusion surgit, et l'en-tête CustomHeaderName
+ est défini à la valeur three.mod_headers sera sollicité, et il se
+ basera sur la configuration qui a défini l'en-tête
+ CustomHeaderName à la valeur three.
+ mod_headers utilise normalement cette configuration pour
+ accomplir sa tâche, à savoir définir des en-têtes HTTP. Cela ne veut
+ cependant pas dire qu'un module ne peut pas effectuer des actions plus
+ complexes comme désactiver des directives car elle ne sont pas
+ nécessaires ou obsolètes, etc...Ceci est aussi vrai pour les fichiers .htaccess car ils possèdent la même
+ priorité que les sections Directory dans l'ordre de
+ fusion. Il faut bien comprendre que les sections de configuration comme
+ Directory et FilesMatch ne
+ sont pas comparables avec les directives spécifiques de modules comme
+ Header ou RewriteRule car elles agissent à des
+ niveaux différents.
+
Voici un exemple imaginaire qui montre l'ordre de combinaison des sections. +En supposant qu'elles s'appliquent toutes à la requête, les directives de +cet exemple seront appliquées dans l'ordre suivant : A > B > C > D > +E.
+ +<Location "/"> + E +</Location> + +<Files "f.html"> + D +</Files> + +<VirtualHost *> + <Directory "/a/b"> + B + </Directory> +</VirtualHost> + +<DirectoryMatch "^.*b$"> + C +</DirectoryMatch> + +<Directory "/a/b"> + A +</Directory>+ + +
Pour un exemple plus concret, considérez ce qui suit. Sans tenir compte
+de toute restriction d'accès placée dans les sections <Directory>, la section <Location> sera
+évaluée en dernier et permettra un accès au serveur sans aucune restriction.
+En d'autres termes, l'ordre de la combinaison des sections est important,
+soyez donc prudent !
<Location "/"> + Require all granted +</Location> + +# Arrghs! Cette section <Directory> n'aura aucun effet +<Directory "/"> + <RequireAll> + Require all granted + Require not host badguy.example.com + </RequireAll> +</Directory>+ + + + +
Serveur HTTP Apache Version 2.4
+Ce document explique le fonctionnement de certaines directives du serveur +de base qui sont utilisées pour configurer les opérations élémentaires du +serveur.
+ Identification du serveur Localisation des fichiers Limitation de l'utilisation des ressources Choix d'implémentation| Modules Apparentés | Directives Apparentées |
|---|---|
Les directives ServerAdmin et
+ ServerTokens contrôlent la nature des
+ informations à propos du serveur qui seront affichées dans les documents
+ générés par le serveur comme les messages d'erreur. La directive
+ ServerTokens définit la valeur du
+ champ d'en-tête de la réponse du serveur HTTP.
Le serveur utilise les directives
+ ServerName,
+ UseCanonicalName et
+ UseCanonicalPhysicalPort pour
+ déterminer la manière de construire des URLs vers ses propres ressources.
+ Par exemple, quand un client émet une requête vers un répertoire, mais
+ n'ajoute pas le slash final au nom du répertoire, httpd doit rediriger le
+ client vers le nom complet incluant le slash final afin que le client
+ puisse résoudre correctement les références relatives présentes dans
+ le document.
| Modules Apparentés | Directives Apparentées |
|---|---|
Ces directives contrôlent la localisation des différents fichiers
+ nécessaires au bon fonctionnement de httpd. Quand le chemin utilisé ne
+ commence pas par un slash (/), la localisation des fichiers est relative
+ à la valeur de la directive
+ ServerRoot. Soyez prudent avec la
+ localisation de fichiers dans des répertoires où les utilisateurs non root
+ ont les droits en écriture. Voir la documention sur les
+ Conseils à propos
+ de la sécurité pour plus de détails.
| Modules Apparentés | Directives Apparentées |
|---|---|
Les directives LimitRequest* permettent de
+ limiter la quantité de ressources consommées par httpd pour le traitement
+ des requêtes des clients. Cette limitation permet de minimiser les effets
+ de certains types d'attaques par déni de service.
Les directives RLimit* permettent de limiter la
+ quantité de ressources utilisable par les processus initiés (forked) par
+ les processus enfants httpd. Elles permettent en particulier de contrôler
+ les ressources utilisées par les scripts CGI et les commandes exec des
+ "Inclusions côté serveur" (Server Side Includes ou SSI).
La directive ThreadStackSize
+ permet sur certaines plates-formes de contrôler la taille de la pile.
| Modules Apparentés | Directives Apparentées |
|---|---|
La directive Mutex permet de modifier
+ l'implémentation sous-jacente des mutex, afin de résoudre les
+ problèmes de fonctionnement ou de performance dus au choix par
+ défaut d'APR.
Serveur HTTP Apache Version 2.4
+Cette page contient la liste des éléments actuellement disponibles de +la Documentation du serveur HTTP Apache Version +2.4.
+ Notes de version Utilisation du serveur HTTP Apache Documentation des serveurs virtuels Apache Guide de réécriture d'URLs Chiffrement SSL/TLS avec Apache Guides, Tutoriels, and Recettes Notes spécifiques à certains systèmes Le serveur HTTP Apache et ses programmes associés Documentations diverses sur Apache Modules Apache Documentation du développeur Glossaire et IndexServeur HTTP Apache Version 2.4
+Le cache des objets partagés est un concept de partage de données + de base entre tous les processus d'un serveur, sans se préoccuper du + modèle de threads et de processus. On + l'utilise lorsque les avantages apportés par le partage de données + entre processus contrebalance la perte de performances consécutive à + la communication interprocessus.
+Le cache d'objets partagés en tant que tel est une abstraction. + Il est implémenté par quatre modules différents. Pour pouvoir + utiliser le cache, un ou plusieurs de ces modules doivent être + présents et configurés.
+Le seul élément de configuration consiste à définir le
+ fournisseur de cache à utiliser. Ceci est de la responsabilité des
+ modules qui utilisent le cache, et pour cela, ils activent la
+ sélection via des directives telles que CacheSocache, AuthnCacheSOCache, SSLSessionCache, et SSLStaplingCache.
Les fournisseurs actuellement disponibles sont :
+mod_socache_dbm)mod_socache_dc)mod_socache_memcache)mod_socache_shmcb)L'API fournit les fonctions suivantes :
+ +Serveur HTTP Apache Version 2.4
+Le module mod_ssl du serveur HTTP Apache fournit une
+interface avec la bibliothèque OpenSSL, qui permet d'effectuer un
+chiffrement fort en s'appuyant sur les protocoles "Couche Points d'accès
+Sécurisés" (Secure Sockets Layer - SSL) et "Sécurité de la Couche Transport"
+(Transport Layer Security - TLS).
Documentation mod_sslLa documentation complète sur les directives et les variables +d'environnement fournies par ce module se trouve dans la +documentation de référence de mod_ssl. +
+Serveur HTTP Apache Version 2.4
+Ce document couvre la compatibilité ascendante entre mod_ssl et +d'autres solutions SSL. mod_ssl n'est pas la seule solution SSL pour Apache ; +quatre autres produits sont (ou ont été) également disponibles : +Apache-SSL, le produit libre de +Ben Laurie (d'où mod_ssl est issu à l'origine en 1998), Secure +Web Server, un produit commercial de Red Hat (basé sur mod_ssl), +Raven SSL Module, un produit commercial +de Covalent (basé lui aussi sur mod_ssl), et enfin Stronghold, produit +commercial de C2Net et maintenant de Red Hat, (basé sur une branche +d'évolution différente appelée Sioux jusqu'à Stronghold 2.x et basé sur +mod_ssl depuis Stronghold 3.x).
+ +En plus de ses fonctionnalités propres, mod_ssl rassemble la plupart de +celles des autres solutions SSL, si bien qu'il est très simple de +migrer depuis un module plus ancien vers mod_ssl. Les directives de +configuration et les noms des variables d'environnement utilisés par les +solutions SSL plus anciennes diffèrent de ceux qu'utilise mod_ssl ; +les tableaux de correspondance ci-dessous fournissent les équivalences +de termes utilisés par mod_ssl.
+ Directives de configuration Variables d'environnement Fonctions de personnalisation des journauxLa correspondance entre les directives de configuration qu'utilise +Apache-SSL 1.x et mod_ssl 2.0.x est fournie dans le Tableau +1. La correspondance depuis Sioux 1.x et Stronghold 2.x n'est que +partielle car certaines fonctionnalités de ces interfaces ne sont pas +supportées par mod_ssl.
+ + +| Ancienne directive | Directive mod_ssl | Commentaires |
|---|---|---|
| Compatibilité entre Apache-SSL 1.x et mod_ssl 2.0.x : | ||
SSLEnable | SSLEngine on | plus compacte |
SSLDisable | SSLEngine off | plus compacte |
SSLLogFile
+file | | Utilisez plutôt la directive
+de niveau module LogLevel. |
SSLRequiredCiphers spec | SSLCipherSuite spec | renommée |
SSLRequireCipher c1 ... | SSLRequire %{SSL_CIPHER} in {"c1",
+...} | plus générale |
SSLBanCipher c1 ... | SSLRequire not (%{SSL_CIPHER} in {"c1",
+...}) | plus générale |
SSLFakeBasicAuth | SSLOptions +FakeBasicAuth | rassemblées |
SSLCacheServerPath dir | - | fonctionnalité supprimée |
SSLCacheServerPort integer | - | fonctionnalité supprimée |
| Compatibilité avec Apache-SSL 1.x : | ||
SSLExportClientCertificates | SSLOptions +ExportCertData | rassemblées |
SSLCacheServerRunDir dir | - | fonctionnalité non supportée |
| Compatibilité avec Sioux 1.x : | ||
SSL_CertFile file | SSLCertificateFile file | renommée |
SSL_KeyFile file | SSLCertificateKeyFile file | renommée |
SSL_CipherSuite arg | SSLCipherSuite arg | renommée |
SSL_X509VerifyDir arg | SSLCACertificatePath arg | renommée |
SSL_Log
+file | - | Utilisez plutôt la directive
+de niveau module LogLevel |
SSL_Connect flag | SSLEngine flag | renommée |
SSL_ClientAuth arg | SSLVerifyClient arg | renommée |
SSL_X509VerifyDepth arg | SSLVerifyDepth arg | renommée |
SSL_FetchKeyPhraseFrom arg | - | pas de véritable équivalent ; utiliser SSLPassPhraseDialog |
SSL_SessionDir dir | - | pas de véritable équivalent ; utiliser SSLSessionCache |
SSL_Require expr | - | pas de véritable équivalent ; utiliser SSLRequire |
SSL_CertFileType arg | - | fonctionnalité non supportée |
SSL_KeyFileType arg | - | fonctionnalité non supportée |
SSL_X509VerifyPolicy arg | - | fonctionnalité non supportée |
SSL_LogX509Attributes arg | - | fonctionnalité non supportée |
| Compatibilité avec Stronghold 2.x : | ||
StrongholdAccelerator engine | SSLCryptoDevice engine | renommée |
StrongholdKey dir | - | sans objet |
StrongholdLicenseFile dir | - | sans objet |
SSLFlag flag | SSLEngine flag | renommée |
SSLSessionLockFile file | SSLMutex file | renommée |
SSLCipherList spec | SSLCipherSuite spec | renommée |
RequireSSL | SSLRequireSSL | renommée |
SSLErrorFile file | - | fonctionnalité non supportée |
SSLRoot dir | - | fonctionnalité non supportée |
SSL_CertificateLogDir dir | - | fonctionnalité non supportée |
AuthCertDir dir | - | fonctionnalité non supportée |
SSL_Group name | - | fonctionnalité non supportée |
SSLProxyMachineCertPath dir | SSLProxyMachineCertificatePath dir | renommée |
SSLProxyMachineCertFile file | SSLProxyMachineCertificateFile file | renommée |
SSLProxyCipherList spec | SSLProxyCipherSpec spec | renommée |
La correspondance entre les noms des variables d'environnement utilisés par +les solutions SSL plus anciennes et les noms utilisés par mod_ssl est fournie +dans le Tableau 2.
+ +| Ancienne variable | Variable mod_ssl | Commentaires |
|---|---|---|
SSL_PROTOCOL_VERSION | SSL_PROTOCOL | renommée |
SSLEAY_VERSION | SSL_VERSION_LIBRARY | renommée |
HTTPS_SECRETKEYSIZE | SSL_CIPHER_USEKEYSIZE | renommée |
HTTPS_KEYSIZE | SSL_CIPHER_ALGKEYSIZE | renommée |
HTTPS_CIPHER | SSL_CIPHER | renommée |
HTTPS_EXPORT | SSL_CIPHER_EXPORT | renommée |
SSL_SERVER_KEY_SIZE | SSL_CIPHER_ALGKEYSIZE | renommée |
SSL_SERVER_CERTIFICATE | SSL_SERVER_CERT | renommée |
SSL_SERVER_CERT_START | SSL_SERVER_V_START | renommée |
SSL_SERVER_CERT_END | SSL_SERVER_V_END | renommée |
SSL_SERVER_CERT_SERIAL | SSL_SERVER_M_SERIAL | renommée |
SSL_SERVER_SIGNATURE_ALGORITHM | SSL_SERVER_A_SIG | renommée |
SSL_SERVER_DN | SSL_SERVER_S_DN | renommée |
SSL_SERVER_CN | SSL_SERVER_S_DN_CN | renommée |
SSL_SERVER_EMAIL | SSL_SERVER_S_DN_Email | renommée |
SSL_SERVER_O | SSL_SERVER_S_DN_O | renommée |
SSL_SERVER_OU | SSL_SERVER_S_DN_OU | renommée |
SSL_SERVER_C | SSL_SERVER_S_DN_C | renommée |
SSL_SERVER_SP | SSL_SERVER_S_DN_SP | renommée |
SSL_SERVER_L | SSL_SERVER_S_DN_L | renommée |
SSL_SERVER_IDN | SSL_SERVER_I_DN | renommée |
SSL_SERVER_ICN | SSL_SERVER_I_DN_CN | renommée |
SSL_SERVER_IEMAIL | SSL_SERVER_I_DN_Email | renommée |
SSL_SERVER_IO | SSL_SERVER_I_DN_O | renommée |
SSL_SERVER_IOU | SSL_SERVER_I_DN_OU | renommée |
SSL_SERVER_IC | SSL_SERVER_I_DN_C | renommée |
SSL_SERVER_ISP | SSL_SERVER_I_DN_SP | renommée |
SSL_SERVER_IL | SSL_SERVER_I_DN_L | renommée |
SSL_CLIENT_CERTIFICATE | SSL_CLIENT_CERT | renommée |
SSL_CLIENT_CERT_START | SSL_CLIENT_V_START | renommée |
SSL_CLIENT_CERT_END | SSL_CLIENT_V_END | renommée |
SSL_CLIENT_CERT_SERIAL | SSL_CLIENT_M_SERIAL | renommée |
SSL_CLIENT_SIGNATURE_ALGORITHM | SSL_CLIENT_A_SIG | renommée |
SSL_CLIENT_DN | SSL_CLIENT_S_DN | renommée |
SSL_CLIENT_CN | SSL_CLIENT_S_DN_CN | renommée |
SSL_CLIENT_EMAIL | SSL_CLIENT_S_DN_Email | renommée |
SSL_CLIENT_O | SSL_CLIENT_S_DN_O | renommée |
SSL_CLIENT_OU | SSL_CLIENT_S_DN_OU | renommée |
SSL_CLIENT_C | SSL_CLIENT_S_DN_C | renommée |
SSL_CLIENT_SP | SSL_CLIENT_S_DN_SP | renommée |
SSL_CLIENT_L | SSL_CLIENT_S_DN_L | renommée |
SSL_CLIENT_IDN | SSL_CLIENT_I_DN | renommée |
SSL_CLIENT_ICN | SSL_CLIENT_I_DN_CN | renommée |
SSL_CLIENT_IEMAIL | SSL_CLIENT_I_DN_Email | renommée |
SSL_CLIENT_IO | SSL_CLIENT_I_DN_O | renommée |
SSL_CLIENT_IOU | SSL_CLIENT_I_DN_OU | renommée |
SSL_CLIENT_IC | SSL_CLIENT_I_DN_C | renommée |
SSL_CLIENT_ISP | SSL_CLIENT_I_DN_SP | renommée |
SSL_CLIENT_IL | SSL_CLIENT_I_DN_L | renommée |
SSL_EXPORT | SSL_CIPHER_EXPORT | renommée |
SSL_KEYSIZE | SSL_CIPHER_ALGKEYSIZE | renommée |
SSL_SECKEYSIZE | SSL_CIPHER_USEKEYSIZE | renommée |
SSL_SSLEAY_VERSION | SSL_VERSION_LIBRARY | renommée |
SSL_STRONG_CRYPTO | - | Non supportée par mod_ssl |
SSL_SERVER_KEY_EXP | - | Non supportée par mod_ssl |
SSL_SERVER_KEY_ALGORITHM | - | Non supportée par mod_ssl |
SSL_SERVER_KEY_SIZE | - | Non supportée par mod_ssl |
SSL_SERVER_SESSIONDIR | - | Non supportée par mod_ssl |
SSL_SERVER_CERTIFICATELOGDIR | - | Non supportée par mod_ssl |
SSL_SERVER_CERTFILE | - | Non supportée par mod_ssl |
SSL_SERVER_KEYFILE | - | Non supportée par mod_ssl |
SSL_SERVER_KEYFILETYPE | - | Non supportée par mod_ssl |
SSL_CLIENT_KEY_EXP | - | Non supportée par mod_ssl |
SSL_CLIENT_KEY_ALGORITHM | - | Non supportée par mod_ssl |
SSL_CLIENT_KEY_SIZE | - | Non supportée par mod_ssl |
Quand mod_ssl est activé, le Format de journal courant
+(Custom Log Format) du module mod_log_config possède
+des fonctions supplémentaires comme indiqué dans le chapitre de référence.
+En plus de la fonction de format étendu
+``%{varname}x'' que l'on peut utiliser pour
+extraire le contenu d'une variable fournie par n'importe quel module,
+la fonction
+de format cryptographique ``%{name}c'' a
+été ajoutée à des fins de compatibilité ascendante. Les appels de fonctions
+actuellement implémentés sont énumérés dans le
+Tableau 3.
| Appel de fonction | Description |
|---|---|
%...{version}c | Version du protocole SSL |
%...{cipher}c | Chiffrement SSL |
%...{subjectdn}c | Nom distinctif du sujet du certificat du client |
%...{issuerdn}c | Nom distinctif de l'émetteur du certificat du client |
%...{errcode}c | Erreur lors de la vérification du certificat (numérique) |
%...{errstr}c | Erreur lors de la vérification du certificat (chaîne de caractères) |
Serveur HTTP Apache Version 2.4
+++Le sage n'apporte pas de bonnes réponses, il pose les bonnes questions
+-- Claude Levi-Strauss
+ +
Des erreurs telles que ``mod_ssl: Child could not open
+ SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (avec l'erreur
+ système qui suit) [...] System: Permission denied (errno: 13)''
+ sont souvent provoquées par des permissions trop restrictives sur les
+ répertoires parents. Assurez-vous que tous les répertoires
+ parents (ici /opt, /opt/apache et
+ /opt/apache/logs) ont le bit x positionné au moins pour
+ l'UID sous lequel les processus enfants d'Apache s'exécutent (voir la
+ directive User).
Pour fonctionner correctement, les logiciels de cryptographie ont
+ besoin d'une source de données aléatoires. De nombreux systèmes
+ d'exploitation libres proposent un "périphérique source d'entropie"
+ qui fournit ce service (il se nomme en général
+ /dev/random). Sur d'autres systèmes, les applications
+ doivent amorcer manuellement
+ le Générateur de Nombres Pseudo-Aléatoires d'OpenSSL
+ (Pseudo Random Number Generator -PRNG) à l'aide de données appropriées
+ avant de générer des clés ou d'effectuer un chiffrement à clé
+ publique. Depuis la version 0.9.5, les fonctions d'OpenSSL qui nécessitent
+ des données aléatoires provoquent une erreur si le PRNG n'a pas été amorcé
+ avec une source de données aléatoires d'au moins 128 bits.
Pour éviter cette erreur, mod_ssl doit fournir
+ suffisamment d'entropie au PRNG pour lui permettre de fonctionner
+ correctement. Ce niveau d'entropie est défini par la directive
+ SSLRandomSeed.
SSL_XXX
+ne sont-elles pas disponibles dans mes scripts CGI et SSI ?Oui. HTTP et HTTPS utilisent des ports différents (HTTP écoute le port + 80 et HTTPS le port 443), si bien qu'il n'y a pas de conflit direct entre + les deux. Vous pouvez soit exécuter deux instances séparées du serveur, + chacune d'entre elles écoutant l'un de ces ports, soit utiliser l'élégante + fonctionnalité d'Apache que constituent les hôtes virtuels pour créer + deux serveurs virtuels gérés par la même instance d'Apache - le + premier serveur répondant en HTTP aux requêtes sur le port 80, + le second répondant en HTTPS aux requêtes sur le port + 443.
+ + +Vous pouvez associer le protocole HTTPS à n'importe quel port, mais le port
+standard est le port 443, que tout navigateur compatible HTTPS va utiliser par
+défaut. Vous pouvez forcer votre navigateur à utiliser un port différent en le
+précisant dans l'URL. Par exemple, si votre serveur est configuré pour
+servir des pages en HTTPS sur le port 8080, vous pourrez y accéder par
+l'adresse https://example.com:8080/.
Alors que vous utilisez simplement
+ +$ telnet localhost 80
+ GET / HTTP/1.0
pour tester facilement Apache via HTTP, les choses ne sont pas si
+ simples pour HTTPS à cause du protocole SSL situé entre TCP et HTTP.
+ La commande OpenSSL s_client vous permet cependant
+ d'effectuer un test similaire via HTTPS :
$ openssl s_client -connect localhost:443 -state -debug
+ GET / HTTP/1.0
Avant la véritable réponse HTTP, vous recevrez des informations + détaillées à propos de l'établissement de la connexion SSL. Si vous + recherchez un client en ligne de commande à usage plus général qui comprend + directement HTTP et HTTPS, qui peut effectuer des opérations GET et POST, + peut utiliser un mandataire, supporte les requêtes portant sur une partie + d'un fichier (byte-range), etc..., vous devriez vous tourner vers + l'excellent outil cURL. Grâce à lui, + vous pouvez vérifier si Apache répond correctement aux requêtes via + HTTP et HTTPS comme suit :
+ +$ curl http://localhost/
+ $ curl https://localhost/
Ceci peut arriver si vous vous connectez à un serveur HTTPS (ou à
+un serveur virtuel) via HTTP (par exemple, en utilisant
+http://example.com/ au lieu de https://example.com).
+Cela peut aussi arriver en essayant de vous connecter via HTTPS à un
+serveur HTTP (par exemple, en utilisant https://example.com/
+avec un serveur qui ne supporte pas HTTPS, ou le supporte, mais sur un
+port non standard). Assurez-vous que vous vous connectez bien à un
+serveur (virtuel) qui supporte SSL.
Une configuration incorrecte peut provoquer ce type d'erreur.
+Assurez-vous que vos directives Listen s'accordent avec vos directives
+ <VirtualHost>. Si
+ l'erreur persiste, recommencez depuis le début en restaurant la
+ configuration par défaut fournie parmod_ssl.
SSL_XXX
+ne sont-elles pas disponibles dans mes scripts CGI et SSI ?Assurez-vous que la directive ``SSLOptions +StdEnvVars'' est
+bien présente dans le contexte de vos requêtes CGI/SSI.
Normalement, pour basculer entre HTTP et HTTPS, vous devez utiliser des
+hyperliens pleinement qualifiés (car vous devez modifier le schéma de l'URL).
+Cependant, à l'aide du module mod_rewrite, vous pouvez
+manipuler des hyperliens relatifs, pour obtenir le même effet.
RewriteEngine on
+RewriteRule "^/(.*)_SSL$" "https://%{SERVER_NAME}/$1" [R,L]
+RewriteRule "^/(.*)_NOSSL$" "http://%{SERVER_NAME}/$1" [R,L]
+
+
+ Ce jeu de règles rewrite vous permet d'utiliser des hyperliens de la
+ forme <a href="document.html_SSL"> pour passer en HTTPS
+ dans les liens relatifs. (Remplacez SSL par NOSSL pour passer en HTTP.)
Un fichier de clé privée RSA est un fichier numérique que vous pouvez +utiliser pour déchiffrer des messages que l'on vous a envoyés. Il a son +pendant à caractère public que vous pouvez distribuer (par le biais de votre +certificat), ce qui permet aux utilisateurs de chiffrer les messages qu'ils +vous envoient.
+Une Demande de Signature de Certificat (CSR) est un fichier numérique + qui contient votre clé publique et votre nom. La CSR doit être envoyée à + une Autorité de Certification (CA), qui va la convertir en vrai certificat + en la signant.
+Un certificat contient votre clé publique RSA, votre nom, le nom + de la CA, et est signé numériquement par cette dernière. Les navigateurs + qui reconnaissent la CA peuvent vérifier la signature du certificat, et + ainsi en extraire votre clé publique RSA. Ceci leur permet de vous envoyer + des messages chiffrés que vous seul pourrez déchiffrer.
+Se référer au chapitre Introduction + pour une description générale du protocole SSL.
+ + +Oui. En général, avec ou sans mod_ssl intégré, le démarrage
+d'Apache ne présente pas de différences. Cependant, si votre fichier de clé
+privée SSL possède un mot de passe, vous devrez le taper au démarrage
+d'Apache.
Devoir entrer manuellement le mot de passe au démarrage du serveur peut + poser quelques problèmes - par exemple, quand le serveur est démarré au + moyen de scripts au lancement du système. Dans ce cas, vous pouvez suivre + les étapes ci-dessous pour supprimer le + mot de passe de votre clé privée. Gardez à l'esprit qu'agir ainsi augmente + les risques de sécurité - agissez avec précaution !
+ + +PATH.server.key et server.crt :$ openssl req -new -x509 -nodes -out server.crt
+ -keyout server.keyhttpd.conf :
+ SSLCertificateFile "/path/to/this/server.crt" +SSLCertificateKeyFile "/path/to/this/server.key"+ +
server.key n'a
+ pas de mot de passe. Pour ajouter un mot de passe à la clé, vous
+ devez exécuter la commande suivante et confirmer le mot de passe comme
+ demandé.$ openssl rsa -des3 -in server.key -out
+ server.key.new
+ $ mv server.key.new server.key
server.key ainsi que son mot de
+ passe en lieu sûr.
+ Voici la marche à suivre pas à pas :
+PATH.
+ $ openssl genrsa -des3 -out server.key 2048server.key et le mot de passe
+ éventuellement défini en lieu sûr.
+ Vous pouvez afficher les détails de cette clé privée RSA à l'aide de la
+ commande :$ openssl rsa -noout -text -in server.key$ openssl rsa -in server.key -out server.key.unsecure$ openssl req -new -key server.key -out server.csrhttps://www.foo.dom/, le FQDN sera "www.foo.dom". Vous
+ pouvez afficher les détails de ce CSR avec :$ openssl req -noout -text -in server.csr$ openssl x509 -noout -text -in server.crtserver.key et server.crt. Ils sont précisés dans
+ votre fichier httpd.conf comme suit :
+ SSLCertificateFile "/path/to/this/server.crt" +SSLCertificateKeyFile "/path/to/this/server.key"+ + Le fichier
server.csr n'est plus nécessaire.
+ La solution la plus simple consiste à utiliser les scripts
+ CA.sh ou CA.pl fournis avec OpenSSL. De
+ préférence, utilisez cette solution, à moins que vous ayez de bonnes
+ raisons de ne pas le faire. Dans ce dernier cas, vous pouvez créer un
+ certificat auto-signé comme suit :
$ openssl genrsa -des3 -out server.key 2048server.key et le mot de passe
+ éventuellement défini en lieu sûr.
+ Vous pouvez afficher les détails de cette clé privée RSA à l'aide de la
+ commande :$ openssl rsa -noout -text -in server.key$ openssl rsa -in server.key -out server.key.unsecure$ openssl req -new -x509 -nodes -sha1 -days 365
+ -key server.key -out server.crt -extensions usr_certserver.crt. Vous pouvez afficher les détails de ce
+ certificat avec :$ openssl x509 -noout -text -in server.crtVous devez simplement lire la clé avec l'ancien mot de passe et la +réécrire en spécifiant le nouveau mot de passe. Pour cela, vous pouvez +utiliser les commandes suivantes :
+ + +$ openssl rsa -des3 -in server.key -out server.key.new
+ $ mv server.key.new server.key
La première fois qu'il vous est demandé un mot de passe PEM, vous + devez entrer l'ancien mot de passe. Ensuite, on vous demandera d'entrer + encore un mot de passe - cette fois, entrez le nouveau mot de passe. Si on + vous demande de vérifier le mot de passe, vous devrez entrer le nouveau + mot de passe une seconde fois.
+ + +L'apparition de ce dialogue au démarrage et à chaque redémarrage provient +du fait que la clé privée RSA contenue dans votre fichier server.key est +enregistrée sous forme chiffrée pour des raisons de sécurité. Le +déchiffrement de ce fichier nécessite un mot de passe, afin de pouvoir être +lu et interprété. Cependant, La suppression du mot de passe diminue le niveau de +sécurité du serveur - agissez avec précautions !
+$ cp server.key server.key.org$ openssl rsa -in server.key.org -out server.key$ chmod 400 server.keyMaintenant, server.key contient une copie non chiffrée de
+ la clé. Si vous utilisez ce fichier pour votre serveur, il ne vous
+ demandera plus de mot de passe. CEPENDANT, si quelqu'un arrive à obtenir
+ cette clé, il sera en mesure d'usurper votre identité sur le réseau.
+ Vous DEVEZ par conséquent vous assurer que seuls root ou le serveur web
+ peuvent lire ce fichier (de préférence, démarrez le serveur web sous
+ root et faites le s'exécuter sous un autre utilisateur, en n'autorisant
+ la lecture de la clé que par root).
Une autre alternative consiste à utiliser la directive
+ ``SSLPassPhraseDialog exec:/chemin/vers/programme''. Gardez
+ cependant à l'esprit que ce n'est bien entendu ni plus ni moins
+ sécurisé.
Une clé privée contient une série de nombres. Deux de ces nombres forment la +"clé publique", les autres appartiennent à la "clé privée". Les bits de la +"clé publique" sont inclus quand vous générez une CSR, et font par +conséquent partie du certificat associé.
+Pour vérifier que la clé publique contenue dans votre certificat + correspond bien à la partie publique de votre clé privée, il vous suffit + de comparer ces nombres. Pour afficher le certificat et la clé, + utilisez cette commande :
+ +$ openssl x509 -noout -text -in server.crt
+ $ openssl rsa -noout -text -in server.key
Les parties `modulus' et `public exponent' doivent être identiques dans + la clé et le certificat. Comme le `public exponent' est habituellement + 65537, et comme il est difficile de vérifier visuellement que les nombreux + nombres du `modulus' sont identiques, vous pouvez utiliser l'approche + suivante :
+ +$ openssl x509 -noout -modulus -in server.crt | openssl md5
+ $ openssl rsa -noout -modulus -in server.key | openssl md5
Il ne vous reste ainsi que deux nombres relativement courts à comparer. + Il est possible, en théorie que ces deux nombres soient les mêmes, sans que + les nombres du modulus soient identiques, mais les chances en sont infimes.
+Si vous souhaitez vérifier à quelle clé ou certificat appartient une CSR + particulière, vous pouvez effectuer le même calcul + sur la CSR comme suit :
+ +$ openssl req -noout -modulus -in server.csr | openssl md5
Le format des certificats par défaut pour OpenSSL est le format PEM,
+qui est tout simplement un format DER codé en Base64, avec des lignes
+d'en-têtes et des annotations. Certaines applications, comme
+Microsoft Internet Explorer, ont besoin d'un certificat au format DER de base.
+Vous pouvez convertir un fichier PEM cert.pem en son équivalent
+au format DER cert.der à l'aide de la commande suivante :
+$ openssl x509 -in cert.pem -out cert.der
+-outform DER
Ceci peut se produire si votre certificat de serveur est signé + par une autorité de certification intermédiaire. Plusieurs CAs, + comme Verisign ou Thawte, ont commencé à signer les certificats avec + des certificats intermédiaires au lieu de leur certificat racine.
+ +Les certificats de CA intermédiaires se situe à un niveau + intermédiaire entre le certificat racine de la CA (qui est installé dans les + navigateurs) et le certificat du serveur (que vous avez installé sur + votre serveur). Pour que le navigateur puisse traverser et vérifier + la chaîne de confiance depuis le certificat du serveur jusqu'au + certificat racine, il faut lui fournir les certificats + intermédiaires. Les CAs devraient pouvoir fournir de tels + paquetages de certificats intermédiaires à installer sur les + serveurs.
+ +Vous devez inclure ces certificats intermédiaires via la
+ directive SSLCertificateChainFile.
Ce problème peut avoir plusieurs causes, mais la principale réside dans le
+cache de session SSL défini par la directive
+SSLSessionCache. Le cache de session
+DBM est souvent à la source du problème qui peut être résolu en utilisant le
+cache de session SHM (ou en n'utilisant tout simplement pas de cache).
SSL utilise un procédé de chiffrement fort qui nécessite la manipulation +d'une quantité très importante de nombres. Lorsque vous effectuez une requête +pour une page web via HTTPS, tout (même les images) est chiffré avant d'être +transmis. C'est pourquoi un accroissement du traffic HTTPS entraîne une +augmentation de la charge.
+ + +Ce problème provient en général d'un périphérique /dev/random
+qui bloque l'appel système read(2) jusqu'à ce que suffisamment d'entropie
+soit disponible pour servir la requête. Pour plus d'information, se référer au
+manuel de référence de la directive
+SSLRandomSeed.
En général, tous les algorithmes de chiffrement supportés par la version
+d'OpenSSL installée, le sont aussi par mod_ssl. La liste des
+algorithmes disponibles peut dépendre de la manière dont vous avez installé
+OpenSSL. Typiquement, au moins les algorithmes suivants sont supportés :
Pour déterminer la liste réelle des algorithmes disponibles, vous + pouvez utiliser la commande suivante :
+$ openssl ciphers -v
Par défaut et pour des raisons de sécurité, OpenSSl ne permet pas +l'utilisation des algorithmes de chiffrements ADH. Veuillez vous informer +sur les effets pervers potentiels si vous choisissez d'activer le support +de ces algorithmes de chiffrements.
+Pour pouvoir utiliser les algorithmes de chiffrements Diffie-Hellman
+anonymes (ADH), vous devez compiler OpenSSL avec
+``-DSSL_ALLOW_ADH'', puis ajouter ``ADH'' à votre
+directive SSLCipherSuite.
Soit vous avez fait une erreur en définissant votre directive
+SSLCipherSuite (comparez-la avec
+l'exemple préconfiguré dans extra/httpd-ssl.conf), soit vous avez
+choisi d'utiliser des algorithmes DSA/DH au lieu de RSA lorsque vous avez
+généré votre clé privée, et avez ignoré ou êtes passé outre les
+avertissements. Si vous avez choisi DSA/DH, votre serveur est incapable de
+communiquer en utilisant des algorithmes de chiffrements SSL basés sur RSA
+(du moins tant que vous n'aurez pas configuré une paire clé/certificat RSA
+additionnelle). Les navigateurs modernes tels que NS ou IE ne peuvent
+communiquer par SSL qu'avec des algorithmes RSA. C'est ce qui provoque l'erreur
+"no shared ciphers". Pour la corriger, générez une nouvelle paire
+clé/certificat pour le serveur en utilisant un algorithme de chiffrement
+RSA.
La raison est très technique, et s'apparente au problème de la primauté de
+l'oeuf ou de la poule. La couche du protocole SSL se trouve en dessous de la
+couche de protocole HTTP qu'elle encapsule. Lors de l'établissement d'une
+connexion SSL (HTTPS), Apache/mod_ssl doit négocier les paramètres du
+protocole SSL avec le client. Pour cela, mod_ssl doit consulter la
+configuration du serveur virtuel (par exemple, il doit accéder à la suite
+d'algorithmes de chiffrement, au certificat du serveur, etc...). Mais afin de
+sélectionner le bon serveur virtuel, Apache doit connaître le contenu du champ
+d'en-tête HTTP Host. Pour cela, il doit lire l'en-tête de la
+requête HTTP. Mais il ne peut le faire tant que la négociation SSL n'est pas
+terminée, or, la phase de négociation SSL a besoin du nom d'hôte contenu
+dans l'en-tête de la requête. Voir la question suivante pour
+contourner ce problème.
Notez que si votre certificat comporte un nom de serveur avec + caractères génériques, ou des noms de serveurs multiples dans le + champ subjectAltName, vous pouvez utiliser SSL avec les serveurs + virtuels à base de noms sans avoir à contourner ce problème.
+ + +L'hébergement virtuel basé sur le nom est une méthode très populaire + d'identification des différents hôtes virtuels. Il permet d'utiliser la + même adresse IP et le même numéro de port pour de nombreux sites + différents. Lorsqu'on se tourne vers SSL, il semble tout naturel de penser + que l'on peut appliquer la même méthode pour gérer plusieurs hôtes + virtuels SSL sur le même serveur.
+ +C'est possible, mais seulement si on utilise une version 2.2.12 + ou supérieure du serveur web compilée avec OpenSSL + version 0.9.8j ou supérieure. Ceci est du au fait que + l'utilisation de l'hébergement virtuel à base de nom + avec SSL nécessite une fonctionnalité appelée + Indication du Nom de Serveur (Server Name Indication - SNI) que + seules les révisions les plus récentes de la + spécification SSL supportent.
+ +Notez que si votre certificat comporte un nom de serveur avec + caractères génériques, ou des noms de serveurs multiples dans le + champ subjectAltName, vous pouvez utiliser SSL avec les serveurs + virtuels à base de noms sans avoir à contourner ce problème.
+ +La raison en est que le protocole SSL constitue une couche séparée qui + encapsule le protocole HTTP. Aini, la session SSL nécessite une + transaction séparée qui prend place avant que la session HTTP n'ait débuté. + Le serveur reçoit une requête SSL sur l'adresse IP X et le port Y + (habituellement 443). Comme la requête SSL ne contenait aucun + en-tête Host:, le serveur n'avait aucun moyen de déterminer quel hôte virtuel SSL il + devait utiliser. En général, il utilisait le premier + qu'il trouvait et qui + correspondait à l'adresse IP et au port spécifiés.
+ +Par contre, si vous utilisez des versions du serveur web et + d'OpenSSL qui supportent SNI, et si le navigateur du client le + supporte aussi, alors le nom d'hôte sera inclus dans la + requête SSL originale, et le serveur web pourra + sélectionner le bon serveur virtuel SSL.
+ +Bien entendu, vous pouvez utiliser l'hébergement virtuel basé sur le nom + pour identifier de nombreux hôtes virtuels non-SSL + (tous sur le port 80 par exemple), et ne gérer qu'un seul hôte virtuel SSL + (sur le port 443). Mais dans ce cas, vous devez définir le numéro de port + non-SSL à l'aide de la directive NameVirtualHost dans ce style :
+ +NameVirtualHost 192.168.1.1:80+ + +
il existe d'autres solutions alternatives comme :
+ +Utiliser des adresses IP différentes pour chaque hôte SSL. + Utiliser des numéros de port différents pour chaque hôte SSL.
+ + +Bien que la négociation pour la compression SSL ait été définie dans la +spécification de SSLv2 et TLS, ce n'est qu'en mai 2004 que la RFC 3749 a +défini DEFLATE comme une méthode de compression standard négociable. +
+Depuis la version 0.9.8, OpenSSL supporte cette compression par défaut
+lorsqu'il est compilé avec l'option zlib. Si le client et le
+serveur supportent la compression, elle sera utilisée. Cependant, la
+plupart des clients essaient encore de se connecter avec un Hello SSLv2.
+Comme SSLv2 ne comportait pas de table des algorithmes de compression préférés
+dans sa négociation, la compression ne peut pas être négociée avec ces clients.
+Si le client désactive le support SSLv2, un Hello SSLv3 ou TLS peut être
+envoyé, selon la bibliothèque SSL utilisée, et la compression peut être mise
+en oeuvre. Vous pouvez vérifier si un client utilise la compression SSL en
+journalisant la variable %{SSL_COMPRESS_METHOD}x.
+
Non, le couple utilisateur/mot de passe est transmis sous forme chiffrée. + L'icône de chiffrement dans les navigateurs Netscape n'est pas vraiment + synchronisé avec la couche SSL/TLS. Il ne passe à l'état verrouillé + qu'au moment où la première partie des données relatives à la page web + proprement dite sont transférées, ce qui peut prêter à confusion. Le + dispositif d'authentification de base appartient à la couche HTTP, qui + est située au dessus de la couche SSL/TLS dans HTTPS. Avant tout + transfert de données HTTP sous HTTPS, la couche SSL/TLS a déjà achevé + sa phase de négociation et basculé dans le mode de communication + chiffrée. Ne vous laissez donc pas abuser par l'état de cet icône.
+ + +La première raison en est la présence dans l'implémentation SSL de +certaines versions de MSIE de bogues subtils en rapport avec le +dispositif de "maintien en vie" (keep-alive) HTTP, et les alertes de +notification de fermeture de session SSL en cas de coupure de la +connexion au point d'entrée (socket). De plus, l'interaction entre +SSL et les fonctionnalités HTTP/1.1 pose problème avec certaines +versions de MSIE. Vous pouvez contourner ces problèmes en interdisant +à Apache l'utilisation de HTTP/1.1, les connexions avec maintien en vie +ou l'envoi de messages de notification de fermeture de session SSL aux +clients MSIE. Pour cela, vous pouvez utiliser la directive suivante +dans votre section d'hôte virtuel avec support SSL :
+SetEnvIf User-Agent "MSIE [2-5]" \ + nokeepalive ssl-unclean-shutdown \ + downgrade-1.0 force-response-1.0+ +
En outre, certaines versions de MSIE ont des problèmes avec des
+ algorithmes de chiffrement particuliers. Hélas, il n'est pas
+ possible d'apporter une solution spécifique à MSIE pour ces
+ problèmes, car les algorithmes de chiffrement sont utilisés dès la
+ phase de négociation SSL. Ainsi, une directive
+ SetEnvIf spécifique
+ à MSIE ne peut être d'aucun secours. Par contre, vous devrez
+ ajuster les paramètres généraux de manière drastique. Avant de
+ vous décider, soyez sûr que vos clients rencontrent vraiment des
+ problèmes. Dans la négative, n'effectuez pas ces ajustements car
+ ils affecteront tous vos clients, ceux utilisant MSIE,
+ mais aussi les autres.
Le protocole TLS-SRP (Echange de clés sécurisé par mot de passe
+ pour TLS comme spécifié dans la RFC 5054) peut compléter ou même
+ remplacer les certificats lors du processus d'authentification des
+ connexions SSL. Pour utiliser TLS-SRP, spécifiez un fichier de
+ vérification SRP OpenSSL via la directive SSLSRPVerifierFile. Vous pouvez créer
+ le fichier de vérification via l'utilitaire openssl :
+ openssl srp -srpvfile passwd.srpv -add username
+
Une fois ce fichier créé, vous devez le référencer dans la + configuration du serveur SSL :
+
+ SSLSRPVerifierFile /path/to/passwd.srpv
+
Pour forcer les clients à utiliser des algorithmes de chiffrement + basés sur TLS-SRP et s'affranchissant des certificats, utilisez la + directive suivante :
+
+ SSLCipherSuite "!DSS:!aRSA:SRP"
+
Depuis la version 2.4.7,
+ mod_ssl utilise des paramètres DH qui comportent
+ des nombres premiers de plus de 1024 bits. Cependant, java 7 et ses versions
+ antérieures ne supportent que les nombres premiers DH d'une longueur
+ maximale de 1024 bits.
Si votre client basé sur Java s'arrête avec une exception telle
+ que java.lang.RuntimeException: Could not generate DH
+ keypair et
+ java.security.InvalidAlgorithmParameterException: Prime size
+ must be multiple of 64, and can only range from 512 to 1024
+ (inclusive), et si httpd enregistre le message tlsv1
+ alert internal error (SSL alert number 80) dans son journal
+ des erreurs (avec un LogLevel
+ info ou supérieur), vous pouvez soit réarranger la
+ liste d'algorithmes de mod_ssl via la directive SSLCipherSuite (éventuellement en
+ conjonction avec la directive SSLHonorCipherOrder), soit utiliser des
+ paramètres DH personnalisés avec un nombre
+ premier de 1024 bits, paramètres qui seront toujours prioritaires
+ par rapport à tout autre paramètre DH par défaut.
Pour générer des paramètres DH personnalisés, utilisez la
+ commande openssl dhparam 1024. Vous pouvez aussi
+ utiliser les
+ paramètres DH standards issus de la RFC 2409, section 6.2 :
-----BEGIN DH PARAMETERS----- +MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR +Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL +/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC +-----END DH PARAMETERS-----
Ajoute les paramètres personnalisés incluant les lignes "BEGIN DH
+ PARAMETERS" et "END DH PARAMETERS" à la fin du premier fichier de
+ certificat défini via la directive SSLCertificateFile.
Voici les sources d'informations disponibles ; vous devez chercher +ici en cas de problème.
+ +Voici toutes les possibilités de support pour mod_ssl, par ordre + de préférence. Merci d'utiliser ces possibilités + dans cet ordre - ne vous précipitez pas sur celle qui vous + paraît la plus alléchante.
+Vous devez toujours fournir au moins les informations +suivantes :
+ +httpd -v. La version d'OpenSSL peut être déterminée
+ en exécutant openssl version. Si Lynx est installé,
+ vous pouvez aussi exécuter la commandelynx -mime_header
+ http://localhost/ | grep Server et ainsi obtenir ces
+ informations en une seule fois.
+ configure que
+ vous avez utilisée.
+ En général non, du moins tant que vous n'aurez pas fourni plus de +détails à propos de la localisation dans le code où Apache a effectué +son vidage mémoire. Ce dont nous avons en général besoin pour vous +aider est une trace de ce qui s'est passé (voir la question suivante). +Sans cette information, il est pratiquement impossible de déterminer +la nature du problème et de vous aider à le résoudre.
+ + +Vous trouverez ci-dessous les différentes étapes permettant +d'obtenir une journalisation des évènements (backtrace) :
+OPTIM="-g -ggdb3"''. Sur les autres plates-formes,
+ l'option ``OPTIM="-g"'' est un minimum.
+ CoreDumpDirectory /tmp'' pour être sûr que le
+ fichier de vidage mémoire puisse bien être écrit. Vous devriez
+ obtenir un fichier /tmp/core ou
+ /tmp/httpd.core. Si ce n'est pas le cas, essayez de
+ lancer votre serveur sous un UID autre que root.
+ Pour des raisons de sécurité, de nombreux
+ noyaux modernes de permettent pas à un processus de vider sa
+ mémoire une fois qu'il a accompli un setuid() (à moins
+ qu'il effectue un exec()) car des informations d'un
+ niveau privilégié pourraient être transmises en mémoire. Si
+ nécessaire, vous pouvez exécuter /chemin/vers/httpd -X
+ manuellement afin de ne pas permettre à Apache de se clôner (fork).
+ gdb /path/to/httpd /tmp/httpd.core ou une commande
+ similaire. Dans GDB, tout ce que vous avez à faire est d'entrer
+ bt, et voila, vous obtenez la backtrace. Pour les
+ débogueurs autres que GDB consulter le manuel correspondant.
+ Serveur HTTP Apache Version 2.4
+Ce document doit vous permettre de démarrer et de faire fonctionner +une configuration de base. Avant de vous lancer dans l'application de +techniques avancées, il est fortement recommandé de lire le reste +de la documentation SSL afin d'en comprendre le fonctionnement de +manière plus approfondie.
+ Exemple de configuration basique Suites de chiffrement et mise en application de la sécurité
+de haut niveau Agrafage OCSP Authentification du client et contrôle d'accès JournalisationVotre configuration SSL doit comporter au moins les directives +suivantes :
+ +LoadModule ssl_module modules/mod_ssl.so + +Listen 443 +<VirtualHost *:443> + ServerName www.example.com + SSLEngine on + SSLCertificateFile "/path/to/www.example.com.cert" + SSLCertificateKeyFile "/path/to/www.example.com.key" +</VirtualHost>+ + +
Les directives suivantes ne permettent que les + chiffrements de plus haut niveau :
+SSLCipherSuite HIGH:!aNULL:!MD5+ + +
Avec la configuration qui suit, vous indiquez une préférence pour + des algorityhmes de chiffrement spécifiques optimisés en matière de + rapidité (le choix final sera opéré par mod_ssl, dans la mesure ou le + client les supporte) :
+ +SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5 +SSLHonorCipherOrder on+ + + +
Dans ce cas bien évidemment, une directive SSLCipherSuite au niveau du serveur principal
+ qui restreint le choix des suites de chiffrement aux versions les plus
+ fortes ne conviendra pas. mod_ssl peut cependant être
+ reconfiguré au sein de blocs Location qui permettent
+ d'adapter la configuration générale à un répertoire spécifique ;
+ mod_ssl peut alors forcer automatiquement une
+ renégociation des paramètres SSL pour parvenir au but recherché.
+ Cette configuration peut se présenter comme suit :
# soyons très tolérant a priori +SSLCipherSuite ALL:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL + +<Location "/strong/area"> +# sauf pour https://hostname/strong/area/ et ses sous-répertoires +# qui exigent des chiffrements forts +SSLCipherSuite HIGH:!aNULL:!MD5 +</Location>+ + +
Le protocole de contrôle du statut des certificats en ligne (Online +Certificate Status Protocol - OCSP) est un mécanisme permettant de +déterminer si un certificat a été révoqué ou non, et l'agrafage OCSP en +est une fonctionnalité particulière par laquelle le serveur, par exemple +httpd et mod_ssl, maintient une liste des réponses OCSP actuelles pour +ses certificats et l'envoie aux clients qui communiquent avec lui. La +plupart des certificats contiennent l'adresse d'un répondeur OCSP maintenu +par l'Autorité de Certification (CA) spécifiée, et mod_ssl peut requérir +ce répondeur pour obtenir une réponse signée qui peut être envoyée aux +clients qui communiquent avec le serveur.
+ +L'agrafage OCSP est la méthode la plus performante pour obtenir le +statut d'un certificat car il est disponible au niveau du serveur, et le +client n'a donc pas besoin d'ouvrir une nouvelle connexion vers +l'autorité de certification. Autres avantages de l'absence de +communication entre le client et l'autorité de certification : +l'autorité de certification n'a pas accès à l'historique de navigation +du client, et l'obtention du statut du certificat est plus efficace car +elle n'est plus assujettie à une surcharge éventuelle des serveurs de +l'autorité de certification.
+ +La charge du serveur est moindre car la réponse qu'il a obtenu du +répondeur OCSP peut être réutilisée par tous les clients qui utilisent +le même certificat dans la limite du temps de validité de la réponse.
+ +Une fois le support général SSL correctement configuré, l'activation +de l'agrafage OCSP ne requiert que des modifications mineures +à la configuration de httpd et il suffit en général de l'ajout de ces +deux directives :
+ +SSLUseStapling On +SSLStaplingCache "shmcb:ssl_stapling(32768)"+ + +
Ces directives sont placées de façon à ce qu'elles aient une portée
+globale (et particulièrement en dehors de toute section VirtualHost), le
+plus souvent où sont placées les autres directives de configuration
+globales SSL, comme conf/extra/httpd-ssl.conf pour les
+installations de httpd à partir des sources, ou
+/etc/apache2/mods-enabled/ssl.conf pour Ubuntu ou Debian,
+etc...
Le chemin spécifié par la directive
+SSLStaplingCache (par exemple logs/)
+doit être le même que celui spécifié par la directive
+SSLSessionCache. Ce chemin est relatif au chemin
+spécifié par la directive ServerRoot.
Cette directive SSLStaplingCache particulière
+nécessite le chargement du module mod_socache_shmcb (à
+cause du préfixe shmcb de son argument). Ce module est en
+général déjà activé pour la directive
+SSLSessionCache, ou pour des modules autres que
+mod_ssl. Si vous activez un cache de session SSL
+utilisant un mécanisme autre que mod_socache_shmcb,
+utilisez aussi ce mécanisme alternatif pour la directive
+SSLStaplingCache. Par exemple :
SSLSessionCache "dbm:ssl_scache" +SSLStaplingCache "dbm:ssl_stapling"+ + +
Vous pouvez utiliser la commande openssl pour vérifier que votre +serveur envoie bien une réponse OCSP :
+ +$ openssl s_client -connect www.example.com:443 -status -servername www.example.com +... +OCSP response: +====================================== +OCSP Response Data: + OCSP Response Status: successful (0x0) + Response Type: Basic OCSP Response +... + Cert Status: Good +...+ +
Les sections suivantes explicitent les situations courantes qui
+requièrent des modifications supplémentaires de la configuration. Vous
+pouvez aussi vous référer au manuel de référence de
+mod_ssl.
Les réponses OCSP sont stockées dans le cache d'agrafage SSL. Alors +que les réponses ont une taille de quelques centaines à quelques +milliers d'octets, mod_ssl supporte des réponses d'une taille jusqu'à +environ 10 ko. Dans notre cas, le nombre de certificats est conséquent +et la taille du cache (32768 octets dans l'exemple ci-dessus) doit être +augmentée. En cas d'erreur lors du stockage d'une réponse, le +message AH01929 sera enregistré dans le journal.
+ + +Veuillez vous référer à la documentation de la directive SSLStaplingForceURL.
Vous pouvez vérifier si un certificat spécifie un répondeur OCSP en +utilisant la commande openssl comme suit :
+ +$ openssl x509 -in ./www.example.com.crt -text | grep 'OCSP.*http' +OCSP - URI:http://ocsp.example.com+ +
Si un URI OCSP est fourni et si le serveur web peut communiquer +directement avec lui sans passer par un mandataire, aucune modification +supplémentaire de la configuration n'est requise. Notez que les règles +du pare-feu qui contrôlent les connexions sortantes en provenance du +serveur web devront peut-être subir quelques ajustements.
+ +Si aucun URI OCSP n'est fourni, contactez votre autorité de
+certification pour savoir s'il en existe une ; si c'est le
+cas, utilisez la directive SSLStaplingForceURL pour la spécifier dans
+la configuration du serveur virtuel qui utilise le certificat.
Ajoutez la directive SSLUseStapling Off à la
+configuration des serveurs virtuels pour lesquels l'agrafage OCSP doit
+être désactivé.
De nombreuses directives permettent de gérer les temps de réponse et
+les erreurs. Référez-vous à la documentation de SSLStaplingFakeTryLater, SSLStaplingResponderTimeout, et SSLStaplingReturnResponderErrors.
AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate!+
Afin de pouvoir supporter l'agrafage OCSP lorsqu'un certificat de +serveur particulier est utilisé, une chaîne de certification pour ce +certificat doit être spécifiée. Si cela n'a pas été fait lors de +l'activation de SSL, l'erreur AH02217 sera enregistrée lorsque +l'agrafage OCSP sera activé, et les clients qui utilisent le certificat +considéré ne recevront pas de réponse OCSP.
+ +Veuillez vous référer à la documentation des directives SSLCertificateChainFile et SSLCertificateFile pour spécifier une
+chaîne de certification.
Lorsque vous connaissez tous vos clients (comme c'est en général le cas
+ au sein d'un intranet d'entreprise), vous pouvez imposer une
+ authentification basée uniquement sur les certificats. Tout ce dont vous
+ avez besoin pour y parvenir est de créer des certificats clients signés par
+ le certificat de votre propre autorité de certification
+ (ca.crt), et d'authentifier les clients à l'aide de ces
+ certificats.
# exige un certificat client signé par le certificat de votre CA +# contenu dans ca.crt +SSLVerifyClient require +SSLVerifyDepth 1 +SSLCACertificateFile "conf/ssl.crt/ca.crt"+ + + +
Pour forcer les clients à s'authentifier à l'aide de certificats pour une
+URL particulière, vous pouvez utiliser les fonctionnalités de reconfiguration
+de mod_ssl en fonction du répertoire :
SSLVerifyClient none +SSLCACertificateFile "conf/ssl.crt/ca.crt" + +<Location "/secure/area"> +SSLVerifyClient require +SSLVerifyDepth 1 +</Location>+ + + +
La clé du problème consiste à vérifier si une partie du certificat
+ client correspond à ce que vous attendez. Cela signifie en général
+ consulter tout ou partie du nom distinctif (DN), afin de vérifier s'il
+ contient une chaîne connue. Il existe deux méthodes pour y parvenir ;
+ on utilise soit le module mod_auth_basic, soit la
+ directive SSLRequire.
La méthode du module mod_auth_basic est en général
+ incontournable lorsque les certificats ont un contenu arbitraire, ou
+ lorsque leur DN ne contient aucun champ connu
+ (comme l'organisation, etc...). Dans ce cas, vous devez construire une base
+ de données de mots de passe contenant tous les clients
+ autorisés, comme suit :
SSLVerifyClient none +SSLCACertificateFile "conf/ssl.crt/ca.crt" +SSLCACertificatePath "conf/ssl.crt" + +<Directory "/usr/local/apache2/htdocs/secure/area"> +SSLVerifyClient require + SSLVerifyDepth 5 + SSLOptions +FakeBasicAuth + SSLRequireSSL + AuthName "Snake Oil Authentication" + AuthType Basic + AuthBasicProvider file + AuthUserFile "/usr/local/apache2/conf/httpd.passwd" + Require valid-user +</Directory>+ + + +
Le mot de passe utilisé dans cet exemple correspond à la chaîne de
+ caractères "password" chiffrée en DES. Voir la documentation de la
+ directive SSLOptions pour
+ plus de détails.
/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA +/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA +/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA
Lorsque vos clients font tous partie d'une même hiérarchie, ce qui
+ apparaît dans le DN, vous pouvez les authentifier plus facilement en
+ utilisant la directive SSLRequire, comme suit :
SSLVerifyClient none
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+SSLCACertificatePath "conf/ssl.crt"
+
+<Directory "/usr/local/apache2/htdocs/secure/area">
+ SSLVerifyClient require
+ SSLVerifyDepth 5
+ SSLOptions +FakeBasicAuth
+ SSLRequireSSL
+ SSLRequire %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
+ and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
+</Directory>
+
+
+
+On suppose dans ces exemples que les clients de l'intranet ont des
+ adresses IP dans la gamme 192.168.1.0/24, et que la partie de l'intranet
+ à laquelle vous voulez autoriser l'accès depuis l'Internet est
+ /usr/local/apache2/htdocs/subarea. Ces lignes de configuration
+ doivent se trouver en dehors de votre hôte virtuel HTTPS, afin qu'elles
+ s'appliquent à la fois à HTTP et HTTPS.
SSLCACertificateFile "conf/ssl.crt/company-ca.crt"
+
+<Directory "/usr/local/apache2/htdocs">
+# En dehors de subarea, seul l'accès depuis l'intranet est
+# autorisé
+ Require ip 192.168.1.0/24
+</Directory>
+
+<Directory "/usr/local/apache2/htdocs/subarea">
+# Dans subarea, tout accès depuis l'intranet est autorisé
+# mais depuis l'Internet, seul l'accès par HTTPS + chiffrement fort + Mot de passe
+# ou HTTPS + chiffrement fort + certificat client n'est autorisé.
+
+# Si HTTPS est utilisé, on s'assure que le niveau de chiffrement est fort.
+# Autorise en plus les certificats clients comme une alternative à
+# l'authentification basique.
+ SSLVerifyClient optional
+ SSLVerifyDepth 1
+ SSLOptions +FakeBasicAuth +StrictRequire
+ SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128
+
+ # ON oblige les clients venant d'Internet à utiliser HTTPS
+ RewriteEngine on
+ RewriteCond "%{REMOTE_ADDR}" "!^192\.168\.1\.[0-9]+$"
+ RewriteCond "%{HTTPS}" "!=on"
+ RewriteRule "." "-" [F]
+
+ # On permet l'accès soit sur les critères réseaux, soit par authentification Basique
+ Satisfy any
+
+ # Contrôle d'accès réseau
+ Require ip 192.168.1.0/24
+
+ # Configuration de l'authentification HTTP Basique
+ AuthType basic
+ AuthName "Protected Intranet Area"
+ AuthBasicProvider file
+ AuthUserFile "conf/protected.passwd"
+ Require valid-user
+</Directory>
+
+
+mod_ssl peut enregistrer des informations de
+ débogage très verbeuses dans le journal des erreurs, lorsque sa
+ directive LogLevel est définie
+ à des niveaux de trace élevés. Par contre, sur un serveur très
+ sollicité, le niveau info sera probablement déjà trop
+ élevé. Souvenez-vous que vous pouvez configurer la directive
+ LogLevel par module afin de
+ pourvoir à vos besoins.
Serveur HTTP Apache Version 2.4
+Ce chapitre en guise d'introduction est destiné aux lecteurs pour lesquels
+le Web, HTTP et Apache sont familiers, mais ne sont pas des experts en matière
+de sécurité. Il n'a pas la prétention d'être un guide détaillé sur le
+protocole SSL, il ne traitera pas non plus des techniques spécifiques de gestion
+des certificats dans une organisation, ni des importants problèmes légaux de
+brevets ou des restrictions d'importation ou d'exportation. Il se veut plutôt
+une base de travail pour les utilisateurs de mod_ssl en
+rassemblant différents concepts, définitions et exemples comme point de départ
+pour une exploration plus détaillée.
Techniques de chiffrement Certificats Couche Points d'Accès Sécurisés - Secure Sockets Layer (SSL) RéférencesLa maîtrise de SSL nécessite la compréhension des algorithmes de +chiffrement, des fonctions relatives aux empreintes de messages (comme les +fonctions de type hash ou non réversibles), et des signatures numériques. Ces +techniques pourraient faire l'objet d'un ouvrage à elles seules (voir par +exemple [AC96]) et constituent les bases de la +confidentialité, de l'intégrité et de l'authentification.
+ +Supposons qu'Alice veuille envoyer un message à sa banque pour + transférer une certaine somme. Alice souhaiterait que le message soit + privé, car il contient des informations comme son numéro de compte et le + montant du transfert. Une solution consisterait à utiliser un algorithme de + chiffrement, technique qui permet de remplacer un message par sa version + chiffrée, illisible jusqu'à ce qu'elle soit déchiffrée. + Sous sa forme chiffrée, + le message ne peut être déchiffré qu'en utilisant une clé secrète. Sans la + clé, le message est inutilisable : les bons algorithmes de chiffrement + rendent si difficile la restitution du texte original par des intrus que + ceux-ci y gaspilleraient leurs efforts.
+ +Il existe deux catégories d'algorithmes de chiffrement : conventionnel + ou à clé publique.
+ +Tout le monde peut chiffrer un message en utilisant la clé publique, + mais seul le propriétaire de la clé privée sera en mesure de le lire. De + cette façon, Alice peut envoyer des messages privés au propriétaire d'une + paire de clés (sa banque), en les chiffrant à l'aide de la clé publique. + Seule la banque sera en mesure de les déchiffrer.
+ + +Bien qu'Alice puisse chiffrer son message pour le rendre privé, il + subsiste toujours le risque que quelqu'un puisse modifier le message + original ou le remplacer par un autre, afin d'effectuer le transfert de + fonds à son profit, par exemple. Une solution pour garantir l'intégrité du + message consisterait pour Alice à créer un résumé concentré de son message + qu'elle enverrait à sa banque avec ce dernier. A la réception du message, + la banque crée son propre résumé et le compare avec celui qu'Alice a + envoyé. Si les deux résumés sont identiques, le message reçu n'a pas + été modifié.
+ +Un résumé tel que celui-ci est appelé + empreinte numérique de message (message digest), + fonction irréversible (one-way function) ou + fonction de hashage (hash function). Une empreinte de message + constitue une représentation courte et de longueur fixe, d'un message plus + long et de longueur variable. Les algorithmes de création d'empreintes sont + conçus pour produire une empreinte unique pour chaque message. Les + empreintes de messages sont conçues pour que la restitution du message + à partir de l'empreinte soit d'une difficulté insurmontable, et qu'il soit + (en théorie) impossible de trouver deux messages différents qui produisent + la même empreinte -- ce qui élimine la possibilité de remplacer un message + par un autre en conservant la même empreinte.
+ +Trouver le moyen d'envoyer l'empreinte de manière sécurisée à la banque + constitue un autre défit auquel Alice doit faire face ; si l'empreinte + n'est pas envoyée de manière sécurisée, son intégrité peut être compromise, + et avec elle, la possibilité pour la banque de vérifier l'intégrité du + message original. L'intégrité du message ne peut être vérifiée que si + l'empreinte qui lui est associée est envoyée de manière sécurisée.
+ +Une solution pour envoyer l'empreinte de manière sécurisée consiste à + l'inclure dans une signature numérique.
+ + +Quand Alice envoie un message à sa banque, cette dernière doit s'assurer +que le message a bien été envoyé par elle, pour éviter qu'un intrus puisse +effectuer une transaction sur son compte. Une signature numérique, +créée par Alice et incluse dans le message, permet d'atteindre cet +objectif.
+ +Les signatures numériques peuvent être créées en chiffrant une empreinte de +message, ainsi que d'autres informations (comme un numéro d'ordre) avec la clé +privée de l'expéditeur. Bien que tout le monde puisse déchiffrer la +signature à l'aide de la clé publique, seul l'expéditeur connait la clé privée. +Ce qui implique que seul l'expéditeur peut avoir signé le message. Inclure +l'empreinte dans la signature entraîne que cette dernière n'est valable que +pour ce message ; ceci assure aussi l'intégrité du message car personne ne +peut modifier l'empreinte et ensuite signer le message.
+Afin de se prémunir contre l'interception et la réutilisation de la +signature par un intrus quelques jours plus tard, la signature contient un +numéro d'ordre unique. Ceci protège la banque contre une plainte frauduleuse +de la part d'Alice alléguant qu'elle n'a pas envoyé le message -- +elle seule peut l'avoir signé (non-répudiation).
+ + +Bien qu'Alice soit parvenue à envoyer un message privé à sa banque, après +l'avoir signé et avoir ainsi assuré l'intégrité du message, elle doit encore vérifier +qu'elle communique réellement avec la banque. C'est à dire qu'elle doit +s'assurer que la clé publique qu'elle utilise appartient bien à la paire de +clés de la banque, et non à celle d'un intrus. +De même, la banque doit vérifier que la +signature du message a bien été construite avec la clé privée d'Alice.
+ +Si chaque partie possède un certificat qui valide l'identité de l'autre, +confirme la clé publique, et est signé par un organisme de confiance, alors +les deux protagonistes peuvent être sûrs que la personne avec laquelle ils +communiquent est bien celle avec laquelle ils désirent le faire. Un tel +organisme de confiance s'appelle une Autorité de Certification, et +on utilise les certificats à des fins d'authentification.
+ +Un certificat associe une clé publique avec l'identité réelle d'un + individu, d'un serveur, ou d'une autre entité plus connue sous le nom de + sujet. Comme on le voit dans le Tableau 1, les + information concernant le sujet comprennent des informations + d'identification (le nom distinctif ou distinguished name - dn), ainsi que + la clé publique. Il comporte aussi l'identification et la signature de + l'autorité de certification qui a délivré le certificat, ainsi que la + période de validité de ce dernier. Il peut aussi contenir des informations + supplémentaires (ou extensions) telles que des informations de gestion + destinées à l'autorité de certification, comme un numéro de série.
+ +| Sujet | +Nom distinctif, Clé publique |
|---|---|
| Fournisseur | +Nom distinctif, Signature |
| Période de validité | +Pas avant, Pas après |
| Informations de gestion | +Version, Numéro de série |
| Extensions | +Contraintes de base, Drapeaux Netscape, etc. |
Un nom distinctif sert à fournir une identité dans un contexte + spécifique -- par exemple, un individu peut posséder un certificat + personnel, et aussi un certificat en tant qu'employé. Les noms distinctifs + doivent respecter le standard X509 [X509], qui définit + les champs, les noms de champs, et les abréviations utilisées pour faire + référence aux champs (voir Tableau 2).
+ +| Champ du DN | +Abrév. | +Description | +Exemple |
|---|---|---|---|
| Nom complet (Common Name) | +CN | +Nom certifié | +CN=Joe Average |
| Organisation or Entreprise | +O | +Nom est associé à cette organisation |
+ O=Snake Oil, Ltd. |
| Unité organisationnelle (Organizational Unit) | +OU | +Nom est associé avec cette unité organisationnelle, + par exemple un département |
+ OU=Research Institute |
| Ville/Localisation | +L | +Nom est localisé dans cette ville | +L=Snake City |
| Etat/Province | +ST | +Nom est localisé dans cet état/province | +ST=Desert |
| Pays | +C | +Nom est localisé dans ce pays (code ISO) | +C=XZ |
Une autorité de certification peut définir une contrainte spécifiant
+ quels champs du nom distinctif sont optionnels et lesquels sont
+ obligatoires. Elle peut aussi imposer des contraintes sur le contenu des
+ champs, ce que peuvent aussi faire les utilisateurs de certificats. Par
+ exemple, un navigateur Netscape peut exiger, dans le cas d'un certificat
+ de serveur, que le nom complet (Common Name) corresponde à un nom générique
+ contenant le nom de domaine du serveur, comme
+ *.snakeoil.com.
Le format binaire d'un certificat est défini en utilisant la + notation ASN.1 [ASN1] [PKCS]. + Cette notation definit la manière de spécifier les contenus, et les règles + d'encodage définissent la manière dont ces information sont converties au + format binaire. L'encodage binaire du certificat est défini par les Règles + d'Encodage Distinctives (Distinguished Encoding Rules - DER), qui se basent + d'une manière plus générale sur les Règles d'Encodage de Base (Basic + Encoding Rules - BER). Pour les transmissions qui ne supportent pas le + format binaire, ce dernier peut être converti au format ASCII en utilisant + le codage Base64 [MIME]. Lorsqu'il est placé entre des + délimiteurs de début et de fin (comme ci-dessous), on dit que le certificat + est encodé au format PEM ("Privacy Enhanced Mail").
+ +-----BEGIN CERTIFICATE----- +MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx +FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG +A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv +cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz +bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL +MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h +a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl +cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN +AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB +gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b +vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa +lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV +HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB +gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt +2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7 +dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ== +-----END CERTIFICATE-----
En vérifiant les informations contenues dans une demande de certificat + avant de l'accorder, l'autorité de certification s'assure de l'identité du + propriétaire de la clé privée issue de sa paire de clés. Par exemple, Si + Alice demande un certificat personnel, l'autorité de certification doit + d'abord s'assurer qu'elle correspond vraiment à la personne à laquelle + la demande de certificat fait référence.
+ +Une autorité de certification peut aussi émettre un certificat à + destination d'une + autre autorité de certification. Pour vérifier un certificat, Alice + peut être amenée à vérifier le certificat de l'émetteur pour chaque + autorité de certification parente, jusqu'à ce qu'elle en atteigne une + en qui elle a confiance. Elle peut aussi ne faire confiance qu'aux + certificats faisant l'objet d'une chaîne limitée d'émetteurs, afin + de réduire le risque de rencontrer un "mauvais" certificat dans la + chaîne.
+ + +Comme indiqué plus haut, chaque certificat nécessite la validation + de l'identité du sujet par un émetteur de certificats + de niveau supérieur, et ceci en + remontant jusqu'à l'Autorité de Certification (CA) racine. Ceci pose un + problème : qui va se porter garant du certificat de l'autorité racine + qui ne possède pas d'émetteur de certificat ? C'est uniquement dans ce + cas que le certificat est auto-signé, l'émetteur du certificat et son + sujet étant confondus. Les navigateurs sont préconfigurés avec une + liste d'autorités de certification de confiance, mais il est important + d'être extrèmement prudent avant de faire confiance à un certificat + auto-signé. La large publication d'une clé publique par l'autorité + racine réduit cependant les risques encourus + en faisant confiance à cette clé -- + si quelqu'un publiait une clé en se faisant passer pour l'autorité, il + serait vite démasqué.
+ +Quelques compagnies, comme Thawte et VeriSign, + se sont proclamées elles-mêmes Autorités de Certification. Ces + compagnies proposent les services suivant :
+ +Vous pouvez aussi créer votre propre autorité de certification. Bien + que risqué dans l'environnement de l'Internet, ceci peut s'avérer utile + dans un Intranet, où l'organisme peut vérifier facilement les identités + des individus et des serveurs.
+ + +Constituer une autorité de certification représente une + responsabilité qui nécessite une solide infrastructure administrative, + technique et gestionnaire. Les autorités de certification ne se + contentent pas d'émettre des certificats, elles doivent aussi les gérer + -- à savoir elles déterminent leur durée de validité, elles les + renouvellent, et elles maintiennent des listes de certificats qui ont + été émis dans le passé mais ne sont plus valides (Listes de révocations + de certificats, ou CRLs).
+ +Par exemple, si Alice est titulaire d'un certificat en tant + qu'employée d'une compagnie, mais vient de quitter cette compagnie, + son certificat doit être révoqué. Comme les certificats ne sont émis + qu'après vérification de l'identité du sujet, et peuvent être envoyés + à tous ceux avec lesquels le sujet peut communiquer, il est impossible + de discerner à partir du seul certificat s'il a été révoqué. Pour + vérifier la validité d'un certificat, il est donc nécessaire de + contacter l'autorité de certification qui l'a émis afin de pouvoir + consulter ses listes de révocations de certificats -- ce qui n'est + en général pas une partie automatique du processus.
+ +Si votre autorité de certification ne fait pas partie de la liste + des autorités de confiance de votre navigateur, il faut enregistrer le + certificat de l'autorité de certification dans ce dernier, ce qui lui + permettra de valider les certificats de serveurs signés par cette + autorité de certification. Ceci peut être dangereux, car une fois le + certificat enregistré, le navigateur acceptera tous les certificats + signés par cette autorité de certification.
+Le protocole Couche Points d'Accès Sécurisés est une couche protocolaire +qui pourrait s'intercaler entre un protocole d'une couche réseau orientée +connexion (comme TCP/IP) et une couche protocolaire d'application (comme HTTP). +SSL fournit une communication sécurisée entre client et serveur en permettant +l'authentification mutuelle, l'utilisation des signatures numériques pour la +vérification de l'intégrité des données, et le chiffrement pour la +confidentialité.
+ +Ce protocole est conçu pour supporter un grand choix d'algorithmes +spécifiques utilisés pour la cryptographie, les empreintes et les signatures. +Ceci permet la sélection d'un algorithme pour des serveurs spécifiques en +respectant la légalité, les règles d'exportation ou autres contraintes, et +permet aussi au protocole de tirer parti des nouveaux algorithmes. Ces choix +font l'objet d'une négociation entre client et serveur lors de +l'établissement de la session protocolaire.
+ +| Version | +Source | +Description | +
|---|---|---|
| SSL v2.0 | +Standard du fournisseur (de Netscape Corp.) | +Premier protocole SSL pour lequel il existe des implémentations | +
| SSL v3.0 | +Projet Internet arrivé à expiration (de Netscape Corp.) [SSL3] | +Comporte des révisions permettant de prévenir certaines attaques de + sécurité spécifiques, ajout de chiffrements non RSA, et support des + chaînes de certification | +
| TLS v1.0 | +Standard proposé pour l'Internet (de l'IETF) [TLS1] | +Révision de SSL 3.0 pour mettre à jour la couche MAC vers HMAC, + ajout du bourrage de bloc pour le chiffrement de bloc, standardisation + de l'ordonnancement des messages et plus de messages d'alerte. | +
| TLS v1.1 | +Standard proposé pour l'Internet (de l'IETF) [TLS11] | +Mise à jour de TLS 1.0 pour la protection contre les + attaques de type Cipher block chaining (CBC). | +
| TLS v1.2 | +Standard proposé pour l'Internet (de l'IETF) [TLS12] | +Mise à jour de TLS 1.1 rendant les condensés MD5 obsolètes, + et introduisant une incompatibilité avec SSL ce qui interdit toute + négociation en vue d'une utilisation de SSLv2. | +
Il existe plusieurs versions du protocole SSL, comme le montre le +Tableau 4. Comme indiqué dans ce dernier, un des apports +de SSL 3.0 est le support du chargement des chaînes de certification. Cette +fonctionnalité permet à un serveur de passer au navigateur un certificat de +serveur accompagné du certificat de l'émetteur. Le chargement de la +chaîne permet aussi au navigateur de valider le certificat du serveur, même si +les certificats de l'autorité de certification ne sont pas installés pour les +émetteurs intermédiaires, car ils sont inclus dans la chaîne de certification. +SSL 3.0 sert de base au standard du protocole Sécurité de la Couche Transport +ou Transport Layer Security +[TLS], actuellement en développement au sein de +l'Internet Engineering Task Force (IETF).
+ +La session SSL est établie en suivant une séquence d'échanges + d'informations entre client et serveur, comme le montre la + Figure 1. Cette séquence peut varier, selon que + le serveur est configuré pour fournir un certificat de serveur ou + réclame un certificat client. Bien que dans certains cas, des étapes + d'échanges d'informations supplémentaires soient nécessaires pour la + gestion des informations de chiffrement, cet article résume un scénario + courant. Se reporter aux spécifications SSL pour avoir la liste de + toutes les possibilités.
+ +Une fois la session SSL établie, elle peut être réutilisée. Ceci + permet d'éviter la perte de performances due à la répétition des nombreuses + étapes nécessaires à l'établissement d'une session. Pour parvenir à ceci, + le serveur assigne un identifiant de session unique à chaque session SSL ; + cet identifiant est mis en cache dans le serveur et le client peut + l'utiliser pour des connexions ultérieures afin de réduire la durée des + échanges d'informations (et ceci jusqu'à ce que l'identifiant de session + arrive à expiration dans le cache du serveur).
+
+ 
+ Figure 1 : Séquence
+ simplifiée d'échanges d'informations SSL
Les éléments de la séquence d'échanges d'informations, tels qu'ils + sont utilisés par le client et le serveur, sont énumérés ci-après :
+ +La première étape, la négociation de la suite de chiffrement, permet au + client et au serveur de choisir une suite de chiffrement qu'ils supportent + tous les deux. La spécification du protocole SSL 3.0 définit 31 suites de + chiffrement. Une suite de chiffrement se compose des éléments + suivants :
+ +Ces trois éléments sont décrits dans les sections suivantes.
+ + +La méthode d'échange de la clé définit la manière + dont la clé de chiffrement + symétrique secrète et partagée utilisée pour le transfert des données de + l'application sera acceptée par le client et le serveur. SSL 2.0 utilise + l'échange de clé RSA seulement, tandis que SSL 3.0 supporte tout un choix + d'algorithmes d'échange de clé incluant l'échange de clé RSA (quand les + certificats sont utilisés), et l'échange de clés Diffie-Hellman (pour + échanger des clés sans certificat, ou en l'absence de communication + préalable entre le client et le serveur).
+ +Les signatures numériques constituent une variante dans le choix des + méthodes d'échange de clé -- utiliser les signatures ou pas, et dans + l'affirmative, quel genre de signatures utiliser. La signature à l'aide + d'une clé privée fournit une protection contre une attaque + "man-in-the-middle" au cours de laquelle + l'échange d'informations destiné à générer la + clé partagée peut être intercepté [AC96, p516].
+ + +Comme décrit plus haut, SSL utilise le chiffrement symétrique + conventionnel pour chiffrer les messages au cours d'une session. Il existe + neuf choix possibles pour le chiffrement, y compris l'option du transfert + non chiffré :
+ +"CBC" signifie Cipher Block Chaining (Chaînage de blocs chiffrés), + c'est à dire qu'une portion du bloc de texte chiffré précédent est utilisée + pour le chiffrement du bloc courant. "DES" signifie Data Encryption + Standard (Standard de Chiffrement des Données) + [AC96, ch12], et possède de nombreuses variantes + (telles que DES40 et 3DES_EDE). Parmi les algorithmes disponibles, "Idea" + est actuellement un des meilleurs et des plus puissants sur le plan + cryptographique, et "RC2" est un algorithme propriétaire de RSA DSI + [AC96, ch13].
+ + +Le choix d'une fonction de création d'empreinte détermine la manière + dont une empreinte est créée à partir d'une unité de données. SSL supporte + les fonctions suivantes :
+ +On utilise l'empreinte de message pour créer un Code d'Authentification + de Message (Message Authentication Code - MAC) qui est chiffré avec le + message afin de vérifier son intégrité et de se protéger contre les + attaques de type "rejeu".
+ + +La séquence d'échanges d'informations utilise trois protocoles :
+ +Ces protocoles, ainsi que les données du protocole de l'application, + sont encapsulés dans le Protocole d'enregistrement SSL + (SSL Record Protocol), comme + le montre la Figure 2. Un protocole encapsulé est + tranféré en tant que données par le protocole de la couche de niveau + inférieur, qui ne se préoccupe pas du contenu des données. Le protocole + encapsulé n'a aucune connaissance du protocole sous-jacent.
+ +
+ 
+ Figure 2:
+ Pile du protocole SSL
L'encapsulation des protocoles de contrôle SSL dans le protocole + d'enregistrement signifie que si une session active est renégociée, les + protocoles de contrôle seront transmis de manière sécurisée. S'il n'y + avait pas de session préalable, la suite de chiffrement Null est utilisée, + ce qui signifie que les messages ne seront pas chiffrés et ne possèderont + pas d'empreinte d'intégrité, jusqu'à ce que la session ait été établie.
+ + +Le protocole d'enregistrement SSL, comme le montre la + Figure 3, est utilisé pour transmettre les données + de l'application et les données de contrôle SSL entre le client et le + serveur, les données étant nécessairement fragmentées en éléments plus + petits, ou plusieurs messages de données avec protocole de niveau + supérieur pouvant être combinés en un seul élément. Ce protocole peut + joindre des signatures d'empreintes, compresser et chiffrer ces éléments + avant de les transmettre en utilisant le protocole fiable de transport + sous-jacent (Note : actuellement, aucune implémentation majeure de SSL + n'inclut le support de la compression).
+ +
+ 
+ Figure 3:
+ Protocole d'enregistrement SSL
Une des utilisations courantes de SSL est la sécurisation des
+ communication HTTP sur le Web entre un navigateur et un serveur web. Ceci
+ n'exclut pas l'utilisation de HTTP non sécurisé - la version sécurisée
+ (appelée HTTPS) est identique à du vrai HTTP sur SSL,
+ mais utilise le préfixe
+ d'URL https au lieu de http, et un port
+ de serveur différent (par défaut le port 443).
+ Ceci constitue pour une large part
+ ce qu'apporte mod_ssl au serveur web Apache.
Applied Cryptography, 2nd Edition, Wiley, +1996. Voir http://www.counterpane.com/ pour diverses autres productions de Bruce +Schneier.
Specification of Abstract Syntax Notation +One (ASN.1), dernière mise à jour en 2008. Voir http://www.itu.int/ITU-T/asn1/. +
The Directory - Authentication +Framework. A titre de référence, voir http://en.wikipedia.org/wiki/X.509. +
Public Key Cryptography Standards (PKCS), +RSA Laboratories Technical Notes, Voir http://www.rsasecurity.com/rsalabs/pkcs/.
Multipurpose Internet Mail Extensions +(MIME) Part One: Format of Internet Message Bodies, RFC2045. +Voir par exemple http://tools.ietf.org/html/rfc2045.
The SSL Protocol +Version 3.0, 1996. Voir http://www.netscape.com/eng/ssl3/draft302.txt.
The TLS Protocol Version 1.0, +1999. Voir http://ietf.org/rfc/rfc2246.txt.
Le protocole TLS Version 1.1, +2006. Voir http://tools.ietf.org/html/rfc4346.
Le protocole TLS Version 1.2, +2008. Voir http://tools.ietf.org/html/rfc5246.
Serveur HTTP Apache Version 2.4
+Ce document couvre l'arrêt et le redémarrage du + serveur HTTP Apache sur + les systèmes Unix et similaires. Les utilisateurs de Windows NT, 2000 + and XP doivent consulter + Exécuter httpd en tant que + service et les utilisateurs de Windows 9x et ME doivent consulter + Exécuter httpd comme une + application de type console pour plus d'informations sur le contrôle + de httpd à partir de ces plateformes.
+ Introduction Arrêter immédiatement Redémarrage en douceur Redémarrer immédiatement Arrêt en douceurAfin d'arrêter ou redémarrer le serveur HTTP Apache, vous devez envoyer un signal aux
+ processus httpd en cours d'exécution. Les signaux
+ peuvent être envoyés de deux manières. La
+ première méthode consiste à
+ utiliser la commande unix kill
+ pour envoyer directement des signaux aux processus. Vous pouvez remarquer
+ que plusieurs processus httpd s'exécutent sur votre
+ système, mais il vous suffit d'envoyer les signaux au processus parent,
+ dont le PID est enregistré dans le fichier précisé par la directive
+ PidFile. Autrement dit, vous
+ n'aurez jamais besoin d'envoyer des signaux à aucun des
+ processus enfants, mais seulement au processus parent. Quatre types
+ de signaux peuvent être envoyés au processus parent :
+ TERM,
+ USR1,
+ HUP, et
+ WINCH, qui
+ seront décrit plus loin.
Pour envoyer un signal au processus parent, vous devez entrer une commande + du style :
+ +kill -TERM `cat /usr/local/apache2/logs/httpd.pid`
La seconde méthode permettant d'envoyer des signaux aux processus
+ httpd
+ consiste à utiliser les options stop,
+ restart, graceful et
+ graceful-stop du commutateur -k de la ligne
+ de commande comme décrit ci-dessous. Ce sont des arguments du binaire
+ httpd, mais il est recommandé de les utiliser
+ avec le script de contrôle apachectl, qui se
+ chargera de les passer à httpd.
Après avoir envoyé un signal à httpd, vous pouvez
+ suivre le cours de son action en entrant :
tail -f /usr/local/apache2/logs/error_log
Adaptez ces exemples en fonction de la définition de vos directives
+ ServerRoot et
+ PidFile.
apachectl -k stopA la réception du signal TERM ou stop,
+ le processus parent tente immédiatement
+ de tuer tous ses processus enfants. Cela peut durer plusieurs secondes.
+ Après cela, le processus parent lui-même se termine. Toutes les requêtes
+ en cours sont terminées, et plus aucune autre n'est traitée.
apachectl -k gracefulA la réception du signal USR1 ou
+ graceful, le
+ processus parent envoie aux processus enfants
+ l'ordre de se terminer une fois leur requête courante
+ traitée (ou de se terminer immédiatement s'ils n'ont plus rien à traiter).
+ Le processus parent relit ses fichiers de configuration et
+ réouvre ses fichiers de log. Chaque fois qu'un enfant s'éteint, le
+ processus parent le remplace par un processus
+ enfant de la nouvelle génération de la
+ configuration, et celui-ci commence immédiatement à traiter les
+ nouvelles requêtes.
Ce code est conçu pour toujours respecter la directive de contrôle
+ de processus des modules MPMs, afin que les nombres de processus et de
+ threads
+ disponibles pour traiter les demandes des clients soient maintenus à
+ des valeurs appropriées tout au long du processus de démarrage.
+ En outre, il respecte la directive
+ StartServers de la manière
+ suivante : si après une seconde au moins StartServers nouveaux processus
+ enfants n'ont pas été créés, un nombre suffisant de processus
+ supplémentaires est créé pour combler le manque. Ainsi le code
+ tente de maintenir à la fois le nombre approprié de processus enfants
+ en fonction de la charge du serveur, et le nombre de processus défini par la
+ directive StartServers.
Les utilisateurs du module mod_status
+ noteront que les statistiques du serveur ne sont pas
+ remises à zéro quand un signal USR1 est envoyé. Le code
+ a été conçu à la fois pour minimiser la durée durant laquelle le
+ serveur ne peut pas traiter de nouvelles requêtes (elle sont mises en
+ file d'attente par le système d'exploitation, et ne sont ainsi jamais
+ perdues) et pour respecter vos paramètres de personnalisation.
+ Pour y parvenir, il doit conserver le
+ tableau utilisé pour garder la trace de tous les processus
+ enfants au cours des différentes générations.
Dans son état des processus,
+ le module status utilise aussi un caractère G afin d'indiquer
+ quels processus enfants ont encore des traitements de requêtes en cours
+ débutés avant que l'ordre graceful restart ne soit donné.
Pour l'instant, il est impossible pour un script de rotation
+ des logs utilisant
+ USR1 de savoir de manière certaine si tous les processus
+ enfants inscrivant des traces de pré-redémarrage sont terminés.
+ Nous vous suggérons d'attendre un délai suffisant après l'envoi du
+ signal USR1
+ avant de faire quoi que ce soit avec les anciens logs. Par exemple,
+ si la plupart de vos traitements durent moins de 10 minutes pour des
+ utilisateurs empruntant des liaisons à faible bande passante, alors vous
+ devriez attendre 15 minutes avant de faire quoi que ce soit
+ avec les anciens logs.
Lorsque vous initiez un redémarrage, une vérification de + la syntaxe est tout d'abord effectuée, afin de s'assurer qu'il n'y a + pas d'erreurs dans les fichiers de configuration. Si votre fichier de + configuration comporte des erreurs de syntaxe, vous recevrez un message + d'erreur les concernant, et le serveur refusera de redémarrer. Ceci + permet d'éviter la situation où un serveur a + été arrêté et ne peut plus redémarrer, + et où vous vous retrouvez avec un serveur hors-service.
+ +Ceci ne garantit pas encore que le serveur va redémarrer
+ correctement. Pour vérifier la sémantique des fichiers de configuration
+ en plus de leur syntaxe, vous pouvez essayer de démarrer
+ httpd sous un utilisateur non root.
+ S'il n'y a pas d'erreur, il tentera d'ouvrir ses sockets et ses fichiers
+ de log et échouera car il n'a pas les privilèges root (ou parce que
+ l'instance actuelle de
+ httpd est déjà associée à ces ports). S'il échoue
+ pour toute autre raison, il y a probablement une erreur dans le
+ fichier de configuration et celle-ci doit être corrigée avant de lancer
+ le redémarrage en douceur.
apachectl -k restartA la réception du signal HUP ou
+ restart, le
+ processus parent tue ses processus enfants comme pour le signal
+ TERM, mais le processus parent ne se termine pas.
+ Il relit ses fichiers de configuration, et réouvre ses fichiers de log.
+ Puis il donne naissance à un nouveau jeu de processus enfants
+ et continue de traiter les requêtes.
Les utilisateurs du module mod_status
+ noteront que les statistiques du serveur sont remises à zéro quand un
+ signal HUP est envoyé.
apachectl -k graceful-stopA la réception du signal WINCH ou
+ graceful-stop, le
+ processus parent ordonne à ses processus enfants
+ de s'arrêter après le traitement de leur requête en cours
+ (ou de s'arrêter immédiatement s'ils n'ont plus de requête à traiter).
+ Le processus parent va alors supprimer son fichier
+ PidFile et cesser l'écoute
+ de tous ses ports. Le processus parent va continuer à s'exécuter,
+ et va surveiller les processus enfants
+ qui ont encore des requêtes à traiter. Lorsque tous les processus enfants
+ ont terminé leurs traitements et se sont arrêtés ou lorsque le délai
+ spécifié par la directive GracefulShutdownTimeout a été atteint,
+ le processus parent s'arrêtera à son tour. Si ce délai est atteint,
+ tout processus enfant encore en cours d'exécution se verra envoyer
+ le signal TERM
+ afin de le forcer à s'arrêter.
L'envoi du signal TERM va arrêter immédiatement
+ les processus parent et enfants en état "graceful". Cependant,
+ comme le fichier PidFile
+ aura été supprimé, vous ne pourrez pas utiliser
+ apachectl ou httpd pour envoyer ce signal.
Le signal graceful-stop vous permet d'exécuter
+ simultanément plusieurs instances de httpd
+ avec des configurations identiques. Ceci s'avère une fonctionnalité
+ puissante quand vous effectuez des mises à jour "en douceur"
+ de httpd ; cependant, cela peut aussi causer des blocages fatals et des
+ situations de compétition (race conditions)
+ avec certaines configurations.
On a pris soin de s'assurer que les fichiers sur disque
+ comme les fichiers verrou (Mutex) et les fichiers socket Unix
+ (ScriptSock) contiennent le PID
+ du serveur, et coexistent sans problème. Cependant, si une directive de
+ configuration, un module tiers ou une CGI résidente utilise un autre
+ verrou ou fichier d'état sur disque, il faut prendre soin de s'assurer
+ que chaque instance de httpd qui s'exécute
+ n'écrase pas les fichiers des autres instances.
Vous devez aussi prendre garde aux autres situations de compétition,
+ comme l'enregistrement des logs avec un transfert de ceux-ci
+ via un pipe vers le programme rotatelogs. Plusieurs instances
+ du programme rotatelogs qui tentent d'effectuer
+ une rotation des mêmes fichiers de log en même temps peuvent détruire
+ mutuellement leurs propres fichiers de log.
Serveur HTTP Apache Version 2.4
+La fonctionnalité suEXEC permet + l'exécution des programmes CGI et + SSI sous un utilisateur autre que celui sous + lequel s'exécute le serveur web qui appelle ces programmes. + Normalement, lorsqu'un programme CGI ou SSI est lancé, il + s'exécute sous le même utilisateur que celui du serveur web qui + l'appelle.
+ +Utilisée de manière appropriée, cette fonctionnalité peut + réduire considérablement les risques de sécurité encourus + lorsqu'on autorise les utilisateurs à développer et faire + s'exécuter des programmes CGI ou SSI de leur cru. Cependant, mal + configuré, suEXEC peut causer de nombreux problèmes et même créer + de nouvelles failles dans la sécurité de votre ordinateur. Si + vous n'êtes pas familier avec la gestion des programmes + setuid root et les risques de sécurité qu'ils comportent, + nous vous recommandons vivement de ne pas tenter + d'utiliser suEXEC.
+ Avant de commencer Modèle de sécurité de suEXEC Configurer et installer suEXEC Activation et désactivation
+de suEXEC Utilisation de suEXEC Débogage de suEXEC Avis à la population !
+ Avertissements et exemplesAvant de foncer tête baissée dans la lecture de ce document, + vous devez tenir compte de certaines hypothèses concernant vous-même + et l'environnement dans lequel vous allez utiliser suexec.
+ +Premièrement, vous devez utiliser un système d'exploitation + UNIX ou dérivé, capable d'effectuer des opérations + setuid et setgid. Tous les + exemples de commande sont donnés en conséquence. D'autres + plates-formes, même si elles supportent suEXEC, peuvent + avoir une configuration différente.
+ +Deuxièmement, vous devez être familier avec les concepts de base + relatifs à la sécurité de votre ordinateur et son administration. + Ceci implique la compréhension des opérations + setuid/setgid et des différents effets qu'elles + peuvent produire sur votre système et son niveau de sécurité.
+ +Troisièmement, vous devez utiliser une version + non modifiée du code de suEXEC. L'ensemble du + code de suEXEC a été scruté et testé avec soin par les développeurs + et de nombreux bêta testeurs. Toutes les précautions ont été prises + pour s'assurer d'une base sûre de code non seulement simple, mais + aussi solide. La modification de ce code peut causer des problèmes + inattendus et de nouveaux risques de sécurité. Il est + vivement recommandé de ne pas modifier le code de + suEXEC, à moins que vous ne soyez un programmeur spécialiste des + particularités liées à la sécurité, et souhaitez partager votre + travail avec l'équipe de développement du serveur HTTP Apache afin + de pouvoir en discuter.
+ +Quatrièmement et dernièrement, l'équipe de développement du + serveur HTTP Apache a décidé de ne + PAS inclure suEXEC dans l'installation par défaut + d'Apache httpd. Pour pouvoir mettre en oeuvre suEXEC, l'administrateur + doit porter la plus grande attention aux détails. Après avoir bien + réfléchi aux différents points de la configuration de suEXEC, + l'administrateur peut l'installer selon les méthodes classiques. + Les valeurs des paramètres de configuration doivent être + déterminées et spécifiées avec soin par l'administrateur, afin de + maintenir la sécurité du système de manière appropriée lors de + l'utilisation de la fonctionnalité suEXEC. C'est par le biais de + ce processus minutieux que nous espérons réserver + l'installation de suEXEC aux administrateurs prudents et + suffisamment déterminés à vouloir l'utiliser.
+ +Vous êtes encore avec nous ? Oui ? Bien. + Alors nous pouvons continuer !
+Avant d'installer et configurer suEXEC, nous allons tout d'abord + décrire le modèle de sécurité que vous êtes sur le point + d'implémenter. Vous devriez ainsi mieux comprendre ce qui se passe + vraiment à l'intérieur de suEXEC et quelles précautions ont été + prises pour préserver la sécurité de votre système.
+ +suEXEC est basé sur un programme "conteneur" + (wrapper) setuid qui est appelé par le serveur HTTP Apache principal. + Ce conteneur est appelé quand une requête HTTP concerne + un programme CGI ou SSI que l'administrateur + a décidé de faire s'exécuter + sous un utilisateur autre que celui du serveur principal. + Lorsqu'il reçoit une telle requête, Apache httpd fournit au conteneur + suEXEC le nom du programme, ainsi que les identifiants utilisateur + et groupe sous lesquels le programme doit s'exécuter.
+ +Le conteneur effectue ensuite les vérifications suivantes afin + de déterminer la réussite ou l'échec du processus -- si une seule + de ces conditions n'est pas vérifiée, le programme journalise + l'erreur et se termine en retournant un code d'erreur, sinon il + continue :
+ ++ Ceci permet de s'assurer que l'utilisateur qui exécute le + conteneur est vraiment un utilisateur appartenant au système. +
++ Le conteneur ne s'exécutera que si on lui fournit un nombre + d'arguments correct. Le serveur HTTP apache sait quel est le + bon format des arguments. Si le conteneur ne reçoit pas un + nombre d'arguments correct, soit il a été modifié, + soit quelque chose ne va pas dans la portion suEXEC de + votre binaire Apache httpd. +
++ Cet utilisateur est-il celui autorisé à exécuter le + conteneur ? Un seul utilisateur (celui d'Apache) est + autorisé à exécuter ce programme. +
+
+ Le chemin du programme CGI ou SSI cible débute-t-il par un
+ '/' ou contient-il une référence arrière '..' ? Ceci est
+ interdit ; le programme CGI ou SSI cible doit se trouver dans
+ la hiérarchie de la racine des documents de suEXEC (voir
+ --with-suexec-docroot=DIR ci-dessous).
+
+ L'utilisateur cible existe-t-il ? +
++ Le groupe cible existe-t-il ? +
+
+ suEXEc ne permet pas à
+ root d'exécuter des programmes CGI/SSI.
+
+ Le numéro d'identifiant utilisateur minimum est défini à + l'exécution du script configure. Ceci vous permet de définir + le numéro d'identifiant utilisateur le plus bas qui sera + autorisé à éxécuter des programmes CGI/SSI. En particulier, + cela permet d'écarter les comptes système. +
+
+ Actuellement, suEXEC ne permet pas au groupe
+ root d'exécuter des programmes CGI/SSI.
+
+ Le numéro d'identifiant de groupe minimum est spécifié lors + de l'exécution du script configure. Ceci vous permet de + définir l'identifiant de groupe le plus bas possible qui sera + autorisé à exécuter des programmes CGI/SSI, et est + particulièrement utile pour écarter les groupes "système". +
++ C'est ici que le programme obtient l'identité des utilisateur + et groupe cibles via des appels à setuid et setgid. De même, + la liste des accès groupe est initialisée avec tous les + groupes auxquels l'utilisateur cible appartient. +
++ S'il n'existe pas, il ne peut pas contenir de fichier. Et si + l'on ne peut pas s'y positionner, il n'existe probablement + pas. +
+
+ Si la requête concerne une portion de la racine du serveur,
+ le répertoire demandé est-il dans la hiérarchie de la racine
+ des documents de suEXEC ? Si la requête concerne un
+ UserDir, le répertoire demandé est-il dans
+ la hiérarchie du répertoire défini comme le répertoire
+ utilisateur de suEXEC (voir les
+ options de configuration de suEXEC) ?
+
+ Le répertoire ne doit pas être ouvert aux autres + utilisateurs ; seul l'utilisateur propriétaire doit pouvoir + modifier le contenu du répertoire. +
++ S'il n'existe pas, il ne peut pas être exécuté. +
++ Les utilisateurs autres que le propriétaire ne doivent pas + pouvoir modifier le programme CGI/SSI. +
++ Les programmes cibles ne doivent pas pouvoir modifier à + nouveau les identifiants utilisateur/groupe. +
++ L'utilisateur est-il le propriétaire du fichier ? +
++ suExec nettoie l'environnement des processus en établissant + un chemin d'exécution sûr (défini lors de la configuration), + et en ne passant que les variables dont les noms font partie + de la liste de l'environnement sûr (créée de même lors de la + configuration). +
++ C'est là où l'exécution de suEXEC s'arrête et où commence + celle du programme CGI/ssi cible. +
+Ce sont les opérations standards effectuées par le modèle de + sécurité du conteneur suEXEC. Il peut paraître strict et est + susceptible d'imposer de nouvelles limitations et orientations + dans la conception des programmes CGI/SSI, mais il a été développé + avec le plus grand soin, étape par étape, en se focalisant sur + la sécurité.
+ +Pour plus d'informations sur la mesure dans laquelle ce modèle + de sécurité peut limiter vos possibilités au regard de la + configuration du serveur, ainsi que les risques de sécurité qui + peuvent être évités grâce à une configuration appropriée de suEXEC, + se référer à la section "Avis à la population !" de ce document.
+C'est ici que nous entrons dans le vif du sujet.
+ +Options de configuration de suEXEC
+
--enable-suexec--with-suexec-xxxxx doit accompagner l'option
+ --enable-suexec pour qu'APACI (l'utilitaire de
+ configuration de la compilation d'Apache) accepte votre demande
+ d'utilisation de la fonctionnalité suEXEC.--with-suexec-bin=PATHsuexec doit être codé en
+ dur dans le serveur pour des raisons de sécurité. Cette option
+ vous permet de modifier le chemin par défaut.
+ Par exemple
+ --with-suexec-bin=/usr/sbin/suexec--with-suexec-caller=UID--with-suexec-userdir=DIRUserDir
+ "simple" (c'est à dire ne contenant pas de
+ "*"), l'option --with-suexec-userdir
+ devra contenir la même valeur. SuEXEC ne fonctionnera pas
+ correctement si la directive UserDir contient une valeur
+ différente du répertoire home de l'utilisateur tel qu'il est
+ défini dans le fichier passwd. la valeur par défaut
+ est "public_html".UserDir différente
+ pour chacun d'entre eux, vous devrez faire en sorte que chaque
+ UserDir possède un répertoire parent commun ; donnez alors à
+ l'option --with-suexec-userdir le nom
+ de ce répertoire commun. Si tout ceci n'est pas défini
+ correctement, les requêtes CGI "~userdir" ne fonctionneront
+ pas !--with-suexec-docroot=DIRUserDir) dans laquelle la fonctionnalité suEXEC
+ pourra être utilisée. La valeur par défaut est la valeur de
+ --datadir accompagnée du suffixe
+ "/htdocs" ;
+ Par exemple, si vous exécutez configure avec
+ "--datadir=/home/apache", la valeur
+ "/home/apache/htdocs" sera utilisée par défaut comme
+ racine des documents pour le conteneur suEXEC.--with-suexec-uidmin=UID--with-suexec-gidmin=GID--with-suexec-logfile=FILEsuexec_log" et se trouve dans votre
+ répertoire standard des fichiers journaux défini par
+ --logfiledir--with-suexec-safepath=PATH/usr/local/bin:/usr/bin:/bin".Si vous avez activé la fonctionnalité suEXEC à l'aide de
+ l'option --enable-suexec, le binaire
+ suexec sera automatiquement construit (en même temps
+ que httpd) lorsque vous exécuterez la commande
+ make.
Lorsque tous les composants auront été construits, vous pourrez
+ exécuter la commande make install afin de les
+ installer. Le binaire suexec sera installé dans le
+ répertoire défini à l'aide de l'option --sbindir. La
+ localisation par défaut est "/usr/local/apache2/bin/suexec".
Veuillez noter que vous aurez besoin des
+ privilèges root pour passer l'étape de
+ l'installation. Pour que le conteneur puisse changer
+ l'identifiant utilisateur, il doit avoir comme propriétaire
+ root, et les droits du fichier doivent
+ inclure le bit d'exécution setuserid.
Bien que le conteneur suEXEC vérifie que l'utilisateur qui
+ l'appelle correspond bien à l'utilisateur spécifié à l'aide de
+ l'option --with-suexec-caller du programme
+ configure, il subsiste toujours le risque qu'un
+ appel système ou une bibliothèque fasse appel à suEXEC avant que
+ cette vérification ne soit exploitable sur votre système. Pour
+ tenir compte de ceci, et parce que c'est en général la meilleure
+ pratique, vous devez utiliser les permissions du système de
+ fichiers afin de vous assurer que seul le groupe sous lequel
+ s'exécute httpd puisse faire appel à suEXEC.
Si, par exemple, votre serveur web est configuré pour + s'exécuter en tant que :
+ +User www +Group webgroup+ + +
et suexec se trouve à
+ "/usr/local/apache2/bin/suexec", vous devez exécuter les
+ commandes
+ chgrp webgroup /usr/local/apache2/bin/suexec
+ chmod 4750 /usr/local/apache2/bin/suexec
+
Ceci permet de s'assurer que seul le groupe sous lequel httpd + s'exécute (ici webgroup) puisse faire appel au conteneur + suEXEC.
+ +Au démarrage, httpd vérifie la présence du fichier
+ suexec dans le répertoire défini par
+ l'option --sbindir du script configure (le
+ répertoire par défaut est "/usr/local/apache/sbin/suexec"). Si
+ httpd trouve un conteneur suEXEC correctement configuré, il
+ enregistrera le message suivant dans le journal des erreurs :
+ [notice] suEXEC mechanism enabled (wrapper: /path/to/suexec)
+
Si ce message n'est pas généré au démarrage du serveur, ce + dernier ne trouve probablement pas le programme conteneur à + l'endroit où il est sensé être, ou l'exécutable suexec n'est pas + installé en setuid root.
+ +Si le serveur HTTP Apache est déjà en cours d'exécution, et si + vous activez le mécanisme suEXEC pour la première fois, vous + devez arrêter et redémarrer httpd. Un redémarrage + à l'aide d'un simple signal HUP ou USR1 suffira.
+Pour désactiver suEXEC, vous devez supprimer le fichier
+ suexec, puis arrêter et redémarrer
+ httpd.
Les requêtes pour des programmes CGI ne feront appel au
+ conteneur suEXEC que si elles concernent un hôte virtuel
+ contenant une directive SuexecUserGroup, ou si elles sont
+ traitées par mod_userdir.
Hôtes virtuels :
Une des méthodes
+ d'utilisation du conteneur suEXEC consiste à insérer une
+ directive SuexecUserGroup dans une section
+ VirtualHost. En définissant
+ des valeurs différentes de celles du serveur principal, toutes les
+ requêtes pour des ressources CGI seront exécutées sous
+ les User et Group définis pour cette section
+ <VirtualHost>. Si cette
+ directive est absente de la section <VirtualHost>, l'utilisateur du
+ serveur principal sera pris par défaut
Répertoires des utilisateurs :
Avec
+ cette méthode, les
+ requêtes traitées par mod_userdir appelleront le
+ conteneur suEXEC pour exécuter le programme CGI sous l'identifiant
+ utilisateur du répertoire utilisateur concerné. Seuls prérequis
+ pour pouvoir accéder à cette fonctionnalité : l'exécution des CGI
+ doit être activée pour l'utilisateur concerné, et le script doit
+ passer avec succès le test des vérifications de
+ sécurité décrit plus haut. Voir aussi l'
+ option de compilation
+ --with-suexec-userdir.
Le conteneur suEXEC va écrire ses informations de journalisation
+ dans le fichier défini par l'option de compilation
+ --with-suexec-logfile comme indiqué plus haut. Si vous
+ pensez avoir configuré et installé correctement le conteneur,
+ consultez ce journal, ainsi que le journal des erreurs du serveur
+ afin de déterminer l'endroit où vous avez fait fausse route.
NOTE ! Cette section est peut-être incomplète. + Pour en consulter la dernière révision, voir la version de la Documentation en ligne.
+ +Quelques points importants du conteneur peuvent + imposer des contraintes du point de vue de la configuration du + serveur. Veuillez en prendre connaissance avant de soumettre un + rapport de bogue à propos de suEXEC.
+ ++ Pour des raisons de sécurité et d'efficacité, toutes les + requêtes suEXEC ne doivent concerner que des ressources + situées dans la racine des documents définie pour les + requêtes concernant un hôte virtuel, ou des ressources + situées dans la racine des documents définies pour les + requêtes concernant un répertoire utilisateur. Par exemple, + si vous avez configuré quatre hôtes virtuels, vous devrez + définir la structure des racines de documents de vos hôtes + virtuels en dehors d'une hiérarchie de documents principale + de httpd, afin de tirer parti de suEXEC dans le contexte des + hôtes virtuels (Exemple à venir). +
++ Modifier cette variable peut s'avérer dangereux. Assurez-vous + que tout chemin que vous ajoutez à cette variable est un + répertoire de confiance. Vous n'avez + probablement pas l'intention d'ouvrir votre serveur de façon + à ce que l'on puisse y exécuter un cheval de Troie. +
++ Encore une fois, ceci peut vous causer de + graves ennuis si vous vous y essayez sans + savoir ce que vous faites. Evitez de vous y risquer dans la + mesure du possible. +
+Serveur HTTP Apache Version 2.4
+Afin d'assister les utilisateurs lors de leurs opérations de mise à
+ jour, nous maintenons un document
+ qui comporte des informations critiques à l'attention des personnes qui
+ utilisent déjà le serveur HTTP Apache. Ces informations
+ ne sont que de brèves notes, et vous
+ trouverez plus d'informations dans le document Nouvelles fonctionnalités, ou dans
+ le fichier src/CHANGES. Les développeurs d'applications
+ et de modules trouveront un résumé des modifications de l'API dans la
+ vue d'ensemble Mises à jour de
+ l'API.
Ce document présente les changements de comportement du serveur qui + peuvent nécessiter une modification de la configuration, et une + méthode pour utiliser la version 2.4 du serveur en parallèle avec la + version 2.2. Pour tirer parti des nouvelles fonctionnalités de la + version 2.4, reportez-vous au document "Nouvelles fonctionnalités".
+ +Ce document ne décrit que les modifications intervenues entre les versions + 2.2 et 2.4. Si vous effectuez une mise à jour depuis la version 2.0, vous + devez aussi consulter le + document de mise + à jour de 2.0 vers 2.2.
+ + Modifications des paramètres de compilation Modifications de la configuration à l'exécution Changements divers Modules tiers Problèmes de mise à jour courantsLe processus de compilation est très similaire à celui de la
+ version 2.2. Dans la plupart des cas, vous pourrez utiliser votre
+ ancienne ligne de commande configure (telle qu'elle
+ est enregistrée dans le fichier build/config.nice
+ situé dans le répertoire de compilation du serveur). Voici certains
+ changements intervenus dans la configuration par défaut :
mod_cache_disk dans la version 2.4.mod_lbmethod_bybusyness. Vous devrez compiler et
+ chargés tous les modules correspondants que votre configuration
+ utilise.LoadModule
+ sont mises en commentaires dans le fichier de configuration.Des changements significatifs dans la configuration de +l'autorisation, ainsi que quelques changements mineurs, peuvent +nécessiter une mise à jour des fichiers de configuration de la version +2.2 avant de les utiliser sous la version 2.4.
+ +Tout fichier de configuration qui gère des autorisations devra + probablement être mis à jour.
+ +Vous devez vous reporter au document Authentification, autorisation et contrôle + d'accès, et plus particulièrement à la section Pour aller plus loin qu'une simple + autorisation qui explique les nouveaux mécanismes permettant de + contrôler l'ordre dans lequel les directives d'autorisation sont + appliquées.
+ +Les directives qui contrôlent la manière dont les modules
+ d'autorisation réagissent lorsqu'ils ne reconnaissent pas
+ l'utilisateur authentifié ont été supprimées : elles comprennent les
+ directives AuthzLDAPAuthoritative, AuthzDBDAuthoritative,
+ AuthzDBMAuthoritative, AuthzGroupFileAuthoritative,
+ AuthzUserAuthoritative et AuthzOwnerAuthoritative. Ces directives
+ ont été remplacées par les directives plus explicites RequireAny, RequireNone, et RequireAll.
Si vous utilisez mod_authz_dbm, vous devez
+ mettre à jour votre configuration en remplaçant les directives du
+ style Require group ... par des directives du style
+ Require dbm-group ....
Dans la version 2.2, le contrôle d'accès basé sur le nom d'hôte
+ du client, son adresse IP, ou d'autres caractéristiques de la
+ requête était assuré via les directives Order, Allow, Deny, et Satisfy.
Dans la version 2.4, ce contrôle d'accès est assuré, comme tout
+ contrôle d'autorisation, par le nouveau module
+ mod_authz_host. Bien que le module
+ mod_access_compat soit fourni à des fins de
+ compatibilité avec les anciennes configurations, les anciennes
+ directives de contrôle d'accès devront être remplacées par les
+ nouveaux mécanismes d'authentification.
Mélanger d'anciennes directives comme Order, Allow ou Deny avec des nouvelles comme
+ Require est techniquement
+ possible mais déconseillé. En effet, mod_access_compat a
+ été conçu pour supporter des configurations ne contenant que des anciennes
+ directives afin de faciliter le passage à la version 2.4. Les
+ exemples ci-dessous vous permettront de vous faire une meilleure idée des
+ problèmes qui peuvent survenir.
+
Voici quelques exemples de contrôle d'accès avec l'ancienne et + la nouvelle méthode :
+ +Dans cet exemple, il n'y a pas d'authentification et toutes les requêtes sont rejetées :
+Order deny,allow +Deny from all+
Require all denied+
Dans cet exemple, il n'y a pas d'authentification et toutes les requêtes sont acceptées :
+Order allow,deny +Allow from all+
Require all granted+
Dans l'exemple suivant, il n'y a pas d'authentification et tous les + hôtes du domaine example.org ont l'autorisation d'accès, tous les autres + étant rejetés :
+ +Order Deny,Allow +Deny from all +Allow from example.org+
Require host example.org+
Dans l'exemple suivant, tous les hôtes du domaine example.org + ont l'autorisation d'accès, tous les autres sont rejetés :
+ +Order Deny,Allow +Deny from all +Allow from example.org+
Require host example.org+
Dans l'exemple suivant, le mélange d'anciennes et de nouvelles + directives produit des résultats inattendus.
+ +DocumentRoot "/var/www/html" + +<Directory "/"> + AllowOverride None + Order deny,allow + Deny from all +</Directory> + +<Location "/server-status"> + SetHandler server-status + Require local +</Location> + +access.log - GET /server-status 403 127.0.0.1 +error.log - AH01797: client denied by server configuration: /var/www/html/server-status+
Pourquoi httpd interdit l'accès à server-status alors que la
+ configuration semble l'autoriser ? Parce que dans ce scénario de fusion de configuration, les
+ directives de mod_access_compat sont prioritaires par
+ rapport à celles de mod_authz_host.
L'exemple suivant quant à lui produit un résultat conforme :
+ +DocumentRoot "/var/www/html" + +<Directory "/"> + AllowOverride None + Require all denied +</Directory> + +<Location "/server-status"> + SetHandler server-status + Order deny,allow + Deny from all + Allow From 127.0.0.1 +</Location> + +access.log - GET /server-status 200 127.0.0.1+
En conclusion, même si une configuration hybride peut fonctionner, + essayez de l'éviter lors de la mise à jour : soit conservez les anciennes + directives, puis migrez-les vers les nouvelles ultérieurement, soit + effectuez une migration immédiate de toutes les anciennes directives vers + les nouvelles. +
+ + +Dans de nombreuses configurations avec authentification où la directive
+ Satisfy était définie à sa valeur par défaut
+ ALL, les lignes de configuration qui désactivent le contrôle
+ d'accès basé sur l'hôte sont maintenant omises :
# configuration en version 2.2 qui désactive le contrôle d'accès basé sur le nom +# d'hôte pour n'utiliser que l'authentification +Order Deny,Allow +Allow from all +AuthType Basic +AuthBasicProvider file +AuthUserFile /example.com/conf/users.passwd +AuthName secure +Require valid-user+
# Pas besoin de remplacer les directives de contrôle d'accès basées sur le nom +# d'hôte désactivées +AuthType Basic +AuthBasicProvider file +AuthUserFile /example.com/conf/users.passwd +AuthName secure +Require valid-user+
Dans les configurations où l'authentification et le contrôle d'accès se + combinaient dans un but précis, les directives de contrôle d'accès doivent + être migrées. Dans l'exemple suivant, les requêtes qui correspondent aux + deux critères sont acceptées :
+Order allow,deny +Deny from all +# ALL est la valeur par défaut de Satisfy +Satisfy ALL +Allow from 127.0.0.1 +AuthType Basic +AuthBasicProvider file +AuthUserFile /example.com/conf/users.passwd +AuthName secure +Require valid-user+
AuthType Basic +AuthBasicProvider file +AuthUserFile /example.com/conf/users.passwd +AuthName secure +<RequireAll> + Require valid-user + Require ip 127.0.0.1 +</RequireAll>+
Dans les configurations où l'authentification et le contrôle d'accès se + combinaient dans un but précis, les directives de contrôle d'accès doivent + être migrées. Dans l'exemple suivant, les requêtes qui correspondent à + au moins un critère sont acceptées :
+Order allow,deny +Deny from all +Satisfy any +Allow from 127.0.0.1 +AuthType Basic +AuthBasicProvider file +AuthUserFile /example.com/conf/users.passwd +AuthName secure +Require valid-user+
AuthType Basic +AuthBasicProvider file +AuthUserFile /example.com/conf/users.passwd +AuthName secure +# Implicite : <RequireAny> +Require valid-user +Require ip 127.0.0.1+
D'autres ajustements mineurs peuvent s'avérer nécessaires pour + certaines configurations particulières, comme décrit ci-dessous.
+ +MaxRequestsPerChild a été renommée en
+ MaxConnectionsPerChild;
+ ce nouveau nom reflète mieux l'usage de cette directive.
+ L'ancien nom est encore supporté.MaxClients a
+ été renommée en MaxRequestWorkers; ce nouveau
+ nom reflète mieux l'usage de cette directive. Pour les
+ modules multiprocessus asynchrones, comme event, le nombre
+ maximal de clients n'est pas équivalent au nombre de threads du
+ worker. L'ancien nom est encore supporté.DefaultType ne produit plus aucun
+ effet, si ce n'est d'émettre un avertissement si elle est
+ définie à une valeur autre que none. D'autres
+ directives de configuration la remplacent dans la version 2.4.
+ AllowOverride est maintenant
+ None.EnableSendfile est maintenant Off.FileETag est maintenant "MTime Size"
+ (sans INode).mod_dav_fs: le format du fichier DavLockDB a changé pour les systèmes
+ avec inodes. L'ancien fichier DavLockDB doit être supprimé dans le
+ cadre de la mise à jour.
+ KeepAlive
+ n'accepte que les valeurs On ou Off.
+ Avant, toute valeur autre que "Off" ou "0" était traitée comme
+ "On".Mutex.
+ Vous devez évaluer l'impact de ces directives obsolètes dans
+ votre configuration version 2.2 afin de déterminer si elles
+ peuvent être simplement supprimées, ou si elles doivent être
+ remplacées par la directive Mutex.mod_cache: la directive CacheIgnoreURLSessionIdentifiers
+ effectue maintenant une correspondance exacte dans la chaîne de
+ paramètres au lieu d'une correspondance partielle. Si votre
+ configuration mettait en jeu des sous-chaînes comme
+ sessionid pour correspondre à
+ /une-application/image.gif;jsessionid=123456789,
+ vous devez maintenant utiliser la chaîne de correspondance
+ complète jsessionid.
+ mod_cache: le second paramètre de la
+ directive CacheEnable
+ ne concerne les contenus en mandat direct que s'ils débutent par
+ le protocole approprié. Dans les versions 2.2 et antérieures, un
+ paramètre tel que '/' concernait tous les contenus.mod_ldap: la directive LDAPTrustedClientCert s'utilise
+ maintenant exclusivement au sein d'une configuration de niveau
+ répertoire. Si vous utilisez cette directive, passez en revue
+ votre configuration pour vous assurer qu'elle est bien présente
+ dans tous les contextes de répertoire nécessaires.mod_filter: la syntaxe de la directive
+ FilterProvider utilise
+ maintenant une expression booléenne pour déterminer si un filtre
+ s'applique.
+ mod_include:
+ #if expr utilise maintenant le
+ nouvel interpréteur d'expressions.
+ L'ancienne syntaxe peut être réactivée via la directive
+ SSILegacyExprParser.
+ mod_charset_lite : l'option
+ DebugLevel a été supprimée en faveur d'une
+ configuration de la directive LogLevel au niveau répertoire.
+ mod_ext_filter : l'option
+ DebugLevel a été supprimée en faveur d'une
+ configuration de la directive LogLevel au niveau répertoire.
+ mod_proxy_scgi: certaines applications web
+ ne fonctionneront plus correctement avec la nouvelle
+ configuration de PATH_INFO qui est différente de
+ celle de la version 2.2. La configuration
+ précédente peut être
+ restaurée en définissant la variable
+ proxy-scgi-pathinfo.mod_ssl: le contrôle de révocation des
+ certificats basé sur les CRL doit être maintenant explicitement
+ configuré via la directive SSLCARevocationCheck.
+ mod_substitute: la taille maximale d'une
+ ligne est maintenant 1Mo.
+ mod_reqtimeout: si ce module est chargé, il
+ définit maintenant certains temps d'attente par défaut.mod_dumpio: la directive
+ DumpIOLogLevel n'est plus supportée. Les
+ données sont toujours enregistrées au niveau trace7
+ de LogLevelErrorLog ou CustomLog étaient invoquées
+ en utilisant /bin/sh -c. A
+ partir de la version 2.4, les commandes de redirection des logs
+ sont exécutées directement. Pour retrouver l'ancien
+ comportement, voir la documentation
+ sur la redirection des logsmod_auto_index: extrait maintenant les titres
+ et affiche la description pour les fichiers .xhtml qui étaient
+ jusqu'alors ignorés.mod_ssl : le format par défaut des variables
+ *_DN a changé. Il est cependant encore possible
+ d'utiliser l'ancien format via la nouvelle option
+ LegacyDNStringFormat de la directive SSLOptions. Le protocole SSLv2 n'est
+ plus supporté. Les directives SSLProxyCheckPeerCN et
+ SSLProxyCheckPeerExpire
+ sont maintenant définies par défaut à On, et les requêtes mandatées
+ vers des serveurs HTTPS possèdant des certificats non conformes ou
+ périmés échoueront donc avec un code d'erreur 502 (Bad gateway).htpasswd utilise maintenant par défaut les
+ condensés MD5 sur toutes les plates-formes.NameVirtualHost n'a plus aucun effet, si
+ ce n'est l'émission d'un avertissement. Toute combinaison
+ adresse/port apparaissant dans plusieurs serveurs virtuels est
+ traitée implicitement comme un serveur virtuel basé sur le nom.
+ mod_deflate n'effectue plus de compression
+ s'il s'aperçoit que la quantité de données ajoutée par la
+ compression est supérieure à la quantité de données à compresser.
+ #if expr=
+ du module mod_include, ou si la directive
+ SSILegacyExprParser a
+ été activée pour le répertoire contenant les pages d'erreur.
+ mod_authn_alias
+ dans les précédentes versions (en fait la directive
+ AuthnProviderAlias)
+ est maintenant fournie par mod_authn_core.
+ LogLevel qui permet de définir
+ un niveau de journalisation approprié pour le module
+ mod_rewrite. Voir aussi la section journalisation de
+ mod_rewrite.Tous les modules tiers doivent être recompilés pour la + version 2.4 avant d'être chargés.
+ +De nombreux modules tiers conçus pour la version 2.2 + fonctionneront sans changement avec le serveur HTTP Apache + version 2.4. Certains nécessiteront cependant des modifications ; se + reporter à la vue d'ensemble Mise à jour de l'API.
+Invalid command 'User', perhaps misspelled or defined by
+ a module not included in the server configuration - chargez
+ le module mod_unixdInvalid command 'Require', perhaps misspelled or defined
+ by a module not included in the server configuration, ou
+ Invalid command 'Order', perhaps misspelled or defined by a
+ module not included in the server configuration - chargez
+ le module mod_access_compat, ou mettez à jour
+ vers la version 2.4 les directives d'autorisation.Ignoring deprecated use of DefaultType in line NN of
+ /path/to/httpd.conf - supprimez la directive DefaultType et remplacez-la par les
+ directives de configuration appropriées.Invalid command 'AddOutputFilterByType', perhaps misspelled
+ or defined by a module not included in the server configuration
+ - la directive AddOutputFilterByType qui était
+ jusqu'alors implémentée par le module core, l'est maintenant par
+ le module mod_filter, qui doit donc être chargé.configuration error: couldn't check user: /path -
+ chargez le module mod_authn_core..htaccess ne sont pas traités -
+ Vérifiez la présence d'une directive AllowOverride appropriée ; sa valeur par
+ défaut est maintenant None.Serveur HTTP Apache Version 2.4
+Ce document explique comment le serveur HTTP Apache utilise l'URL contenue dans une + requête pour déterminer le noeud du système de fichier à partir duquel le + fichier devra être servi.
+ Modules et directives concernés Racine des documents (DocumentRoot) Fichiers situés en dehors de
+l'arborescence DocumentRoot Répertoires des utilisateurs Redirection d'URL Mandataire inverse (Reverse Proxy) Moteur de réécriture Fichier non trouvé (File Not Found) Autres modules de mise en correspondance des
+URLs| Modules Apparentés | Directives Apparentées |
|---|---|
La méthode par défaut de httpd pour déterminer quel fichier servir pour
+ une requête donnée, consiste à extraire le chemin du fichier de la requête
+ (la partie de l'URL qui suit le nom d'hôte et le port), puis de l'ajouter
+ à la fin de la valeur de la directive
+ DocumentRoot définie dans vos fichiers
+ de configuration.
+ Ainsi, les fichiers et répertoires
+ situés en dessous de DocumentRoot
+ constituent l'arborescence de base des documents qui seront visibles
+ depuis le web.
Par exemple, si la directive
+ DocumentRoot contient
+ /var/www/html, une requête pour
+ http://www.example.com/fish/guppies.html retournera le
+ fichier /var/www/html/fish/guppies.html au client.
Si la requête concerne un répertoire (autrement dit un chemin se
+ terminant par un slash /), le nom du fichier qui sera
+ recherché et servi depuis ce répertoire est défini via la directive
+ DirectoryIndex. Par exemple,
+ supposons que DocumentRoot ait été définie comme
+ précédemment, et que vous ayez défini DirectoryIndex
+ comme suit :
DirectoryIndex index.html index.php
Si httpd reçoit alors une requête pour
+ http://www.example.com/fish/, il tentera de servir le
+ fichier /var/www/html/fish/index.html. Si ce fichier
+ n'existe pas, il tentera de servir le fichier
+ /var/www/html/fish/index.php.
Si aucun de ces fichiers existe, httpd tentera de générer et
+ d'afficher un index du répertoire, à condition que
+ mod_autoindex ait été chargé et configuré pour le
+ permettre.
httpd supporte aussi les Hôtes virtuels,
+ ce qui lui permet de traiter des requêtes pour plusieurs hôtes.
+ Dans ce cas, un DocumentRoot
+ différent peut être défini pour chaque hôte virtuel;
+ les directives fournies par le module
+ mod_vhost_alias peuvent aussi être utilisées afin de
+ déterminer dynamiquement le noeud approprié du système de fichiers
+ à partir duquel servir un contenu en fonction de l'adresse IP
+ ou du nom d'hôte.
La directive DocumentRoot est
+ définie dans le fichier de configuration de votre serveur principal
+ (httpd.conf), mais peut aussi être redéfinie pour chaque
+ Hôte virtuel supplémentaire que vous avez créé.
Il existe de nombreuses circonstances pour lesquelles il est nécessaire
+ d'autoriser l'accès web à des portions du système de fichiers qui ne se
+ trouvent pas dans l'arborescence DocumentRoot. httpd propose de nombreuses
+ solutions pour réaliser cela. Sur les systèmes Unix, les liens
+ symboliques permettent de rattacher d'autres portions du système de
+ fichiers au DocumentRoot. Pour des raisons de sécurité,
+ httpd ne suivra les liens symboliques que si les Options pour le répertoire concerné contiennent
+ FollowSymLinks ou SymLinksIfOwnerMatch.
Une autre méthode consiste à utiliser la directive Alias pour rattacher toute portion
+ du système de fichiers à l'arborescence du site web. Par exemple, avec
Alias "/docs" "/var/web"+ + +
l'URL http://www.example.com/docs/dir/file.html
+ correspondra au fichier /var/web/dir/file.html. La
+ directive
+ ScriptAlias
+ fonctionne de la même manière, excepté que tout contenu localisé dans le
+ chemin cible sera traité comme un script CGI.
Pour les situations qui nécessitent plus de flexibilité, vous disposez
+ des directives AliasMatch
+ et ScriptAliasMatch
+ qui permettent des substitutions et comparaisons puissantes basées
+ sur les expressions rationnelles.
+ Par exemple,
ScriptAliasMatch "^/~([a-zA-Z0-9]+)/cgi-bin/(.+)" "/home/$1/cgi-bin/$2"+ + +
fera correspondre une requête du style
+ http://example.com/~user/cgi-bin/script.cgi au chemin
+ /home/user/cgi-bin/script.cgi, et traitera le fichier résultant
+ comme un script CGI.
Sur les systèmes Unix, on peut traditionnellement faire référence
+ au répertoire personnel d'un utilisateur particulier à l'aide de
+ l'expression ~user/.
+ Le module mod_userdir
+ étend cette idée au web en autorisant l'accès aux fichiers situés dans les
+ répertoires home des utilisateurs à l'aide d'URLs
+ comme dans ce qui suit :
http://www.example.com/~user/file.html
Pour des raisons de sécurité, il est déconseillé de permettre un accès
+ direct à un répertoire home d'utilisateur depuis le web. A cet effet, la
+ directive UserDir
+ spécifie un répertoire où sont situés les fichiers accessibles depuis le web
+ dans le répertoire home de l'utilisateur.
+ Avec la configuration par défaut
+ Userdir public_html, l'URL ci-dessus correspondra à un fichier
+ dont le chemin sera du style
+ /home/user/public_html/file.html où
+ /home/user/ est le répertoire home de l'utilisateur tel qu'il
+ est défini dans /etc/passwd.
La directive Userdir met à votre disposition de nombreuses
+ formes différentes pour les systèmes où /etc/passwd ne
+ spécifie pas la localisation du répertoire home.
Certains jugent le symbole "~" (dont le code sur le web est souvent
+ %7e) inapproprié et préfèrent utiliser une chaîne de
+ caractères différente pour représenter les répertoires utilisateurs.
+ mod_userdir ne supporte pas cette fonctionnalité. Cependant, si les
+ répertoires home des utilisateurs sont structurés de manière rationnelle,
+ il est possible d'utiliser la directive
+ AliasMatch
+ pour obtenir l'effet désiré. Par exemple, pour faire correspondre
+ http://www.example.com/upages/user/file.html à
+ /home/user/public_html/file.html, utilisez la directive
+ AliasMatch suivante :
AliasMatch "^/upages/([a-zA-Z0-9]+)(/(.*))?$" "/home/$1/public_html/$3"+ +
Les directives de configuration décrites dans les sections précédentes
+ demandent à httpd d'extraire un contenu depuis un emplacement spécifique
+ du système de fichiers
+ et de la retourner au client. Il est cependant parfois
+ souhaitable d'informer le
+ client que le contenu demandé est localisé à une URL différente, et de
+ demander au client d'élaborer une nouvelle requête avec la nouvelle URL.
+ Ce processus se nomme redirection et est implémenté par la
+ directive Redirect.
+ Par exemple, si le contenu du répertoire /foo/ sous
+ DocumentRoot est déplacé vers le
+ nouveau répertoire /bar/, vous pouvez demander aux clients
+ de le requérir à sa nouvelle localisation comme suit :
Redirect permanent "/foo/" "http://www.example.com/bar/"+ + +
Ceci aura pour effet de rediriger tout chemin d'URL commençant par
+ /foo/ vers le même chemin d'URL sur le serveur
+ www.example.com en remplaçant /foo/ par
+ /bar/. Vous pouvez rediriger les clients non seulement sur le
+ serveur d'origine, mais aussi vers n'importe quel autre serveur.
httpd propose aussi la directive RedirectMatch pour traiter les problèmes
+ de réécriture d'une plus grande complexité. Par exemple, afin de rediriger
+ les requêtes pour la page d'accueil du site vers un site différent, mais
+ laisser toutes les autres requêtes inchangées, utilisez la
+ configuration suivante :
RedirectMatch permanent "^/$" "http://www.example.com/startpage.html"+ + +
De même, pour rediriger temporairement toutes les pages d'un site + vers une page particulière d'un autre site, utilisez ce qui suit :
+ +RedirectMatch temp ".*" "http://othersite.example.com/startpage.html"+ +
httpd vous permet aussi de rapatrier des documents distants +dans l'espace des URL du serveur local. +Cette technique est appelée mandataire inverse ou reverse +proxying car le serveur web agit comme un serveur mandataire en +rapatriant les documents depuis un serveur distant puis les renvoyant +au client. Ceci diffère d'un service de mandataire usuel (direct) car, pour le client, +les documents semblent appartenir au serveur mandataire inverse.
+ +Dans l'exemple suivant, quand les clients demandent des documents situés
+dans le répertoire
+/foo/, le serveur rapatrie ces documents depuis le répertoire
+/bar/ sur internal.example.com
+et les renvoie au client comme s'ils appartenaient au serveur local.
ProxyPass "/foo/" "http://internal.example.com/bar/" +ProxyPassReverse "/foo/" "http://internal.example.com/bar/" +ProxyPassReverseCookieDomain internal.example.com public.example.com +ProxyPassReverseCookiePath "/foo/" "/bar/"+ + +
La directive ProxyPass configure
+le serveur pour rapatrier les documents appropriés, alors que la directive
+ProxyPassReverse
+réécrit les redirections provenant de
+internal.example.com de telle manière qu'elles ciblent le
+répertoire approprié sur le serveur local. De manière similaire, les directives
+ProxyPassReverseCookieDomain
+et ProxyPassReverseCookiePath
+réécrivent les cookies élaborés par le serveur d'arrière-plan.
Il est important de noter cependant, que les liens situés dans les documents
+ne seront pas réécrits. Ainsi, tout lien absolu sur
+internal.example.com fera décrocher le client
+du serveur mandataire et effectuer sa requête directement sur
+internal.example.com. Vous pouvez modifier ces liens (et
+d'utres contenus) situés dans la page au moment où elle est envoyée au
+client en utilisant le module mod_substitute.
Substitute "s/internal\.example\.com/www.example.com/i"+ + +
Le module mod_proxy_html rend possible une réécriture plus
+élaborée des liens en HTML et XHTML. Il permet de créer des listes
+d'URLs et de leurs réécritures, de façon à pouvoir gérer des scénarios
+de réécriture complexes.
Le moteur de réécriture mod_rewrite peut s'avérer
+ utile lorsqu'une substitution plus puissante est nécessaire.
+ Les directives fournies par ce module peuvent utiliser des caractéristiques de la
+ requête comme le type de navigateur ou l'adresse IP source afin de décider
+ depuis où servir le contenu. En outre, mod_rewrite peut utiliser des
+ fichiers ou programmes de bases de données externes pour déterminer comment
+ traiter une requête. Le moteur de réécriture peut effectuer les trois types
+ de mise en correspondance discutés plus haut :
+ redirections internes (aliases), redirections externes, et services mandataires.
+ De nombreux exemples pratiques utilisant mod_rewrite sont discutés dans la
+ documentation détaillée de mod_rewrite.
Inévitablement, apparaîtront des URLs qui ne correspondront à aucun + fichier du système de fichiers. + Ceci peut arriver pour de nombreuses raisons. + Il peut s'agir du déplacement de documents d'une + localisation vers une autre. Dans ce cas, le mieux est d'utiliser la + redirection d'URL pour informer les clients de la + nouvelle localisation de la ressource. De cette façon, vous êtes sur que + les anciens signets et liens continueront de fonctionner, même si la + ressource est déplacée.
+ +Une autre cause fréquente d'erreurs "File Not Found" est l'erreur de
+ frappe accidentelle dans les URLs, soit directement dans le navigateur,
+ soit dans les liens HTML. httpd propose le module
+ mod_speling (sic) pour tenter de résoudre ce problème.
+ Lorsque ce module est activé, il intercepte les erreurs
+ "File Not Found" et recherche une ressource possédant un nom de fichier
+ similaire. Si un tel fichier est trouvé, mod_speling va envoyer une
+ redirection HTTP au client pour lui communiquer l'URL correcte.
+ Si plusieurs fichiers proches sont trouvés, une liste des alternatives
+ possibles sera présentée au client.
mod_speling possède une fonctionnalité particulièrement utile : + il compare les noms de fichiers sans tenir compte de la casse. + Ceci peut aider les systèmes où les utilisateurs ne connaissent pas la + sensibilité des URLs à la casse et bien sûr les systèmes de fichiers unix. + Mais l'utilisation de mod_speling pour toute autre chose que la correction + occasionnelle d'URLs peut augmenter la charge du serveur, car chaque + requête "incorrecte" entraîne une redirection d'URL et une nouvelle requête + de la part du client.
+ +mod_dir fournit la directive FallbackResource qui permet d'associer
+ des URIs virtuels à une ressource réelle qui peut ainsi les servir.
+ Cette directive remplace avantageusement
+ mod_rewrite lors de l'implémentation d'un
+ "contrôleur frontal".
Si toutes les tentatives pour localiser le contenu
+ échouent, httpd
+ retourne une page d'erreur avec le code de statut HTTP 404
+ (file not found). L'apparence de cette page est contrôlée à l'aide de la
+ directive ErrorDocument
+ et peut être personnalisée de manière très flexible comme discuté dans le
+ document
+ Réponses personnalisées aux erreurs.
Les autres modules disponibles pour la mise en correspondance des + URLs sont :
+mod_actions - Met une URL en correspondance
+ avec un script CGI en fonction de la méthode de la requête, ou du
+ type MIME de la ressource.mod_dir - Permet une mise en correspondance
+ basique d'un slash terminal dans un fichier index comme
+ index.html.mod_imagemap - Met en correspondance une
+ requête avec une URL en fonction de la zone d'une image intégrée à
+ un document HTML dans laquelle un utilisateur clique.mod_negotiation - Sélectionne le document
+ approprié en fonction de préférences du client telles que la langue
+ ou la compression du contenu.Serveur HTTP Apache Version 2.4
+Ce document vise à expliquer dans le détail comment le serveur + HTTP Apache procède lors du choix de l'utilisation + d'un serveur virtuel en fonction d'une requête reçue.
+ +Il est recommandé de lire la documentation + Serveurs virtuels à base de nom et serveurs virtuels à base + d'adresse IP pour déterminer quel type de serveur virtuel nous + convient le mieux, puis de lire les documentations serveurs virtuels à base de nom ou serveurs virtuels à base d'adresse IP, et enfin + d'étudier quelques exemples.
+ +Si vous voulez entrer dans les détails, vous pouvez revenir vers + cette page.
+ +Un serveur principal (main_server) contient toutes
+ les définitions qui apparaissent en dehors des sections
+ <VirtualHost>.
Les serveurs virtuels, aussi
+ appelés vhosts (pour virtual hosts), sont définis par les
+ sections <VirtualHost>.
Chaque directive VirtualHost comporte une ou
+ plusieurs adresses et des ports optionnels.
Il est possible d'utiliser des noms d'hôtes dans la définition + d'un serveur virtuel, mais ils seront résolus en adresses IP au + démarrage du serveur, et si une résolution de nom échoue, cette + définition de serveur virtuel sera ignorée. Cette méthode est par + conséquent déconseillée.
+ +L'adresse peut
+ être spécifiée sous la forme *, ce qui conviendra à la
+ requête si aucun autre serveur virtuel ne possède l'adresse IP
+ explicite correspondant à celle de la requête.
L'adresse qui apparaît dans la directive VirtualHost
+ peut être associée à un port optionnel. Si aucun port n'est
+ spécifié, il s'agit d'un port générique qui peut aussi être spécifié
+ comme *. Le port générique correspond à toutes les
+ valeurs de port.
(Il ne faut pas confondre les numéros de port sur lesquels Apache
+ est en écoute avec les numéros de port spécifiés dans la directive
+ VirtualHost ; ces derniers ne servent qu'à définir le
+ serveur virtuel qui sera sélectionné pour traiter la
+ requête. Pour définir les ports sur lesquels Apache est en écoute,
+ utilisez la directive Listen).
+
L'ensemble des adresses (y compris les résultats multiples
+ A issus des requêtes DNS) est appelé jeu
+ d'adresses du serveur virtuel.
Apache fait automatiquement sa sélection à partir de l'en-tête
+ HTTP Host fourni par le client, lorsque la
+ correspondance la plus exacte du point de vue adresse IP/port a lieu
+ pour plusieurs serveurs virtuels.
La directive ServerName peut
+ apparaître en quelque endroit de la définition d'un serveur.
+ Cependant, chaque occurrence écrase la précédente (pour ce serveur).
+ Si aucune directive ServerName n'est spécifiée, le
+ serveur tente de déterminer le nom du serveur à partir de l'adresse
+ IP.
Le premier serveur virtuel à base de nom apparaissant dans le + fichier de configuration pour une paire IP:port donnée est + significatif car c'est lui qui sera utilisé pour toutes les requêtes + reçues sur cette adresse IP/port et pour laquelle aucun autre + serveur virtuel ne possède un ServerName ou un ServerAlias + correspondant. Il sera aussi utilisé pour toutes les connexions SSL + si le serveur ne supporte pas l'Indication du nom du serveur.
+ +Tous les noms spécifiés au sein d'une section
+ VirtualHost sont traités comme un
+ ServerAlias (sans caractères génériques), mais ne sont
+ écrasés par aucune directive ServerAlias.
Pour chaque serveur virtuel, diverses valeurs sont initialisées + par défaut. En particulier :
+ +ServerAdmin,
+ Timeout,
+ KeepAliveTimeout,
+ KeepAlive,
+ MaxKeepAliveRequests,
+ ReceiveBufferSize,
+ ou SendBufferSize,
+ alors la valeur de chacun de ces paramètres est héritée de celle du
+ serveur principal. (C'est à dire, héritée de la valeur finale après
+ lecture de la configuration du serveur principal.)L'essentiel des valeurs de configuration des serveurs virtuels + provient de valeurs par défaut issues du serveur principal. + Mais la position dans le fichier de configuration des directives + du serveur principal n'a pas d'importance -- l'ensemble de la + configuration du serveur principal est lu avant que ces valeurs par + défaut soient appliquées aux serveur virtuels. Ainsi, même si la + définition d'une valeur apparaît après celle d'un serveur virtuel, + cette valeur peut affecter la definition du serveur virtuel.
+ +Dans le cas où le serveur principal n'a pas de ServerName
+ à ce stade, le nom de la machine sur laquelle tourne le programme
+ httpd est utilisé à sa place. Nous appellerons
+ jeu d'adresses du serveur principal les adresses IP
+ renvoyées par une résolution DNS sur le ServerName
+ du serveur principal.
Pour tous les champs ServerName non définis, dans
+ le cas d'une configuration en serveur virtuel par nom, la valeur
+ adoptée par défaut est la première adresse donnée dans la section
+ VirtualHost qui définit le serveur virtuel.
Si un serveur virtuel contient la valeur magique
+ _default_, il fonctionne sur le même ServerName
+ que le serveur principal.
À la réception d'une requête, le serveur procède comme suit pour + déterminer quel serveur virtuel utiliser :
+ +Lors d'une première connexion sur une adresse/port, le serveur
+ recherche toutes les directives VirtualHost qui
+ possèdent la même adresse IP/port.
S'il n'y a aucune correspondance exacte pour cette adresse/port,
+ la recherche s'effectue sur la valeur générique (*).
Si aucune correspondance n'est enfin trouvée, la requête sera + servie par le serveur principal.
+ +S'il existe des définitions VirtualHost pour
+ l'adresse IP, l'étape suivante consiste à déterminer si nous avons à
+ faire à un serveur virtuel à base de nom ou d'adresse IP.
Si une seule section VirtualHost présente la
+ meilleure correspondance avec la paire adresse IP/port, aucune
+ action n'est entreprise et la requête est
+ traitée par le serveur virtuel qui correspond.
Si plusieurs sections VirtualHost présentent la
+ meilleure correspondance avec la paire adresse IP/port, le terme
+ "liste" dans les étapes suivantes fait référence à la liste des
+ serveurs virtuels qui correspondent, selon l'ordre dans lequel ils
+ apparaissent dans le fichier de configuration.
Si la connexion utilise SSL, si le serveur supporte l'Indication de nom de serveur,
+ et si la négociation du client SSL inclut l'extension TLS dans le
+ nom d'hôte requis, alors ce nom d'hôte sera utilisé par la suite, tout
+ comme un en-tête Host: aurait été utilisé dans le cas
+ d'une connexion non-SSL. Si ces conditions ne sont pas réunies, le
+ premier serveur virtuel à base de nom dont l'adresse correspond sera
+ utilisé pour les connexions SSL. Ceci est important car c'est le
+ serveur virtuel qui détermine quel certificat le serveur va utiliser
+ pour la connexion.
Si la requête contient un en-tête Host:, on
+ recherche dans la liste le premier serveur virtuel dont le
+ ServerName ou le ServerAlias correspond,
+ et c'est celui-ci qui va traiter la requête. Un en-tête
+ Host: peut comporter un numéro de port mais Apache
+ l'ignore systématiquement et utilise toujours le
+ port sur lequel il a effectivement reçu la requête.
Le premier serveur virtuel du fichier de configuration qui
+ possède l'adresse spécifiée est prioritaire et intercepte toutes les
+ requêtes à destination d'un nom de serveur inconnu, ou toute requête
+ sans en-tête Host: (comme les requêtes HTTP/1.0).
La recherche par adresse IP décrite ci-avant n'est faite + qu'une fois pour chaque session TCP/IP, alors que la + recherche par nom est réalisée pour chaque requête au + cours d'une connexion persistante (KeepAlive). En d'autres termes, + il est possible pour un client de faire des requêtes sur + différents serveurs virtuels par nom, au cours d'une unique + connexion persistante.
+ + + +Au cas où l'URI de la requête est absolu, et que son nom de + serveur et son port correspondent au serveur principal (ou l'un + des serveurs virtuels configurés), et qu'ils correspondent + à l'adresse et au port de la requête, alors l'URI est amputé + de son préfixe protocole/nom de serveur/port et traité par le + serveur correspondant (principal ou virtuel). Si cette correspondance + n'existe pas, l'URI reste inchangé et la requête est considérée + comme une requête d'un serveur mandataire (proxy).
+ + +ServerName et
+ ServerAlias ne sont jamais
+ réalisées pour les serveurs virtuels par IP.Host: n'est jamais utilisé
+ pour les tests de correspondances. Apache ne prend en compte
+ que le numéro de port sur lequel le client a envoyé la requête.*). En d'autres termes, le serveur
+ principal n'est utile que pour les combinaisons adresse/port
+ non spécifiées (sauf quand un serveur virtuel _default_
+ correspond au port).VirtualHost, car cela oblige le serveur a s'appuyer
+ sur le DNS au moment du démarrage. De plus, vous vous exposez
+ à des problèmes de sécurité si vous n'avez pas la maîtrise du
+ DNS pour la totalité de vos domaines. Voir la documentation
+ disponible ici, ainsi que
+ les deux points précisés ci-après.ServerName devrait toujours
+ être indiqué pour chaque serveur virtuel. Sans cela, une
+ résolution DNS est nécessaire pour chaque serveur virtuel.En plus des points évoqués sur la page des + problèmes liés au DNS, + voici quelques points intéressants :
+ +VirtualHost.
+ (Ceci améliore grandement la lisibilité de la configuration
+ -- la manière dont la configuration est interprétée après la
+ lecture des fichiers ne met pas en évidence le fait que les
+ définitions positionnées avant et surtout après les serveurs
+ virtuels peuvent impacter le fonctionnement de tous les
+ serveurs virtuels.)Serveur HTTP Apache Version 2.4
+Le but de ce document est d'essayer de répondre aux questions + les plus répandues sur la configuration des serveurs virtuels. + Les scénarios présentés ici se rencontrent quand plusieurs + serveurs Webs doivent tourner sur une seule et même machine au + moyen de serveurs virtuels par nom + ou par IP.
+ + Fonctionnement de plusieurs serveurs
+ virtuels par nom sur une seule adresse IP. Serveurs virtuels par nom sur plus
+ d'une seule adresse IP. Servir le même contenu sur des
+ adresses IP différentes (telle qu'une adresse interne et une
+ externe). Servir différents sites sur différents
+ ports. Hébergement virtuel basé sur IP Hébergements virtuels mixtes basés sur
+ les ports et sur les IP Hébergements virtuels mixtes basé sur
+ les noms et sur IP Utilisation simultanée de
+ Virtual_host et de mod_proxy Utilisation de serveurs virtuels
+ _default_ Migration d'un serveur virtuel
+ par nom en un serveur virtuel par IP Utilisation de la directive
+ ServerPathVotre serveur possède plusieurs noms d'hôte qui correspondent à une seule
+ adresse IP, et vous souhaitez des réponses différentes si on demande
+ www.example.com ou www.example.org.
La configuration de serveurs virtuels
+ sous Apache ne provoque pas leur apparition magique dans la
+ configuration du DNS. Il faut que leurs noms soient
+ définis dans le DNS, et qu'ils y soient résolus sur l'adresse IP
+ du serveur, faute de quoi personne ne pourra visiter votre site Web.
+ Il est possible d'ajouter des entrées dans le fichier
+ hosts pour tests locaux, mais qui ne fonctionneront
+ que sur la machine possédant ces entrées.
# Apache doit écouter sur le port 80 +Listen 80 +<VirtualHost *:80> + DocumentRoot "/www/example1" + ServerName www.example.com + + # Autres directives ici +</VirtualHost> + +<VirtualHost *:80> + DocumentRoot "/www/example2" + ServerName www.example.org + + # Autres directives ici +</VirtualHost>+ + + +
Les astérisques correspondent à toutes les adresses, si bien que
+ le serveur principal ne répondra jamais à aucune requête. Comme le
+ serveur virtuel
+ ServerName www.example.com se trouve en premier dans le fichier
+ de configuration, il a la plus grande priorité et peut être vu
+ comme serveur par défaut ou primaire ;
+ ce qui signifie que toute requête reçue ne correspondant à aucune
+ des directives ServerName sera servie par ce premier
+ <VirtualHost>.
La configuration ci-dessus correspond à ce que l'on souhaite pour + la plupart des serveurs virtuels à base de nom. Il faudra cependant + utiliser une configuration différente si vous souhaitez servir un + contenu différent en fonction de l'adresse IP ou du port.
+ +Vous pouvez remplacer *
+ par une adresse IP du système. Le serveur virtuel concerné
+ ne sera alors sélectionné que pour les requêtes HTTP vers
+ cette adresse IP.
En général, il est commode d'utiliser * sur
+ les systèmes dont l'adresse IP n'est pas constante - par
+ exemple, pour des serveurs dont l'adresse IP est attribuée
+ dynamiquement par le FAI, et où le DNS est géré au moyen
+ d'un DNS dynamique quelconque. Comme * signifie
+ n'importe quelle adresse, cette configuration
+ fonctionne sans devoir être modifiée quand l'adresse IP du
+ système est modifiée.
Toutes les techniques présentées ici + peuvent être étendues à un plus grand nombre d'adresses IP.
+Le serveur a deux adresses IP. Sur l'une
+ (172.20.30.40), le serveur "principal"
+ server.example.com doit répondre, et sur l'autre
+ (172.20.30.50), deux serveurs virtuels (ou plus)
+ répondront.
Listen 80 + +# Serveur "principal" sur 172.20.30.40 +ServerName server.example.com +DocumentRoot "/www/mainserver" + +<VirtualHost 172.20.30.50> + DocumentRoot "/www/example1" + ServerName www.example.com + + # D'autres directives ici ... +</VirtualHost> + +<VirtualHost 172.20.30.50> + DocumentRoot "/www/example2" + ServerName www.example.org + + # D'autres directives ici ... +</VirtualHost>+ + +
Toute requête arrivant sur une autre adresse que
+ 172.20.30.50 sera servie par le serveur principal.
+ Les requêtes vers 172.20.30.50 avec un nom de serveur
+ inconnu, ou sans en-tête Host:, seront servies par
+ www.example.com.
La machine serveur dispose de deux adresses IP
+ (192.168.1.1 et 172.20.30.40). Cette
+ machine est placée à la fois sur le réseau interne (l'Intranet)
+ et le réseau externe (Internet). Sur Internet, le nom
+ server.example.com pointe vers l'adresse externe
+ (172.20.30.40), mais sur le réseau interne, ce même
+ nom pointe vers l'adresse interne (192.168.1.1).
Le serveur peut être configuré pour répondre de la même manière
+ aux requêtes internes et externes, au moyen d'une seule section
+ <VirtualHost>.
<VirtualHost 192.168.1.1 172.20.30.40> + DocumentRoot "/www/server1" + ServerName server.example.com + ServerAlias server +</VirtualHost>+ + +
Ainsi, les requêtes en provenance de chacun des deux réseaux
+ seront servies par le même <VirtualHost>.
Sur le réseau interne, il est possible
+ d'utiliser le nom raccourci server au lieu du nom
+ complet server.example.com.
Notez également que dans l'exemple précédent, vous pouvez
+ remplacer la liste des adresses IP par des * afin
+ que le serveur réponde de la même manière sur toutes ses
+ adresses.
Vous disposez de plusieurs domaines pointant sur la même adresse + IP et vous voulez également servir de multiples ports. L'exemple + suivant montre que la sélection en fonction du nom intervient après + la sélection de la meilleure correspondance du point de vue adresse + IP/port.
+ +Listen 80 +Listen 8080 + +<VirtualHost 172.20.30.40:80> + ServerName www.example.com + DocumentRoot "/www/domain-80" +</VirtualHost> + +<VirtualHost 172.20.30.40:8080> + ServerName www.example.com + DocumentRoot "/www/domain-8080" +</VirtualHost> + +<VirtualHost 172.20.30.40:80> + ServerName www.example.org + DocumentRoot "/www/otherdomain-80" +</VirtualHost> + +<VirtualHost 172.20.30.40:8080> + ServerName www.example.org + DocumentRoot "/www/otherdomain-8080" +</VirtualHost>+ + +
Le serveur dispose de deux adresses IP (172.20.30.40
+ et 172.20.30.50) correspondant respectivement aux noms
+ www.example.com et www.example.org.
Listen 80 + +<VirtualHost 172.20.30.40> + DocumentRoot "/www/example1" + ServerName www.example.com +</VirtualHost> + +<VirtualHost 172.20.30.50> + DocumentRoot "/www/example2" + ServerName www.example.org +</VirtualHost>+ + +
Les requêtes provenant d'adresses non spécifiées dans l'une des
+ directives <VirtualHost> (comme pour
+ localhost par exemple) seront dirigées vers le serveur
+ principal, s'il en existe un.
Le serveur dispose de deux adresses IP (172.20.30.40
+ et 172.20.30.50) correspondant respectivement aux noms
+ www.example.com et www.example.org.
+ Pour chacun d'eux, nous voulons un hébergement sur les ports 80
+ et 8080.
Listen 172.20.30.40:80 +Listen 172.20.30.40:8080 +Listen 172.20.30.50:80 +Listen 172.20.30.50:8080 + +<VirtualHost 172.20.30.40:80> + DocumentRoot "/www/example1-80" + ServerName www.example.com +</VirtualHost> + +<VirtualHost 172.20.30.40:8080> + DocumentRoot "/www/example1-8080" + ServerName www.example.com +</VirtualHost> + +<VirtualHost 172.20.30.50:80> + DocumentRoot "/www/example2-80" + ServerName www.example.org +</VirtualHost> + +<VirtualHost 172.20.30.50:8080> + DocumentRoot "/www/example2-8080" + ServerName www.example.org +</VirtualHost>+ + +
Toute adresse indiquée comme argument d'une section VirtualHost + et n'apparaissant dans aucun autre serveur virtuel, fait de cette + section un serveur virtuel sélectionnable uniquement en fonction de + son adresse IP.
+ +Listen 80 +<VirtualHost 172.20.30.40> + DocumentRoot "/www/example1" + ServerName www.example.com +</VirtualHost> + +<VirtualHost 172.20.30.40> + DocumentRoot "/www/example2" + ServerName www.example.org +</VirtualHost> + +<VirtualHost 172.20.30.40> + DocumentRoot "/www/example3" + ServerName www.example.net +</VirtualHost> + +# IP-based +<VirtualHost 172.20.30.50> + DocumentRoot "/www/example4" + ServerName www.example.edu +</VirtualHost> + +<VirtualHost 172.20.30.60> + DocumentRoot "/www/example5" + ServerName www.example.gov +</VirtualHost>+ + +
Virtual_host et de mod_proxyL'exemple suivant montre comment une machine peut mandater
+ un serveur virtuel fonctionnant sur le serveur d'une autre machine.
+ Dans cet exemple, un serveur virtuel de même nom est configuré sur
+ une machine à l'adresse 192.168.111.2. La directive
+ ProxyPreserveHost On est
+ employée pour permette au nom de domaine d'être préservé lors du
+ transfert, au cas où plusieurs noms de domaines cohabitent sur
+ une même machine.
<VirtualHost *:*> + ProxyPreserveHost On + ProxyPass "/" "http://192.168.111.2/" + ProxyPassReverse "/" "http://192.168.111.2/" + ServerName hostname.example.com +</VirtualHost>+ + +
_default__default_ pour tous les portsExemple de capture de toutes les requêtes émanant + d'adresses IP ou de ports non connus, c'est-à-dire, d'un + couple adresse/port non traité par aucun autre serveur virtuel.
+ +<VirtualHost _default_:*> + DocumentRoot "/www/default" +</VirtualHost>+ + +
L'utilisation d'un tel serveur virtuel avec un joker pour le + port empêche de manière efficace qu'une requête n'atteigne le + serveur principal.
+ +Un serveur virtuel par défaut ne servira jamais une requête
+ qui est envoyée vers un couple adresse/port utilisée par un
+ serveur virtuel par nom. Si la requête contient un en-tête
+ Host: inconnu, ou si celui-ci est absent, elle
+ sera toujours servie par le serveur virtuel primaire par nom
+ (celui correspondant à ce couple adresse/port trouvé en premier
+ dans le fichier de configuration).
Vous pouvez utiliser une directive
+ AliasMatch ou
+ RewriteRule afin de
+ réécrire une requête pour une unique page d'information (ou pour
+ un script).
_default_ pour des ports différentsLa configuration est similaire à l'exemple précédent, mais
+ le serveur écoute sur plusieurs ports et un second serveur virtuel
+ _default_ pour le port 80 est ajouté.
<VirtualHost _default_:80> + DocumentRoot "/www/default80" + # ... +</VirtualHost> + +<VirtualHost _default_:*> + DocumentRoot "/www/default" + # ... +</VirtualHost>+ + +
Le serveur virtuel par défaut défini pour le port 80 (il doit + impérativement être placé avant un autre serveur virtuel par + défaut traitant tous les ports grâce au joker *) capture toutes + les requêtes envoyées sur une adresse IP non spécifiée. Le + serveur principal n'est jamais utilisé pour servir une requête.
+ + +_default_ pour un seul portNous voulons créer un serveur virtuel par défaut seulement + pour le port 80.
+ +<VirtualHost _default_:80> + DocumentRoot "/www/default" +... +</VirtualHost>+ + +
Une requête vers une adresse non spécifiée sur le port 80 + sera servie par le serveur virtuel par défaut, et toute autre + requête vers une adresse et un port non spécifiés sera servie + par le serveur principal.
+ +L'utilisation du caractère générique * dans la
+ déclaration d'un serveur virtuel l'emporte sur
+ _default_.
Le serveur virtuel par nom avec le nom de domaine
+ www.example.org (de notre exemple
+ par nom) devrait obtenir sa propre adresse IP. Pendant la
+ phase de migration, il est possible d'éviter les problèmes avec
+ les noms de serveurs et autres serveurs mandataires qui mémorisent
+ les vielles adresses IP pour les serveurs virtuels par nom.
+ La solution est simple, car il suffit d'ajouter la nouvelle
+ adresse IP (172.20.30.50) dans la directive
+ VirtualHost.
Listen 80 +ServerName www.example.com +DocumentRoot "/www/example1" + +<VirtualHost 172.20.30.40 172.20.30.50> + DocumentRoot "/www/example2" + ServerName www.example.org + # ... +</VirtualHost> + +<VirtualHost 172.20.30.40> + DocumentRoot "/www/example3" + ServerName www.example.net + ServerAlias *.example.net + # ... +</VirtualHost>+ + +
Le serveur virtuel peut maintenant être joint par la nouvelle + adresse (comme un serveur virtuel par IP) et par l'ancienne + adresse (comme un serveur virtuel par nom).
+ +ServerPathDans le cas où vous disposez de deux serveurs virtuels par nom,
+ le client doit transmettre un en-tête Host: correct
+ pour déterminer le serveur concerné. Les vieux clients HTTP/1.0
+ n'envoient pas un tel en-tête et Apache n'a aucun indice pour
+ connaître le serveur virtuel devant être joint (il sert la
+ requête à partir d'un serveur virtuel primaire). Dans un soucis
+ de préserver la compatibilité descendante, il suffit de créer
+ un serveur virtuel primaire chargé de retourner une page contenant
+ des liens dont les URLs auront un préfixe identifiant les serveurs
+ virtuels par nom.
<VirtualHost 172.20.30.40> + # serveur virtuel primaire + DocumentRoot "/www/subdomain" + RewriteEngine On + RewriteRule "." "/www/subdomain/index.html" + # ... +</VirtualHost> + +<VirtualHost 172.20.30.40> + DocumentRoot "/www/subdomain/sub1" + ServerName www.sub1.domain.tld + ServerPath "/sub1/" + RewriteEngine On + RewriteRule "^(/sub1/.*)" "/www/subdomain$1 + # ... +</VirtualHost> + +<VirtualHost 172.20.30.40> + DocumentRoot "/www/subdomain/sub2" + ServerName www.sub2.domain.tld + ServerPath "/sub2/" + RewriteEngine On + RewriteRule "^(/sub2/.*)" "/www/subdomain$1" + # ... +</VirtualHost>+ + +
À cause de la directive
+ ServerPath, une requête sur
+ une URL http://www.sub1.domain.tld/sub1/ est
+ toujours servie par le serveur sub1-vhost.
+ Une requête sur une URL http://www.sub1.domain.tld/ n'est
+ servie par le serveur sub1-vhost que si le client envoie un en-tête
+ Host: correct. Si aucun en-tête Host:
+ n'est transmis, le serveur primaire sera utilisé.
Notez qu'il y a une singularité : une requête sur
+ http://www.sub2.domain.tld/sub1/ est également servie
+ par le serveur sub1-vhost si le client n'envoie pas d'en-tête
+ Host:.
Les directives RewriteRule
+ sont employées pour s'assurer que le client qui envoie un en-tête
+ Host: correct puisse utiliser d'autres variantes d'URLs,
+ c'est-à-dire avec ou sans préfixe d'URL.
Serveur HTTP Apache Version 2.4
+Quand de nombreux serveurs virtuels sont créés, Apache peut + dépasser les limites en descripteurs de fichiers ('file descriptors', + également appelés gestionnaires de fichiers) si chacun + des serveurs virtuels utilise ses propres fichiers journaux. Le + nombre total de descripteurs de fichiers utilisés par Apache est + d'un par fichier journal, un pour chacune des autres directives + de fichiers journaux, plus un nombre constant compris entre 10 et 20 + pour son fonctionnement interne. Les systèmes d'exploitation Unix + limitent le nombre de descripteurs de fichiers utilisables par + processus ; une valeur courante pour cette limite est de 64, et + cette valeur peut le plus souvent être augmentée.
+ +Apache tente d'accroître cette valeur limite si nécessaire, mais + sans y parvenir dans les cas suivants :
+ +setrlimit().setrlimit(RLIMIT_NOFILE) ne fonctionne pas
+ sur votre système d'exploitation (c'est le cas sous Solaris 2.3).En cas de problème, Vous pouvez :
+ +<VirtualHost>,
+ en donc en envoyant les informations aux fichiers journaux du
+ serveur principal (Voir Éclatement des
+ fichiers journaux ci-dessous pour plus d'informations sur
+ cette possibilité).
+ #!/bin/sh
+
+ ulimit -S -n 100
+ exec httpd
Lorsque vous choisissez d'enregistrer les informations émanant de +plusieurs serveurs virtuels dans un même fichier journal, vous voudrez +ensuite pouvoir scinder ces informations à des fins de statistiques, par +exemple, sur les différents serveurs virtuels. Il est possible de procéder +de la manière suivante :
+ +Tout d'abord, vous devez ajouter le nom du serveur virtuel à chaque
+entrée du journal. Ceci se paramètre au moyen de la directive
+ LogFormat et de la
+variable %v. Ajoutez cette variable au début de la chaîne
+de définition du format de journalisations :
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost +CustomLog logs/multiple_vhost_log vhost+ + +
Cette configuration va provoquer la création d'un fichier de
+journalisation au format standard (CLF : 'Common Log Format'), mais dont
+chaque ligne débutera par le nom canonique du serveur virtuel (spécifié
+par la directive ServerName).
+(Voir mod_log_config pour d'autres informations sur la
+personnalisation des fichiers journaux.)
Au moment de séparer les informations du fichier journal en un fichier
+par serveur virtuel, le programme
+split-logfile peut être
+utilisé. Ce programme peut être trouvé dans le répertoire
+support de la distribution d'Apache.
Exécutez ce programme au moyen de la commande :
+ +
+split-logfile < /logs/multiple_vhost_log
+
Une fois exécuté avec le nom du fichier contenant tous les journaux,
+ce programme va générer un fichier pour chacun des serveurs virtuels
+qui apparaît dans le fichier d'entrée. Chaque fichier en sortie est
+nommé nomduserveur.log.
Serveur HTTP Apache Version 2.4
+Le principe des Serveurs Virtuels consiste à
+ faire fonctionner un ou plusieurs serveurs Web (comme
+ www.company1.example.com et www.company2.example.com)
+ sur une même machine. Les serveurs virtuels peuvent être soit
+ "par-IP" où une adresse IP est
+ attribuée pour chaque serveur Web, soit "par-nom" où plusieurs noms de domaine se côtoient sur
+ des mêmes adresses IP. L'utilisateur final ne perçoit pas
+ qu'en fait il s'agit d'un même serveur physique.
Apache a été le précurseur des serveurs proposant cette + méthode de serveurs virtuels basés sur les adresses IP. Ses + versions 1.1 et suivantes proposent les deux + méthodes de serveurs virtuels : par-IP et par-nom. Cette + deuxième méthode est parfois également appelée host-based + ou serveur virtuel non-IP.
+ +Vous trouverez ci-dessous une liste documentaire qui vous + expliquera en détails le fonctionnement du support des serveurs + virtuels par le serveur HTTP Apache.
+ +<VirtualHost>ServerNameServerAliasServerPathPour vérifier et analyser la configuration de vos serveurs
+ virtuels, vous pouvez utiliser l'argument -S sur
+ la ligne de commande.
+
+ apachectl -S
+
+
+ httpd.exe -S
+
Cette commande affichera dans le détail comment Apache a
+ traité son fichier de configuration. Les erreurs de configuration
+ peuvent être corrigées par l'examen attentif des adresses IP et
+ des noms de serveurs. (Consultez la documentation du programme
+ httpd pour les autres arguments de la ligne de
+ commande)
Serveur HTTP Apache Version 2.4
+ Système requis Comment configurer Apache Configuration de processus multiples Configuration d'un unique processus
+résident pour des serveurs virtuelsComme l'indique le terme par IP, le serveur + doit disposer de différentes paires adresses IP/port pour chaque + serveur virtuel par IP. La machine peut posséder + plusieurs connexions physiques au réseau, ou utiliser des + interfaces virtuelles qui sont supportées par la plupart des + systèmes d'exploitation modernes (Consultez la documentation des + systèmes d'exploitation pour plus de détails, notamment les "alias + IP" et la commande "ifconfig" pour les activer), et/ou utiliser + plusieurs numéros de port.
+ +Selon la terminologie du serveur HTTP Apache, l'utilisation d'une + seule adresse IP avec plusieurs ports TCP s'apparente aussi à de + l'hébergement virtuel basé sur IP.
+Il y a deux manières de configurer Apache pour le support de
+ multiples serveurs virtuels. Il suffit soit de faire tourner un
+ processus résident httpd pour chaque nom de
+ domaine, soit de faire tourner un unique processus résident qui
+ gère tous les serveurs virtuels.
Utilisez des processus résidents multiples lorsque :
+ +User,
+ Group,
+ Listen, et
+ ServerRoot différents.Listen, soit sur toutes
+ les adresses avec le joker "*", soit uniquement sur des adresses
+ spécifiques. Donc, si vous avez besoin d'écouter une adresse
+ en particulier, vous devrez le faire pour l'ensemble des
+ autres adresses (Bien qu'il soit plus simple de lancer un
+ processus httpd pour écouter N-1 adresses,
+ et un autre pour l'adresse restante).Utilisez un unique processus résident lorsque :
+ +Créez une installation indépendante du programme
+ httpd pour chaque serveur virtuel. Pour
+ chacune d'elle, utilisez la directive
+ Listen dans le fichier
+ de configuration pour définir l'adresse IP (ou serveur virtuel)
+ que le processus résident doit gérer. Par exemple :
Listen 192.0.2.100:80+ + +
Il est recommandé d'utiliser une adresse IP plutôt qu'un nom + de domaine (consultez Problèmes DNS + avec Apache).
+ +Dans ce cas, un unique processus httpd va gérer les requêtes
+ pour le serveur principal et tous les serveurs virtuels. Dans le
+ fichier de configuration, la directive
+ VirtualHost va servir à
+ définir les autres directives
+ ServerAdmin,
+ ServerName,
+ DocumentRoot,
+ ErrorLog et
+ TransferLog ou
+ CustomLog avec des
+ valeurs différentes pour chaque serveur virtuel. Par exemple :
<VirtualHost 172.20.30.40:80> + ServerAdmin webmaster@www1.example.com + DocumentRoot "/www/vhosts/www1" + ServerName www1.example.com + ErrorLog "/www/logs/www1/error_log" + CustomLog "/www/logs/www1/access_log" combined +</VirtualHost> + +<VirtualHost 172.20.30.50:80> + ServerAdmin webmaster@www2.example.org + DocumentRoot "/www/vhosts/www2" + ServerName www2.example.org + ErrorLog "/www/logs/www2/error_log" + CustomLog "/www/logs/www2/access_log" combined +</VirtualHost>+ + +
Il est recommandé d'utiliser une adresse IP plutôt qu'un nom + de domaine comme argument à la directive <VirtualHost> + (consultez Problèmes DNS + avec Apache).
+ +Presque toutes les directives de configuration + peuvent être employées dans une directive VirtualHost, à l'exception + des directives qui contrôlent la création du processus et de + quelques autres. Pour connaître celles utilisables dans une + directive VirtualHost, vérifiez leur + Contexte en utilisant + l'directive index.
+ + +SuexecUserGroup peut être
+ utilisées à l'intérieur d'une directive VirtualHost si l'exécution se fait
+ sous suEXEC. (Voir suEXEC).
SÉCURITÉ : lorsque vous spécifiez où écrire les + fichiers journaux, soyez attentif aux risques si quelqu'un d'autre + que celui qui a démarré Apache dispose des droits d'écriture + sur l'emplacement de ces fichiers. Consultez les + Conseils sur la sécurité + pour plus de détails.
+ +Serveur HTTP Apache Version 2.4
+Ce document propose une méthode performante pour servir un nombre
+ quelconque d'hôtes virtuels avec le serveur HTTP Apache. Un document séparé décrit comment
+ utiliser mod_rewrite pour gérer l'hébergement
+ virtuel de masse dynamique.
+
A qui ce document est-il destiné ? Vue d'ensemble Hébergement virtuel
+dynamique avec mod_vhost_alias Système de serveurs virtuels dynamiques
+simplifié Utiliser plusieurs systèmes
+d'hébergement virtuel sur le même serveur Pour un hébergement virtuel par IP plus
+efficace Hébergement virtuel de masse avec
+mod_rewrite Hébergement virtuel en masse avec mod_macroLes techniques décrites ici vous concernent si votre
+ httpd.conf contient de nombreuses sections
+ <VirtualHost> très semblables,
+ dans le style :
<VirtualHost 111.22.33.44> + ServerName customer-1.example.com + DocumentRoot "/www/hosts/customer-1.example.com/docs" + ScriptAlias "/cgi-bin/" "/www/hosts/customer-1.example.com/cgi-bin" +</VirtualHost> + +<VirtualHost 111.22.33.44> + ServerName customer-2.example.com + DocumentRoot "/www/hosts/customer-2.example.com/docs" + ScriptAlias "/cgi-bin/" "/www/hosts/customer-2.example.com/cgi-bin" +</VirtualHost> + +<VirtualHost 111.22.33.44> + ServerName customer-N.example.com + DocumentRoot "/www/hosts/customer-N.example.com/docs" + ScriptAlias "/cgi-bin/" "/www/hosts/customer-N.example.com/cgi-bin" +</VirtualHost>+ + +
Nous voulons remplacer toutes les configurations
+ <VirtualHost> par un mécanisme qui les génère
+ dynamiquement. Ceci présente certains avantages :
Le principal désavantage réside dans le fait que vous ne pouvez + pas définir un fichier journal différent pour chaque serveur + virtuel. De toute façon, ce serait une mauvaise idée si vous avez de + nombreux serveurs virtuels, car cela nécessiterait un nombre important de descripteurs de + fichier. Il est préférable de rediriger les journaux via un pipe ou + une file fifo vers un + programme, et faire en sorte que ce dernier éclate les journaux + en un journal par serveur virtuel. L'utilitaire split-logfile + constitue un exemple de ce traitement.
+ +Un serveur virtuel peut être défini par deux informations : son
+ adresse IP, et le contenu de l'en-tête Host: de la
+ requête HTTP. La technique d'hébergement virtuel dynamique de masse
+ utilisée ici consiste à insérer automatiquement ces informations
+ dans le chemin du fichier à utiliser pour répondre à la requête. On
+ peut y parvenir assez facilement en utilisant
+ mod_vhost_alias avec Apache httpd, mais on peut aussi
+ utiliser mod_rewrite.
Par défaut, ces deux modules + sont désactivés ; vous devez activer l'un d'eux lors de la + compilation et de la configuration d'Apache httpd si vous voulez utiliser + cette technique.
+ +Certains paramètres doivent être extraits de la requête pour que le serveur
+ dynamique se présente comme un serveur dynamique normal. Le plus
+ important est le nom du serveur, que le serveur utilise pour générer des
+ URLs d'auto-référencement, etc... Il est défini via la directive
+ ServerName, et les CGIs peuvent s'y référer via la
+ variable d'environnement SERVER_NAME. Sa véritable
+ valeur utilisée à l'exécution est contrôlée par la définition de la
+ directive
+ UseCanonicalName. Avec
+ UseCanonicalName Off, le nom du serveur correspond au
+ contenu de l'en-tête Host: de la requête. Avec
+ UseCanonicalName DNS, il est extrait d'une recherche
+ DNS inverse sur l'adresse IP du serveur virtuel. La première
+ configuration est utilisée pour l'hébergement virtuel dynamique par
+ nom, et la deuxième pour l'hébergement virtuel dynamique par IP. Si
+ httpd ne peut pas déterminer le nom du serveur, soit parce qu'il
+ n'y a pas d'en-tête Host:, soit parce que la recherche
+ DNS a échoué, il prend en compte la valeur définie par la directive
+ ServerName.
L'autre paramètre à extraire est la racine des documents (définie
+ via la directive DocumentRoot et disponible pour les
+ scripts CGI via la variable d'environnement DOCUMENT_ROOT).
+ Dans une configuration classique, il est utilisé par le module core
+ pour faire correspondre les URIs aux noms de fichiers, mais lorsque
+ la configuration du serveur comporte des serveurs virtuels, ce
+ traitement doit être pris en charge par un autre module (soit
+ mod_vhost_alias, soit mod_rewrite), qui
+ utilise un méthode de correspondance différente. Aucun de ces
+ modules ne se chargeant de définir la variable d'environnement
+ DOCUMENT_ROOT, si des CGIs ou des documents SSI
+ doivent en faire usage, ils obtiendront une valeur erronée.
Cet extrait de fichier httpd.conf implémente
+ l'hébergement virtuel décrit dans la section À qui ce document est-il destiné ? ci-dessus
+ en utilisant mod_vhost_alias.
# extrait le nom du serveur de l'en-tête Host: +UseCanonicalName Off + +# ce format de journal peut être éclaté en journaux par serveur virtuel +# à l'aide du premier champ via l'utilitaire split-logfile +LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon +CustomLog "logs/access_log" vcommon + +# inclut le nom du serveur dans les noms de fichiers ressources +# nécessaires aux traitements des requêtes +VirtualDocumentRoot "/www/hosts/%0/docs" +VirtualScriptAlias "/www/hosts/%0/cgi-bin"+ + +
Pour changer cette configuration en solution de serveur virtuel
+ par IP, il suffit de remplacer UseCanonicalName
+ Off par UseCanonicalName DNS. Le nom du serveur
+ inséré dans le nom de fichier sera alors déduit de l'adresse IP du
+ serveur virtuel. La variable %0 fait référence au nom
+ de serveur de la requête, tel qu'il est indiqué dans l'en-tête
+ Host:.
Voir la documentation du module mod_vhost_alias
+ pour d'avantages d'exemples d'utilisation.
Il s'agit d'une adaptation du système ci-dessus, ajusté pour un
+ serveur d'hébergement web de FAI. Grâce à la variable
+ %2, on peut extraire des sous-chaînes de caractères du
+ nom du serveur pour les utiliser dans le nom de fichier afin, par
+ exemple, de définir /home/user/www comme emplacement des
+ documents pour www.user.example.com. Un seul répertoire
+ cgi-bin suffit pour l'ensemble des
+ serveurs virtuels.
UseCanonicalName Off + +LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon +CustomLog "logs/access_log" vcommon + +# insertion d'une partie du nom du serveur dans les noms de fichiers +VirtualDocumentRoot "/home/%2/www" + +# répertoire cgi-bin unique +ScriptAlias "/cgi-bin/" "/www/std-cgi/"+ + +
Vous trouverez des exemples plus élaborés d'utilisation de la
+ directive VirtualDocumentRoot dans la documentation du
+ module mod_vhost_alias.
Moyennant une configuration un peu plus compliquée, vous pouvez
+ contrôler la portée des différentes configurations d'hébergement
+ virtuel à l'aide des directives <VirtualHost>
+ normales de httpd. Par exemple, on peut associer une adresse IP pour
+ les pages d'accueil des clients en général, et une autre pour les
+ clients commerciaux avec la configuration suivante. Cette
+ configuration peut être combinée avec les sections
+ <VirtualHost> conventionnelles, comme indiqué
+ plus loin.
UseCanonicalName Off + +LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon + +<Directory "/www/commercial"> + Options FollowSymLinks + AllowOverride All +</Directory> + +<Directory "/www/homepages"> + Options FollowSymLinks + AllowOverride None +</Directory> + +<VirtualHost 111.22.33.44> + ServerName www.commercial.example.com + + CustomLog "logs/access_log.commercial" vcommon + + VirtualDocumentRoot "/www/commercial/%0/docs" + VirtualScriptAlias "/www/commercial/%0/cgi-bin" +</VirtualHost> + +<VirtualHost 111.22.33.45> + ServerName www.homepages.example.com + + CustomLog "logs/access_log.homepages" vcommon + + VirtualDocumentRoot "/www/homepages/%0/docs" + ScriptAlias "/cgi-bin/" "/www/std-cgi/" +</VirtualHost>+ + +
Si le premier bloc VirtualHost ne comporte pas de
+ directive ServerName, c'est
+ le nom issu d'une recherche DNS inverse à partir de l'adresse IP
+ du serveur virtuel qui sera utilisé. Si ce nom ne correspond pas
+ à celui que vous voulez utiliser, vous pouvez ajouter une entrée
+ de remplacement (par exemple ServerName
+ none.example.com) pour éviter ce comportement.
Les changements de configuration suggérés pour transformer le premier exemple en hébergement virtuel par IP + conduisent à une configuration peu efficace. Chaque requête + nécessite une nouvelle recherche DNS. Pour éviter cette surcharge de + travail, le système de fichiers peut être organisé pour correspondre + aux adresses IP, plutôt qu'aux noms de serveurs, supprimant par + la-même la nécessité d'une recherche DNS. La journalisation doit + aussi être adaptée pour fonctionner sur un tel système.
+ +# obtention du nom du serveur par recherche DNS inverse +# sur l'adresse IP +UseCanonicalName DNS + +# insertion de l'adresse IP dans les journaux afin de pouvoir les +# éclater +LogFormat "%A %h %l %u %t \"%r\" %s %b" vcommon +CustomLog "logs/access_log" vcommon + +# insertion de l'adresse IP dans les noms de fichiers +VirtualDocumentRootIP "/www/hosts/%0/docs" +VirtualScriptAliasIP "/www/hosts/%0/cgi-bin"+ + +
+L'hébergement virtuel de masse peut aussi être effectué en utilisant
+mod_rewrite, soit à l'aide de simples directives RewriteRule, soit en utilisant des
+techniques plus compliquées comme le stockage externe des définitions
+des serveurs virtuels, ces dernières étant accessibles via des
+directives RewriteMap. Ces
+techniques sont décrites dans la documentation sur la réécriture.
Une autre option pour générer dynamiquement des serveurs virtuels : +mod_macro ; ce module permet de créer un modèle de serveur virtuel que +vous pourrez invoquer pour des noms d'hôtes multiples. La section +Usage de la documentation du module présente un exemple qui +illustre cette méthode. +
+Serveur HTTP Apache Version 2.4
+Ce document décrit quand et comment utiliser des serveurs + virtuels par nom.
+ Serveurs virtuels par nom vs. par IP Comment le serveur sélectionne-t-il le serveur
+virtuel basé sur le nom approprié Utilisation de serveurs virtuels par nomLes serveurs virtuels par IP utilisent l'adresse IP + de la connexion afin de déterminer quel serveur virtuel doit + répondre. Par conséquent, vous devez disposer d'adresses IP + différentes pour chaque serveur.
+ +Avec un hébergement + virtuel par nom, le serveur s'appuie sur les informations + transmises par le client dans les en-têtes HTTP de ses requêtes. + La technique présentée ici vous permet de disposer de serveurs + virtuels différents partagés sur une même adresse IP.
+ +L'hébergement virtuel par nom est habituellement plus simple, + car il vous suffit de configurer votre serveur DNS pour que + chaque domaine pointe sur l'adresse IP dont vous disposez, et de + configurer votre serveur Apache HTTP afin qu'il reconnaisse + ces domaines. Il réduit aussi la pénurie en adresses IP. Par + conséquent, vous devriez utiliser l'hébergement virtuel par + nom, sauf dans le cas où vous utiliseriez des équipements qui + nécessitent un hébergement basé sur IP. Les raisons historiques de + l'hébergement basé sur IP dans un but de support de certains clients ne + s'appliquent plus à un serveur web d'usage général.
+ +La sélection du serveur virtuel en fonction du nom s'opère en + dehors de l'algorithme de sélection du serveur virtuel en fonction + de l'adresse IP, ce qui signifie que les recherches du point de vue + du nom du serveur ne s'effectuent que parmi le jeu de serveurs + virtuels pour lesquels la correspondance avec la paire adresse + IP/port est la plus exacte.
+ +Il est important de savoir que la première étape de la résolution + de serveur virtuel basée sur le nom est une résolution basée sur IP. + La résolution de serveur virtuel basée sur le nom ne fait que + choisir le serveur virtuel basé sur le nom le plus approprié, en se + limitant aux candidats qui conviennent le mieux du point de vue IP. + La résolution basée sur IP est sans objet si l'on + utilise un caractère générique (*) pour l'adresse IP dans + toutes les directives VirtualHost.
+ +A l'arrivée d'une requête, le serveur va rechercher l'argument de
+ section <VirtualHost> présentant la meilleure
+ (la plus exacte) correspondance avec la paire adresse IP/port
+ utilisée dans la requête. Si plusieurs serveurs virtuels possèdent
+ cette même paire adresse IP/port, Apache va ensuite comparer les
+ valeurs des directives ServerName et ServerAlias avec le nom de serveur
+ présent dans la requête.
Si vous ne définissez pas de directive ServerName pour un serveur virtuel à base
+ de nom, le serveur utilisera par défaut le nom de domaine
+ entièrement qualifié (FQDN) déduit du nom d'hôte système. Cette
+ configuration sans nom de serveur explicite peut conduire à des
+ erreurs de choix du serveur virtuel à utiliser et est déconseillée.
Si aucune directive ServerName ou ServerAlias ne correspond dans + la liste de serveurs virtuels présentant la meilleure correspondance + du point de vue adresse IP/port, c'est le premier serveur + virtuel de cette liste qui sera utilisé.
+ + +| Modules Apparentés | Directives Apparentées |
|---|---|
La première étape consiste à créer une section
+ <VirtualHost>
+ pour chacun des serveurs à définir. Dans chaque section
+ <VirtualHost>,
+ vous devez définir au minimum une directive
+ ServerName pour désigner
+ le serveur concerné et une directive
+ DocumentRoot pour préciser
+ l'emplacement sur le système de fichiers du contenu de ce serveur.
Toute requête qui ne correspond à aucune section <VirtualHost> existante
+ est traitée avec la configuration du serveur principal, sans
+ tenir compte du nom d'hôte ou de la directive ServerName.
Lorsque vous ajoutez un serveur virtuel basé sur le nom à un
+ serveur existant, et si les caractéristiques de ce serveur
+ virtuel correspondent à des combinaisons IP/port préexistantes,
+ les requêtes seront alors traitées par un serveur virtuel
+ explicite. Dans ce cas, il est en général judicieux de créer un
+ serveur virtuel par défaut
+ comportant une directive ServerName correspondant au nom du
+ serveur principal. De nouveaux domaines sur les mêmes interface
+ et port, mais nécessitant des configurations distinctes,
+ pourront alors être ajoutés en tant que serveurs virtuels
+ spécifiques (et non par défaut).
Il est toujours préférable de définir une directive ServerName au niveau de chaque serveur
+ virtuel à base de nom. Si un serveur virtuel ne définit pas
+ de directive ServerName, le
+ nom de ce serveur virtuel sera hérité du serveur principal. Si
+ aucun nom de serveur n'a été explicitement défini au niveau du
+ serveur principal, le serveur tentera de déterminer son nom via
+ une résolution de nom DNS inverse sur la première adresse
+ d'écoute. Dans tous les cas, ce nom de serveur hérité influencera
+ la sélection du serveur virtuel à base de nom, c'est pourquoi il
+ est toujours préférable de définir une directive ServerName pour chaque serveur virtuel
+ à base de nom.
Par exemple, supposez que vous hébergez le domaine
+ www.example.com et que vous souhaitez ajouter le
+ serveur virtuel other.example.com qui pointe sur
+ la même adresse IP. Il vous suffit d'ajouter la configuration
+ suivante à httpd.conf :
<VirtualHost *:80> + # Le premier serveur virtuel de la liste est aussi le + # serveur par défaut pour *:80 + ServerName www.example.com + ServerAlias example.com + DocumentRoot "/www/domain" +</VirtualHost> + +<VirtualHost *:80> + ServerName other.example.com + DocumentRoot "/www/otherdomain" +</VirtualHost>+ + +
Autrement, vous pouvez spécifiez une adresse IP explicite
+ à la place de * dans la directive
+ <VirtualHost>.
+ Par exemple, cette méthode est utile si vous souhaitez faire
+ tourner quelques serveurs virtuels par nom sur une même adresse
+ IP, et d'autres, soit par IP, soit basés sur un autre jeu de
+ serveurs virtuels par nom sur une autre adresse IP.
Plusieurs serveurs sont accessibles par plus d'un nom. Il
+ suffit de placer la directive
+ ServerAlias dans une section
+ <VirtualHost>.
+ Par exemple, dans la première section
+ <VirtualHost>
+ ci-dessus, la directive ServerAlias
+ indique aux utilisateurs les autres noms permis pour accéder au
+ même site Web :
ServerAlias example.com *.example.com+ + +
ainsi, toutes les requêtes portant sur un domaine
+ example.com seront servies par le serveur virtuel
+ www.example.com. Les caractères joker *
+ et ? peuvent être utilisés pour les correspondances.
+ Bien entendu, vous ne pouvez pas inventer des noms et les placer
+ dans une directive ServerName
+ ou ServerAlias. Tout d'abord, votre serveur DNS
+ doit être correctement configuré pour lier ces noms à une
+ adresse IP associée avec votre serveur.
La recherche du serveur virtuel à base de nom qui correspond au
+ plus près à la requête s'effectue parmi les <virtualhost> selon leur
+ ordre d'apparition dans le fichier de configuration. Le premier
+ serveur virtuel dont le ServerName ou le ServerAlias correspond est utilisé, sans
+ priorité particulière en cas de présence de caractères génériques
+ (que ce soit pour le ServerName ou le ServerAlias).
La liste complète des noms dans la section VirtualHost sont traités comme une
+ directive ServerAlias sans
+ caractères génériques.
Finalement, vous pouvez affiner la configuration des serveurs
+ virtuels en plaçant d'autres directives à l'intérieur des sections
+ <VirtualHost>.
+ La plupart des directives peut être placée dans ces sections en
+ y changeant seulement la configuration du serveur virtuel associé.
+ Pour déterminer si une directive particulière est permise,
+ consultez le contexte de la
+ directive. Le jeu de directives configurées dans le contexte
+ du serveur principal (en dehors de toutes sections
+ <VirtualHost>)
+ sera utilisé seulement s'il n'y a pas de configuration contraire
+ par un serveur virtuel.