-<?xml version="1.0" encoding="ISO-8859-1" ?>
+<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1673563:1738542 (outdated) -->
+<!-- English Revision: 1738542 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviwed by : Vincent Deffontaines -->
<title>Authentification et autorisation</title>
<summary>
- <p>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.</p>
+ <p>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.</p>
- <p>Pour le contr
ôle d'accès en général, voir le How-To <a
- href="access.html">Contrôle d'accès</a>.</p>
+ <p>Pour le contr
ôle d'accès en général, voir le How-To <a
+ href="access.html">Contrôle d'accès</a>.</p>
</summary>
-<section id="related"><title>Modules et directives concernés</title>
+<section id="related"><title>Modules et directives concernés</title>
-<p>Trois groupes de modules sont concernés par le processus
+<p>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.</p>
</ul>
<p>On peut aussi ajouter <module>mod_authn_core</module> et
- <module>mod_authz_core</module>. Ces modules implémentent des
- directives générales qui opèrent au dessus de tous les modules
+ <module>mod_authz_core</module>. Ces modules implémentent des
+ directives générales qui opèrent au dessus de tous les modules
d'authentification.</p>
<p>Le module <module>mod_authnz_ldap</module> est un fournisseur
d'authentification et d'autorisation. Le module
<module>mod_authz_host</module> 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
- <module>mod_access_compat</module> a été créé à des fins de
- compatibilité ascendante avec mod_access.</p>
+ 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
+ <module>mod_access_compat</module> a été créé à des fins de
+ compatibilité ascendante avec mod_access.</p>
<p>Vous devriez aussi jeter un coup d'oeil au manuel de recettes de <a
- href="access.html">Contrôle d'accès</a>, qui décrit les différentes
- méthodes de contrôle d'accès à votre serveur.</p>
+ href="access.html">Contrôle d'accès</a>, qui décrit les différentes
+ méthodes de contrôle d'accès à votre serveur.</p>
</section>
<section id="introduction"><title>Introduction</title>
<p>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.</p>
+ 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.</p>
- <p>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 à
+ <p>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.</p>
<note><title>Note :</title>
- <p>Si vos données ont un réel besoin de sécurisation, prévoyez
- l'utilisation de <module>mod_ssl</module> en plus de toute méthode
+ <p>Si vos données ont un réel besoin de sécurisation, prévoyez
+ l'utilisation de <module>mod_ssl</module> en plus de toute méthode
d'authentification.</p>
</note>
</section>
-<section id="theprerequisites"><title>Les prérequis</title>
- <p>Les directives décrites dans cet article devront être insérées
+<section id="theprerequisites"><title>Les prérequis</title>
+ <p>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 <directive module="core"
+ général dans une section <directive module="core"
type="section">Directory</directive>), soit au niveau de la
- configuration des répertoires (fichiers <code>.htaccess</code>)</p>
+ configuration des répertoires (fichiers <code>.htaccess</code>)</p>
<p>Si vous envisagez l'utilisation de fichiers
<code>.htaccess</code>, la configuration de votre serveur devra
permettre l'ajout de directives d'authentification dans ces
fichiers. Pour ce faire, on utilise la directive <directive
- module="core">AllowOverride</directive>, qui spécifie quelles
- directives pourront éventuellement contenir les fichiers de
- configuration de niveau répertoire.</p>
+ module="core">AllowOverride</directive>, qui spécifie quelles
+ directives pourront éventuellement contenir les fichiers de
+ configuration de niveau répertoire.</p>
<p>Comme il est ici question d'authentification, vous aurez besoin
d'une directive <directive module="core">AllowOverride</directive>
<p>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.</p>
+ posséder les droits en écriture sur ce fichier.</p>
- <p>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
+ <p>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.</p>
<p>Enfin, vous devrez vous assurer que les modules
<module>mod_authn_core</module> et <module>mod_authz_core</module>
- ont été soit compilés avec le binaire httpd, soit chargés par le
+ 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
+ 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.</p>
</section>
<section id="gettingitworking"><title>Mise en oeuvre</title>
- <p>Nous décrivons ici les bases de la protection par mot de passe
- d'un répertoire de votre serveur.</p>
+ <p>Nous décrivons ici les bases de la protection par mot de passe
+ d'un répertoire de votre serveur.</p>
- <p>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
+ <p>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
+ entrerons dans les détails plus loin, et pour le moment, nous nous
contenterons d'un fichier de mots de passe en mode texte.</p>
- <p>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
+ <p>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
<code>/usr/local/apache/htdocs</code>, vous pouvez enregistrer le
fichier des mots de passe dans
<code>/usr/local/apache/passwd</code>.</p>
<p>L'utilitaire <program>htpasswd</program> fourni avec Apache
- permet de créer ce fichier. Vous le trouverez dans le répertoire
+ permet de créer ce fichier. Vous le trouverez dans le répertoire
<code>bin</code> 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.</p>
+ installé Apache à partir d'un paquetage tiers, il sera probablement
+ dans le chemin par défaut de vos exécutables.</p>
- <p>Pour créer le fichier, tapez :</p>
+ <p>Pour créer le fichier, tapez :</p>
<example>
htpasswd -c /usr/local/apache/passwd/passwords rbowen
</example>
<p>Si <program>htpasswd</program> 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 à <code>/usr/local/apache2/bin/htpasswd</code>.</p>
+ 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 à <code>/usr/local/apache2/bin/htpasswd</code>.</p>
- <p>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
+ <p>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 <code>httpd.conf</code>, soit utiliser un fichier
- <code>.htaccess</code>. Par exemple, si vous voulez protéger le
- répertoire <code>/usr/local/apache/htdocs/secret</code>, vous pouvez
+ <code>.htaccess</code>. Par exemple, si vous voulez protéger le
+ répertoire <code>/usr/local/apache/htdocs/secret</code>, vous pouvez
utiliser les directives suivantes, soit dans le fichier
<code>/usr/local/apache/htdocs/secret/.htaccess</code>, soit dans le
- fichier <code>httpd.conf</code> à l'intérieur d'une section <Directory
+ fichier <code>httpd.conf</code> à l'intérieur d'une section <Directory
"/usr/local/apache/htdocs/secret"> :</p>
<highlight language="config">
Require user rbowen
</highlight>
- <p>Examinons ces directives une à une. La directive <directive
- module="mod_authn_core">AuthType</directive> définit la méthode
- utilisée pour authentifier l'utilisateur. La méthode la plus
- courante est <code>Basic</code>, et elle est implémentée par
- <module>mod_auth_basic</module>. Il faut cependant garder à l'esprit
+ <p>Examinons ces directives une à une. La directive <directive
+ module="mod_authn_core">AuthType</directive> définit la méthode
+ utilisée pour authentifier l'utilisateur. La méthode la plus
+ courante est <code>Basic</code>, et elle est implémentée par
+ <module>mod_auth_basic</module>. 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 <module>mod_ssl</module>. Apache
- supporte une autre méthode d'authentification : <code>AuthType
- Digest</code>. Cette méthode est implémentée par le module <module
- >mod_auth_digest</module> 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
+ 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 <module>mod_ssl</module>. Apache
+ supporte une autre méthode d'authentification : <code>AuthType
+ Digest</code>. Cette méthode est implémentée par le module <module
+ >mod_auth_digest</module> 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 <module>mod_ssl</module>.</p>
<p>La directive <directive
- module="mod_authn_core">AuthName</directive> définit
- l'<dfn>Identificateur</dfn> (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.</p>
-
- <p>Ainsi par exemple, une fois un client authentifié dans la zone
- <code>"Fichiers réservés"</code>, il soumettra à nouveau
- automatiquement le même mot de passe pour toute zone du même serveur
- marquée de l'identificateur <code>"Fichiers réservés"</code>. 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é.</p>
+ module="mod_authn_core">AuthName</directive> définit
+ l'<dfn>Identificateur</dfn> (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.</p>
+
+ <p>Ainsi par exemple, une fois un client authentifié dans la zone
+ <code>"Fichiers réservés"</code>, il soumettra à nouveau
+ automatiquement le même mot de passe pour toute zone du même serveur
+ marquée de l'identificateur <code>"Fichiers réservés"</code>. 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é.</p>
<p>La directive <directive
module="mod_auth_basic">AuthBasicProvider</directive> est, dans ce
- cas, facultative, car <code>file</code> est la valeur par défaut
+ cas, facultative, car <code>file</code> est la valeur par défaut
pour cette directive. Par contre, cette directive sera obligatoire
si vous utilisez une autre source d'authentification comme
<module>mod_authn_dbm</module> ou
<module>mod_authn_dbd</module>.</p>
<p>La directive <directive
- module="mod_authn_file">AuthUserFile</directive> définit le chemin
- du fichier de mots de passe que nous venons de créer avec
- <program>htpasswd</program>. 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
+ module="mod_authn_file">AuthUserFile</directive> définit le chemin
+ du fichier de mots de passe que nous venons de créer avec
+ <program>htpasswd</program>. 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
<module>mod_authn_dbm</module> fournit la directive <directive
module="mod_authn_dbm">AuthDBMUserFile</directive>. Les programmes <program>
dbmmanage</program> et <program>htdbm</program> permettent de
- créer et manipuler ces fichiers. Vous
+ créer et manipuler ces fichiers. Vous
trouverez de nombreuses options d'autres types d'authentification
fournies par des modules tiers dans la <a
- href="http://modules.apache.org/">Base de données des modules
+ href="http://modules.apache.org/">Base de données des modules
d'Apache</a>.</p>
<p>Enfin, la directive <directive
- module="mod_authz_core">Require</directive> 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
+ module="mod_authz_core">Require</directive> 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
<directive module="mod_authz_core">Require</directive>.</p>
</section>
-<section id="lettingmorethanonepersonin"><title>Autorisation d'accès à
+<section id="lettingmorethanonepersonin"><title>Autorisation d'accès à
plusieurs personnes</title>
<p>Les directives ci-dessus n'autorisent qu'une personne (quelqu'un
- possédant le nom d'utilisateur <code>rbowen</code>) à accéder au
- répertoire. Dans la plupart des cas, vous devrez autoriser
- l'accès à plusieurs personnes. C'est ici
+ possédant le nom d'utilisateur <code>rbowen</code>) à 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 <directive module="mod_authz_groupfile"
>AuthGroupFile</directive>.</p>
- <p>Si vous voulez autoriser l'accès à plusieurs personnes, vous
- devez créer un fichier de groupes qui associe des noms de groupes
+ <p>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 :</p>
+ est très simple, et vous pouvez le créer avec votre éditeur favori.
+ Son contenu se présente comme suit :</p>
<example>
Nom-de-groupe: rbowen dpitts sungo rshersey
</example>
<p>Il s'agit simplement une liste des membres du groupe sous la
- forme d'une ligne séparée par des espaces.</p>
+ forme d'une ligne séparée par des espaces.</p>
- <p>Pour ajouter un utilisateur à votre fichier de mots de passe
- préexistant, entrez :</p>
+ <p>Pour ajouter un utilisateur à votre fichier de mots de passe
+ préexistant, entrez :</p>
<example>
htpasswd /usr/local/apache/passwd/passwords dpitts
</example>
- <p>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 <code>-c</code> qui permet de créer un nouveau fichier de
+ <p>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 <code>-c</code> qui permet de créer un nouveau fichier de
mots de passe)..</p>
<p>Maintenant, vous devez modifier votre fichier
</highlight>
<p>Maintenant, quiconque appartient au groupe
- <code>Nom-de-groupe</code>, et possède une entrée dans le fichier
- <code>password</code> pourra accéder au répertoire s'il tape le bon
+ <code>Nom-de-groupe</code>, et possède une entrée dans le fichier
+ <code>password</code> pourra accéder au répertoire s'il tape le bon
mot de passe.</p>
- <p>Il existe une autre méthode moins contraignante pour autoriser
- l'accès à plusieurs personnes. Plutôt que de créer un fichier de
+ <p>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 :</p>
<highlight language="config">Require valid-user</highlight>
<p>Le remplacement de la ligne <code>Require user rbowen</code> par
- la ligne <code>Require valid-user</code> autorisera l'accès à
- quiconque possédant une entrée dans le fichier password, et ayant
- tapé le bon mot de passe.</p>
+ la ligne <code>Require valid-user</code> autorisera l'accès à
+ quiconque possédant une entrée dans le fichier password, et ayant
+ tapé le bon mot de passe.</p>
</section>
-<section id="possibleproblems"><title>Problèmes possibles</title>
- <p>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
+<section id="possibleproblems"><title>Problèmes possibles</title>
+ <p>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.</p>
+ 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.</p>
- <p>En conséquence, ce ralentissement impose une limite pratique au
+ <p>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
+ 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.</p>
+ d'utilisateurs, et serez alors appelés à utiliser une méthode
+ d'authentification différente.</p>
</section>
-<section id="dbmdbd"><title>Autre méthode de stockage des mots de
+<section id="dbmdbd"><title>Autre méthode de stockage des mots de
passe</title>
- <p>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.</p>
+ <p>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.</p>
<p>Pour y parvenir, on peut utiliser les modules
<module>mod_authn_dbm</module> ou <module>mod_authn_dbd</module>.
Vous pouvez choisir comme format de stockage <code>dbm</code> ou
- <code>dbd</code> à la place de <code>file</code> pour la directive
+ <code>dbd</code> à la place de <code>file</code> pour la directive
<directive module="mod_auth_basic">AuthBasicProvider</directive>.</p>
- <p>Par exemple, pour sélectionner un fichier dbm à la place d'un
+ <p>Par exemple, pour sélectionner un fichier dbm à la place d'un
fichier texte :</p>
<highlight language="config">
</highlight>
<p>D'autres options sont disponibles. Consultez la documentation de
- <module>mod_authn_dbm</module> pour plus de détails.</p>
+ <module>mod_authn_dbm</module> pour plus de détails.</p>
</section>
<section id="multprovider"><title>Utilisation de plusieurs fournisseurs
d'authentification</title>
- <p>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
+ <p>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
+ 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 :</p>
<p>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
+ 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.</p>
+ basée sur un fichier de mots de passe peut permettre l'attribution
+ d'autorisations basée sur un annuaire LDAP.</p>
- <p>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
+ <p>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.</p>
<highlight language="config">
</Directory>
</highlight>
- <p>Pour un scénario d'autorisation un peu plus avancé, des
+ <p>Pour un scénario d'autorisation un peu plus avancé, des
directives de conteneur d'autorisation comme <directive
module="mod_authz_core" type="section">RequireAll</directive> et
<directive module="mod_authz_core"
type="section">RequireAny</directive> 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
+ appliquées peut être entièrement contrôlé au niveau de la
configuration. Voir <a
href="../mod/mod_authz_core.html#logic">Conteneurs
- d'autorisations</a> pour un exemple de ce contrôle.</p>
+ d'autorisations</a> pour un exemple de ce contrôle.</p>
</section>
<section id="beyond"><title>Pour aller plus loin qu'une simple
autorisation</title>
- <p>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.</p>
+ <p>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.</p>
<section id="authandororder"><title>Appliquer logique et
ordonnancement</title>
- <p>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
+ <p>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
- <directive module="mod_authz_core">Require</directive> 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
+ <directive module="mod_authz_core">Require</directive> 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 <directive
module="mod_authz_core">Require</directive> apparaissent dans la
configuration.</p>
type="section">RequireAll</directive>
et <directive module="mod_authz_core"
type="section">RequireAny</directive>, 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 <a
+ 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 <a
href="../mod/mod_authz_core.html#logic">Conteneurs
- d'autorisations</a> pour un exemple de la manière de les
+ d'autorisations</a> pour un exemple de la manière de les
utiliser pour exprimer des logiques d'autorisation
complexes.</p>
- <p>Par défaut, toutes les directives <directive
+ <p>Par défaut, toutes les directives <directive
module="mod_authz_core">Require</directive> sont
- traitées comme si elles étaient contenues dans une directive
+ traitées comme si elles étaient contenues dans une directive
<directive module="mod_authz_core"
type="section">RequireAny</directive>. En d'autres termes, il
suffit
- qu'une méthode d'autorisation s'applique avec succès pour que
- l'autorisation soit accordée.</p>
+ qu'une méthode d'autorisation s'applique avec succès pour que
+ l'autorisation soit accordée.</p>
</section>
<section id="reqaccessctrl"><title>Utilisation de fournisseurs
- d'autorisation pour le contrôle d'accès</title>
- <p>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
+ d'autorisation pour le contrôle d'accès</title>
+ <p>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.</p>
<p>Les fournisseurs d'autorisation <code>all</code>,
<code>env</code>, <code>host</code> et <code>ip</code> 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.</p>
+ 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.</p>
- <p>L'utilisation de ces fournisseurs est spécifiée à l'aide de
+ <p>L'utilisation de ces fournisseurs est spécifiée à l'aide de
la directive <directive
module="mod_authz_core">Require</directive>. 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 :</p>
+ seront appelés dans le processus d'autorisation au cours du
+ traitement de la requête. Par exemple :</p>
<highlight language="config">Require ip <var>address</var></highlight>
- <p>où <var>adresse</var> est une adresse IP (ou une adresse IP
+ <p>où <var>adresse</var> est une adresse IP (ou une adresse IP
partielle) ou :</p>
<highlight language="config">Require host <var>domain_name</var></highlight>
- <p>où <var>nom_domaine</var> 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.</p>
+ <p>où <var>nom_domaine</var> 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.</p>
<p>Par exemple, si vous voulez rejeter les spams dont une
machine vous inonde, vous pouvez utiliser ceci :</p>
</highlight>
<p>Ainsi, les visiteurs en provenance de cette adresse ne
- pourront pas voir le contenu concerné par cette directive. Si,
+ pourront pas voir le contenu concerné par cette directive. Si,
par contre, vous connaissez le nom de la machine, vous pouvez
utiliser ceci :</p>
</RequireAll>
</highlight>
- <p>Et si vous voulez interdire l'accès à toutes les machines
- d'un domaine, vous pouvez spécifier une partie seulement de
+ <p>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 :</p>
<highlight language="config">
<p>L'utilisation de la directive <directive
module="mod_authz_core" type="section">RequireAll</directive>
avec de multiples directives <directive module="mod_authz_core"
- type="section">Require</directive>, toutes avec la négation
- <code>not</code>, 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.</p>
+ type="section">Require</directive>, toutes avec la négation
+ <code>not</code>, 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.</p>
</section>
- <section id="filesystem"><title>Compatibilité ascendante du contrôle
- d'accès</title>
- <p>L'adoption d'un mécanisme à base de fournisseurs pour
- l'authentification, a pour effet colatéral de rendre inutiles
+ <section id="filesystem"><title>Compatibilité ascendante du contrôle
+ d'accès</title>
+ <p>L'adoption d'un mécanisme à base de fournisseurs pour
+ l'authentification, a pour effet colatéral de rendre inutiles
les directives <directive
module="mod_access_compat">Order</directive>, <directive
module="mod_access_compat">Allow</directive>, <directive
module="mod_access_compat">Deny</directive> et <directive
- module="mod_access_compat">Satisfy</directive>. Cependant, et à
- des fins de compatibilité ascendante vers les anciennes
- configurations, ces directives ont été déplacées vers le module
+ module="mod_access_compat">Satisfy</directive>. Cependant, et à
+ des fins de compatibilité ascendante vers les anciennes
+ configurations, ces directives ont été déplacées vers le module
<module>mod_access_compat</module>.</p>
+ <note type="warning"><title>Note</title>
+ <p>Les directives fournies par le module
+ <module>mod_access_compat</module> sont devenues obsolètes depuis
+ la refonte du module <module>mod_authz_host</module>. Mélanger d'anciennes
+ directives comme <directive
+ module="mod_access_compat">Order</directive>, <directive
+ module="mod_access_compat">Allow</directive> ou <directive
+ module="mod_access_compat">Deny</directive> avec des nouvelles comme
+ <directive module="mod_authz_core">Require</directive> est techniquement
+ possible mais déconseillé. En effet, <module>mod_access_compat</module> 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
+ <a href="../upgrading.html">upgrading</a> pour plus de détails.
+ </p>
+ </note>
</section>
</section>
<section id="socache"><title>Mise en cache de l'authentification</title>
<p>Dans certains cas, l'authentification constitue une charge
- inacceptable pour un fournisseur d'authentification ou votre réseau.
+ inacceptable pour un fournisseur d'authentification ou votre réseau.
Ceci est susceptible d'affecter les utilisateurs du module
<module>mod_authn_dbd</module> (ou les fournisseurs
- tiers/personnalisés). Pour résoudre ce problème, HTTPD 2.3/2.4
+ tiers/personnalisés). Pour résoudre ce problème, HTTPD 2.3/2.4
propose un nouveau fournisseur de mise en cache,
<module>mod_authn_socache</module>, qui permet de mettre en cache
- les données d'authentification, et ainsi réduire la charge du/des
+ les données d'authentification, et ainsi réduire la charge du/des
fournisseurs(s) originels.</p>
<p>Cette mise en cache apportera un gain en performance substantiel
- à certains utilisateurs.</p>
+ à certains utilisateurs.</p>
</section>
<section id="moreinformation"><title>Pour aller plus loin . . .</title>
<p>Vous pouvez aussi lire la documentation de
<module>mod_auth_basic</module> et <module>mod_authz_host</module>
- qui contient des informations supplémentaires à propos du
+ 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 <directive
+ Certaines configurations d'authentification peuvent aussi être
+ simplifiées à l'aide de la directive <directive
type="section"
module="mod_authn_core">AuthnProviderAlias</directive>.</p>
- <p>Les différents algorithmes de chiffrement supportés par Apache
- pour authentifier les donn
ées sont expliqués dans <a
+ <p>Les différents algorithmes de chiffrement supportés par Apache
+ pour authentifier les donn
ées sont expliqués dans <a
href="../misc/password_encryptions.html">PasswordEncryptions</a>.</p>
- <p>Enfin vous pouvez consulter la recette <a href="access.html">Contrôle
- d'accès</a>, qui décrit un certain nombre de situations en relation
+ <p>Enfin vous pouvez consulter la recette <a href="access.html">Contrôle
+ d'accès</a>, qui décrit un certain nombre de situations en relation
avec le sujet.</p>
</section>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
-<!-- English Revision: 1732097:1738639 (outdated) -->
+<!-- English Revision: 1738639 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
</dd>
</dl>
+ <dl>
+ <dt>HTTP/2 avec httpd</dt>
+ <dd>
+ <p>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.
+ </p>
+
+ <p>Voir le <a href="http2.html">guide HTTP/2</a></p>
+ </dd>
+ </dl>
+
<dl>
<dt>Introduction au Inclusions côté Serveur (Server Side Includes
ou SSI)</dt>
-<?xml version="1.0" encoding="ISO-8859-1" ?>
+<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 1657858:1739105 (outdated) -->
+<!-- English Revision: 1739105 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<title>Fichiers journaux</title>
<summary>
- <p>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.</p>
+ <p>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.</p>
</summary>
<section id="overview">
</related>
<p>
- 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
+ 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
+ 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.
</p>
<p>
- Ce document décrit le fonctionnement des modules de journalisation
+ Ce document décrit le fonctionnement des modules de journalisation
fournis en standard avec le serveur httpd.
</p>
</section>
<section id="security">
- <title>Avertissement à propos de la sécurité</title>
+ <title>Avertissement à propos de la sécurité</title>
- <p>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
+ <p>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 <em>PAS</em> 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 <a href="misc/security_tips.html">conseils sur la sécurité</a>
- pour plus de détails.</p>
+ 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 <a href="misc/security_tips.html">conseils sur la sécurité</a>
+ pour plus de détails.</p>
<p>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
+ 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.</p>
</section>
</related>
<p>Le journal des erreurs du serveur, dont le nom et la localisation sont
- définis par la directive <directive module="core">ErrorLog</directive>,
+ définis par la directive <directive module="core">ErrorLog</directive>,
est le journal le plus important. C'est dans celui-ci
- que le démon Apache httpd va envoyer les informations de diagnostic et
+ 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.</p>
-
- <p>Le journal des erreurs est habituellement enregistré dans un fichier
- (en général <code>error_log</code> sur les systèmes de type Unix et
- <code>error.log</code> sur Windows et OS/2). Sur les systèmes de type Unix,
+ 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.</p>
+
+ <p>Le journal des erreurs est habituellement enregistré dans un fichier
+ (en général <code>error_log</code> sur les systèmes de type Unix et
+ <code>error.log</code> sur Windows et OS/2). Sur les systèmes de type Unix,
le serveur peut aussi enregistrer ses erreurs dans
<code>syslog</code> ou les
- <a href="#piped">rediriger vers un programme</a> par l'intermédiaire d'un
+ <a href="#piped">rediriger vers un programme</a> par l'intermédiaire d'un
tube de communication (pipe).</p>
- <p>Le format par défaut du journal des erreurs est descriptif et de forme
+ <p>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 : </p>
+ plupart des entrées du journal. Voici un message typique
+ à titre d'exemple : </p>
<example>
[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
/export/home/live/ap/htdocs/test
</example>
- <p>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
+ <p>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 <directive module="core">LogLevel</directive> 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.
+ 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
+ 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).</p>
- <p>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
+ <p>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 <code>stderr</code> sera recopiée
+ débogage en provenance de scripts CGI. Toute information qu'un script CGI
+ écrit sur la sortie d'erreurs standard <code>stderr</code> sera recopiée
telle quelle dans le journal des erreurs.</p>
<p>La directive <directive module="core">ErrorLogFormat</directive>
vous permet de personnaliser le format du journal des erreurs, et de
- définir les informations à journaliser. Si
- <module>mod_unique_id</module> est présent, vous pouvez utiliser le
- drapeau <code>%L</code> à la fois dans le journal des erreurs et
+ définir les informations à journaliser. Si
+ <module>mod_unique_id</module> est présent, vous pouvez utiliser le
+ drapeau <code>%L</code> à 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.</p>
+ 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.</p>
<p>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 :</p>
+ 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 :</p>
<example>
tail -f error_log
<title>Journalisation par module</title>
<p>La directive <directive module="core">LogLevel</directive> 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
+ 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
+ pour les autres modules. Ceci est particulièrement utile lorsque
+ vous voulez obtenir des détails sur le fonctionnement de modules
comme <module>mod_proxy</module> ou <module>mod_rewrite</module>.</p>
- <p>Pour ce faire, vous devez spécifier le nom du module dans votre
+ <p>Pour ce faire, vous devez spécifier le nom du module dans votre
directive <directive>LogLevel</directive> :</p>
<highlight language="config">
LogLevel info rewrite:trace5
</highlight>
- <p>Dans cet exemple, le niveau de journalisation général est défini
- à info, et à <code>trace5</code> pour <module>mod_rewrite</module>.</p>
+ <p>Dans cet exemple, le niveau de journalisation général est défini
+ à info, et à <code>trace5</code> pour <module>mod_rewrite</module>.</p>
<note>Cette directive remplace les directives de journalisation par
- module des versions précédentes du serveur, comme
+ module des versions précédentes du serveur, comme
<code>RewriteLog</code>.</note>
</section>
<section id="accesslog">
- <title>Journal des accès</title>
+ <title>Journal des accès</title>
<related>
<modulelist>
</directivelist>
</related>
- <p>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
+ <p>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 <directive module="mod_log_config">CustomLog</directive>.
La directive <directive module="mod_log_config">LogFormat</directive>
- 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.</p>
-
- <p>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 à <a href="http://dmoz.org/Computers/Software/Internet/
+ 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.</p>
+
+ <p>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 à <a href="http://dmoz.org/Computers/Software/Internet/
Site_Management/Log_Analysis/">Open Directory</a>.</p>
- <p>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
+ <p>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
<code>TransferLog</code>. La directive
<directive module="mod_log_config">CustomLog</directive> rassemble
- désormais les fonctionnalités de toutes les anciennes directives.</p>
+ désormais les fonctionnalités de toutes les anciennes directives.</p>
- <p>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
+ <p>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
- <a href="mod/mod_log_config.html#formats">chaînes de format</a> de la
+ peut contenir une chaîne de format, vous pouvez vous référer au chapitre
+ <a href="mod/mod_log_config.html#formats">chaînes de format</a> de la
documentation du module <module>mod_log_config</module>.</p>
<section id="common">
<title>Format habituel du journal</title>
- <p>Voici une configuration typique pour le journal des accès :</p>
+ <p>Voici une configuration typique pour le journal des accès :</p>
<highlight language="config">
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
</highlight>
- <p>Ici est définie l'<em>identité</em> <code>common</code> 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 (<code>"</code>) doivent être échappées en les faisant
- précéder d'un anti-slash (<code>\</code>) 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
- "<code>\n</code>" et "<code>\t</code>" pour insérer respectivement
- un passage à la ligne et une tabulation.</p>
+ <p>Ici est définie l'<em>identité</em> <code>common</code> 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 (<code>"</code>) doivent être échappées en les faisant
+ précéder d'un anti-slash (<code>\</code>) 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
+ "<code>\n</code>" et "<code>\t</code>" pour insérer respectivement
+ un passage à la ligne et une tabulation.</p>
<p>La directive <directive module="mod_log_config">CustomLog</directive>
- 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
+ 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
<directive module="core">ServerRoot</directive>, sauf s'il
- débute par un slash.</p>
+ débute par un slash.</p>
- <p>La configuration ci-dessus va enregistrer les entrées de
+ <p>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 :</p>
+ 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 :</p>
<example>
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
/apache_pb.gif HTTP/1.0" 200 2326
</example>
- <p>Chaque partie de cette entrée de journal est décrite
+ <p>Chaque partie de cette entrée de journal est décrite
dans ce qui suit.</p>
<dl>
<dt><code>127.0.0.1</code> (<code>%h</code>)</dt>
- <dd>Il s'agit de l'adresse IP du client (l'hôte distant) qui a envoyé
- la requête au serveur. Si la directive
- <directive module="core">HostnameLookups</directive> est positionnée à
- <code>On</code>, 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
+ <dd>Il s'agit de l'adresse IP du client (l'hôte distant) qui a envoyé
+ la requête au serveur. Si la directive
+ <directive module="core">HostnameLookups</directive> est positionnée à
+ <code>On</code>, 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 <program>logresolve</program>
- 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
+ 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.</dd>
+ et l'utilisateur, l'adresse indiquée sera celle du mandataire et non
+ celle de la machine à l'origine de la requête.</dd>
<dt><code>-</code> (<code>%l</code>)</dt>
<dd>Le "trait d'union" indique que la portion d'information
- correspondante n'est pas disponible. Dans le cas présent, l'information
- non disponible est l'identité (RFC 1413) du client telle que déterminée
+ correspondante n'est pas disponible. Dans le cas présent, l'information
+ non disponible est l'identité (RFC 1413) du client telle que déterminée
par <code>identd</code> 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
- <directive module="mod_ident">IdentityCheck</directive> est positionnée
- à <code>On</code>.</dd>
+ 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
+ <directive module="mod_ident">IdentityCheck</directive> est positionnée
+ à <code>On</code>.</dd>
<dt><code>frank</code> (<code>%u</code>)</dt>
<dd>Il s'agit de l'identifiant utilisateur de la personne qui a
- demandé le document, issu d'une authentification HTTP.
- Ce même identifiant est en général fourni aux scripts CGI par
- l'intermédiaire de la valeur de la variable d'environnement
- <code>REMOTE_USER</code>. Si le statut de la requête (voir plus loin)
+ demandé le document, issu d'une authentification HTTP.
+ Ce même identifiant est en général fourni aux scripts CGI par
+ l'intermédiaire de la valeur de la variable d'environnement
+ <code>REMOTE_USER</code>. 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
- "<code>-</code>", comme la partie précédente.</dd>
+ pas encore authentifié. Si le document n'est pas protégé par
+ mot de passe, cette partie d'information sera représentée par
+ "<code>-</code>", comme la partie précédente.</dd>
<dt><code>[10/Oct/2000:13:55:36 -0700]</code>
(<code>%t</code>)</dt>
<dd>
- L'heure à laquelle la requête a été reçue.
+ L'heure à laquelle la requête a été reçue.
Le format est le suivant :
<p class="indent">
- <code>[jour/mois/année:heure:minutes:secondes zone]<br />
+ <code>[jour/mois/année:heure:minutes:secondes zone]<br />
jour = 2*chiffre<br />
mois = 3*lettre<br />
- année = 4*chiffre<br />
+ année = 4*chiffre<br />
heure = 2*chiffre<br />
minutes = 2*chiffre<br />
secondes = 2*chiffre<br />
zone = (`+' | `-') 4*chiffre</code>
</p>Il est possible de modifier le format d'affichage de l'heure
- en spécifiant <code>%{format}t</code> dans la chaîne de format du
- journal, où <code>format</code> est une chaîne de format
+ en spécifiant <code>%{format}t</code> dans la chaîne de format du
+ journal, où <code>format</code> est une chaîne de format
de la forme de celle de la fonction <code>strftime(3)</code>
- de la bibliothèque C standard, ou choisie parmi les
- formats spéciaux supportés. Pour plus de détails,
+ de la bibliothèque C standard, ou choisie parmi les
+ formats spéciaux supportés. Pour plus de détails,
reportez-vous aux. <a
- href="mod/mod_log_config.html#formats">chaînes de format</a>
+ href="mod/mod_log_config.html#formats">chaînes de format</a>
de <module>mod_log_config</module>.
</dd>
<dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
(<code>\"%r\"</code>)</dt>
- <dd>La ligne de la requête du client est placée entre guillemets.
+ <dd>La ligne de la requête du client est placée entre guillemets.
Elle contient de nombreuses informations utiles. Tout d'abord, la
- méthode utilisée par le client est <code>GET</code>. Ensuite, le
- client a demandé la ressource <code>/apache_pb.gif</code>, et enfin,
- le client a utilisé le protocole <code>HTTP/1.0</code>. Il est aussi
- possible d'enregistrer séparément une ou plusieurs parties de la
- requête. Par exemple, la chaîne de format "<code>%m %U %q %H</code>"
- 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
+ méthode utilisée par le client est <code>GET</code>. Ensuite, le
+ client a demandé la ressource <code>/apache_pb.gif</code>, et enfin,
+ le client a utilisé le protocole <code>HTTP/1.0</code>. Il est aussi
+ possible d'enregistrer séparément une ou plusieurs parties de la
+ requête. Par exemple, la chaîne de format "<code>%m %U %q %H</code>"
+ 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
"<code>%r</code>".</dd>
<dt><code>200</code> (<code>%>s</code>)</dt>
<dd>C'est le code de statut que le serveur retourne au client. Cette
- information est très importante car elle indique si la requête a fait
- l'objet d'une réponse positive (codes commençant par 2), une
- redirection (codes commençant par 3), une erreur due au client (codes
- commençant par 4), ou une erreur due au serveur (codes commençant
- par 5). Vous trouverez la liste complète des codes de statut possibles
+ information est très importante car elle indique si la requête a fait
+ l'objet d'une réponse positive (codes commençant par 2), une
+ redirection (codes commençant par 3), une erreur due au client (codes
+ commençant par 4), ou une erreur due au serveur (codes commençant
+ par 5). Vous trouverez la liste complète des codes de statut possibles
dans la <a href="http://www.w3.org/Protocols/rfc2616/
rfc2616.txt">specification HTTP</a> (RFC2616 section 10).</dd>
<dt><code>2326</code> (<code>%b</code>)</dt>
- <dd>La dernière partie indique la taille de l'objet retourné au client,
- en-têtes non compris. Si aucun contenu n'a été retourné au client, cette
+ <dd>La dernière partie indique la taille de l'objet retourné au client,
+ en-têtes non compris. Si aucun contenu n'a été retourné au client, cette
partie contiendra "<code>-</code>". Pour indiquer l'absence de contenu
par "<code>0</code>", utilisez <code>%B</code> au lieu de
<code>%b</code>.</dd>
</section>
<section id="combined">
- <title>Combined Log Format (Format de journalisation combiné)</title>
+ <title>Combined Log Format (Format de journalisation combiné)</title>
- <p>Une autre chaîne de format couramment utilisée est le
- "Combined Log Format" (Format de journalisation combiné). Il s'utilise
+ <p>Une autre chaîne de format couramment utilisée est le
+ "Combined Log Format" (Format de journalisation combiné). Il s'utilise
comme suit :</p>
<highlight language="config">
</highlight>
<p>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 "%" <code>%{<em>header</em>}i</code>,
- où <em>header</em> 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 :</p>
+ supplémentaires. Chacun de ces deux champs utilise la directive
+ commençant par le caractère "%" <code>%{<em>header</em>}i</code>,
+ où <em>header</em> 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 :</p>
<example>
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
(Win98; I ;Nav)"
</example>
- <p>Les champs supplémentaires sont :</p>
+ <p>Les champs supplémentaires sont :</p>
<dl>
<dt><code>"http://www.example.com/start.html"</code>
(<code>\"%{Referer}i\"</code>)</dt>
- <dd>L'en-tête "Referer" (sic) de la requête HTTP. Il indique le site
- depuis lequel le client prétend avoir lancé sa requête. (Ce doit être
+ <dd>L'en-tête "Referer" (sic) de la requête HTTP. Il indique le site
+ depuis lequel le client prétend avoir lancé sa requête. (Ce doit être
la page qui contient un lien vers <code>/apache_pb.gif</code> ou
inclut ce dernier fichier).</dd>
<dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
(<code>\"%{User-agent}i\"</code>)</dt>
- <dd>L'en-tête User-Agent de la requête HTTP. C'est une information
- d'identification que le navigateur du client envoie à propos
- de lui-même.</dd>
+ <dd>L'en-tête User-Agent de la requête HTTP. C'est une information
+ d'identification que le navigateur du client envoie à propos
+ de lui-même.</dd>
</dl>
</section>
<section id="multiple">
- <title>Journaux d'accès multiples</title>
+ <title>Journaux d'accès multiples</title>
- <p>Plusieurs journaux d'accès peuvent être créés en spécifiant tout
+ <p>Plusieurs journaux d'accès peuvent être créés en spécifiant tout
simplement plusieurs directives
<directive module="mod_log_config">CustomLog</directive> 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
+ 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
<directive module="mod_log_config">CustomLog</directive> montrent
comment simuler les effets des directives <code>ReferLog</code> et
<code>AgentLog</code>.</p>
</highlight>
<p>Cet exemple montre aussi qu'il n'est pas obligatoire d'associer
- une chaîne de format à un alias au moyen de la directive
+ une chaîne de format à un alias au moyen de la directive
<directive module="mod_log_config">LogFormat</directive>. Elle peut
- être définie directement dans la ligne de la directive
+ être définie directement dans la ligne de la directive
<directive module="mod_log_config">CustomLog</directive>.</p>
</section>
<section id="conditional">
<title>Journalisation conditionnelle</title>
- <p>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
+ <p>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
<a href="env.html">variables d'environnement</a>. 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
+ 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 <directive module="mod_setenvif">SetEnvIf</directive>,
puis la clause <code>env=</code> de la directive
<directive module="mod_log_config">CustomLog</directive> pour inclure
- ou exclure les requêtes pour lesquelles
- la variable d'environnement est définie.
+ ou exclure les requêtes pour lesquelles
+ la variable d'environnement est définie.
Quelques exemples :</p>
<highlight language="config">
-# Marque les requêtes en provenance de l'interface loop-back
+# 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
+# Marque les requêtes pour le fichier robots.txt
SetEnvIf Request_URI "^/robots\.txt$" dontlog
-# Journalise toutes les autres requêtes
+# Journalise toutes les autres requêtes
CustomLog logs/access_log common env=!dontlog
</highlight>
- <p>Autre exemple, imaginons l'enregistrement des requêtes en provenance
+ <p>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.</p>
CustomLog logs/non_english_log common env=!english
</highlight>
- <p>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 :</p>
+ <p>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 :</p>
<highlight language="config">
SetEnv CACHE_MISS 1
CustomLog logs/access_log common-cache
</highlight>
- <p><module>mod_cache</module> va s'exécuter avant
- <module>mod_env</module>, 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
+ <p><module>mod_cache</module> va s'exécuter avant
+ <module>mod_env</module>, 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
<code>-</code>, tandis que dans le cas contraire elle sera
<code>1</code>.</p>
<p>En plus de la syntaxe <code>env=</code>, la directive <directive
module="mod_log_config">LogFormat</directive> supporte les
- valeurs de journalisation conditionnelles basées sur le code de la
- réponse HTTP :</p>
+ valeurs de journalisation conditionnelles basées sur le code de la
+ réponse HTTP :</p>
<highlight language="config">
LogFormat "%400,501{User-agent}i" browserlog
</highlight>
<p>Dans le premier exemple, le <code>User-agent</code> 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 <code>Referer</code> sera enregistré si
- le code d'état HTTP n'est <strong>pas</strong> 200, 204, ou 302
- (remarquez le caractère "!" avant les codes d'état).</p>
+ 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 <code>Referer</code> sera enregistré si
+ le code d'état HTTP n'est <strong>pas</strong> 200, 204, ou 302
+ (remarquez le caractère "!" avant les codes d'état).</p>
<p>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
+ 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.</p>
+ 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.</p>
</section>
</section>
<section id="rotation">
<title>Rotation des journaux</title>
- <p>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
+ <p>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
+ 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
- <a href="stopping.html">redémarré</a> après le déplacement ou la
- suppression des fichiers journaux de façon à ce qu'il en ouvre
+ C'est pourquoi le serveur doit être
+ <a href="stopping.html">redémarré</a> après le déplacement ou la
+ suppression des fichiers journaux de façon à ce qu'il en ouvre
de nouveaux.</p>
- <p>Avec un redémarrage <em>graceful</em>, on peut faire en sorte que le
+ <p>Avec un redémarrage <em>graceful</em>, 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
+ 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
+ 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 :</p>
gzip access_log.old error_log.old
</example>
- <p>La section suivante présente une autre méthode de rotation des journaux
- qui consiste à utiliser les
- <a href="#piped">journaux redirigés</a>.</p>
+ <p>La section suivante présente une autre méthode de rotation des journaux
+ qui consiste à utiliser les
+ <a href="#piped">journaux redirigés</a>.</p>
</section>
<section id="piped">
- <title>Journaux redirigés</title>
+ <title>Journaux redirigés</title>
- <p>Nous avons vu que le démon httpd écrivait les informations de
- journalisation des erreurs et des accès dans un fichier journal ;
+ <p>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
+ 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 "<code>|</code>", suivi du nom de l'exécutable qui va
- recueillir les entrées de journal sur son entrée
+ le caractère pipe "<code>|</code>", 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
+ 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é.)</p>
-
- <p>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.</p>
-
- <p>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
é <program>rotatelogs</program>. Par exemple, pour une rotation des
+ pendant l'exécution du serveur.
+ (Nous dénommons cette technique "journalisation
+ redirigée fiable" grâce à cette dernière fonctionnalité.)</p>
+
+ <p>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.</p>
+
+ <p>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
é <program>rotatelogs</program>. Par exemple, pour une rotation des
journaux toutes les 24 heures, ajoutez ces lignes :</p>
<highlight language="config">
CustomLog "|/usr/local/apache/bin/rotatelogs /var/log/access_log 86400" common
</highlight>
- <p>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
+ <p>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.</p>
- <p>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.</p>
+ <p>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.</p>
- <p>Par défaut, le processus de redirection du journal est lancé sans
+ <p>Par défaut, le processus de redirection du journal est lancé sans
invoquer un shell. Pour invoquer un shell, utilisez "<code>|$</code>"
- au lieu de "<code>|</code>" (en général avec <code>/bin/sh -c</code>)
+ au lieu de "<code>|</code>" (en général avec <code>/bin/sh -c</code>)
:</p>
<highlight language="config">
</highlight>
- <p>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 "<code>||</code>" est aussi supportée pour
- des raisons de compatibilité avec Apache 2.2 et est équivalente à
+ <p>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 "<code>||</code>" est aussi supportée pour
+ des raisons de compatibilité avec Apache 2.2 et est équivalente à
"<code>|</code>".</p>
- <note><title>Note à propos de la plateforme Windows</title>
- <p>Notez que sous Windows, la mémoire allouée au bureau (desktop
+ <note><title>Note à propos de la plateforme Windows</title>
+ <p>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 <code>SharedSection</code>
- de la clé de registre
+ 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 <code>SharedSection</code>
+ de la clé de registre
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\SubSystems\Windows.
<strong>Modifiez cette valeur avec prudence</strong> ; 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.</p>
+ 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.</p>
</note>
</section>
<section id="virtualhost">
- <title>Hôtes virtuels</title>
+ <title>Hôtes virtuels</title>
- <p>Lorsqu'un serveur poss
ède plusieurs <a href
- ="vhosts/">hôtes virtuels</a>, il existe de nombreuses solutions pour gérer
+ <p>Lorsqu'un serveur poss
ède plusieurs <a href
+ ="vhosts/">hôtes virtuels</a>, 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
+ 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
<directive module="core" type="section">VirtualHost</directive> 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.</p>
+ 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.</p>
<p>Si des directives <directive module=
"mod_log_config">CustomLog</directive> ou
- <directive module="core">ErrorLog</directive> sont placées dans une section
+ <directive module="core">ErrorLog</directive> sont placées dans une section
<directive module="core" type="section">VirtualHost</directive>, 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 <a
+ 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 <a
href="vhosts/fd-limits.html">nombre de descripteurs
- de fichiers insuffisant</a> peuvent rapidement apparaître.</p>
+ de fichiers insuffisant</a> peuvent rapidement apparaître.</p>
- <p>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 :</p>
+ <p>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 :</p>
<highlight language="config">
LogFormat "%v %l %u %t \"%r\" %>s %b" comonvhost
CustomLog logs/access_log comonvhost
</highlight>
- <p>Le champ <code>%v</code> sert à enregistrer le nom de l'hôte virtuel qui
- traite la requ
ête. Un programme tel que <a
- href="programs/split-logfile.html">split-logfile</a> peut ensuite être utilisé
- pour générer "à froid" autant de journaux que d'hôtes virtuels.</p>
+ <p>Le champ <code>%v</code> sert à enregistrer le nom de l'hôte virtuel qui
+ traite la requ
ête. Un programme tel que <a
+ href="programs/split-logfile.html">split-logfile</a> peut ensuite être utilisé
+ pour générer "à froid" autant de journaux que d'hôtes virtuels.</p>
</section>
<section id="other">
</related>
<section>
- <title>Enregistrement du nombre réel d'octets envoyés et reçus</title>
+ <title>Enregistrement du nombre réel d'octets envoyés et reçus</title>
<p>Le module <module>mod_logio</module> fournit deux champs
- <directive module="mod_log_config">LogFormat</directive> supplémentaires
- (%I et %O) qui permettent d'enregistrer le nombre réel d'octets reçus et
- envoyés sur le réseau.</p>
+ <directive module="mod_log_config">LogFormat</directive> supplémentaires
+ (%I et %O) qui permettent d'enregistrer le nombre réel d'octets reçus et
+ envoyés sur le réseau.</p>
</section>
<section>
<title>Journalisation de style investigation judiciaire (forensic logging)</title>
<p>Le module <module>mod_log_forensic</module> 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é.</p>
+ à 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é.</p>
</section>
<section id="pidfile">
<title>Fichier PID</title>
- <p>Au démarrage, le démon httpd Apache enregistre l'identifiant du
+ <p>Au démarrage, le démon httpd Apache enregistre l'identifiant du
processus httpd parent dans le fichier <code>logs/httpd.pid</code>.
- Le nom de ce fichier peut être modifié à l'aide de la directive
+ Le nom de ce fichier peut être modifié à l'aide de la directive
<directive module="mpm_common">PidFile</directive>. Cet identifiant
- permet à l'administrateur de redémarrer et arrêter le démon en
+ 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 <a href="stopping.html">Arrêt et redémarrage</a>.</p>
+ utiliser l'option de ligne de commande -k. Pour plus de détails,
+ consulter la page <a href="stopping.html">Arrêt et redémarrage</a>.</p>
</section>
<section id="scriptlog">
<title>Journal des scripts</title>
- <p>Afin de faciliter le débogage, la directive
+ <p>Afin de faciliter le débogage, la directive
<directive module="mod_cgi">ScriptLog</directive> 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
+ 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 <a href="mod/mod_cgi.html">mod_cgi</a>.</p>
</section>
-<?xml version="1.0"?>
+<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1673563:1738542 (outdated) -->
+<!-- English Revision: 1738542 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<modulesynopsis metafile="mod_access_compat.xml.meta">
<name>mod_access_compat</name>
-<description>Autorisations de groupe à base de nom d'hôte (nom ou
+<description>Autorisations de groupe à base de nom d'hôte (nom ou
adresse IP)</description>
<status>Extension</status>
<sourcefile>mod_access_compat.c</sourcefile>
<identifier>access_compat_module</identifier>
<compatibility>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
+à 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
<module>mod_authz_host</module></compatibility>
<summary>
<directive module="core" type="section">Location</directive>, ainsi
que dans les fichiers <code><a
href="core.html#accessfilename">.htaccess</a></code> 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 <a href="../env.html">variables
+ 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 <a href="../env.html">variables
d'environnement</a>. Les directives <directive
module="mod_access_compat">Allow</directive> et <directive
- module="mod_access_compat">Deny</directive> permettent de spécifier
- quels clients sont ou ne sont pas autorisés à accéder au serveur,
+ module="mod_access_compat">Deny</directive> permettent de spécifier
+ quels clients sont ou ne sont pas autorisés à accéder au serveur,
alors que la directive <directive
- module="mod_access_compat">Order</directive> définit le statut
- d'accès par défaut, et détermine la manière dont les directives
+ module="mod_access_compat">Order</directive> définit le statut
+ d'accès par défaut, et détermine la manière dont les directives
<directive module="mod_access_compat">Allow</directive> et
<directive module="mod_access_compat">Deny</directive> interagissent
entre elles.</p>
- <p>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 <directive
- module="mod_access_compat">Satisfy</directive> pour déterminer la
- manière dont ces deux modes de restrictions interagissent.</p>
+ <p>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 <directive
+ module="mod_access_compat">Satisfy</directive> pour déterminer la
+ manière dont ces deux modes de restrictions interagissent.</p>
<note type="warning"><title>Note</title>
<p>Les directives fournies par le module
- <module>mod_access_compat</module> sont devenues obsolètes depuis
- la refonte d'authz. Voir <module>mod_authz_host</module>.</p>
+ <module>mod_access_compat</module> sont devenues obsolètes depuis
+ la refonte du module <module>mod_authz_host</module>. Mélanger d'anciennes
+ directives comme <directive
+ module="mod_access_compat">Order</directive>, <directive
+ module="mod_access_compat">Allow</directive> ou <directive
+ module="mod_access_compat">Deny</directive> avec des nouvelles comme
+ <directive module="mod_authz_core">Require</directive> est techniquement
+ possible mais déconseillé. En effet, <module>mod_access_compat</module> 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
+ <a href="../upgrading.html">upgrading</a> pour plus de détails.
+ </p>
</note>
- <p>En général, les directives de restriction d'accès s'appliquent à
- toutes les méthodes d'accès (<code>GET</code>, <code>PUT</code>,
+ <p>En général, les directives de restriction d'accès s'appliquent à
+ toutes les méthodes d'accès (<code>GET</code>, <code>PUT</code>,
<code>POST</code>, 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 <directive module="core"
+ 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 <directive module="core"
type="section">Limit</directive>.</p>
<note><title>Fusion des sections de configuration</title>
- <p>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.</p>
+ <p>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.</p>
</note>
</summary>
<directivesynopsis>
<name>Allow</name>
-<description>Spécifie quels hôtes peuvent accéder à une certaine zone du
+<description>Spécifie quels hôtes peuvent accéder à une certaine zone du
serveur</description>
-<syntax> Allow from all|<var>hôte</var>|env=[!]<var>variable
+<syntax> Allow from all|<var>hôte</var>|env=[!]<var>variable
d'environnement</var>
-[<var>hôte</var>|env=[!]<var>variable d'environnement</var>] ...</syntax>
+[<var>hôte</var>|env=[!]<var>variable d'environnement</var>] ...</syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>Limit</override>
<usage>
- <p>La directive <directive>Allow</directive> 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.</p>
+ <p>La directive <directive>Allow</directive> 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.</p>
<p>Le premier argument de cette directive est toujours
<code>from</code>. Les arguments suivants peuvent prendre trois
- formes différentes. Si <code>Allow from all</code> est spécifié,
- tout hôte se voit accordé l'accès, en tenant compte des directives
+ formes différentes. Si <code>Allow from all</code> est spécifié,
+ tout hôte se voit accordé l'accès, en tenant compte des directives
<directive module="mod_access_compat">Deny</directive> et <directive
- module="mod_access_compat">Order</directive> 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 <em>nom d'hôte</em> sous
+ module="mod_access_compat">Order</directive> 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 <em>nom d'hôte</em> sous
une des formes suivantes :</p>
<dl>
Allow from example.org
Allow from .net example.edu
</highlight>
- <p>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,
+ <p>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, <code>foo.example.org</code>
correspondra, mais <code>fooexample.org</code> 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 <directive
+ définition de la directive <directive
module="core">HostnameLookups</directive>. 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
+ 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.</p></dd>
- <dt>Une adresse IP complète</dt>
+ <dt>Une adresse IP complète</dt>
<dd>
<highlight language="config">
Allow from 10.1.2.3
Allow from 192.168.1.104 192.168.1.205
</highlight>
- <p>L'adresse IP d'un hôte auquel on a accordé l'accès</p></dd>
+ <p>L'adresse IP d'un hôte auquel on a accordé l'accès</p></dd>
<dt>Une adresse IP partielle</dt>
Allow from 10.1
Allow from 10 172.20 192.168.2
</highlight>
- <p>De un à trois des premiers octets d'une adresse IP, afin de
- restreindre l'accès à un sous-réseau.</p></dd>
+ <p>De un à trois des premiers octets d'une adresse IP, afin de
+ restreindre l'accès à un sous-réseau.</p></dd>
- <dt>Une paire réseau/masque de sous-réseau</dt>
+ <dt>Une paire réseau/masque de sous-réseau</dt>
<dd>
<highlight language="config">
Allow from 10.1.0.0/255.255.0.0
</highlight>
- <p>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.</p></dd>
+ <p>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.</p></dd>
- <dt>Une spécification CIDR réseau/nnn</dt>
+ <dt>Une spécification CIDR réseau/nnn</dt>
<dd>
<highlight language="config">
Allow from 10.1.0.0/16
</highlight>
- <p>Identique au cas précédent, mis à part que le masque est
- constitué des nnn bits de poids fort.</p></dd>
+ <p>Identique au cas précédent, mis à part que le masque est
+ constitué des nnn bits de poids fort.</p></dd>
</dl>
- <p>Notez que les trois derniers exemples désignent le même ensemble
- d'hôtes.</p>
+ <p>Notez que les trois derniers exemples désignent le même ensemble
+ d'hôtes.</p>
- <p>On peut spécifier des adresses et sous-réseaux IPv6 de la manière
+ <p>On peut spécifier des adresses et sous-réseaux IPv6 de la manière
suivante :</p>
<highlight language="config">
Allow from 2001:db8::a00:20ff:fea7:ccea/10
</highlight>
- <p>Le troisième format d'argument de la directive
- <directive>Allow</directive> permet de contrôler l'accès au serveur
+ <p>Le troisième format d'argument de la directive
+ <directive>Allow</directive> permet de contrôler l'accès au serveur
en fonction de l'existence d'une <a
href="../env.html">variable d'environnement</a>. Lorsque <code>Allow
- from env=<var>variable d'environnement</var></code> est spécifié, la
- requête est autorisée si la variable d'environnement <var>variable
+ from env=<var>variable d'environnement</var></code> est spécifié, la
+ requête est autorisée si la variable d'environnement <var>variable
d'environnement</var> existe. En revanche, lorsque <code>Allow from
- env=!<var>env-variable</var></code> est spécifié, la
- requête est autorisée si la variable d'environnement <var>variable
- d'environnement</var> n'existe pas. Le serveur permet de définir
+ env=!<var>env-variable</var></code> est spécifié, la
+ requête est autorisée si la variable d'environnement <var>variable
+ d'environnement</var> 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
+ caractéristiques de la requête client et en utilisant les directives
fournies par le module <module>mod_setenvif</module>. Ainsi, on peut
utiliser la directive <directive>Allow</directive> pour permettre
- l'accès en fonction de paramètres comme le <code>User-Agent</code>
+ l'accès en fonction de paramètres comme le <code>User-Agent</code>
(type de navigateur) des clients, le <code>Referer</code>, ou
- d'autres champs d'en-tête de la requête HTTP.</p>
+ d'autres champs d'en-tête de la requête HTTP.</p>
<highlight language="config">
SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
</Directory>
</highlight>
- <p>Dans cet exemple, les navigateurs dont la chaîne user-agent
+ <p>Dans cet exemple, les navigateurs dont la chaîne user-agent
commence par <code>KnockKnock/2.0</code> se verront accorder
- l'accès, alors que tous les autres seront rejetés.</p>
+ l'accès, alors que tous les autres seront rejetés.</p>
<note><title>Fusion des sections de configuration</title>
- <p>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.</p>
+ <p>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.</p>
</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>Deny</name>
-<description>Définit quels hôtes ne sont pas autorisés à accéder au
+<description>Définit quels hôtes ne sont pas autorisés à accéder au
serveur</description>
-<syntax> Deny from all|<var>hôte</var>|env=[!]<var>variable
+<syntax> Deny from all|<var>hôte</var>|env=[!]<var>variable
d'environnement</var>
-[<var>hôte</var>|env=[!]<var>variable d'environnement</var>] ...</syntax>
+[<var>hôte</var>|env=[!]<var>variable d'environnement</var>] ...</syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>Limit</override>
<usage>
- <p>Cette directive permet de restreindre l'accès au serveur en
- fonction du nom d'hôte, de l'adresse IP ou de variables
+ <p>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
<directive>Deny</directive> sont identiques aux arguments de la
directive <directive
<directivesynopsis>
<name>Order</name>
-<description>Définit le statut d'accès par défaut et l'ordre dans lequel
+<description>Définit le statut d'accès par défaut et l'ordre dans lequel
les directives <directive>Allow</directive> et
-<directive>Deny</directive> sont évaluées.</description>
+<directive>Deny</directive> sont évaluées.</description>
<syntax> Order <var>ordre</var></syntax>
<default>Order Deny,Allow</default>
<contextlist><context>directory</context><context>.htaccess</context>
<usage>
- <p>La directive <directive>Order</directive>, associée aux
+ <p>La directive <directive>Order</directive>, associée aux
directives <directive module="mod_access_compat">Allow</directive>
et <directive module="mod_access_compat">Deny</directive>,
- 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 <directive
+ 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 <directive
module="mod_access_compat">Allow</directive>, soit toutes les
directives <directive
- module="mod_access_compat">Deny</directive> qui sont traitées, selon
- la définition de la directive <directive
+ module="mod_access_compat">Deny</directive> qui sont traitées, selon
+ la définition de la directive <directive
module="mod_access_compat">Order</directive>. Le reste des
directives (<directive module="mod_access_compat">Deny</directive>
ou <directive module="mod_access_compat">Allow</directive>) 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.</p>
+ 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.</p>
<p>Notez que toutes les directives <directive
module="mod_access_compat">Allow</directive> et <directive
- module="mod_access_compat">Deny</directive> 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
+ module="mod_access_compat">Deny</directive> 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 <directive
- module="mod_access_compat">Allow</directive> sont considérées comme
+ module="mod_access_compat">Allow</directive> sont considérées comme
un groupe, toutes les lignes <directive
module="mod_access_compat">Deny</directive> comme un autre, et le
- statut par défaut a son existence propre.</p>
+ statut par défaut a son existence propre.</p>
- <p><em>Ordre</em> peut être :</p>
+ <p><em>Ordre</em> peut être :</p>
<dl>
<dt><code>Allow,Deny</code></dt>
<dd>Dans un premier temps, toutes les directives <directive
- module="mod_access_compat">Allow</directive> sont évaluées ; au
- moins une d'entre elles doit correspondre, sinon la requête est
- rejetée. Ensuite, toutes les directives <directive
- module="mod_access_compat">Deny</directive> 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
+ module="mod_access_compat">Allow</directive> sont évaluées ; au
+ moins une d'entre elles doit correspondre, sinon la requête est
+ rejetée. Ensuite, toutes les directives <directive
+ module="mod_access_compat">Deny</directive> 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
<directive module="mod_access_compat">Allow</directive> ou
- <directive module="mod_access_compat">Deny</directive> est rejetée
- par défaut.</dd>
+ <directive module="mod_access_compat">Deny</directive> est rejetée
+ par défaut.</dd>
<dt><code>Deny,Allow</code></dt>
<dd>Dans un premier temps, toutes les directives <directive
- module="mod_access_compat">Deny</directive> sont évaluées ; Si au
- moins une d'entre elles correspond, la requête est rejetée,
- <strong>à moins</strong> qu'elle corresponde aussi à une directive
+ module="mod_access_compat">Deny</directive> sont évaluées ; Si au
+ moins une d'entre elles correspond, la requête est rejetée,
+ <strong>à moins</strong> qu'elle corresponde aussi à une directive
<directive module="mod_access_compat">Allow</directive>. Toute
- requête qui ne correspond à aucune directive <directive
+ requête qui ne correspond à aucune directive <directive
module="mod_access_compat">Allow</directive> ou <directive
- module="mod_access_compat">Deny</directive> est autorisée.</dd>
+ module="mod_access_compat">Deny</directive> est autorisée.</dd>
<dt><code>Mutual-failure</code></dt>
- <dd>Cet argument a le même effet que <code>Allow,Deny</code> et
- est devenu de ce fait obsolète.</dd>
+ <dd>Cet argument a le même effet que <code>Allow,Deny</code> et
+ est devenu de ce fait obsolète.</dd>
</dl>
- <p>Les mots-clés ne peuvent être séparés que par des virgules ;
+ <p>Les mots-clés ne peuvent être séparés que par des virgules ;
<em>aucun espace</em> ne doit s'intercaler entre eux.</p>
<table border="1">
<tr>
<th>Match</th>
- <th>Résultat Allow,Deny</th>
- <th>Résultat Deny,Allow</th>
+ <th>Résultat Allow,Deny</th>
+ <th>Résultat Deny,Allow</th>
</tr><tr>
- <th>Correspond à Allow seulement</th>
- <td>Requête autorisée</td>
- <td>Requête autorisée</td>
+ <th>Correspond à Allow seulement</th>
+ <td>Requête autorisée</td>
+ <td>Requête autorisée</td>
</tr><tr>
- <th>Correspond à Deny seulement</th>
- <td>Requête rejetée</td>
- <td>Requête rejetée</td>
+ <th>Correspond à Deny seulement</th>
+ <td>Requête rejetée</td>
+ <td>Requête rejetée</td>
</tr><tr>
<th>Aucune correspondance</th>
- <td>Par défaut la seconde directive : rejet</td>
- <td>Par défaut la seconde directive : autorisation</td>
+ <td>Par défaut la seconde directive : rejet</td>
+ <td>Par défaut la seconde directive : autorisation</td>
</tr><tr>
- <th>Correspond à Allow & Deny</th>
- <td>La dernière correspondance l'emporte : rejet</td>
- <td>La dernière correspondance l'emporte : autorisation</td>
+ <th>Correspond à Allow & Deny</th>
+ <td>La dernière correspondance l'emporte : rejet</td>
+ <td>La dernière correspondance l'emporte : autorisation</td>
</tr>
</table>
- <p>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é.</p>
+ <p>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é.</p>
<highlight language="config">
Order Deny,Allow
Allow from example.org
</highlight>
- <p>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é
+ <p>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 <directive
module="mod_access_compat">Deny</directive>, et consiste donc en un
- refus d'accès.</p>
+ refus d'accès.</p>
<highlight language="config">
Order Allow,Deny
</highlight>
<p>Par contre, si la valeur de la directive
- <directive>Order</directive>, dans l'exemple précédent, est
- <code>Deny,Allow</code>, tout le monde a l'autorisation d'accès.
- Ceci est dû au fait que <code>Allow from example.org</code> sera
- évalué en dernier, sans tenir compte de l'ordre réel dans lequel les
+ <directive>Order</directive>, dans l'exemple précédent, est
+ <code>Deny,Allow</code>, tout le monde a l'autorisation d'accès.
+ Ceci est dû au fait que <code>Allow from example.org</code> 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 <code>Deny from foo.example.org</code>. Tout hôte qui
+ l'emporter sur <code>Deny from foo.example.org</code>. Tout hôte qui
n'est pas dans le domaine <code>example.org</code> aura aussi
- l'autorisation d'accès car le statut par défaut est positionné sur
+ l'autorisation d'accès car le statut par défaut est positionné sur
<directive
module="mod_access_compat">Allow</directive> et constitue donc une
- autorisation d'accès.</p>
+ autorisation d'accès.</p>
- <p>La présence d'une directive <directive>Order</directive> peut
- affecter le contrôle d'accès à une partie du serveur même en
+ <p>La présence d'une directive <directive>Order</directive> peut
+ affecter le contrôle d'accès à une partie du serveur même en
l'abscence de directives <directive
module="mod_access_compat">Allow</directive> et <directive
- module="mod_access_compat">Deny</directive> associées, à cause de
- son influence sur le statut par défaut. Par exemple,</p>
+ module="mod_access_compat">Deny</directive> associées, à cause de
+ son influence sur le statut par défaut. Par exemple,</p>
<highlight language="config">
<Directory "/www">
</Directory>
</highlight>
- <p>va interdire tout accès au répertoire <code>/www</code> à cause
- du statut d'accès par défaut qui est défini à <directive
+ <p>va interdire tout accès au répertoire <code>/www</code> à cause
+ du statut d'accès par défaut qui est défini à <directive
module="mod_access_compat">Deny</directive>.</p>
- <p>La directive <directive>Order</directive> ne contrôle l'ordre
- dans lequel sont traitées les directives d'accès qu'au cours de
+ <p>La directive <directive>Order</directive> 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 <directive
module="mod_access_compat">Allow</directive> ou <directive
- module="mod_access_compat">Deny</directive> située dans une section
+ module="mod_access_compat">Deny</directive> située dans une section
<directive module="core" type="section">Location</directive> sera
- toujours évaluée après une directive <directive
+ toujours évaluée après une directive <directive
module="mod_access_compat">Allow</directive> ou <directive
- module="mod_access_compat">Deny</directive> située dans une section
+ module="mod_access_compat">Deny</directive> située dans une section
<directive module="core" type="section">Directory</directive> ou un
fichier <code>.htaccess</code>, sans tenir compte de la
- définition de la directive <directive>Order</directive>. Pour plus
- de détails à propos de la fusion des sections de configuration, voir
+ définition de la directive <directive>Order</directive>. Pour plus
+ de détails à propos de la fusion des sections de configuration, voir
le document <a
href="../sections.html">Comment fonctionnent les sections Directory,
Location et Files</a>.</p>
<note><title>Fusion des sections de configuration</title>
- <p>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.</p>
+ <p>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.</p>
</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>Satisfy</name>
-<description>Interaction entre le contrôle d'accès en fonction de l'hôte
+<description>Interaction entre le contrôle d'accès en fonction de l'hôte
et l'authentification utilisateur</description>
<syntax>Satisfy Any|All</syntax>
<default>Satisfy All</default>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>
-<compatibility>Affecté par <directive module="core" type="section"
+<compatibility>Affecté par <directive module="core" type="section"
>Limit</directive> et <directive module="core"
-type="section">LimitExcept</directive> à partir de la version
+type="section">LimitExcept</directive> à partir de la version
2.0.51</compatibility>
<usage>
- <p>Politique d'accès dans le cas où on utilise à la fois <directive
+ <p>Politique d'accès dans le cas où on utilise à la fois <directive
module="mod_access_compat">Allow</directive> et <directive
module="mod_authz_core">Require</directive>. L'argument est soit
<code>All</code>, soit <code>Any</code>. L'utilisation de cette
- directive n'a de sens que si l'accès à une zone particulière du
+ 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 (<code>All</code>), le client doit satisfaire à la
+ de l'adresse IP de l'hôte client. Dans ce cas, par
+ défaut (<code>All</code>), le client doit satisfaire à la
restriction d'adresse, <em>et</em> fournir un couple
utilisateur/mot de passe valide. Avec l'argument <code>Any</code>,
- le client se verra accorder l'accès s'il satisfait à la restriction
+ 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
+ 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.</p>
<p>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
+ 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 :</p>
<highlight language="config">
</highlight>
<p>
- Une autre utilisation fréquente de la directive
- <directive>Satisfy</directive> est l'allègement des restrictions
- d'accès à un sous-répertoire par rapport aux restrictions d'accès au
- répertoire parent :
+ Une autre utilisation fréquente de la directive
+ <directive>Satisfy</directive> est l'allègement des restrictions
+ d'accès à un sous-répertoire par rapport aux restrictions d'accès au
+ répertoire parent :
</p>
<highlight language="config">
</Directory>
</highlight>
- <p>Dans l'exemple ci-dessus, l'accès au répertoire
- <code>/var/www/private</code> nécessitera une authentification,
- alors que l'accès au répertoire <code>/var/www/private/public</code>
- sera accordé sans restriction.</p>
+ <p>Dans l'exemple ci-dessus, l'accès au répertoire
+ <code>/var/www/private</code> nécessitera une authentification,
+ alors que l'accès au répertoire <code>/var/www/private/public</code>
+ sera accordé sans restriction.</p>
<p>Depuis la version 2.0.51, les directives
- <directive>Satisfy</directive> peuvent être restreintes à certaines
- méthodes particulières à l'aide des sections <directive
+ <directive>Satisfy</directive> peuvent être restreintes à certaines
+ méthodes particulières à l'aide des sections <directive
module="core" type="section">Limit</directive> et <directive
module="core" type="section">LimitExcept</directive>.</p>
<note><title>Fusion des sections de configuration</title>
- <p>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.</p>
+ <p>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.</p>
</note>
</usage>
<seealso><directive module="mod_access_compat">Allow</directive></seealso>
-<?xml version="1.0"?>
+<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1375044:1739075 (outdated) -->
+<!-- English Revision: 1739075 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<modulesynopsis metafile="mod_privileges.xml.meta">
<name>mod_privileges</name>
-<description>Support des privilèges de Solaris et de l'exécution des
-serveurs virtuels sous différents identifiants
+<description>Support des privilèges de Solaris et de l'exécution des
+serveurs virtuels sous différents identifiants
utilisateurs.</description>
<status>Experimental</status>
<sourcefile>mod_privileges.c</sourcefile>
plates-formes Solaris 10 et OpenSolaris</compatibility>
<summary>
-<p>Ce module permet l'exécution de différents serveurs virtuels sous
-différents identifiants Unix <var>User</var> et <var>Group</var>,
-et avec diff
érents <a
-href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp">Privilèges
-Solaris</a>. 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é.</p>
-
-<p>À la différence de perchild, <module>mod_privileges</module> n'est
-pas un module MPM. Il travaille <em>au sein</em> d'un modèle de
-traitement pour définir les privilèges et les User/Group <em>pour chaque
-requête</em> 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
+<p>Ce module permet l'exécution de différents serveurs virtuels sous
+différents identifiants Unix <var>User</var> et <var>Group</var>,
+href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp">Privilèges
+Solaris</a>. 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é.</p>
+
+<p>À la différence de perchild, <module>mod_privileges</module> n'est
+pas un module MPM. Il travaille <em>au sein</em> d'un modèle de
+traitement pour définir les privilèges et les User/Group <em>pour chaque
+requête</em> 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.</p>
-<p><module>mod_privileges</module> traite des problèmes de sécurité
-similaires à ceux de <a href="../suexec.html">suexec</a> ; 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
+<p><module>mod_privileges</module> traite des problèmes de sécurité
+similaires à ceux de <a href="../suexec.html">suexec</a> ; 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
-<strong>mod_php</strong>, qui est lui-même incompatible avec les modules
-MPM threadés. Il est également bien adapté aux autres applications de type
+particulièrement à l'exécution des applications PHP sous
+<strong>mod_php</strong>, 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 <strong>mod_perl</strong>,
<strong>mod_python</strong>, et <strong>mod_ruby</strong>, ainsi qu'aux
applications en langage C telles que les modules Apache pour lesquels la
-séparation des privilèges constitue un problème.</p>
+séparation des privilèges constitue un problème.</p>
</summary>
-<section id="security"><title>Considérations à propos de sécurité</title>
+<section id="security"><title>Considérations à propos de sécurité</title>
-<p><module>mod_privileges</module> introduit de nouveaux problèmes de
-sécurité dans les situations où du <strong>code non sûr</strong> peut
-s'exécuter <strong>à l'intérieur du processus du serveur web</strong>.
-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.</p>
+<p><module>mod_privileges</module> introduit de nouveaux problèmes de
+sécurité dans les situations où du <strong>code non sûr</strong> peut
+s'exécuter <strong>à l'intérieur du processus du serveur web</strong>.
+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.</p>
-<p>Les principaux problèmes de sécurité que l'on rencontre avec
+<p>Les principaux problèmes de sécurité que l'on rencontre avec
mod_privileges sont :</p>
-<ul><li>L'exécution sous un utilisateur système pose les mêmes problèmes
-de sécurité que mod_suexec, et pratiquement les mêmes que cgiwrap et
+<ul><li>L'exécution sous un utilisateur système pose les mêmes problèmes
+de sécurité que mod_suexec, et pratiquement les mêmes que cgiwrap et
suphp.</li>
-<li>Une extension utilisateur (module ou script) malveillante, écrite en connaissant les mécanismes
-utilisés par <strong>mod_privileges</strong>,
-pourrait élever ses privilèges à tout niveau
+<li>Une extension utilisateur (module ou script) malveillante, écrite en connaissant les mécanismes
+utilisés par <strong>mod_privileges</strong>,
+pourrait élever ses privilèges à tout niveau
accessible au processus httpd dans tout serveur virtuel. Ceci introduit
-de nouveaux risques si (et seulement si) mod_privileges est compilé avec
+de nouveaux risques si (et seulement si) mod_privileges est compilé avec
l'option <var>BIG_SECURITY_HOLE</var>.</li>
-<li>Une extension utilisateur (module ou script) malveillante, écrite en connaissant les mécanismes
-utilisés par <strong>mod_privileges</strong>,
-pourrait élever ses privilèges pour s'attribuer
+<li>Une extension utilisateur (module ou script) malveillante, écrite en connaissant les mécanismes
+utilisés par <strong>mod_privileges</strong>,
+pourrait élever ses privilèges pour s'attribuer
l'identifiant utilisateur d'un autre utilisateur (et/ou groupe)
-système.</li>
+système.</li>
</ul>
<p>La directive <directive>PrivilegesMode</directive> vous permet de
-sélectionner soit le mode <var>FAST</var>, soit le mode
+sélectionner soit le mode <var>FAST</var>, soit le mode
<var>SECURE</var>. Vous pouvez panacher les modes en utilisant par
exemple le mode <var>FAST</var> pour les utilisateurs de confiance et
-les chemins contenant du code entièrement audité, tout en imposant le
-mode <var>SECURE</var> où un utilisateur non sûr a la possibilité
+les chemins contenant du code entièrement audité, tout en imposant le
+mode <var>SECURE</var> où un utilisateur non sûr a la possibilité
d'introduire du code.</p>
-<p>Avant de décrire les modes, il nous faut présenter les cas
+<p>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
+"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.</p>
+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.</p>
<dl>
<dt>Mode FAST</dt>
-<dd>En mode <var>FAST</var>, les requêtes sont traitées "in-process"
-avec les uid/gid et privilèges sélectionnés, si bien que la
-surcharge est négligeable. Ceci convient aux situations "Benign", mais
-n'est pas sécurisé contre un attaquant augmentant ses privilèges avec un
+<dd>En mode <var>FAST</var>, les requêtes sont traitées "in-process"
+avec les uid/gid et privilèges sélectionnés, si bien que la
+surcharge est négligeable. Ceci convient aux situations "Benign", mais
+n'est pas sécurisé contre un attaquant augmentant ses privilèges avec un
module ou script "in-process".</dd>
<dt>Mode SECURE</dt>
-<dd>Une requête en mode <var>SECURE</var> génère un sous-processus qui
-supprime les privilèges. Ce comportement est très similaire à
-l'exécution d'un programme CGI avec suexec, mais il reste valable tout
-au long du cycle de traitement de la requête, avec en plus l'avantage
-d'un contrôle précis des privilèges.</dd>
+<dd>Une requête en mode <var>SECURE</var> génère un sous-processus qui
+supprime les privilèges. Ce comportement est très similaire à
+l'exécution d'un programme CGI avec suexec, mais il reste valable tout
+au long du cycle de traitement de la requête, avec en plus l'avantage
+d'un contrôle précis des privilèges.</dd>
</dl>
-<p>Vous pouvez sélectionner différents
+<p>Vous pouvez sélectionner différents
<directive>PrivilegesMode</directive>s pour chaque serveur virtuel, et
-même dans un contexte de répertoire à l'intérieur d'un serveur virtuel.
-Le mode <var>FAST</var> convient lorsque les utilisateurs sont sûrs
-et/ou n'ont pas le privilège de charger du code "in-process". Le mode
-<var>SECURE</var> convient dans les cas où du code non sûr peut
-s'exécuter "in-process". Cependant, même en mode <var>SECURE</var>, il
+même dans un contexte de répertoire à l'intérieur d'un serveur virtuel.
+Le mode <var>FAST</var> convient lorsque les utilisateurs sont sûrs
+et/ou n'ont pas le privilège de charger du code "in-process". Le mode
+<var>SECURE</var> convient dans les cas où du code non sûr peut
+s'exécuter "in-process". Cependant, même en mode <var>SECURE</var>, il
n'y a pas de protection contre un utilisateur malveillant qui a la
-possibilité d'introduire du code supportant les privilèges <em>avant le
-début du cycle de traitement de la requête.</em></p>
+possibilité d'introduire du code supportant les privilèges <em>avant le
+début du cycle de traitement de la requête.</em></p>
</section>
<directivesynopsis>
<name>PrivilegesMode</name>
-<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.</description>
+<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.</description>
<syntax>PrivilegesMode FAST|SECURE|SELECTIVE</syntax>
<default>PrivilegesMode FAST</default>
<contextlist>
<context>directory</context>
</contextlist>
<compatibility>Disponible sous Solaris 10 et OpenSolaris avec des
-modules MPMs non threadés (comme <module>prefork</module> ou un module
-personnalisé).</compatibility>
+modules MPMs non threadés (comme <module>prefork</module> ou un module
+personnalisé).</compatibility>
<usage><p>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 <var>SECURE</var>, chaque requête est traitée
-dans un sous-processus sécurisé, ce qui induit une dégradation sensible
-des performances. En mode <var>FAST</var>, le serveur n'est pas protégé
-contre l'augmentation de privilège comme décrit plus haut.</p>
-<p>Cette directive est sensiblement différente selon qu'elle se trouve
+performances et la sécurité à l'encontre des codes malicieux supportant
+les privilèges. En mode <var>SECURE</var>, chaque requête est traitée
+dans un sous-processus sécurisé, ce qui induit une dégradation sensible
+des performances. En mode <var>FAST</var>, le serveur n'est pas protégé
+contre l'augmentation de privilège comme décrit plus haut.</p>
+<p>Cette directive est sensiblement différente selon qu'elle se trouve
dans une section <code><Directory></code> (ou Location/Files/If)
ou au niveau global ou dans un <code><VirtualHost></code>.</p>
-<p>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 <code><Directory></code>
-sera <strong>ignorée</strong>. Le pseudo-mode SELECTIVE confie le choix
+<p>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 <code><Directory></code>
+sera <strong>ignorée</strong>. Le pseudo-mode SELECTIVE confie le choix
du mode FAST ou SECURE aux directives contenues dans une
section<code><Directory></code>.</p>
<p>Dans une section <code><Directory></code>, 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
+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).</p>
<note type="warning"><title>Avertissement</title>
- Lorsque le mode SELECTIVE a été défini pour un serveur virtuel,
- l'activation des privilèges doit être reportée <em>après</em>
- la détermination, par la phase de comparaison du traitement de
- la requête, du contexte <code><Directory></code> qui
- s'applique à la requête. Ceci peut donner à un attaquant
- l'opportunité d'introduire du code via une directive <directive
- module="mod_rewrite">RewriteMap</directive> s'exécutant au
+ Lorsque le mode SELECTIVE a été défini pour un serveur virtuel,
+ l'activation des privilèges doit être reportée <em>après</em>
+ la détermination, par la phase de comparaison du traitement de
+ la requête, du contexte <code><Directory></code> qui
+ s'applique à la requête. Ceci peut donner à un attaquant
+ l'opportunité d'introduire du code via une directive <directive
+ module="mod_rewrite">RewriteMap</directive> s'exécutant au
niveau global ou d'un serveur virtuel <em>avant</em> que les
- privilèges n'aient été supprimés et l'uid/gid défini.
+ privilèges n'aient été supprimés et l'uid/gid défini.
</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>VHostUser</name>
-<description>Définit l'identifiant utilisateur sous lequel s'exécute un
+<description>Définit l'identifiant utilisateur sous lequel s'exécute un
serveur virtuel.</description>
<syntax>VHostUser <var>identifiant-utilisateur-unix</var></syntax>
-<default>Hérite de l'identifiant utilisateur spécifié par la directive
+<default>Hérite de l'identifiant utilisateur spécifié par la directive
<directive module="mod_unixd">User</directive></default>
<contextlist><context>virtual host</context></contextlist>
<compatibility>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-threadés (<module>prefork</module> ou MPM
-personnalisé).</compatibility>
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé).</compatibility>
<usage>
- <p>La directive <directive>VHostUser</directive> permet de définir
+ <p>La directive <directive>VHostUser</directive> 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 <a
- href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp">Privilèges
- Solaris</a>. Comme la définition
+ 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 <a
+ href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp">Privilèges
+ Solaris</a>. Comme la définition
s'applique au <em>processus</em>, cette directive est incompatible
- avec les modules MPM threadés.</p>
- <p><var>identifiant-utilisateur-unix</var> peut être :</p>
+ avec les modules MPM threadés.</p>
+ <p><var>identifiant-utilisateur-unix</var> peut être :</p>
<dl>
<dt>Un nom d'utilisateur</dt>
- <dd>Fait référence à l'utilisateur donné par son nom.</dd>
+ <dd>Fait référence à l'utilisateur donné par son nom.</dd>
- <dt><code>#</code> suivi d'un numéro d'utilisateur.</dt>
- <dd>Fait référence à l'utilisateur donné par son numéro.</dd>
+ <dt><code>#</code> suivi d'un numéro d'utilisateur.</dt>
+ <dd>Fait référence à l'utilisateur donné par son numéro.</dd>
</dl>
- <note type="warning"><title>Sécurité</title>
- <p>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
+ <note type="warning"><title>Sécurité</title>
+ <p>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 <a href="../suexec.html">suexec</a>.</p></note>
</usage>
<seealso><directive module="mod_unixd">User</directive></seealso>
<directivesynopsis>
<name>VHostGroup</name>
-<description>Définit l'identifiant du groupe sous lequel s'exécute un
+<description>Définit l'identifiant du groupe sous lequel s'exécute un
serveur virtuel.</description>
<syntax>VHostGroup <var>identifiant-groupe-unix</var></syntax>
-<default>Hérite de l'identifiant du groupe spécifié par la directive
+<default>Hérite de l'identifiant du groupe spécifié par la directive
<directive module="mod_unixd">Group</directive></default>
<contextlist><context>virtual host</context></contextlist>
<compatibility>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-threadés (<module>prefork</module> ou MPM
-personnalisé).</compatibility>
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé).</compatibility>
<usage>
- <p>La directive <directive>VHostGroup</directive> permet de définir
+ <p>La directive <directive>VHostGroup</directive> 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 <a
- href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp">Privilèges
- Solaris</a>. Comme la définition
+ 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 <a
+ href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp">Privilèges
+ Solaris</a>. Comme la définition
s'applique au <em>processus</em>, cette directive est incompatible
- avec les modules MPM threadés.</p>
- <p><var>Unix-group</var> peut être :</p>
+ avec les modules MPM threadés.</p>
+ <p><var>Unix-group</var> peut être :</p>
<dl>
<dt>Un nom de groupe</dt>
- <dd>Fait référence au groupe donné par son nom.</dd>
+ <dd>Fait référence au groupe donné par son nom.</dd>
- <dt><code>#</code> suivi d'un numéro de groupe.</dt>
- <dd>Fait référence au groupe donné par son numéro.</dd>
+ <dt><code>#</code> suivi d'un numéro de groupe.</dt>
+ <dd>Fait référence au groupe donné par son numéro.</dd>
</dl>
- <note type="warning"><title>Sécurité</title>
- <p>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
+ <note type="warning"><title>Sécurité</title>
+ <p>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 <a href="../suexec.html">suexec</a>.</p></note>
</usage>
<seealso><directive module="mod_unixd">Group</directive></seealso>
<directivesynopsis>
<name>VHostSecure</name>
-<description>Détermine si le serveur s'exécute avec une sécurité avancée
+<description>Détermine si le serveur s'exécute avec une sécurité avancée
pour les serveurs virtuels.</description>
<syntax>VHostSecure On|Off</syntax>
<default>VHostSecure On</default>
<contextlist><context>virtual host</context></contextlist>
<compatibility>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-threadés (<module>prefork</module> ou MPM
-personnalisé).</compatibility>
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé).</compatibility>
<usage>
- <p>Détermine si les serveurs virtuels traitent les requêtes avec une
- s
écurité avancée en supprimant les <a
+ <p>Détermine si les serveurs virtuels traitent les requêtes avec une
+ s
écurité avancée en supprimant les <a
href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp"
- >Privilèges</a> 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
+ >Privilèges</a> 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 <em>processus</em>, cette directive est incompatible
- avec les modules MPM threadés.</p>
+ avec les modules MPM threadés.</p>
<note><title>Note</title>
<p>Le fait que la directive <directive>VHostSecure</directive>
- empêche une application de fonctionner peut constituer un signal
- d'avertissement indiquant que la sécurité de l'application doit être
+ empêche une application de fonctionner peut constituer un signal
+ d'avertissement indiquant que la sécurité de l'application doit être
revue.</p></note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>VHostCGIMode</name>
-<description>Détermine si le serveur virtuel peut exécuter des
-sous-processus, et définit les privilèges disponibles pour ces
+<description>Détermine si le serveur virtuel peut exécuter des
+sous-processus, et définit les privilèges disponibles pour ces
dernier.</description>
<syntax>VHostCGIMode On|Off|Secure</syntax>
<default>VHostCGIMode On</default>
<contextlist><context>virtual host</context></contextlist>
<compatibility>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-threadés (<module>prefork</module> ou MPM
-personnalisé).</compatibility>
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé).</compatibility>
<usage>
- <p>Détermine si le serveur virtuel est autorisé à exécuter fork et
- exec, et d
éfinit les <a
+ <p>Détermine si le serveur virtuel est autorisé à exécuter fork et
+ exec, et d
éfinit les <a
href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp"
- >privilèges</a> requis pour exécuter des sous-processus. Si cette
- directive est définie à <var>Off</var> le serveur virtuel ne
- disposera d'aucun privilège et ne pourra exécuter ni des programmes
+ >privilèges</a> requis pour exécuter des sous-processus. Si cette
+ directive est définie à <var>Off</var> 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
<module>mod_cgi</module>, ni des programmes externes similaires tels
- que ceux créés via le module <module>mod_ext_filter</module> ou les
- programmes de réécriture externes utilisés par la directive
+ que ceux créés via le module <module>mod_ext_filter</module> ou les
+ programmes de réécriture externes utilisés par la directive
<directive module="mod_rewrite">RewriteMap</directive>. 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 <a
+ 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 <a
href="https://httpd.apache.org/mod_fcgid/">mod_fcgid</a>, ce qui est la
- solution recommandée sous Solaris.</p>
- <p>Si cette directive est définie à <var>On</var> ou
- <var>Secure</var>, le serveur virtuel pourra exécuter les scripts et
- programmes externes cités ci-dessus. Définir la directive
- <directive>VHostCGIMode</directive> à <var>Secure</var> a pour effet
- supplémentaire de n'accorder aucun privilège aux sous-processus,
- comme décrit dans la directive
+ solution recommandée sous Solaris.</p>
+ <p>Si cette directive est définie à <var>On</var> ou
+ <var>Secure</var>, le serveur virtuel pourra exécuter les scripts et
+ programmes externes cités ci-dessus. Définir la directive
+ <directive>VHostCGIMode</directive> à <var>Secure</var> a pour effet
+ supplémentaire de n'accorder aucun privilège aux sous-processus,
+ comme décrit dans la directive
<directive>VHostSecure</directive>.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>DTracePrivileges</name>
-<description>Détermine si les privilèges requis par dtrace sont
-activés.</description>
+<description>Détermine si les privilèges requis par dtrace sont
+activés.</description>
<syntax>DTracePrivileges On|Off</syntax>
<default>DTracePrivileges Off</default>
<contextlist><context>server config</context></contextlist>
<compatibility>>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-threadés (<module>prefork</module> ou MPM
-personnalisé).</compatibility>
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé).</compatibility>
<usage>
- <p>Cette directive qui s'applique à l'ensemble du serveur permet de
- d
éterminer si Apache s'exécutera avec les <a
+ <p>Cette directive qui s'applique à l'ensemble du serveur permet de
+ d
éterminer si Apache s'exécutera avec les <a
href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp"
- >privil
èges</a> requis pour exécuter <a
+ >privil
èges</a> requis pour exécuter <a
href="http://sosc-dr.sun.com/bigadmin/content/dtrace/">dtrace</a>.
- Notez que la définition <var>DTracePrivileges On</var> n'activera
- pas à elle-seule DTrace, mais que <var>DTracePrivileges Off</var>
- l'empêchera de fonctionner.</p>
+ Notez que la définition <var>DTracePrivileges On</var> n'activera
+ pas à elle-seule DTrace, mais que <var>DTracePrivileges Off</var>
+ l'empêchera de fonctionner.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>VHostPrivs</name>
-<description>Assigne des privilèges à un serveur virtuel.</description>
-<syntax>VHostPrivs [+-]?<var>nom-privilège</var> [[+-]?nom-privilège] ...</syntax>
+<description>Assigne des privilèges à un serveur virtuel.</description>
+<syntax>VHostPrivs [+-]?<var>nom-privilège</var> [[+-]?nom-privilège] ...</syntax>
<default>Aucun</default>
<contextlist><context>virtual host</context></contextlist>
<compatibility>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-threadés (<module>prefork</module> ou MPM
-personnalisé) et lorsque <module>mod_privileges</module> est construit
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé) et lorsque <module>mod_privileges</module> est construit
avec l'option de compilation
<var>BIG_SECURITY_HOLE</var>.</compatibility>
<p>La directive <directive>VHostPrivs</directive> permet d'assigner
des <a
href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp"
- >privilèges</a> au choix à un serveur virtuel. Chaque
- <var>nom-privilège</var> correspond à un privilège Solaris tel que
+ >privilèges</a> au choix à un serveur virtuel. Chaque
+ <var>nom-privilège</var> correspond à un privilège Solaris tel que
<var>file_setid</var> ou <var>sys_nfs</var>.</p>
- <p><var>nom-privilège</var> peut être éventuellement préfixé par +
- ou -, ce qui va respectivement accorder ou refuser le privilège. Si
- <var>nom-privilège</var> 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.</p>
+ <p><var>nom-privilège</var> peut être éventuellement préfixé par +
+ ou -, ce qui va respectivement accorder ou refuser le privilège. Si
+ <var>nom-privilège</var> 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.</p>
- <note type="warning"><title>Sécurité</title>
+ <note type="warning"><title>Sécurité</title>
<p>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
+ 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 !</p></note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>VHostCGIPrivs</name>
-<description>Assigne des privilèges au choix aux sous-processus créés
+<description>Assigne des privilèges au choix aux sous-processus créés
par un serveur virtuel.</description>
-<syntax>VHostPrivs [+-]?<var>nom-privilège</var> [[+-]?nom-privilège] ...</syntax>
+<syntax>VHostPrivs [+-]?<var>nom-privilège</var> [[+-]?nom-privilège] ...</syntax>
<default>Aucun</default>
<contextlist><context>virtual host</context></contextlist>
<compatibility>Disponible sous Solaris 10 et OpenSolaris avec les
-modules MPM non-threadés (<module>prefork</module> ou MPM
-personnalisé) et lorsque <module>mod_privileges</module> est construit
+modules MPM non-threadés (<module>prefork</module> ou MPM
+personnalisé) et lorsque <module>mod_privileges</module> est construit
avec l'option de compilation
<var>BIG_SECURITY_HOLE</var>.</compatibility>
<p>La directive <directive>VHostCGIPrivs</directive> permet
d'assigner des <a
href="http://sosc-dr.sun.com/bigadmin/features/articles/least_privilege.jsp"
- >privilèges</a> au choix aux sous-processus créés par un serveur
- virtuel, comme décrit dans la directive
+ >privilèges</a> au choix aux sous-processus créés par un serveur
+ virtuel, comme décrit dans la directive
<directive>VHostCGIMode</directive>. Chaque
- <var>nom-privilège</var> correspond à un privilège Solaris tel que
+ <var>nom-privilège</var> correspond à un privilège Solaris tel que
<var>file_setid</var> ou <var>sys_nfs</var>.</p>
- <p><var>nom-privilège</var> peut être éventuellement préfixé par +
- ou -, ce qui va respectivement accorder ou refuser le privilège. Si
- <var>nom-privilège</var> 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.</p>
+ <p><var>nom-privilège</var> peut être éventuellement préfixé par +
+ ou -, ce qui va respectivement accorder ou refuser le privilège. Si
+ <var>nom-privilège</var> 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.</p>
- <note type="warning"><title>Sécurité</title>
+ <note type="warning"><title>Sécurité</title>
<p>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
+ 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 !</p></note>
</usage>
</directivesynopsis>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1733403:1739051 (outdated) -->
+<!-- English Revision: 1739051 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : VIncent Deffontaines -->
<!--
module <module>mod_rewrite</module>. Il décrit l'utilisation de la
directive <directive module="mod_rewrite">RewriteMap</directive>, et
fournit des exemples pour chacun des différents types de
- <code>RewriteMap</code>.</p>
+ <directive module="mod_rewrite">RewriteMap</directive>.</p>
<note type="warning">Notez que la plupart de ces exemples ne
fonctionneront pas en l'état dans le contexte de votre configuration
données, ceux-ci étant par ailleurs énumérés dans la documentation de
référence de <directive module="mod_rewrite">RewriteMap</directive>.</p>
- <p>La syntaxe de la directive <code>RewriteMap</code> est la suivante
+ <p>La syntaxe de la directive <directive module="mod_rewrite">RewriteMap</directive> est la suivante
:</p>
<highlight language="config">RewriteMap <em>MapName</em> <em>MapType</em>:<em>MapSource</em></highlight>
vide si aucune <em>DefaultValue</em> n'a été spécifiée.</p>
<p>Par exemple, vous pouvez définir une directive
- <directive>RewriteMap</directive> comme suit :</p>
+ <directive module="mod_rewrite">RewriteMap</directive> comme suit :</p>
<highlight language="config">RewriteMap examplemap "txt:/path/to/file/map.txt"</highlight>
<p>Vous pourrez par la suite utiliser cette table de correspondances
- dans une directive <directive>RewriteRule</directive> comme suit :</p>
+ dans une directive <directive module="mod_rewrite">RewriteRule</directive> comme suit :</p>
<highlight language="config">RewriteRule "^/ex/(.*)" "${examplemap:$1}"</highlight>
<p>Il est possible de spécifier une valeur par défaut qui sera utilisée
<note><title>Contexte de répertoire et fichiers.htaccess</title>
<p>
-Vous ne pouvez utiliser la directive <code>RewriteMap</code> ni dans
-les sections <Directory>, ni dans les fichiers
+Vous ne pouvez utiliser la directive <directive module="mod_rewrite">RewriteMap</directive> ni dans
+les sections <directive module="core" type="section">Directory</directive>, ni dans les fichiers
<code>.htaccess</code>. 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
exemples pour chacun d'entre eux.</p>
</section>
+ <section id="int">
+ <title>int: Fonction interne</title>
+
+ <p>Lorsque le type-map <code>int</code> 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 <code>ap_register_rewrite_mapfunc</code>.
+ Les fonctions fournies par défaut sont :
+ </p>
+
+ <ul>
+ <li><strong>toupper</strong>:<br/>
+ Met tous les caractères de la clé en majuscules.</li>
+ <li><strong>tolower</strong>:<br/>
+ Met tous les caractères de la clé en minuscules.</li>
+ <li><strong>escape</strong>:<br/>
+ Protège les caractères spéciaux de la clé en les
+ transformant en leur code hexadécimal.</li>
+ <li><strong>unescape</strong>:<br/>
+ Retraduit les codes hexadécimaux de la clé en caractères
+ spéciaux.</li>
+ </ul>
+
+ <p>
+ Pour utiliser une de ces fonctions, créez une
+ <code>RewriteMap</code> faisant référence à cette fonction int, et
+ utilisez-la dans votre règle <code>RewriteRule</code> :
+ </p>
+
+ <p> <strong>Redirige un URI vers son équivalent en minuscules</strong></p>
+ <highlight language="config">
+
+RewriteMap lc int:tolower
+RewriteRule "(.*)" "${lc:$1}" [R]
+ </highlight>
+
+ <note>
+ <p>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 <module>mod_speling</module>.
+ </p>
+ </note>
+
+ </section>
+
<section id="txt">
<title>txt: tables de correspondances au format texte</title>
<p>Voici un exemple d'entrées valides dans un fichier de
correspondances :</p>
- <p class="indent">
+ <example>
# Ligne de commentaires<br />
<strong><em>clé</em> <em>valeur-substitution</em></strong><br />
<strong><em>clé</em> <em>valeur-substitution</em></strong> # commentaire<br />
- </p>
+ </example>
<p>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
</example>
<p>Ainsi, lorsqu'une requête pour
- <code>http://example.com/produit/TELEVISION</code> arrive, elle est
- transformée en interne en <code>/prods.php?id=993</code>.</p>
+ <code>http://example.com/produit/TELEVISION</code> arrive, la directive
+ <directive module="mod_rewrite">RewriteRule</directive> s'applique, et la
+ requête est transformée en interne en <code>/prods.php?id=993</code>.</p>
<note><title>Note: fichiers .htaccess</title>
L'exemple donné est conçu pour être utilisé dans un contexte de
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]
+RewriteRule "^/(.*)" "http://${servers:dynamic}/$1" [P,L]
</highlight>
<p>Ainsi, lorsqu'une image est demandée et que la première règle
- convient, <code>RewriteMap</code> recherche la chaîne
+ convient, <directive module="mod_rewrite">RewriteMap</directive> recherche la chaîne
<code>statique</code> 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
- <code>RewriteRule</code>.</p>
+ <directive module="mod_rewrite">RewriteRule</directive>.</p>
<p>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
RewriteMap examplemap "dbm=sdbm:/etc/apache/mapfile.dbm"
</highlight>
- <p>Ce type peut être choisi parmi sdbm, gdbm, ndbm ou db. Il est
+ <p>Ce type peut être choisi parmi <code>sdbm</code>, <code>gdbm</code>,
+ <code>ndbm</code> ou <code>db</code>. Il est
cependant recommandé d'utiliser l'utilitaire <a
href="../programs/httxt2dbm.html">httxt2dbm</a> fourni avec le
serveur HTTP Apache, car il utilise la bibliothèque DBM appropriée,
</example>
<p>Vous pouvez alors faire référence au fichier obtenu dans votre
-directive <code>RewriteMap</code> :</p>
+directive <directive module="mod_rewrite">RewriteMap</directive> :</p>
<highlight language="config">
RewriteMap mapname "dbm:/etc/apache/mapfile.map"
</highlight>
fichiers nommés <code>fichier-map.map.dir</code> et
<code>fichier-map.map.pag</code>. Ceci est tout à fait normal, et vous
ne devez utiliser que le nom de base <code>fichier-map.map</code> dans votre
-directive <code>RewriteMap</code>.</p>
+directive <directive module="mod_rewrite">RewriteMap</directive>.</p>
</note>
<note><title>Mise en cache des recherches</title>
</section>
- <section id="int">
- <title>int: Fonction interne</title>
-
- <p>Lorsque le type-map <code>int</code> 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 <code>ap_register_rewrite_mapfunc</code>.
- Les fonctions fournies par défaut sont :
- </p>
-
- <ul>
- <li><strong>toupper</strong>:<br/>
- Met tous les caractères de la clé en majuscules.</li>
- <li><strong>tolower</strong>:<br/>
- Met tous les caractères de la clé en minuscules.</li>
- <li><strong>escape</strong>:<br/>
- Protège les caractères spéciaux de la clé en les
- transformant en leur code hexadécimal.</li>
- <li><strong>unescape</strong>:<br/>
- Retraduit les codes hexadécimaux de la clé en caractères
- spéciaux.</li>
- </ul>
-
- <p>
- Pour utiliser une de ces fonctions, créez une
- <code>RewriteMap</code> faisant référence à cette fonction int, et
- utilisez-la dans votre règle <code>RewriteRule</code> :
- </p>
-
- <p> <strong>Redirige un URI vers son équivalent en minuscules</strong></p>
- <highlight language="config">
-
-RewriteMap lc int:tolower
-RewriteRule "(.*)" "${lc:$1}" [R]
- </highlight>
-
- <note>
- <p>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 <module>mod_speling</module>.
- </p>
- </note>
-
- </section>
-
<section id="prg"><title>prg: Programme de réécriture externe</title>
<p>Lorque le type-map <code>prg</code> est spécifié, la source est
<section id="summary">
<title>Résumé</title>
- <p>La directive <directive>RewriteMap</directive> peut apparaître
+ <p>La directive <directive module="mod_rewrite">RewriteMap</directive> peut apparaître
plusieurs fois. Utilisez une directive
- <directive>RewriteMap</directive> pour chaque fonction de mise en
+ <directive module="mod_rewrite">RewriteMap</directive> pour chaque fonction de mise en
correspondance pour déclarer son fichier de correspondances.</p>
<p>Bien que l'on ne puisse pas <strong>déclarer</strong> de fonction
de mise en correspondance dans un contexte de répertoire (fichier
- <code>.htaccess</code> ou section <Directory>), il est
+ <code>.htaccess</code> ou section <directive module="core"
+ type="section">Directory</directive>), il est
possible d'utiliser cette fonction dans un tel contexte.</p>
</section>
n'écrase pas les fichiers des autres instances.</p>
<p>Vous devez aussi prendre garde aux autres situations de compétition,
- comme l'utilisation de l'enregistrement des logs avec un transfert de ceux-ci
-
dans le style <program>rotatelogs</program>. Plusieurs instances
- du programme
de <program>rotatelogs</program> qui tentent d'effectuer
+ comme l'enregistrement des logs avec un transfert de ceux-ci
+
via un pipe vers le programme <program>rotatelogs</program>. Plusieurs instances
+ du programme <program>rotatelogs</program> 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.</p></note>
</section>
-<?xml version="1.0" encoding="ISO-8859-1" ?>
+<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 1686713:1738542 (outdated) -->
+<!-- English Revision: 1738542 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<manualpage metafile="upgrading.xml.meta">
-<title>Mise à jour de la version 2.2 vers la version 2.4</title>
+<title>Mise à jour de la version 2.2 vers la version 2.4</title>
<summary>
- <p>Afin d'assister les utilisateurs lors de leurs opérations de mise à
+ <p>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
+ 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 <a
- href="new_features_2_4.html">Nouvelles fonctionnalités</a>, ou dans
- le fichier <code>src/CHANGES</code>. Les développeurs d'applications
- et de modules trouveront un résumé des modifications de l'API dans la
- vue d'ensemble <a href="developer/new_api_2_4.html">Mises à jour de
+ href="new_features_2_4.html">Nouvelles fonctionnalités</a>, ou dans
+ le fichier <code>src/CHANGES</code>. Les développeurs d'applications
+ et de modules trouveront un résumé des modifications de l'API dans la
+ vue d'ensemble <a href="developer/new_api_2_4.html">Mises à jour de
l'API</a>.</p>
- <p>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".</p>
+ <p>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".</p>
- <p>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
+ <p>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
<a href="http://httpd.apache.org/docs/2.2/upgrading.html">document de mise
- à jour de 2.0 vers 2.2.</a></p>
+ à jour de 2.0 vers 2.2.</a></p>
</summary>
<seealso><a href="new_features_2_4.html">Vue d'ensemble des nouvelles
-fonctionnalités du serveur HTTP Apache 2.4</a></seealso>
+fonctionnalités du serveur HTTP Apache 2.4</a></seealso>
<section id="compile-time">
- <title>Modifications des paramètres de compilation</title>
- <p>Le processus de compilation est très similaire à celui de la
+ <title>Modifications des paramètres de compilation</title>
+ <p>Le 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 <code>configure</code> (telle qu'elle
- est enregistrée dans le fichier <code>build/config.nice</code>
- situé dans le répertoire de compilation du serveur). Voici certains
- changements intervenus dans la configuration par défaut :</p>
+ est enregistrée dans le fichier <code>build/config.nice</code>
+ situé dans le répertoire de compilation du serveur). Voici certains
+ changements intervenus dans la configuration par défaut :</p>
<ul>
- <li>Les modules suivants ont été supprimés : mod_authn_default,
+ <li>Les modules suivants ont été supprimés : mod_authn_default,
mod_authz_default et mod_mem_cache. Si vous utilisiez
mod_mem_cache sous la version 2.2, vous devez maintenant utiliser
<module>mod_cache_disk</module> dans la version 2.4.</li>
- <li>Toutes les implémentations de répartition de charge ont été
- déplacées vers des sous-modules spécifiques de mod_proxy, comme
+ <li>Toutes les implémentations de répartition de charge ont été
+ déplacées vers des sous-modules spécifiques de mod_proxy, comme
<module>mod_lbmethod_bybusyness</module>. Vous devrez compiler et
- chargés tous les modules correspondants que votre configuration
+ chargés tous les modules correspondants que votre configuration
utilise.</li>
<li>Le support de BeOS, TPF, et des anciennes plates-formes telles
- que A/UX, Next, et Tandem a été supprimé, car
- elles ne sont plus considérées comme maintenues.</li>
+ que A/UX, Next, et Tandem a été supprimé, car
+ elles ne sont plus considérées comme maintenues.</li>
- <li>configure: les modules dynamiques (DSO) sont compilés par
- défaut</li>
+ <li>configure: les modules dynamiques (DSO) sont compilés par
+ défaut</li>
- <li>configure: par défaut, seul un jeu de modules de base est
- chargé. Les autres directives <directive>LoadModule</directive>
+ <li>configure: par défaut, seul un jeu de modules de base est
+ chargé. Les autres directives <directive>LoadModule</directive>
sont mises en commentaires dans le fichier de configuration.</li>
- <li>configure: le jeu de modules "most" est compilé par défaut</li>
+ <li>configure: le jeu de modules "most" est compilé par défaut</li>
<li>configure: le jeu de modules "reallyall" ajoute les modules de
- développeur au jeu "all".</li>
+ développeur au jeu "all".</li>
</ul>
</section>
<section id="run-time">
- <title>Modifications de la configuration à l'exécution</title>
+ <title>Modifications de la configuration à l'exécution</title>
<p>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
+nécessiter une mise à jour des fichiers de configuration de la version
2.2 avant de les utiliser sous la version 2.4.</p>
<section id="authz">
<title>Autorisation</title>
- <p>Tout fichier de configuration qui gère des autorisations devra
- probablement être mis à jour.</p>
+ <p>Tout fichier de configuration qui gère des autorisations devra
+ probablement être mis à jour.</p>
<p>Vous devez vous reporter au document <a
- href="howto/auth.html">Authentification, autorisation et contrôle
- d'acc
ès</a>, et plus particulièrement à la section <a
+ href="howto/auth.html">Authentification, autorisation et contrôle
+ d'acc
ès</a>, et plus particulièrement à la section <a
href="howto/auth.html#beyond">Pour aller plus loin qu'une simple
- autorisation</a> qui explique les nouveaux mécanismes permettant de
- contrôler l'ordre dans lequel les directives d'autorisation sont
- appliquées.</p>
+ autorisation</a> qui explique les nouveaux mécanismes permettant de
+ contrôler l'ordre dans lequel les directives d'autorisation sont
+ appliquées.</p>
- <p>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
+ <p>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 <directive
+ ont été remplacées par les directives plus explicites <directive
module="mod_authz_core">RequireAny</directive>, <directive
module="mod_authz_core">RequireNone</directive>, et <directive
module="mod_authz_core">RequireAll</directive>.</p>
<p>Si vous utilisez <module>mod_authz_dbm</module>, vous devez
- mettre à jour votre configuration en remplaçant les directives du
+ mettre à jour votre configuration en remplaçant les directives du
style <code>Require group ...</code> par des directives du style
<code>Require dbm-group ...</code>.</p>
<section id="access">
- <title>Contrôle d'accès</title>
+ <title>Contrôle d'accès</title>
- <p>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 <directive
+ <p>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 <directive
module="mod_access_compat">Order</directive>, <directive
module="mod_access_compat">Allow</directive>, <directive
module="mod_access_compat">Deny</directive>, et <directive
module="mod_access_compat">Satisfy</directive>.</p>
- <p>Dans la version 2.4, ce contrôle d'accès est assuré, comme tout
- contrôle d'autorisation, par le nouveau module
+ <p>Dans la version 2.4, ce contrôle d'accès est assuré, comme tout
+ contrôle d'autorisation, par le nouveau module
<module>mod_authz_host</module>. Bien que le module
- <module>mod_access_compat</module> 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.</p>
+ <module>mod_access_compat</module> 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.</p>
- <p>Voici quelques exemples de contrôle d'accès avec l'ancienne et
- la nouvelle méthode :</p>
-
- <p>Dans cet exemple, toutes les requêtes sont rejetées :</p>
+ <note><title>Mélanger anciennes et nouvelles directives</title>
+ <p>Mélanger d'anciennes directives comme <directive
+ module="mod_access_compat">Order</directive>, <directive
+ module="mod_access_compat">Allow</directive> ou <directive
+ module="mod_access_compat">Deny</directive> avec des nouvelles comme
+ <directive module="mod_authz_core">Require</directive> est techniquement
+ possible mais déconseillé. En effet, <module>mod_access_compat</module> 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.
+ </p>
+ </note>
+
+ <p>Voici quelques exemples de contrôle d'accès avec l'ancienne et
+ la nouvelle méthode :</p>
+
+ <p>Dans cet exemple, toutes les requêtes sont rejetées :</p>
<example>
<title>version 2.2 :</title>
<highlight language="config">
</highlight>
</example>
- <p>Dans cet exemple, toutes les requêtes sont acceptées :</p>
+ <p>Dans cet exemple, toutes les requêtes sont acceptées :</p>
<example>
<title>version 2.2 :</title>
<highlight language="config">
</highlight>
</example>
- <p>Dans l'exemple suivant, tous les hôtes du domaine example.org
- ont l'autorisation d'accès, tous les autres sont rejetés :</p>
+ <p>Dans l'exemple suivant, tous les hôtes du domaine example.org
+ ont l'autorisation d'accès, tous les autres sont rejetés :</p>
+
+ <example>
+ <title>version 2.2 :</title>
+ <highlight language="config">
+Order Deny,Allow
+Deny from all
+Allow from example.org
+ </highlight>
+ </example>
+ <example>
+ <title>version 2.4 :</title>
+ <highlight language="config">
+ Require host example.org
+ </highlight>
+ </example>
+ <p>Dans l'exemple suivant, tous les hôtes du domaine example.org
+ ont l'autorisation d'accès, tous les autres sont rejetés :</p>
<example>
<title>version 2.2 :</title>
Require host example.org
</highlight>
</example>
+
+ <p>Dans l'exemple suivant, le mélange d'anciennes et de nouvelles
+ directives produit des résultats inattendus.</p>
+
+ <example>
+ <title>Mélange d'anciennes et de nouvelles directives : RESULTAT
+ INATTENDU</title>
+ <highlight language="config">
+DocumentRoot "/var/www/html"
+
+<Directory "/">
+ AllowOverride None
+ Order deny,allow
+ Deny from all
+</Directory>
+
+<Location "/server-status">
+ SetHandler server-status
+ Require 127.0.0.1
+</Location>
+
+access.log - GET /server-status 403 127.0.0.1
+error.log - AH01797: client denied by server configuration: /var/www/html/server-status
+ </highlight>
+ </example>
+ <p>Pourquoi httpd interdit l'accès à server-status alors que la
+ configuration semble l'autoriser ? Parce que dans ce scénario de <a
+ href="sections.html#merging">fusion</a> de configuration, les
+ directives de <module>mod_access_compat</module> sont prioritaires par
+ rapport à celles de <module>mod_authz_host</module>.</p>
+
+ <p>L'exemple suivant quant à lui produit un résultat conforme :</p>
+
+ <example>
+ <title>Mélange d'anciennes et de nouvelles directives : RESULTAT
+ CONFORME</title>
+ <highlight language="config">
+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
+ </highlight>
+ </example>
+ <p>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.
+ </p>
</section>
</section>
<section id="config">
<title>Autres changements dans la configuration</title>
- <p>D'autres ajustements mineurs peuvent s'avérer nécessaires pour
- certaines configurations particulières, comme décrit ci-dessous.</p>
+ <p>D'autres ajustements mineurs peuvent s'avérer nécessaires pour
+ certaines configurations particulières, comme décrit ci-dessous.</p>
<ul>
- <li>La directive <directive>MaxRequestsPerChild</directive> a été renommée en
+ <li>La directive <directive>MaxRequestsPerChild</directive> a été renommée en
<directive module="mpm_common">MaxConnectionsPerChild</directive>;
- ce nouveau nom reflète mieux l'usage de cette directive.
- L'ancien nom est encore supporté.</li>
+ ce nouveau nom reflète mieux l'usage de cette directive.
+ L'ancien nom est encore supporté.</li>
<li>La directive <directive>MaxClients</directive> a
- été renommée en <directive
+ été renommée en <directive
module="mpm_common">MaxRequestWorkers</directive>; ce nouveau
- nom reflète mieux l'usage de cette directive. Pour les
+ nom reflète mieux l'usage de cette directive. Pour les
modules multiprocessus asynchrones, comme <module>event</module>, le nombre
- maximal de clients n'est pas équivalent au nombre de threads du
- worker. L'ancien nom est encore supporté.</li>
+ maximal de clients n'est pas équivalent au nombre de threads du
+ worker. L'ancien nom est encore supporté.</li>
<li>La directive <directive
module="core">DefaultType</directive> ne produit plus aucun
- effet, si ce n'est d'émettre un avertissement si elle est
- définie à une valeur autre que <code>none</code>. D'autres
+ effet, si ce n'est d'émettre un avertissement si elle est
+ définie à une valeur autre que <code>none</code>. D'autres
directives de configuration la remplacent dans la version 2.4.
</li>
- <li>La valeur par défaut de la directive <directive
+ <li>La valeur par défaut de la directive <directive
module="core">AllowOverride</directive> est maintenant
<code>None</code>.</li>
- <li>La valeur par défaut de la directive <directive
+ <li>La valeur par défaut de la directive <directive
module="core">EnableSendfile</directive> est maintenant Off.</li>
- <li>La valeur par défaut de la directive <directive
+ <li>La valeur par défaut de la directive <directive
module="core">FileETag</directive> est maintenant "MTime Size"
(sans INode).</li>
<li><module>mod_dav_fs</module>: le format du fichier <directive
- module="mod_dav_fs">DavLockDB</directive> a changé pour les systèmes
+ module="mod_dav_fs">DavLockDB</directive> a changé pour les systèmes
avec inodes. L'ancien fichier <directive
- module="mod_dav_fs">DavLockDB</directive> doit être supprimé dans le
- cadre de la mise à jour.
+ module="mod_dav_fs">DavLockDB</directive> doit être supprimé dans le
+ cadre de la mise à jour.
</li>
<li>La directive <directive module="core">KeepAlive</directive>
n'accepte que les valeurs <code>On</code> ou <code>Off</code>.
- Avant, toute valeur autre que "Off" ou "0" était traitée comme
+ Avant, toute valeur autre que "Off" ou "0" était traitée comme
"On".</li>
<li>Les directives AcceptMutex, LockFile, RewriteLock, SSLMutex,
- SSLStaplingMutex et WatchdogMutexPath ont été remplacées par la
+ SSLStaplingMutex et WatchdogMutexPath ont été remplacées par la
directive unique <directive module="core">Mutex</directive>.
- 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 <directive
+ 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 <directive
module="core">Mutex</directive>.</li>
<li><module>mod_cache</module>: la directive <directive
module="mod_cache">CacheIgnoreURLSessionIdentifiers</directive>
- 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
- <code>sessionid</code> pour correspondre à
+ 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
+ <code>sessionid</code> pour correspondre à
<code>/une-application/image.gif;jsessionid=123456789</code>,
- vous devez maintenant utiliser la chaîne de correspondance
- complète <code>jsessionid</code>.
+ vous devez maintenant utiliser la chaîne de correspondance
+ complète <code>jsessionid</code>.
</li>
- <li><module>mod_cache</module>: le second paramètre de la
+ <li><module>mod_cache</module>: le second paramètre de la
directive <directive module="mod_cache">CacheEnable</directive>
- 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.</li>
+ 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.</li>
<li><module>mod_ldap</module>: la directive <directive
module="mod_ldap">LDAPTrustedClientCert</directive> 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.</li>
+ 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.</li>
<li><module>mod_filter</module>: la syntaxe de la directive
<directive module="mod_filter">FilterProvider</directive> utilise
- maintenant une expression booléenne pour déterminer si un filtre
+ maintenant une expression booléenne pour déterminer si un filtre
s'applique.
</li>
<li><module>mod_include</module>:
<ul>
- <li>L'élément <code>#if expr</code> utilise maintenant le
- nouvel <a href="expr.html">interpréteur d'expressions</a>.
- L'ancienne syntaxe peut être réactivée via la directive
+ <li>L'élément <code>#if expr</code> utilise maintenant le
+ nouvel <a href="expr.html">interpréteur d'expressions</a>.
+ L'ancienne syntaxe peut être réactivée via la directive
<directive
module="mod_include">SSILegacyExprParser</directive>.
</li>
- <li>Dans la portée du répertoire, une directive de
- configuration SSI* ne provoque plus la réinitialisation à
- leur valeur par défaut de toutes les directives SSI* de
- niveau répertoire.</li>
+ <li>Dans la portée du répertoire, une directive de
+ configuration SSI* ne provoque plus la réinitialisation à
+ leur valeur par défaut de toutes les directives SSI* de
+ niveau répertoire.</li>
</ul>
</li>
<li><module>mod_charset_lite</module> : l'option
- <code>DebugLevel</code> a été supprimée en faveur d'une
+ <code>DebugLevel</code> a été supprimée en faveur d'une
configuration de la directive <directive
- module="core">LogLevel</directive> au niveau répertoire.
+ module="core">LogLevel</directive> au niveau répertoire.
</li>
<li><module>mod_ext_filter</module> : l'option
- <code>DebugLevel</code> a été supprimée en faveur d'une
+ <code>DebugLevel</code> a été supprimée en faveur d'une
configuration de la directive <directive
- module="core">LogLevel</directive> au niveau répertoire.
+ module="core">LogLevel</directive> au niveau répertoire.
</li>
<li><module>mod_proxy_scgi</module>: certaines applications web
ne fonctionneront plus correctement avec la nouvelle
- configuration de <code>PATH_INFO</code> qui est différente de
+ configuration de <code>PATH_INFO</code> 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
+ précédente peut être
+ restaurée en définissant la variable
<code>proxy-scgi-pathinfo</code>.</li>
- <li><module>mod_ssl</module>: le contrôle de révocation des
- certificats basé sur les CRL doit être maintenant explicitement
- configuré via la directive <directive
+ <li><module>mod_ssl</module>: le contrôle de révocation des
+ certificats basé sur les CRL doit être maintenant explicitement
+ configuré via la directive <directive
module="mod_ssl">SSLCARevocationCheck</directive>.
</li>
ligne est maintenant 1Mo.
</li>
- <li><module>mod_reqtimeout</module>: si ce module est chargé, il
- définit maintenant certains temps d'attente par défaut.</li>
+ <li><module>mod_reqtimeout</module>: si ce module est chargé, il
+ définit maintenant certains temps d'attente par défaut.</li>
<li><module>mod_dumpio</module>: la directive
- <directive>DumpIOLogLevel</directive> n'est plus supportée. Les
- données sont toujours enregistrées au niveau <code>trace7</code>
+ <directive>DumpIOLogLevel</directive> n'est plus supportée. Les
+ données sont toujours enregistrées au niveau <code>trace7</code>
de <directive module="core">LogLevel</directive></li>
- <li>Jusqu'à la version 2.2, sur les plateformes de style Unix,
- les commandes de redirection des logs définies via <directive
+ <li>Jusqu'à la version 2.2, sur les plateformes de style Unix,
+ les commandes de redirection des logs définies via <directive
module="core">ErrorLog</directive> ou <directive
- module="mod_log_config">CustomLog</directive> étaient invoquées
+ module="mod_log_config">CustomLog</directive> étaient invoquées
en utilisant <code>/bin/sh -c</code>. A
partir de la version 2.4, les commandes de redirection des logs
- sont exécutées directement. Pour retrouver l'ancien
+ sont exécutées directement. Pour retrouver l'ancien
comportement, voir la <a href="logs.html#piped">documentation
sur la redirection des logs</a></li>
<ul>
<li><module>mod_auto_index</module>: extrait maintenant les titres
- et affiche la description pour les fichiers .xhtml qui étaient
- jusqu'alors ignorés.</li>
+ et affiche la description pour les fichiers .xhtml qui étaient
+ jusqu'alors ignorés.</li>
- <li><module>mod_ssl</module> : le format par défaut des variables
- <code>*_DN</code> a changé. Il est cependant encore possible
+ <li><module>mod_ssl</module> : le format par défaut des variables
+ <code>*_DN</code> a changé. Il est cependant encore possible
d'utiliser l'ancien format via la nouvelle option
<code>LegacyDNStringFormat</code> de la directive <directive
module="mod_ssl">SSLOptions</directive>. Le protocole SSLv2 n'est
- plus supporté. Les directives <directive
+ plus supporté. Les directives <directive
module="mod_ssl">SSLProxyCheckPeerCN</directive> et
<directive module="mod_ssl">SSLProxyCheckPeerExpire</directive>
- 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).</li>
+ 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).</li>
- <li><program>htpasswd</program> utilise maintenant par défaut les
- condensés MD5 sur toutes les plates-formes.</li>
+ <li><program>htpasswd</program> utilise maintenant par défaut les
+ condensés MD5 sur toutes les plates-formes.</li>
<li>La directive <directive
module="core">NameVirtualHost</directive> n'a plus aucun effet, si
- ce n'est l'émission d'un avertissement. Toute combinaison
+ 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.
+ traitée implicitement comme un serveur virtuel basé sur le nom.
</li>
<li><module>mod_deflate</module> 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.
+ 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.
</li>
<li>Les pages d'erreur multilingues de la version 2.2.x ne
- fonctionneront qu'après avoir été corrigées pour
- respecter la nouvelle syntaxe de l'élément <code>#if expr=</code>
+ fonctionneront qu'après avoir été corrigées pour
+ respecter la nouvelle syntaxe de l'élément <code>#if expr=</code>
du module <module>mod_include</module>, ou si la directive
<directive module="mod_include">SSILegacyExprParser</directive> a
- été activée pour le répertoire contenant les pages d'erreur.
+ été activée pour le répertoire contenant les pages d'erreur.
</li>
- <li>La fonctionnalité fournie par <code>mod_authn_alias</code>
- dans les précédentes versions (en fait la directive
+ <li>La fonctionnalité fournie par <code>mod_authn_alias</code>
+ dans les précédentes versions (en fait la directive
<directive module="mod_authn_core">AuthnProviderAlias</directive>)
est maintenant fournie par <module>mod_authn_core</module>.
</li>
- <li>Les directives RewriteLog et RewriteLogLevel ont été
- supprimées. Leur fonctions sont maintenant assurées par la
+ <li>Les directives RewriteLog et RewriteLogLevel ont été
+ supprimées. Leur fonctions sont maintenant assurées par la
directive <directive
- module="core">LogLevel</directive> qui permet de définir
- un niveau de journalisation approprié pour le module
+ module="core">LogLevel</directive> qui permet de définir
+ un niveau de journalisation approprié pour le module
<module>mod_rewrite</module>. Voir aussi la section <a
href="mod/mod_rewrite.html#logging">journalisation de
mod_rewrite</a>.</li>
<section id="third-party">
<title>Modules tiers</title>
- <p>Tous les modules tiers doivent être recompilés pour la
- version 2.4 avant d'être chargés.</p>
+ <p>Tous les modules tiers doivent être recompilés pour la
+ version 2.4 avant d'être chargés.</p>
- <p>De nombreux modules tiers conçus pour la version 2.2
+ <p>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 <a
- href="developer/new_api_2_4.html">Mise à jour de l'API</a>.</p>
+ version 2.4. Certains nécessiteront cependant des modifications ; se
+ reporter
à la vue d'ensemble <a
+ href="developer/new_api_2_4.html">Mise à jour de l'API</a>.</p>
</section>
<section id="commonproblems">
- <title>Problèmes de mise à jour courants</title>
- <ul><li>Erreurs au démarrage :
+ <title>Problèmes de mise à jour courants</title>
+ <ul><li>Erreurs au démarrage :
<ul>
<li><code>Invalid command 'User', perhaps misspelled or defined by
a module not included in the server configuration</code> - chargez
by a module not included in the server configuration</code>, ou
<code>Invalid command 'Order', perhaps misspelled or defined by a
module not included in the server configuration</code> - chargez
- le module <module>mod_access_compat</module>, ou mettez à jour
+ le module <module>mod_access_compat</module>, ou mettez à jour
vers la version 2.4 les directives d'autorisation.</li>
<li><code>Ignoring deprecated use of DefaultType in line NN of
/path/to/httpd.conf</code> - supprimez la directive <directive
module="core">DefaultType</directive> et remplacez-la par les
- directives de configuration appropriées.</li>
+ directives de configuration appropriées.</li>
<li><code>Invalid command 'AddOutputFilterByType', perhaps misspelled
or defined by a module not included in the server configuration
</code> - la directive <directive
- module="mod_filter">AddOutputFilterByType</directive> qui était
- jusqu'alors implémentée par le module core, l'est maintenant par
- le module mod_filter, qui doit donc être chargé.</li>
+ module="mod_filter">AddOutputFilterByType</directive> qui était
+ jusqu'alors implémentée par le module core, l'est maintenant par
+ le module mod_filter, qui doit donc être chargé.</li>
</ul></li>
- <li>Erreurs de traitement des requêtes :
+ <li>Erreurs de traitement des requêtes :
<ul>
<li><code>configuration error: couldn't check user: /path</code> -
chargez le module <module>mod_authn_core</module>.</li>
- <li>Les fichiers <code>.htaccess</code> ne sont pas traités -
- Vérifiez la présence d'une directive <directive
- module="core">AllowOverride</directive> appropriée ; sa valeur par
- défaut est maintenant <code>None</code>.</li>
+ <li>Les fichiers <code>.htaccess</code> ne sont pas traités -
+ Vérifiez la présence d'une directive <directive
+ module="core">AllowOverride</directive> appropriée ; sa valeur par
+ défaut est maintenant <code>None</code>.</li>
</ul>
</li>
</ul>
projects / apache / commitdiff