<?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: 1934650:1935409 (outdated) -->
+<!-- English Revision: 1935409 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<title>Variables d'environnement de CGI</title>
<p>La spécification sur les CGIs (<rfc section="4.1">3875</rfc>) définit un
- certain nombre de variables d'environnement qui s'ajoutent à celles définies
- par la spécification de HTTP. Elles ont été plus largement adoptées et
+ certain nombre de méta-variables dont beaucoup sont affectées de leur valeur
+ à partir des en-têtes HTTP. Apache httpd les met à disposition en tant que
+ variables d’environnement pour les scripts CGI et d’autres mécanismes de
+ traitement des requêtes. Elles ont été plus largement adoptées et
constituent une méthode standard pour transmettre des informations entre le
navigateur et le serveur, et entre les processus au sein du serveur. Nous en
décrivons quelques unes ici. Pour une liste complète des variables de
<?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: 1933720:1935507 (outdated) -->
+<!-- English Revision: 1935507 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<section id="host"><title>Contrôle d'accès en fonction de l'hôte du
client</title>
<p>
- Si vous souhaitez restreindre l'accès à certaines parties de votre
- site web en fonction de l'adresse de l'hôte de vos visiteurs, le
- plus simple pour y parvenir consiste à utiliser le module
+ Si vous souhaitez restreindre l'accès à certaines parties de votre site web
+ en fonction de l'adresse de l'hôte de vos visiteurs, utilisez le module
<module>mod_authz_host</module>.
</p>
<p>Les directives Require s'utilisent comme suit :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
Require host <var>address</var>
Require ip <var>ip.address</var>
- </highlight>
+</highlight>
+</example>
<p>Dans la première forme, <var>nom-hôte</var> est un nom de domaine
pleinement qualifié (fqdn), ou un nom de domaine partiel ; vous
sous-réseau ou une spécification CIDR de la forme réseau/nnn. Il est
possible de spécifier des adresses IPv4 ou IPv6.</p>
+<example><title>Exemples de formats d’adresse IP</title>
+<highlight language="config">
+# Adresse IP complète
+Require ip 10.2.3.4
+# Adresse IP partielle (correspond à tout hôte dans la tranche 172.20.0.0/16)
+Require ip 172.20
+# Paire réseau/masque
+Require ip 192.168.1.0/255.255.255.0
+# Spécification réseau/CIDR
+Require ip 192.168.1.0/24
+# Adresse IPv6
+Require ip 2001:db8::a00:20ff:fea7:ccea
+# Adresse IPv6 avec CIDR
+Require ip 2001:db8:1::/48
+</highlight>
+</example>
+
<p>Voir <a href="../mod/mod_authz_host.html#requiredirectives">la
documentation de mod_authz_host</a> pour d'autres exemples de cette
syntaxe.</p>
<p>Vous pouvez insérer le mot-clé <code>not</code> pour inverser un
- critère particulier. Notez que le mot <code>not</code> réalise la
+ critère particulier. Le mot <code>not</code> réalise la
négation sur la valeur, et ne peut pas être utilisé seul pour autoriser
ou interdire une requête, car <em>non vrai</em> ne
veut pas ici forcément dire <em>faux</em>. Ainsi, pour interdire la
spamer votre forum, vous pouvez ajouter cette ligne pour lui refuser
l'accès :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
<RequireAll>
- Require all granted
- Require not ip 10.252.46.165
+Require all granted
+Require not ip 10.252.46.165
</RequireAll>
- </highlight>
+</highlight>
+</example>
<p>Les visiteurs possédant cette adresse (<code>10.252.46.165</code>) ne pourront pas voir le
contenu concerné par cette directive. Si vous voulez interdir
l'accès à une machine en fonction de son nom, vous pouvez ajouter
ceci :</p>
- <highlight language="config">Require not host <var>host.example.com</var></highlight>
+<example>
+<highlight language="config">
+Require not host <var>host.example.com</var>
+</highlight>
+</example>
<p>Et si vous voulez interdire l'accès à un domaine particulier,
vous pouvez spécifier des adresses IP partielles ou des noms de
domaine, comme ceci :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
Require not ip 192.168.205
-Require not host phishers.example.com moreidiots.example
+Require not host phishers.example.com badguys.example
Require not host gov
- </highlight>
+</highlight>
+</example>
<p>Les directives <directive
module="mod_authz_core">RequireAll</directive>, <directive
fonction du user-agent (le type de navigateur), vous pouvez
spécifier ceci :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
<If "%{HTTP_USER_AGENT} == 'BadBot'">
- Require all denied
+Require all denied
</If>
- </highlight>
+</highlight>
+</example>
<p>En utilisant la syntaxe <code>expr</code> de la directive
<directive module="mod_authz_core">Require</directive>, l'exemple
précédent peut aussi s'écrire :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
Require expr %{HTTP_USER_AGENT} != 'BadBot'
- </highlight>
+</highlight>
+</example>
<note><title>Avertissement :</title>
<p>Contrôler l'accès en fonction de l'en-tête
<p>Par exemple, pour bloquer l'accès à une ressources entre 20h et
7h du matin, vous pouvez utiliser <module>mod_rewrite</module> :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
RewriteEngine On
RewriteCond "%{TIME_HOUR}" ">=20" [OR]
RewriteCond "%{TIME_HOUR}" "<07"
RewriteRule "^/fridge" "-" [F]
- </highlight>
+</highlight>
+</example>
<p>Toute requête arrivant après 20h ou avant 7h du matin provoquera
l'envoi d'une réponse de type 403 Forbidden. Vous pouvez utiliser
<?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: 1933687:1935509 (outdated) -->
+<!-- English Revision: 1935509 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviwed by : Vincent Deffontaines -->
d'une directive <directive module="core">AllowOverride</directive>
du style :</p>
- <highlight language="config">AllowOverride AuthConfig</highlight>
+<example>
+<highlight language="config">
+AllowOverride AuthConfig
+</highlight>
+</example>
<p>Si vous avez l'intention d'ajouter les directives directement
- dans le fichier de configuration principal, vous devrez bien entendu
+ dans le fichier de configuration principal, vous devrez bien entendu
posséder les droits en écriture sur ce fichier.</p>
<p>Vous devrez aussi connaître un tant soit peu la structure des
fichier <code>httpd.conf</code> à l'intérieur d'une section <Directory
"/usr/local/apache/htdocs/secret"> :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
AuthType Basic
AuthName "Restricted Files"
-# (Following line optional)
+# (La ligne suivante est facultative)
AuthBasicProvider file
AuthUserFile "/usr/local/apache/passwd/passwords"
Require user rbowen
- </highlight>
+</highlight>
+</example>
<p>Examinons ces directives une à une. La directive <directive
module="mod_authn_core">AuthType</directive> définit la méthode
<p>Maintenant, vous devez modifier votre fichier
<code>.htaccess</code> comme suit :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
AuthType Basic
AuthName "By Invitation Only"
-# Optional line:
+# Ligne facultative :
AuthBasicProvider file
AuthUserFile "/usr/local/apache/passwd/passwords"
AuthGroupFile "/usr/local/apache/passwd/groups"
Require group GroupName
- </highlight>
+</highlight>
+</example>
<p>Maintenant, quiconque appartient au groupe
<code>Nom-de-groupe</code>, et possède une entrée dans le fichier
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>
+<example>
+<highlight language="config">
+Require valid-user
+</highlight>
+</example>
<p>Le remplacement de la ligne <code>Require user rbowen</code> par
la ligne <code>Require valid-user</code> autorisera l'accès à
<p>Par exemple, pour sélectionner un fichier dbm à la place d'un
fichier texte :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
<Directory "/www/docs/private">
- AuthName "Private"
- AuthType Basic
- AuthBasicProvider dbm
- AuthDBMUserFile "/www/passwords/passwd.dbm"
- Require valid-user
+AuthName "Private"
+AuthType Basic
+AuthBasicProvider dbm
+AuthDBMUserFile "/www/passwords/passwd.dbm"
+Require valid-user
</Directory>
- </highlight>
+</highlight>
+</example>
<p>D'autres options sont disponibles. Consultez la documentation de
<module>mod_authn_dbm</module> pour plus de détails.</p>
conjointement les fournisseurs d'authentification
file et LDAP :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
<Directory "/www/docs/private">
- AuthName "Private"
- AuthType Basic
- AuthBasicProvider file ldap
- AuthUserFile "/usr/local/apache/passwd/passwords"
- AuthLDAPURL ldap://ldaphost/o=yourorg
- Require valid-user
+AuthName "Private"
+AuthType Basic
+AuthBasicProvider file ldap
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthLDAPURL ldap://ldaphost/o=yourorg
+Require valid-user
</Directory>
- </highlight>
+</highlight>
+</example>
<p>Dans cet exemple, le fournisseur file va tenter d'authentifier
l'utilisateur en premier. S'il n'y parvient pas, le fournisseur LDAP
autorisation à base de fichier de groupes et une autorisation à base
de groupes LDAP.</p>
- <highlight language="config">
+<example>
+<highlight language="config">
<Directory "/www/docs/private">
- AuthName "Private"
- AuthType Basic
- AuthBasicProvider file
- AuthUserFile "/usr/local/apache/passwd/passwords"
- AuthLDAPURL ldap://ldaphost/o=yourorg
- AuthGroupFile "/usr/local/apache/passwd/groups"
- Require group GroupName
- Require ldap-group cn=mygroup,o=yourorg
+AuthName "Private"
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthLDAPURL ldap://ldaphost/o=yourorg
+AuthGroupFile "/usr/local/apache/passwd/groups"
+Require group GroupName
+Require ldap-group cn=mygroup,o=yourorg
</Directory>
- </highlight>
+</highlight>
+</example>
<p>Pour un scénario d'autorisation un peu plus avancé, des
directives de conteneur d'autorisation comme <directive
<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
- 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>
-
- <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>
-
- <highlight language="config">Require ip <var>address</var></highlight>
-
- <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>Par exemple, si vous voulez rejeter les spams dont une
- machine vous inonde, vous pouvez utiliser ceci :</p>
-
- <highlight language="config">
-<RequireAll>
- Require all granted
- Require not ip 10.252.46.165
-</RequireAll>
- </highlight>
-
- <p>Ainsi, les visiteurs en provenance de cette adresse ne
- pourront pas voir le contenu concerné par cette directive. Si,
- par contre, vous connaissez le nom de la machine, vous pouvez
- utiliser ceci :</p>
-
- <highlight language="config">
-<RequireAll>
- Require all granted
- Require not host host.example.com
-</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
- l'adresse ou du nom de domaine :</p>
-
- <highlight language="config">
-<RequireAll>
- Require all granted
- Require not ip 192.168.205
- Require not host phishers.example.com moreidiots.example
- Require not host ke
-</RequireAll>
- </highlight>
-
- <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>
+ <p>La vérification du nom d'utilisateur et du mot de passe ne
+ constituent qu'un aspect des méthodes d'authentification. Vous pouvez
+ aussi autoriser ou interdire l’accès en fonction d’autres critères tels
+ que l’adresse IP du client ou le nom d’hôte en utilisant les
+ fournisseurs d’autorisation <code>all</code>, <code>env</code>,
+ <code>host</code> et <code>ip</code> avec la directive <directive
+ module="mod_authz_core">Require</directive>.</p>
+
+ <p>Pour des détails complets et des exemples, voir le tutoriel <a
+ href="access.html">Access Control</a>.</p>
</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.
- 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
- 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
- fournisseurs(s) originels.</p>
- <p>Cette mise en cache apportera un gain en performance substantiel
- à certains utilisateurs.</p>
+ <p>Dans certains cas, l'authentification constitue une charge inacceptable
+ pour un fournisseur d'authentification ou votre réseau. Ceci est
+ susceptible d'affecter les utilisateurs du module
+ <module>mod_authn_dbd</module> (ou les fournisseurs tiers/personnalisés). Le
+ module <module>mod_authn_socache</module> met en cache les données
+ d'authentification, et réduit ainsi la charge du/des fournisseurs(s)
+ originels.</p> <p>Cette mise en cache apportera un gain en performance
+ substantiel à certains utilisateurs.</p>
</section>
<section id="moreinformation"><title>Pour aller plus loin . . .</title>
<?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: 1934247:1935518 (outdated) -->
+<!-- English Revision: 1935518 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<directive module="mod_authn_core">AuthName</directive>
<directive module="mod_authn_file">AuthUserFile</directive>
<directive module="mod_authz_groupfile">AuthGroupFile</directive>
- <directive module="mod_authz_core">Require</directive>
+ <directive module="mod_authz_core">Require</directive>
</directivelist>
</related>
<code>.config</code>, vous pouvez mettre ceci dans le fichier de
configuration de votre serveur :</p>
- <highlight language="config">
- AccessFileName ".config"
- </highlight>
+<example>
+<highlight language="config">
+AccessFileName ".config"
+</highlight>
+</example>
</note>
<p>Les directives dans les fichiers <code>.htaccess</code> utilisent la même
la documentation de cette directive contiendra une section Override,
spécifiant quelle valeur doit prendre la directive <directive
module="core">AllowOverride</directive> pour que cette directive
- soit traitée.</p>
+ soit autorisée.</p>
<note>La valeur par défaut de la directive <directive
module="core">AllowOverride</directive> est <code>None</code>. Cela signifie
<code>.htaccess</code> est chargé en mémoire chaque fois qu'un
document fait l'objet d'une requête.</p>
- <p>Notez aussi que httpd doit rechercher les fichiers
- <code>.htaccess</code> dans tous les répertoires de niveau
- supérieur, afin de rassembler toutes les directives qui s'appliquent
- au répertoire courant (Voir la section <a href="#how">comment sont
- appliquées les directives</a>). Ainsi, si un fichier fait l'objet
- d'une requête à partir d'un répertoire
- <code>/www/htdocs/exemple</code>, httpd doit rechercher les
- fichiers suivants :</p>
+ <p>En outre, httpd doit rechercher des fichiers <code>.htaccess</code> dans
+ tous les répertoires de niveau supérieur pour rassembler la totalité des
+ directives applicables (Voir la section <a href="#how">comment sont
+ appliquées les directives</a>). Ainsi, si un fichier fait l'objet d'une
+ requête à partir d'un répertoire <code>/www/htdocs/exemple</code>, httpd
+ doit rechercher les fichiers suivants :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
/.htaccess
/www/.htaccess
/www/htdocs/.htaccess
/www/htdocs/example/.htaccess
- </highlight>
+</highlight>
+</example>
<p>En conséquence, chaque accès à un fichier de ce répertoire
nécessite 4 accès au système de fichiers supplémentaires pour
rechercher des fichiers <code>.htaccess</code>, même si
- aucun de ces fichiers n'est présent. Notez que cet exemple ne peut
+ aucun de ces fichiers n'est présent. Cet exemple ne peut
se produire que si les fichiers <code>.htaccess</code> ont été
autorisés pour le répertoire <code>/</code>, ce qui est rarement le
cas.</p>
utilisateurs de modifier la configuration du serveur, il peut en
résulter des conséquences sur lesquelles vous n'aurez aucun
contrôle. Réfléchissez bien avant de donner ce privilège à vos
- utilisateurs. Notez aussi que ne pas donner aux utilisateurs les
+ utilisateurs. Ne pas donner aux utilisateurs les
privilèges dont ils ont besoin va entraîner une augmentation des
demandes de support technique. Assurez-vous d'avoir informé
clairement vos utilisateurs du niveau de privilèges que vous leur
contrôle plus fin que dans le cas de la directive <directive
module="core">AllowOverride</directive> seule :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
# N’autoriser que des directives spécifiques, pas des catégories entières de
# directives
AllowOverride None
AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCond
- </highlight>
+</highlight>
+</example>
<p>Avec cette configuration, toute directive non explicitement spécifiée
causera une erreur du serveur si elle est rencontrée dans un fichier
<code>.htaccess</code>. C’est un bon compromis entre possibilité et
impossibilité totales d’outrepasser la configuration globale.</p>
- <p>Notez que mettre un fichier <code>.htaccess</code> contenant une
- directive dans un répertoire <code>/www/htdocs/exemple</code>
- revient exactement au même que mettre la même directive dans une
- section Directory <code><Directory "/www/htdocs/exemple"></code>
- du fichier de configuration de votre serveur principal :</p>
+ <p>Placer une directive dans un fichier <code>.htaccess</code> dans un
+ répertoire <code>/www/htdocs/example</code> équivaut exactement à placer
+ cette même directive dans une section <code><Directory
+ "/www/htdocs/example"></code> de la configuration globale de votre
+ serveur :</p>
- <p>Fichier <code>.htaccess</code> dans
- <code>/www/htdocs/exemple</code> :</p>
+ <p>Fichier <code>.htaccess</code> dans <code>/www/htdocs/example</code>
+ :</p>
<example><title>Contenu du fichier .htaccess dans
- <code>/www/htdocs/exemple</code></title>
- <highlight language="config">AddType text/example ".exm"</highlight>
+ <code>/www/htdocs/example</code></title>
+<example>
+<highlight language="config">
+AddType text/example ".exm"
+</highlight>
+</example>
</example>
<example><title>Section de votre fichier
<code>httpd.conf</code></title>
- <highlight language="config">
+<example>
+<highlight language="config">
<Directory "/www/htdocs/example">
- AddType text/example ".exm"
+AddType text/example ".exm"
</Directory>
- </highlight>
+</highlight>
+</example>
</example>
<p>L'utilisation des fichiers <code>.htaccess</code> peut être
entièrement désactivée en définissant la directive <directive
module="core">AllowOverride</directive> à <code>none</code> :</p>
- <highlight language="config">AllowOverride None</highlight>
+<example>
+<highlight language="config">
+AllowOverride None
+</highlight>
+</example>
</section>
<section id="how"><title>Comment sont appliquées les directives ?</title>
<p>Les directives de configuration situées dans un fichier
<code>.htaccess</code> s'appliquent au répertoire dans lequel ce
fichier <code>.htaccess</code> se trouve, ainsi qu'à tous ses
- sous-répertoires. Cependant, il est important de garder à l'esprit
+ sous-répertoires. Cependant, souvenez-vous
qu'il peut y avoir des fichiers <code>.htaccess</code> dans les
répertoires de niveau supérieur. Les directives sont appliquées
selon l'ordre dans lequel elles sont rencontrées. Ainsi, les
<p>Dans le répertoire <code>/www/htdocs/exemple1</code> se trouve un
fichier <code>.htaccess</code> contenant ce qui suit :</p>
- <highlight language="config">Options +ExecCGI</highlight>
+<example>
+<highlight language="config">
+Options +ExecCGI
+</highlight>
+</example>
- <p>Note : "<code>AllowOverride Options</code>" doit être présent
+ <note>"<code>AllowOverride Options</code>" doit être présent
pour permettre l'utilisation de la directive "<directive
module="core">Options</directive>" dans les fichiers
- <code>.htaccess</code>.</p>
+ <code>.htaccess</code>.</note>
<p>Dans le répertoire <code>/www/htdocs/exemple1/exemple2</code> se
trouve un fichier <code>.htaccess</code> contenant ce qui suit
:</p>
- <highlight language="config">Options Includes</highlight>
+<example>
+<highlight language="config">
+Options Includes
+</highlight>
+</example>
<p>Ainsi, à cause de ce second fichier <code>.htaccess</code> du
répertoire <code>/www/htdocs/exemple1/exemple2</code>, l'exécution
définition de toute autre option dans les fichiers
<code>.htaccess</code>, vous pouvez utiliser :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
<Directory "/www/htdocs">
- AllowOverride All
+AllowOverride All
</Directory>
<Location "/">
- Options +IncludesNoExec -ExecCGI
+Options +IncludesNoExec -ExecCGI
</Location>
- </highlight>
+</highlight>
+</example>
<note>Dans cet exemple, on considère que le chemin défini par la
directive <directive module="core">DocumentRoot</directive> est
<p>Contenu du fichier <code>.htaccess</code> :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
AuthType Basic
AuthName "Password Required"
AuthUserFile "/www/passwords/password.file"
AuthGroupFile "/www/passwords/group.file"
Require group admins
- </highlight>
+</highlight>
+</example>
- <p>Notez que <code>AllowOverride AuthConfig</code> doit être présent
- pour que ces directives produisent leur effet.</p>
+ <note><code>AllowOverride AuthConfig</code> doit être présent
+ pour que ces directives produisent leur effet.</note>
<p>Vous pouvez vous référer au <a href="auth.html">tutoriel sur
l'authentification</a> pour une description plus détaillée de
on utilise les directives de configuration suivantes, placées dans un
fichier <code>.htaccess</code> enregistré dans le répertoire considéré :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
Options +Includes
AddType text/html "shtml"
AddHandler server-parsed shtml
- </highlight>
+</highlight>
+</example>
- <p>Notez que <code>AllowOverride Options</code> et <code>AllowOverride
+ <note><code>AllowOverride Options</code> et <code>AllowOverride
FileInfo</code> doivent être tous les deux présents pour que ces
- directives puissent produire leur effet.</p>
+ directives puissent produire leur effet.</note>
<p>Vous pouvez vous référer au <a href="ssi.html">tutoriel SSI</a>
pour une description plus détaillée des SSI.</p>
sont relatives au répertoire courant, et non à l'URI original. Considérez
les exemples suivants :</p>
+<example>
<highlight language="config">
# Dans httpd.conf
RewriteRule "^/images/(.+)\.jpg" "/images/$1.png"
# Dans un fichier .htaccess situé dans le répertoire images/
RewriteRule "^(.+)\.jpg" "$1.png"
</highlight>
+</example>
<p>On voit que si le fichier <code>.htaccess</code> se situe à la racine
de vos documents, le slash de tête est supprimé de la valeur de
remplacement. Il doit donc en être de même dans votre expression
rationnelle.</p>
-<p>Notez aussi que dans un contexte <code>.htaccess</code>, les expressions
+<p>Dans un contexte <code>.htaccess</code>, les expressions
rationnelles sont recompilées à chaque requête, alors que dans un contexte de
configuration principale, elle ne sont compilées qu’une seule fois et mises en
cache.</p>
l’exécution de programmes CGI dans un répertoire particulier. Pour y
parvenir, vous pouvez utiliser la configuration suivante :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
Options +ExecCGI
AddHandler cgi-script "cgi" "py"
- </highlight>
+</highlight>
+</example>
<p>Alternativement, si vous souhaitez que tous les fichiers d'un
répertoire donné soient considérés comme des programmes CGI, vous
pouvez utiliser la configuration suivante :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
Options +ExecCGI
SetHandler cgi-script
- </highlight>
+</highlight>
+</example>
- <p>Notez que <code>AllowOverride Options</code> et <code>AllowOverride
+ <note><code>AllowOverride Options</code> et <code>AllowOverride
FileInfo</code> doivent être tous les deux présents pour que ces
- directives puissent produire leur effet.</p>
+ directives puissent produire leur effet.</note>
<p>Vous pouvez vous référer au <a href="cgi.html">tutoriel CGI</a>
pour une description plus détaillée de la configuration et de la
dénué de sens dans votre ficher <code>.htaccess</code> et de recharger la
page :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
TestMe
- </highlight>
+</highlight>
+</example>
<p>Si aucune erreur (HTTP 500) n'est générée par le
serveur, il est pratiquement certain qu'une directive
utilisée dans votre fichier <code>.htaccess</code> n'est pas
permise.</p>
- <highlight language="config">
-[Tue May 06 09:12:31.528374 2025] [core:alert] [pid 12345] [client 192.168.1.50:54321] /var/www/html/.htaccess: DirectoryIndex not allowed here
- </highlight>
+<example>
+<highlight language="config">
+[Thu Jun 18 09:12:31.528374 2026] [core:alert] [pid 12345] [client 192.168.1.50:54321] /var/www/html/.htaccess: DirectoryIndex not allowed here
+</highlight>
+</example>
<p>Cela signifie soit que vous utilisez une directive qui n'est
jamais permise dans les fichiers <code>.htaccess</code>, soit
- que vous n'avez tout simplement pas défini la directive
+ que vous n'avez pas défini la directive
<directive module="core">AllowOverride</directive> à un niveau
suffisant pour la directive que vous utilisez. Consultez la
documentation de cette directive pour déterminer quel cas
<p>Le journal des erreurs peut aussi vous signaler une erreur de
syntaxe dans l'usage de la directive elle-même.</p>
- <highlight language="config">
-[Tue May 06 09:14:02.946218 2025] [core:alert] [pid 12345] [client 192.168.1.50:54321] /var/www/html/.htaccess: RewriteCond: bad flag delimiters
- </highlight>
+<example>
+<highlight language="config">
+[Thu Jun 18 09:14:02.946218 2026] [core:alert] [pid 12345] [client 192.168.1.50:54321] /var/www/html/.htaccess: RewriteCond: bad flag delimiters
+</highlight>
+</example>
<p>Dans ce cas, le message d'erreur sera spécifique à l'erreur
de syntaxe que vous avez commise.</p>
<?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: 1874148:1935520 (outdated) -->
+<!-- English Revision: 1935520 -->
<!-- French translation : Lucien GENTIS -->
<!--
<title>Guide de configuration d'un mandataire inverse</title>
<summary>
- <p>En plus de ses fonctions de serveur web "basique", à savoir fournir du
- contenu statique et dynamique à l'utilisateur, Apache httpd (comme la
- plupart des autres serveurs web) peut aussi assurer les fonctions de serveur
- mandataire inverse, connu aussi sous le nom de serveur "passerelle".</p>
-
- <p>Dans un tel scénario, httpd ne génère et n'héberge pas lui-même les
- données, le contenu étant en général obtenu à partir d'un ou plusieurs serveurs
- d'arrière-plan qui n'ont normalement aucune connexion directe avec le réseau
- externe. Lorsque httpd reçoit une requête en provenance d'un client, la
- requête proprement dite est <em>mandatée</em> vers un de ces serveurs
- d'arrière-plan qui traite la requête, génère le contenu et l'envoie à httpd,
- ce dernier générant la véritable réponse HTTP à destination du client.</p>
-
- <p>De nombreuses raisons peuvent vous motiver à utiliser cette
- fonctionnalité, mais elles sont souvent du domaine de la sécurité, de
- la haute disponibilité, de la répartition de charge et de
- l'authentification/autorisation centralisée. Il est alors indispensable que
- l'organisation, la conception et l'architecture de l'infrastructure
- d'arrière-plan (les serveurs qui traitent au sens propre les requêtes) soient
- isolées et protégées de l'extérieur ; vu du client, le serveur mandataire
- inverse <em>est</em> le seul serveur accessible pouvant lui fournir du
+ <p>En plus de servir directement du contenu statique et dynamique, Apache
+ httpd peut remplir les fonctions d’un serveur mandataire inverse (parfois
+ appelé passerelle).</p>
+
+ <p>Dans ce mode, httpd ne génère pas le contenu lui-même. Il redirige chaque
+ requête client vers un ou plusieurs serveurs dorsaux qui n’ont pas d’accès
+ direct au réseau externe. Le serveur dorsal traite la requête et renvoie le
+ contenu à httpd qui, à son tour, envoie la réponse HTTP au client.</p>
+
+ <p>Les buts courants de ce dispositif comprennent la sécurité, la haute
+ disponibilité, la répartition de charge et l’authentification centralisée.
+ L’infrastructure dorsale doit être isolée du réseau externe ; du point de
+ vue du client, le mandataire inverse <em>est</em> la seule source de tout
contenu.</p>
<p>Voici un exemple typique d'implémentation de cette fonctionnalité :</p>
unique :
</p>
- <highlight language="config">
+<example>
+<highlight language="config">
ProxyPass "/" "http://www.example.com/"
- </highlight>
+</highlight>
+</example>
<p>
- Pour être sur que cette redirection soit effectuée et que les en-têtes
- <code>Location:</code> générés par le serveur d'arrière-plan soient
- modifiés pour pointer vers le mandataire inverse, et non vers le serveur
- d'arrière-plan, la directive <directive
- module="mod_proxy">ProxyPassReverse</directive> est souvent requise :
+ Pour s’assurer que les en-têtes <code>Location:</code> générés par le
+ serveur dorsal soient modifiés pour pointer vers le mandataire inverse, et
+ non vers le serveur d'arrière-plan, la directive <directive
+ module="mod_proxy">ProxyPassReverse</directive> est en général requise :
</p>
- <highlight language="config">
+<example>
+<highlight language="config">
ProxyPass "/" "http://www.example.com/"
ProxyPassReverse "/" "http://www.example.com/"
- </highlight>
+</highlight>
+</example>
- <p>Seules des URIs spécifiques peuvent être mandatées, comme le montre
+ <p>Il est possible de spécifier les URIs qui peuvent être mandatés, comme le montre
l'exemple suivant :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
ProxyPass "/images" "http://www.example.com/"
ProxyPassReverse "/images" "http://www.example.com/"
- </highlight>
+</highlight>
+</example>
<p>Dans l'exemple précédent, si le chemin d'une requête commence par
<code>/images</code>, elle sera redirigée vers le serveur d'arrière-plan
</section>
<section id="cluster">
- <title>Clusters et Balancers</title>
+ <title>Grappes et répartiteurs de charge</title>
<p>
- Utiliser un serveur d'arrière-plan unique n'est cependant pas une solution
- idéale car ce dernier peut devenir indisponible ou surchargé, et le
- mandatement inverse vers ce serveur ne présente alors plus aucun avantage.
- La solution réside dans la définition d'un groupe de serveurs
- d'arrière-plan qui vont se partager le traitement des requêtes via un
- mécanisme de répartition de charge et de gestion des indisponibilités pris
- en charge par le mandataire. Ce groupe de répartition est plus connu sous le nom de
- <em>cluster</em>, mais dans la terminologie d'Apache httpd, on utilise
- plutôt le terme de <em>balancer</em>. Un balancer se définit en
- utilisant les directives <directive module="mod_proxy"
- type="section">Proxy</directive> et <directive
- module="mod_proxy">BalancerMember</directive> comme suit :
+ La configuration à un seul serveur dorsal ci-avant comporte un défaut
+ évident : si ce serveur dorsal est éteint ou surchargé, le contenu
+ mandaté ne sera pas disponible. Ce dont on a besoin ici est un groupe de
+ serveurs dorsaux parmi lesquels le serveur mandataire pourra basculer et
+ répartir la charge. Ce groupe est parfois appelé <em>grappe</em>
+ (cluster) ; Apache httpd le nomme <em>répartiteur de charge</em>
+ (balancer). Un répartiteur de charge se définit en utilisant les
+ directives <directive module="mod_proxy" type="section">Proxy</directive>
+ et <directive module="mod_proxy">BalancerMember</directive> :
</p>
- <highlight language="config">
+<example>
+<highlight language="config">
<Proxy balancer://myset>
- BalancerMember http://www2.example.com:8080
- BalancerMember http://www3.example.com:8080
- ProxySet lbmethod=bytraffic
+BalancerMember http://www2.example.com:8080
+BalancerMember http://www3.example.com:8080
+ProxySet lbmethod=bytraffic
</Proxy>
ProxyPass "/images/" "balancer://myset/"
ProxyPassReverse "/images/" "balancer://myset/"
- </highlight>
+</highlight>
+</example>
<p>
Le protocole <code>balancer://</code> indique à httpd que l'on souhaite
- créer un balancer nommé <em>myset</em>. Ce balancer comporte deux serveurs
+ créer un répartiteur de charge nommé <em>myset</em>. Ce répartiteur comporte deux serveurs
d'arrière-plan référencés dans la terminologie httpd sous le nom de
<em>BalancerMembers</em>. Avec cet exemple, toute requête dont le chemin
commence par <code>/images</code> sera mandatée vers <em>un</em> des deux
serveurs d'arrière-plan. La directive <directive
- module="mod_proxy">ProxySet</directive> définit ici pour le balancer
+ module="mod_proxy">ProxySet</directive> définit ici pour le répartiteur
<em>myset</em> un algorithme de
répartition de charge basé sur le trafic entrées/sorties.
</p>
</section>
<section id="config">
- <title>Configuration du Balancer et des BalancerMembers</title>
+ <title>Configuration du répartiteur de charge et de ses membres (workers)</title>
<p>
- Vous pouvez configurer de manière détaillée les <em>balancers</em> et
- <em>workers</em> via les nombreux paramètres de la directive <directive
- module="mod_proxy">ProxyPass</directive>. Par exemple, si vous souhaitez
- que <code>http://www3.example.com:8080</code> traite avec un facteur 3 le
- trafic avec un timeout d'une seconde, utilisez la configuration suivante :
+ Les répartiteurs de charge et leurs membres sont configurés à l’aide de
+ paramètres de la directive <directive
+ module="mod_proxy">ProxyPass</directive>. Par exemple, pour que
+ <code>http://www3.example.com:8080</code> gère le trafic avec un facteur 3
+ et un délai d’une seconde :
</p>
- <highlight language="config">
+<example>
+<highlight language="config">
<Proxy balancer://myset>
- BalancerMember http://www2.example.com:8080
- BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
- ProxySet lbmethod=bytraffic
+BalancerMember http://www2.example.com:8080
+BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+ProxySet lbmethod=bytraffic
</Proxy>
ProxyPass "/images" "balancer://myset/"
ProxyPassReverse "/images" "balancer://myset/"
- </highlight>
+</highlight>
+</example>
</section>
<title>Gestion des indisponibilités (Failover)</title>
<p>
- Vous pouvez aussi définir finement des scénarios pour les cas
- d'indisponibilité d'un ou plusieurs serveurs d'arrière-plan en spécifiant
- quels serveurs doivent alors prendre le relai. Dans l'exemple suivant,
+ Vous pouvez définir finement des scénarios pour les cas d'indisponibilité
+ d'un ou plusieurs serveurs dorsaux en spécifiant quels répartiteurs et
+ leurs membres doivent alors prendre le relai. Dans l'exemple suivant,
trois scénarios sont envisagés :
</p>
<ol>
ou de standby pour chaque jeu de serveurs du répartiteur de charge.
</p>
- <highlight language="config">
+<example>
+<highlight language="config">
<Proxy balancer://myset>
- BalancerMember http://www2.example.com:8080
- BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
- BalancerMember http://spare1.example.com:8080 status=+R
- BalancerMember http://spare2.example.com:8080 status=+R
- BalancerMember http://hstandby.example.com:8080 status=+H
- BalancerMember http://bkup1.example.com:8080 lbset=1
- BalancerMember http://bkup2.example.com:8080 lbset=1
- ProxySet lbmethod=byrequests
+BalancerMember http://www2.example.com:8080
+BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+BalancerMember http://spare1.example.com:8080 status=+R
+BalancerMember http://spare2.example.com:8080 status=+R
+BalancerMember http://hstandby.example.com:8080 status=+H
+BalancerMember http://bkup1.example.com:8080 lbset=1
+BalancerMember http://bkup2.example.com:8080 lbset=1
+ProxySet lbmethod=byrequests
</Proxy>
ProxyPass "/images/" "balancer://myset/"
ProxyPassReverse "/images/" "balancer://myset/"
- </highlight>
+</highlight>
+</example>
<p>
Les serveurs de remplacement à chaud remplacent les serveurs indisponibles
- du même jeu de serveurs du répartiteur de charge. Un serveur est
- considéré comme indisponible s'il est en maintenance, arrêté ou en erreur.
- Les serveurs de standby à chaud sont utilisés si tous les serveurs et
- serveurs de remplacement du jeu de serveurs du répartiteur de charge sont
- indisponibles. Les jeux de serveurs du répartiteur de charge (avec leurs
- serveurs de standby et de remplacement à chaud respectifs) sont toujours
- sollicités dans l'ordre du plus bas lbset vers le plus haut.
+ (en phase de vidage, arrêtés ou en état d’erreur) du même jeu de serveurs
+ du répartiteur de charge. Les serveurs de standby à chaud ne sont activés
+ que si tous les serveurs et serveurs de remplacement du jeu de serveurs du
+ répartiteur de charge sont indisponibles. Les jeux de serveurs du
+ répartiteur de charge sont sollicités dans l'ordre du plus bas lbset vers
+ le plus haut.
</p>
</section>
<title>Gestion du répartiteur de charge</title>
<p>
- L'application <em>balancer-manager</em> fournie avec le mandataire inverse
- d'Apache httpd en est un des outils les plus utiles. Comme
- <module>mod_status</module>, <em>balancer-manager</em> affiche la
- configuration et l'activité actuelles des balancers actifs. L'affichage de
- ces informations n'est cependant pas sa seule fonction ; il permet aussi de
- modifier la plupart d'entre elles et même d'ajouter des membres au groupe
- de répartition de charge en temps réel. Pour activer ces fonctionnalités,
- vous devez ajouter les lignes suivantes à votre fichier de configuration :
+ Apache httpd comporte un <em>gestionnaire de répartiteur de charge</em>
+ (balancer-manager) intégré. Comme <module>mod_status</module>, il affiche
+ la configuration et l’état actuels de vos répartiteurs de charge et de
+ leurs membres. Il vous permet aussi de les reconfigurer à l’exécution
+ — par exemple pour ajouter de nouveaux membres à un répartiteur existant.
+ Pour l’activer, ajoutez les lignes suivantes à votre configuration :
</p>
- <highlight language="config">
+<example>
+<highlight language="config">
<Location "/balancer-manager">
- SetHandler balancer-manager
- Require host localhost
+SetHandler balancer-manager
+Require host localhost
</Location>
- </highlight>
+</highlight>
+</example>
<note type="warning"><title>Avertissement</title>
<p>N'activez le <em>balancer-manager</em> que si vous avez déjà <a
<p class="centered"><img src="../images/bal-man.png" alt="balancer-manager page" /></p>
<p>
- Ce formulaire permet à l'administrateur de modifier certains paramètres,
- de désactiver ou d'ajouter certains serveurs d'arrière-plan, et de
- modifier les règles de répartition de charge. Par exemple, si on clique
+ Ce formulaire permet de modifier certains paramètres,
+ de désactiver ou d'ajouter des serveurs dorsaux, et de
+ modifier les règles de répartition de charge. Si l’on clique
sur le répartiteur, la page suivante s'affiche :
</p>
<p class="centered"><img src="../images/bal-man-b.png" alt="balancer-manager page" /></p>
<section id="health-check">
<title>Vérification dynamique du bon fonctionnement d'un serveur
- d'arrière-plan</title>
+ dorsal</title>
<p>
- Avant que le mandataire httpd ne fasse appel à un serveur d'arrière-plan, il
- peut <em>"tester"</em> si ce dernier est disponible en définissant le
- paramètre <code>ping</code> de ce serveur via la directive <directive
+ Avant de mandater une requête, httpd peut <em>"tester"</em> si le serveur
+ dorsal est disponible en définissant le paramètre <code>ping</code> de ce
+ serveur via la directive <directive
module="mod_proxy">ProxyPass</directive>. Cependant, il est souvent plus
judicieux de vérifier le bon fonctionnement d'un serveur <em>hors
- bande</em> et de manière dynamique via le module
- <module>mod_proxy_hcheck</module> d'Apache httpd.
+ ibande</em> via le module <module>mod_proxy_hcheck</module>.
</p>
</section>
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 1935553:1935724 (outdated) -->
+<!-- English Revision: 1935747 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
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
+ 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>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>
+<example>
+<highlight language="config">
+LogLevel info rewrite:trace5
+</highlight>
+</example>
<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>Voici une configuration typique pour le journal des accès :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog "logs/access_log" common
- </highlight>
+</highlight>
+</example>
<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.
"Combined Log Format" (Format de journalisation combiné). Il s'utilise
comme suit :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog "log/access_log" combined
- </highlight>
+</highlight>
+</example>
<p>Ce format est identique au Common Log Format, avec deux champs
supplémentaires. Chacun de ces deux champs utilise la directive
comment simuler les effets des directives <code>ReferLog</code> et
<code>AgentLog</code>.</p>
- <highlight language="config">
+<example>
+<highlight language="config">
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog "logs/access_log" common
CustomLog "logs/referer_log" "%{Referer}i -> %U"
CustomLog "logs/agent_log" "%{User-agent}i"
- </highlight>
+</highlight>
+</example>
<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
la variable d'environnement est définie.
Quelques exemples :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
# Marque les requêtes en provenance de l'interface loop-back
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# Marque les requêtes pour le fichier robots.txt
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# Journalise toutes les autres requêtes
CustomLog "logs/access_log" common env=!dontlog
- </highlight>
+</highlight>
+</example>
<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>
- <highlight language="config">
- SetEnvIf Accept-Language "en" english
- CustomLog "logs/english_log" common env=english
- CustomLog "logs/non_english_log" common env=!english
- </highlight>
+<example>
+<highlight language="config">
+SetEnvIf Accept-Language "en" english
+CustomLog "logs/english_log" common env=english
+CustomLog "logs/non_english_log" common env=!english
+</highlight>
+</example>
<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">
+<example>
+<highlight language="config">
SetEnv CACHE_MISS 1
LogFormat "%h %l %u %t "%r " %>s %b %{CACHE_MISS}e" common-cache
CustomLog "logs/access_log" common-cache
- </highlight>
+</highlight>
+</example>
<p><module>mod_cache</module> va s'exécuter avant
<module>mod_env</module>, et si son action est couronnée de
valeurs de journalisation conditionnelles basées sur le code de la
réponse HTTP :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
LogFormat "%400,501{User-agent}i" browserlog
LogFormat "%!200,304,302{Referer}i" refererlog
- </highlight>
+</highlight>
+</example>
<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
journal, puis de séparer ultérieurement le journal en plusieurs journaux
individuels. Considérons par exemple les directives suivantes :</p>
- <highlight language="config">
+<example>
+<highlight language="config">
LogFormat "%v %p %h %l %u %t \"%r\" %>s %b" commonvhost
CustomLog "logs/access_log" commonvhost
- </highlight>
+</highlight>
+</example>
<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
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 1602764:1935407 (outdated) -->
+<!-- English Revision: 1935407 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
recompiler le serveur.</p>
<highlight language="config">
- LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
+ LoadModule mpm_event_module modules/mod_mpm_event.so
</highlight>
<p>Toute tentative de charger plusieurs modules MPM via la directive
projects / thirdparty / apache / httpd.git / commitdiff
