From: Lucien Gentis Date: Wed, 1 Jul 2026 15:23:55 +0000 (+0000) Subject: fr doc rebuild. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=c566110552f9a104843cb043eb50bf5f3eb2c677;p=thirdparty%2Fapache%2Fhttpd.git fr doc rebuild. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1935773 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/env.html.fr.utf8 b/docs/manual/env.html.fr.utf8 index 0e8f5e2e58..5f8efa3b62 100644 --- a/docs/manual/env.html.fr.utf8 +++ b/docs/manual/env.html.fr.utf8 @@ -29,8 +29,6 @@  ko  |  tr 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

Deux types de variables d'environnement affectent le serveur HTTP Apache.

@@ -294,8 +292,10 @@

La spécification sur les CGIs (RFC 3875) 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 diff --git a/docs/manual/env.xml.meta b/docs/manual/env.xml.meta index 67070dc314..e9ca77529f 100644 --- a/docs/manual/env.xml.meta +++ b/docs/manual/env.xml.meta @@ -8,7 +8,7 @@ en - fr + fr ja ko tr diff --git a/docs/manual/howto/access.html.fr.utf8 b/docs/manual/howto/access.html.fr.utf8 index ff02ef8b38..1793a00af4 100644 --- a/docs/manual/howto/access.html.fr.utf8 +++ b/docs/manual/howto/access.html.fr.utf8 @@ -27,8 +27,6 @@  es  |  fr 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

Le contrôle d'accès fait référence à tout concept de contrôle d'accès à une ressource quelconque. Il est distinct du processus d'authentification et d'autorisation.

@@ -57,9 +55,8 @@ d'accès

Contrôle d'accès en fonction de l'hôte du client

- 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 mod_authz_host.

@@ -79,10 +76,10 @@ client

Les directives Require s'utilisent comme suit :

- 
Require host address
+
Require host address
 Require ip ip.address
-    

-
+
+

Dans la première forme, nom-hôte est un nom de domaine pleinement qualifié (fqdn), ou un nom de domaine partiel ; vous @@ -93,12 +90,26 @@ Require ip ip.address 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.

+

Exemples de formats d’adresse IP

# 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
+
+

Voir la documentation de mod_authz_host pour d'autres exemples de cette syntaxe.

Vous pouvez insérer le mot-clé not pour inverser un - critère particulier. Notez que le mot not réalise la + critère particulier. Le mot not réalise la négation sur la valeur, et ne peut pas être utilisé seul pour autoriser ou interdire une requête, car non vrai ne veut pas ici forcément dire faux. Ainsi, pour interdire la @@ -108,28 +119,29 @@ Require ip ip.address spamer votre forum, vous pouvez ajouter cette ligne pour lui refuser l'accès :

- 
<RequireAll>
-    Require all granted
-    Require not ip 10.252.46.165
+
<RequireAll>
+Require all granted
+Require not ip 10.252.46.165
 </RequireAll>

-
+

 
     
Les visiteurs possédant cette adresse (10.252.46.165) ne pourront pas voir le
     contenu concerné par cette directive. Si vous voulez interdir
     l'accès à une machine en fonction de son nom, vous pouvez ajouter
     ceci :

 
-    
Require not host host.example.com

-
+
Require not host host.example.com
+

+

 
     
Et si vous voulez interdire l'accès à un domaine particulier,
     vous pouvez spécifier des adresses IP partielles ou des noms de
     domaine, comme ceci :

 
-    
Require not ip 192.168.205
-Require not host phishers.example.com moreidiots.example
+
Require not ip 192.168.205
+Require not host phishers.example.com badguys.example
 Require not host gov

-
+

 
     
Les directives RequireAll, RequireAny, et RequireNone ouvrent le champ à des
     critères d'accès plus complexes.

@@ -145,18 +157,18 @@ arbitraires 
 
-    
<If "%{HTTP_USER_AGENT} == 'BadBot'">
-    Require all denied
+
<If "%{HTTP_USER_AGENT} == 'BadBot'">
+Require all denied
 </If>

-
+

 
     
En utilisant la syntaxe expr de la directive
     Require, l'exemple
     précédent peut aussi s'écrire :

 
 
-    
Require expr %{HTTP_USER_AGENT} != 'BadBot'

-
+
Require expr %{HTTP_USER_AGENT} != 'BadBot'

+

 
     
Avertissement :

     
Contrôler l'accès en fonction de l'en-tête
@@ -180,11 +192,11 @@ d'accès 
mod_rewrite :

 
-    
RewriteEngine On
+
RewriteEngine On
 RewriteCond "%{TIME_HOUR}" ">=20" [OR]
 RewriteCond "%{TIME_HOUR}" "<07"
 RewriteRule "^/fridge" "-" [F]

-
+

 
     
Toute requête arrivant après 20h ou avant 7h du matin provoquera
     l'envoi d'une réponse de type 403 Forbidden. Vous pouvez utiliser
diff --git a/docs/manual/howto/access.xml.meta b/docs/manual/howto/access.xml.meta
index ee45dee0b6..39cc277557 100644
--- a/docs/manual/howto/access.xml.meta
+++ b/docs/manual/howto/access.xml.meta
@@ -9,6 +9,6 @@
   
     en
     es
-    fr
+    fr
   
 
diff --git a/docs/manual/howto/auth.html.fr.utf8 b/docs/manual/howto/auth.html.fr.utf8
index cf137f9414..1295a878c4 100644
--- a/docs/manual/howto/auth.html.fr.utf8
+++ b/docs/manual/howto/auth.html.fr.utf8
@@ -30,8 +30,6 @@
  ko  |
  tr 

 

-
Cette traduction peut être périmée. Vérifiez la version
-            anglaise pour les changements récents.

 
     
L'authentification est un processus qui vous permet de vérifier
     qu'une personne est bien celle qu'elle prétend être. L'autorisation
@@ -149,11 +147,11 @@ module de chaque groupe.

     d'une directive AllowOverride
     du style :

 
-    
AllowOverride AuthConfig

-
+
AllowOverride AuthConfig

+

 
     
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.

 
     
Vous devrez aussi connaître un tant soit peu la structure des
@@ -226,13 +224,13 @@ module de chaque groupe.

     fichier httpd.conf à l'intérieur d'une section <Directory
     "/usr/local/apache/htdocs/secret"> :

 
-    
AuthType Basic
+
AuthType Basic
 AuthName "Restricted Files"
-# (Following line optional)
+# (La ligne suivante est facultative)
 AuthBasicProvider file
 AuthUserFile "/usr/local/apache/passwd/passwords"
 Require user rbowen

-
+

 
     
Examinons ces directives une à une. La directive AuthType définit la méthode
     utilisée pour authentifier l'utilisateur. La méthode la plus
@@ -328,14 +326,14 @@ plusieurs personnes Maintenant, vous devez modifier votre fichier
     .htaccess comme suit :

 
-    
AuthType Basic
+
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

-
+

 
     
Maintenant, quiconque appartient au groupe
     Nom-de-groupe, et possède une entrée dans le fichier
@@ -346,8 +344,8 @@ Require group GroupName

     l'accès à plusieurs personnes. Plutôt que de créer un fichier de
     groupes, il vous suffit d'ajouter la directive suivante :

 
-    
Require valid-user

-
+
Require valid-user

+

 
     
Le remplacement de la ligne Require user rbowen par
     la ligne Require valid-user autorisera l'accès à
@@ -399,14 +397,14 @@ passe 
     
Par exemple, pour sélectionner un fichier dbm à la place d'un
     fichier texte :

 
-    
<Directory "/www/docs/private">
-    AuthName "Private"
-    AuthType Basic
-    AuthBasicProvider dbm
-    AuthDBMUserFile "/www/passwords/passwd.dbm"
-    Require valid-user
+
<Directory "/www/docs/private">
+AuthName "Private"
+AuthType Basic
+AuthBasicProvider dbm
+AuthDBMUserFile "/www/passwords/passwd.dbm"
+Require valid-user
 </Directory>

-
+

 
     
D'autres options sont disponibles. Consultez la documentation de
     mod_authn_dbm pour plus de détails.

@@ -424,15 +422,15 @@ d'authentification <Directory "/www/docs/private">
-    AuthName "Private"
-    AuthType Basic
-    AuthBasicProvider file ldap
-    AuthUserFile "/usr/local/apache/passwd/passwords"
-    AuthLDAPURL ldap://ldaphost/o=yourorg
-    Require valid-user
+
<Directory "/www/docs/private">
+AuthName "Private"
+AuthType Basic
+AuthBasicProvider file ldap
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthLDAPURL ldap://ldaphost/o=yourorg
+Require valid-user
 </Directory>

-
+

 
     
Dans cet exemple, le fournisseur file va tenter d'authentifier
     l'utilisateur en premier. S'il n'y parvient pas, le fournisseur LDAP
@@ -450,17 +448,17 @@ d'authentification <Directory "/www/docs/private">
-    AuthName "Private"
-    AuthType Basic
-    AuthBasicProvider file
-    AuthUserFile "/usr/local/apache/passwd/passwords"
-    AuthLDAPURL ldap://ldaphost/o=yourorg
-    AuthGroupFile "/usr/local/apache/passwd/groups"
-    Require group GroupName
-    Require ldap-group cn=mygroup,o=yourorg
+
<Directory "/www/docs/private">
+AuthName "Private"
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthLDAPURL ldap://ldaphost/o=yourorg
+AuthGroupFile "/usr/local/apache/passwd/groups"
+Require group GroupName
+Require ldap-group cn=mygroup,o=yourorg
 </Directory>

-
+

 
     
Pour un scénario d'autorisation un peu plus avancé, des
     directives de conteneur d'autorisation comme <RequireAll> et
@@ -526,75 +524,14 @@ autorisation 
Require. Cette directive
-	permet d'enregistrer quels fournisseurs d'autorisation
-	seront appelés dans le processus d'autorisation au cours du
-	traitement de la requête. Par exemple :

-
-        
Require ip address

-
-
-        
où adresse est une adresse IP (ou une adresse IP
-	partielle) ou :

-
-        
Require host domain_name

-
-
-        
où nom_domaine est un nom de domaine entièrement
-	qualifé (ou un nom de domaine partiel) ; vous pouvez indiquer
-	plusieurs adresses ou noms de domaines, si vous le désirez.

-
-        
Par exemple, si vous voulez rejeter les spams dont une
-	machine vous inonde, vous pouvez utiliser ceci :

-
-        
<RequireAll>
-    Require all granted
-    Require not ip 10.252.46.165
-</RequireAll>

-
-
-        
Ainsi, les visiteurs en provenance de cette adresse ne
-	pourront pas voir le contenu concerné par cette directive. Si,
-	par contre, vous connaissez le nom de la machine, vous pouvez
-	utiliser ceci :

-
-        
<RequireAll>
-    Require all granted
-    Require not host host.example.com
-</RequireAll>

-
-
-        
Et si vous voulez interdire l'accès à toutes les machines
-	d'un domaine, vous pouvez spécifier une partie seulement de
-	l'adresse ou du nom de domaine :

-
-        
<RequireAll>
-    Require all granted
-    Require not ip 192.168.205
-    Require not host phishers.example.com moreidiots.example
-    Require not host ke
-</RequireAll>

-
-
-        
L'utilisation de la directive <RequireAll>
-	avec de multiples directives <Require>, toutes avec la négation
-	not, n'accordera l'accès que si toutes les
-	conditions négatives sont vérifiées. En d'autres termes, l'accès
-	sera refusé si au moins une des conditions négatives n'est pas
-	vérifiée.

+	
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 all, env,
+	host et ip avec la directive Require.

+ 
+        
Pour des détails complets et des exemples, voir le tutoriel Access Control.

 
     
 
@@ -624,17 +561,14 @@ autorisation 
top

 

 
Mise en cache de l'authentification 

-    
Dans certains cas, l'authentification constitue une charge
-    inacceptable pour un fournisseur d'authentification ou votre réseau.
-    Ceci est susceptible d'affecter les utilisateurs du module
-    mod_authn_dbd (ou les fournisseurs
-    tiers/personnalisés). Pour résoudre ce problème, HTTPD 2.3/2.4
-    propose un nouveau fournisseur de mise en cache,
-    mod_authn_socache, qui permet de mettre en cache
-    les données d'authentification, et ainsi réduire la charge du/des
-    fournisseurs(s) originels.

-    
Cette mise en cache apportera un gain en performance substantiel
-    à certains utilisateurs.

+    
Dans certains cas, l'authentification constitue une charge inacceptable
+    pour un fournisseur d'authentification ou votre réseau.  Ceci est
+    susceptible d'affecter les utilisateurs du module
+    mod_authn_dbd (ou les fournisseurs tiers/personnalisés). Le
+    module mod_authn_socache met en cache les données
+    d'authentification, et réduit ainsi la charge du/des fournisseurs(s)
+    originels.
 
Cette mise en cache apportera un gain en performance
+    substantiel à certains utilisateurs.

 
top

 

 
Pour aller plus loin . . . 

diff --git a/docs/manual/howto/auth.xml.meta b/docs/manual/howto/auth.xml.meta
index 5dc018d29c..a8148d403c 100644
--- a/docs/manual/howto/auth.xml.meta
+++ b/docs/manual/howto/auth.xml.meta
@@ -9,7 +9,7 @@
   
     en
     es
-    fr
+    fr
     ja
     ko
     tr
diff --git a/docs/manual/howto/htaccess.html.fr.utf8 b/docs/manual/howto/htaccess.html.fr.utf8
index e70c1fc02e..5844955e26 100644
--- a/docs/manual/howto/htaccess.html.fr.utf8
+++ b/docs/manual/howto/htaccess.html.fr.utf8
@@ -30,8 +30,6 @@
  ko  |
  pt-br 

 

-
Cette traduction peut être périmée. Vérifiez la version
-            anglaise pour les changements récents.

 
 
Les fichiers .htaccess fournissent une méthode pour
 modifier la configuration du serveur au niveau de chaque répertoire, sans
@@ -75,8 +73,8 @@ Includes - SSI)
       .config, vous pouvez mettre ceci dans le fichier de
       configuration de votre serveur :

 
-      
AccessFileName ".config"

-
+
AccessFileName ".config"

+

     
 
     
Les directives dans les fichiers .htaccess utilisent la même
@@ -90,7 +88,7 @@ Includes - SSI)
     directive est permise dans un fichier .htaccess,
     la documentation de cette directive contiendra une section Override,
     spécifiant quelle valeur doit prendre la directive AllowOverride pour que cette directive
-    soit traitée.

+    soit autorisée.

 
     
La valeur par défaut de la directive AllowOverride est None. Cela signifie
     que les fichiers .htaccess seront complètement ignorés, à moins
@@ -145,25 +143,23 @@ Includes - SSI)
     .htaccess est chargé en mémoire chaque fois qu'un
     document fait l'objet d'une requête.

 
-    
Notez aussi que httpd doit rechercher les fichiers
-    .htaccess dans tous les répertoires de niveau
-    supérieur, afin de rassembler toutes les directives qui s'appliquent
-    au répertoire courant (Voir la section comment sont
-    appliquées les directives). Ainsi, si un fichier fait l'objet
-    d'une requête à partir d'un répertoire
-    /www/htdocs/exemple, httpd doit rechercher les
-    fichiers suivants :

+    
En outre, httpd doit rechercher des fichiers .htaccess dans
+    tous les répertoires de niveau supérieur pour rassembler la totalité des
+    directives applicables (Voir la section comment sont
+    appliquées les directives). Ainsi, si un fichier fait l'objet d'une
+    requête à partir d'un répertoire /www/htdocs/exemple, httpd
+    doit rechercher les fichiers suivants :

 
-    
/.htaccess
+
/.htaccess
 /www/.htaccess
 /www/htdocs/.htaccess
 /www/htdocs/example/.htaccess

-
+

 
     
En conséquence, chaque accès à un fichier de ce répertoire
     nécessite 4 accès au système de fichiers supplémentaires pour
     rechercher des fichiers .htaccess, même si
-    aucun de ces fichiers n'est présent. Notez que cet exemple ne peut
+    aucun de ces fichiers n'est présent. Cet exemple ne peut
     se produire que si les fichiers .htaccess ont été
     autorisés pour le répertoire /, ce qui est rarement le
     cas.

@@ -172,7 +168,7 @@ Includes - SSI)
     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
@@ -187,41 +183,41 @@ Includes - SSI)
     nommer individuellement les directives autorisées, vous permettant ainsi un
     contrôle plus fin que dans le cas de la directive AllowOverride seule :

 
-    
# N’autoriser que des directives spécifiques, pas des catégories entières de
+
# N’autoriser que des directives spécifiques, pas des catégories entières de
 # directives
 AllowOverride None
 AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCond

-
+

 
     
Avec cette configuration, toute directive non explicitement spécifiée
     causera une erreur du serveur si elle est rencontrée dans un fichier
     .htaccess. C’est un bon compromis entre possibilité et
     impossibilité totales d’outrepasser la configuration globale.

 
-    
Notez que mettre un fichier .htaccess contenant une
-    directive dans un répertoire /www/htdocs/exemple
-    revient exactement au même que mettre la même directive dans une
-    section Directory <Directory "/www/htdocs/exemple">
-    du fichier de configuration de votre serveur principal :

+    
Placer une directive dans un fichier .htaccess dans un
+    répertoire /www/htdocs/example équivaut exactement à placer
+    cette même directive dans une section <Directory
+    "/www/htdocs/example"> de la configuration globale de votre
+    serveur :

 
-    
Fichier .htaccess dans
-    /www/htdocs/exemple :

+    
Fichier .htaccess dans /www/htdocs/example
+    :

 
     
Contenu du fichier .htaccess dans
-    /www/htdocs/exemple
AddType text/example ".exm"

-

+    /www/htdocs/example
AddType text/example ".exm"

+

 
     
Section de votre fichier
-    httpd.conf
<Directory "/www/htdocs/example">
-    AddType text/example ".exm"
+    httpd.conf
<Directory "/www/htdocs/example">
+AddType text/example ".exm"
 </Directory>

-

+

 
     
L'utilisation des fichiers .htaccess peut être
     entièrement désactivée en définissant la directive AllowOverride à none :

 
-    
AllowOverride None

-
+
AllowOverride None

+

 
top

 

 
Comment sont appliquées les directives ? 

@@ -229,7 +225,7 @@ AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCondLes directives de configuration situées dans un fichier
     .htaccess s'appliquent au répertoire dans lequel ce
     fichier .htaccess se trouve, ainsi qu'à tous ses
-    sous-répertoires. Cependant, il est important de garder à l'esprit
+    sous-répertoires. Cependant, souvenez-vous
     qu'il peut y avoir des fichiers .htaccess dans les
     répertoires de niveau supérieur. Les directives sont appliquées
     selon l'ordre dans lequel elles sont rencontrées. Ainsi, les
@@ -246,19 +242,19 @@ AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCondDans le répertoire /www/htdocs/exemple1 se trouve un
     fichier .htaccess contenant ce qui suit :

 
-    
Options +ExecCGI

-
+
Options +ExecCGI

+

 
-    
Note : "AllowOverride Options" doit être présent
+    
"AllowOverride Options" doit être présent
     pour permettre l'utilisation de la directive "Options"  dans les fichiers
-    .htaccess.

+    .htaccess.

 
     
Dans le répertoire /www/htdocs/exemple1/exemple2 se
     trouve un fichier .htaccess contenant ce qui suit
     :

 
-    
Options Includes

-
+
Options Includes

+

 
     
Ainsi, à cause de ce second fichier .htaccess du
     répertoire /www/htdocs/exemple1/exemple2, l'exécution
@@ -282,14 +278,14 @@ AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCond.htaccess, vous pouvez utiliser :

 
-    
<Directory "/www/htdocs">
-    AllowOverride All
+
<Directory "/www/htdocs">
+AllowOverride All
 </Directory>
 
 <Location "/">
-    Options +IncludesNoExec -ExecCGI
+Options +IncludesNoExec -ExecCGI
 </Location>

-
+

 
     
Dans cet exemple, on considère que le chemin défini par la
     directive DocumentRoot est
@@ -307,15 +303,15 @@ AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCondContenu du fichier .htaccess :

 
-    
AuthType Basic
+
AuthType Basic
 AuthName "Password Required"
 AuthUserFile "/www/passwords/password.file"
 AuthGroupFile "/www/passwords/group.file"
 Require group admins

+

 
-
-    
Notez que AllowOverride AuthConfig doit être présent
-    pour que ces directives produisent leur effet.

+    
AllowOverride AuthConfig doit être présent
+    pour que ces directives produisent leur effet.

 
     
Vous pouvez vous référer au tutoriel sur
     l'authentification pour une description plus détaillée de
@@ -330,14 +326,14 @@ Includes - SSI) 
tutoriel SSI
     pour une description plus détaillée des SSI.

@@ -350,7 +346,7 @@ différentes dans un contexte de répertoire. En particulier, les r&
 sont relatives au répertoire courant, et non à l'URI original. Considérez
 les exemples suivants :

 
-
# Dans httpd.conf
+
# Dans httpd.conf
 RewriteRule "^/images/(.+)\.jpg" "/images/$1.png"
 
 # Dans un fichier .htaccess situé dans le répertoire racine de vos
@@ -359,7 +355,7 @@ RewriteRule "^images/(.+)\.jpg" "images/$1.png"
 
 # Dans un fichier .htaccess situé dans le répertoire images/
 RewriteRule "^(.+)\.jpg" "$1.png"

-
+

 
 
On voit que si le fichier .htaccess se situe à la racine
 de vos documents, le slash de tête est supprimé de la valeur de
@@ -369,7 +365,7 @@ la chaîne /images/ disparaît de cette même valeur
 remplacement. Il doit donc en être de même dans votre expression
 rationnelle.

 
-
Notez aussi que dans un contexte .htaccess, les expressions
+
Dans un contexte .htaccess, 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.

@@ -393,21 +389,21 @@ pour une étude détaillée de l'utilisation du module
     l’exécution de programmes CGI dans un répertoire particulier. Pour y
     parvenir, vous pouvez utiliser la configuration suivante :

 
-    
Options +ExecCGI
+
Options +ExecCGI
 AddHandler cgi-script "cgi" "py"

-
+

 
     
Alternativement, si vous souhaitez que tous les fichiers d'un
     répertoire donné soient considérés comme des programmes CGI, vous
     pouvez utiliser la configuration suivante :

 
-    
Options +ExecCGI
+
Options +ExecCGI
 SetHandler cgi-script

+

 
-
-    
Notez que AllowOverride Options et AllowOverride
+    
AllowOverride Options et AllowOverride
     FileInfo doivent être tous les deux présents pour que ces
-    directives puissent produire leur effet.

+    directives puissent produire leur effet.

 
     
Vous pouvez vous référer au tutoriel CGI
     pour une description plus détaillée de la configuration et de la
@@ -429,8 +425,8 @@ SetHandler cgi-script

     dénué de sens dans votre ficher .htaccess et de recharger la
     page :

 
-    
TestMe

-
+
TestMe

+

 
     
Si aucune erreur (HTTP 500) n'est générée par le
     serveur, il est pratiquement certain qu'une directive
@@ -442,12 +438,12 @@ SetHandler cgi-script

     utilisée dans votre fichier .htaccess n'est pas
     permise.

 
-    
[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

-
+
[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

+

 
 	
Cela signifie soit que vous utilisez une directive qui n'est
 	jamais permise dans les fichiers .htaccess, soit
-	que vous n'avez tout simplement pas défini la directive
+	que vous n'avez pas défini la directive
 	AllowOverride à un niveau
 	suffisant pour la directive que vous utilisez. Consultez la
 	documentation de cette directive pour déterminer quel cas
@@ -456,8 +452,8 @@ SetHandler cgi-script

 	
Le journal des erreurs peut aussi vous signaler une erreur de
 	syntaxe dans l'usage de la directive elle-même.

 
-    
[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

-
+
[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

+

 
 	
Dans ce cas, le message d'erreur sera spécifique à l'erreur
 	de syntaxe que vous avez commise.

diff --git a/docs/manual/howto/htaccess.xml.meta b/docs/manual/howto/htaccess.xml.meta
index 708f779b76..baa69219b0 100644
--- a/docs/manual/howto/htaccess.xml.meta
+++ b/docs/manual/howto/htaccess.xml.meta
@@ -9,7 +9,7 @@
   
     en
     es
-    fr
+    fr
     ja
     ko
     pt-br
diff --git a/docs/manual/howto/http2.html.fr.utf8 b/docs/manual/howto/http2.html.fr.utf8
index 0fb02bb86f..f8264247e4 100644
--- a/docs/manual/howto/http2.html.fr.utf8
+++ b/docs/manual/howto/http2.html.fr.utf8
@@ -27,8 +27,6 @@
  es  |
  fr 

 

-
Cette traduction peut être périmée. Vérifiez la version
-            anglaise pour les changements récents.

 
     
Ce document est le guide de l'utilisateur de l'implémentation de HTTP/2
     dans Apache httpd. Cette fonctionnalité en est au stade
@@ -44,7 +42,7 @@
 
  •  Clients
    • 
 
  •  Outils efficaces pour déboguer HTTP/2
    • 
 
  •  Push serveur
    • 
-
  •  Suggestions précoces
    • 
+
  •  EarlyHints
    • 
 
    Voir aussi
    
 
    top
    
 
    
@@ -55,47 +53,46 @@
     plus efficace des ressources réseau. Il ne modifie pas les aspects
     fondamentaux de HTTP (sa sémantique). Entre autres, il y a toujours des
     requêtes, des réponses et des en-têtes. Par conséquent, si vous connaissez
-    HTTP/1, vous connaissez déjà 95% de HTTP/2.
    
-    
    Beaucoup a déjà été écrit à propos de HTTP/2 et de son fonctionnement. La
-    documentation la plus officielle est bien entendu sa RFC 7540 (ou cette version au format plus
-    lisible : YMMV (RFC 7540). Vous trouverez ici une description des rouages de HTTP/2 dans
-    leurs moindres détails.
    
-    
    Le premier document à lire lorsqu'on ne connaît pas un mécanisme n'est
-    cependant pas sa RFC. Il est préférable de comprendre tout d'abord ce
-    que ce mécanisme est censé faire, et seulement ensuite de lire sa RFC
-    pour comprendre comment il fonctionne. http2  explained de Daniel Stenberg
-    (l'auteur de curl)
-    est un bien meilleur document pour démarrer l'étude de HTTP/2. En outre, de
-    nouveaux langages s'ajoutent régulièrement à sa liste de traductions
-    disponibles !
    
-    
    Si vous n'avez pas envie de le lire parce que vous le trouvez trop long,
-    voici certains pièges à éviter et nouveaux termes à connaître avant de lire
-    ce document :
    
+    HTTP/1, vous connaissez déjà 95% deHTTP/2.
    
+
+    
    Le protocole est définii dans la RFC 9113 (qui rend obsolète la
+    RFC 7540 originale). Pour une approche plus abordable, voir le
+    document http2 explained par Daniel
+    Stenberg, l’auteur de curl. Il couvre les
+    but et conception de HTTP/2 sans nécessiter d’analyse de la notation RFC
+    préalable.
    
+
+    
    En bref, il y a quelques nouveaux termes et pièges à éviter que vous
+    devez garder à l’esprit lors de la lecture de ce document :
    
+
     
      
-        
    • A la différence de HTTP/1 qui est en texte pur, HTTP/2 est un
-	protocole binaire, et alors que le premier est lisible par
-	un humain (par exemple pour sniffer le trafic réseau), le second ne
-	l'est pas. Voir la FAQ
-	officielle pour plus de détails.
      • 
+        
    • À l’opposé de HTTP 1.1 qui est un protocole en texte pur, HTTP/2 est
+	un protocol binaire. Le premier a été pensé pour être
+	lisible par un humain (par exemple pour surveiller le trafic réseau),
+	alors que ce n’est pas le cas pour le second. Vous trouverez plus
+	d’information dans cette question de
+	la FAQ officielle.
      • 
         
    • h2 correspond à HTTP/2 sur TLS (négociation de
 	protocole via ALPN).
      • 
-        
    • h2c correspond à HTTP/2 sur TCP.
      • 
-	
    • Une frame ou trame est la plus petite unité de
-	communication au sein d'une connexion HTTP/2 et comporte une en-tête et
-	une séquence d'octets de longueur variable dont la structure correspond
-	au type de trame. Voir la section correspondante de la documentation
-	officielle pour plus de détails (RFC 7540).
      •  
    • Un
-	stream est un flux bidirectionnel de frames au sein
-	d'une connexion HTTP/2. La notion correspondante dans HTTP/1 est un
-	échange de messages de type requête et réponse. Voir la section
-	correspondante de la documentation officielle pour plus de détails
-	(RFC 7540).
      • 
-        
    • HTTP/2 peut gérer plusieurs streams de données sur
-	la même connexion TCP, ce qui permet d'éviter le point de blocage
-	classique de HTTP/1 pour les requêtes lentes, et de ne pas avoir à
-	ouvrir de nouvelles connexions TCP pour chaque requête/réponse (les
-	connexions persistantes ou KeepAlive avaient contourné le problème dans
-	HTTP/1 mais ne l'avaient pas entièrement résolu)
      • 
+        
    • h2c correspond à HTTP/2 sur TCP en texte clair
+	(sans TLS). Notez que h2c a été supprimé de la spécification actuelle
+	mais que httpd le prend encore en charge.
      • 
+	
    • Une trame (frame) est la plus petite unité de
+	communication au sein d’une connexion HTTP/2 ; elle comporte un en-tête
+	et une séquence d’octets de longueur variable structurée en fonction du
+	type de trame.  Vous trouverez plus d’informations dans la documentation
+	officielle de la RFC 9113.
      • 
+	
    • Un flux (stream) est une circulation
+	bidirectionnelle de trames au sein d’une connexion HTTP/2. Le concept
+	correspondant dans HTTP 1.1 est un échange de messages requête/réponse.
+	Vous trouverez plus d’informations dans la documentation officielle de
+	la RFC 9113.
      • 
+        
    • HTTP/2 peut gérer plusieurs flux de données sur la
+	même connexion TCP, évitant le classique blocage en tête de file
+	des requêtes HTTP 1.1 lentes, ainsi que la nécessité de réinitier des
+	connexions TCP pour chaque requête/réponse (KeepAlive contournait le
+	problème dans HTTP 1.1, mais ne le résolvait pas entièrement).
      • 
+        
     
    
   
    top
    
 
    
@@ -103,14 +100,15 @@
     
     
    Le protocole HTTP/2 est implémenté dans Apache httpd via un module
     propre, pertinemment nommé mod_http2. Ce
-    module implémente toutes les fonctionnalités décrites par la RFC 7540 et
+    module implémente toutes les fonctionnalités décrites par la RFC 9113 et
     supporte les connexions en texte pur (http:), ou sécurisées (https:).
     La variante texte pur se nomme 'h2c', et la variante sécurisée
     'h2'. h2c peut être en mode direct ou
     Upgrade: via une requête initiale en HTTP/1.
    
-    
    Server Push est une nouvelle fonctionnalité offerte
-    aux développeurs web par HTTP/2. La section correspondante de ce document
-    vous indiquera comment votre application peut en tirer parti.
    
+    
    Server Push était une nouvelle fonctionnalité offerte
+    aux développeurs web par HTTP/2, mais elle est maintenant obsolète. Voir la
+    section EarlyHints pour l’alternative
+    recommandée.
    
   
    top
    
 
    
 
    Compilation de httpd avec le support de HTTP/2 
    
@@ -145,32 +143,31 @@
     
    Maintenant que vous disposez d'un binaire httpd compilé avec le
     module mod_http2, l'activation de ce dernier nécessite un
     minimum de configuration supplémentaire. En premier lieu, comme pour tout
-    module Apache, vous devez le charger :
    
-    
    LoadModule http2_module modules/mod_http2.so
    
-
+    module de httpd, vous devez le charger :
    
+
    LoadModule http2_module modules/mod_http2.so
    
+
    
 
     
    La seconde directive que vous devez ajouter à votre fichier de
     configuration est
    
-    
    Protocols h2 http/1.1
    
-
+
    Protocols h2 http/1.1
    
+
    
     
    Ceci permet de définir h2, la variante sécurisée, comme le protocole
     préféré pour les connexions à votre serveur. Si vous souhaitez que toutes les
     variantes soient disponibles, utilisez la directive suivante :
    
-    
    Protocols h2 h2c http/1.1
    
-
-    
    Selon l'endroit où vous placez cette directive, elle affectera l'ensemble
-    de votre serveur, ou seulement un ou plusieurs serveurs virtuels. Vous
+
    Protocols h2 h2c http/1.1
    
+
    
+    
    Selon l'endroit où vous placez cette directive, elle affectera toute les
+    connexions, ou seulement celles vers un serveur virtuel spécifique. Vous
     pouvez aussi l'imbriquer comme dans l'exemple suivant :
    
-    
    Protocols http/1.1
+
    Protocols http/1.1
 <VirtualHost ...>
-    ServerName test.example.org
-    Protocols h2 http/1.1
+ServerName test.example.org
+Protocols h2 http/1.1
 </VirtualHost>
    
+
    
 
-
-    
    Seules les connexions en HTTP/1 seront alors permises, sauf pour le serveur
-    virtuel test.example.org qui acceptera aussi les connexions SSL
-    en HTTP/2.
    
+    
    Seules les connexions en HTTP/1 seront alors permises, sauf pour les
+    connexions SSL vers test.example.org qui propose aussi HTTP/2.
    
     
    Utilisez une chaîne d'algorithmes de chiffrement forte
    
     
    La directive SSLCipherSuite doit
     être définie avec une chaîne d'algorithmes de chiffrement TLS forte. Même si
@@ -188,21 +185,22 @@
     
    L'ordre des protocoles indiqués est aussi important. Par défaut, le
     premier sera le protocole préféré. Lorsqu'un client offre plusieurs choix,
     c'est le plus à gauche qui sera sélectionné. Dans
    
-    
    Protocols http/1.1 h2
    
-
+
    Protocols http/1.1 h2
    
+
    
     
    le protocole préféré sera HTTP/1 et il sera toujours sélectionné sauf si
     un client ne supporte que h2. Comme nous souhaitons communiquer en
     HTTP/2 avec les clients qui le supportent, la meilleure définition de la
     directive est
    
-    
    Protocols h2 h2c http/1.1
    
-
+
    Protocols h2 h2c http/1.1
    
+
    
 
     
    Toujours à propos de l'ordre des protocoles, le client a lui aussi ses
     propres préférences en la matière. À ce titre, si vous le souhaitez, vous
     pouvez configurer votre serveur pour qu'il sélectionne non plus son
     protocole préféré, mais au contraire le protocole préféré
     du client :
    
-    
    ProtocolsHonorOrder Off
    
+
    ProtocolsHonorOrder Off
    
+
    
 
     
    Avec cette directive, l'ordre des protocoles que vous avez
     défini devient caduque et seul l'ordre défini par le client sera pris en
@@ -246,10 +244,10 @@
 
    
 
    Clients 
    
     
-    
    La plupart des navigateurs modernes supportent HTTP/2, mais seulement sur
-    des connexions SSL : Firefox v43, Chrome v45, Safari v9, iOS Safari v9,
-    Opera v35, Chrome pour Android v49 et
-    Internet Explorer v11 sous Windows10 (selon cette source).
    
+    
    Tous les navigateurs modernes prennent en charge HTTP/2 sur
+    des connexions TLS (source). La
+    prise en charge est devenue universelle sur les navigateurs principaux à peu
+    près en 2015.
    
     
    D'autres clients et serveurs sont listés dans le wiki des
     implémentations ; entre autres des implémentations pour c, c++, common
     lisp, dart, erlang, haskell, java, nodejs, php, python, perl, ruby, rust,
@@ -263,14 +261,17 @@
     
     
    Le premier d'entre eux est bien entendu curl. Assurez-vous au préalable que votre
     version supporte HTTP/2 en vérifiant ses Fonctionnalités :
    
-    
        $ curl -V
-    curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
-    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...]
-    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2
-    
    
-
-    
    homebrew sous Mac OS :
    
-    brew install curl --with-openssl --with-nghttp2
+
    $ curl -V
+curl 8.20.0 (x86_64-pc-linux-gnu) libcurl/8.20.0 OpenSSL/3.5.7 zlib/1.3.1 nghttp2/1.69.0
+Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...]
+Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2
+
    
+
    
+    
    Notes à propos de macOS Homebrew
    
+    
    curl de Homebrew inclut par défaut la prise en charge de
+    HTTP/2. Installez le avec la commande brew install curl et
+    suivez les instructions affichées pour le mettre en tête du PATH de votre
+    système.
    
     
    
     
    Pour une inspection en profondeur : wireshark.
    
     
    Le paquet nghttp2 inclut aussi des
@@ -284,13 +285,21 @@
     
     
    Chrome fournit des journaux détaillés des connexions HTTP/2 via la page
     special net-internals page. Il y
-    a aussi cette extension intéressante pour Chrome
-    et Firefox
+    a aussi cette extension intéressante pour Chrome
+    et Firefox
     qui permet d'indiquer que votre navigateur utilise HTTP/2.
    
   
    top
    
 
    
 
    Push serveur 
    
     
+    
    Notification d’obsolescence
    
+    
    Server Push est obsolète dans la RFC 9113. Les
+    navigateurs principaux (Chrome 106+, Edge 106+) ont supprimé sa prise en
+    charge. Bien que mod_http2 implémente encore push, les
+    nouveaux déploiements doivent utiliser 103 Early
+    Hints à titre de méthode plus fiable pour informer les clients à propos
+    des ressources nécessaires.
    
+    
    
     
    Le protocole HTTP/2 permet au serveur de proposer (PUSH) des réponses
     pour lesquelles le client n'a rien demandé. La communication autour de ces
     réponses est du style : "voici une requête que vous n'avez jamais
@@ -315,25 +324,25 @@
     procéder vous-même à ces expérimentations :
    
     
    mod_http2 inspecte l'en-tête de la réponse et recherche les
     en-têtes Link sous un certain format :
    
-    
    Link </xxx.css>;rel=preload, </xxx.js>; rel=preload
    
-
+
    Link </xxx.css>;rel=preload, </xxx.js>; rel=preload
    
+
    
     
    Si la connexion supporte PUSH, ces deux ressources seront envoyées au
     client. En tant que développeur web vous pouvez définir ces en-têtes soit
     directement au niveau de la réponse de votre application, soit en
     configurant votre serveur via
    
-    
    <Location /xxx.html>
-    Header add Link "</xxx.css>;rel=preload"
-    Header add Link "</xxx.js>;rel=preload"
+
    <Location /xxx.html>
+Header add Link "</xxx.css>;rel=preload"
+Header add Link "</xxx.js>;rel=preload"
 </Location>
    
-
+
    
     
    Si vous souhaitez utiliser des liens preload sans déclencher
     de PUSH, vous pouvez utiliser le paramètre nopush comme suit :
    
-    
    Link </xxx.css>;rel=preload;nopush
    
-
+
    Link </xxx.css>;rel=preload;nopush
    
+
    
     
    Vous pouvez aussi désactiver les PUSHes pour l'ensemble de votre
     serveur via la directive
    
-    
    H2Push Off
    
-
+
    H2Push Off
    
+
    
     
    À savoir aussi :
    
     
    Le module maintient un journal des ressources ayant fait l'objet d'un
     PUSH pour chaque connexion (en général des condensés hash des URLs), et
@@ -341,14 +350,13 @@
     lorsque la connexion est fermée, le journal de ses PUSHes est supprimé.
    
     
    Certains développeurs planchent sur la manière de permettre au client
     d'informer le serveur des ressources qu'il possède déjà dans son cache afin
-    d'éviter les PUSHes pour ces dernières, mais ceci n'en est actuellement qu'à
-    un stade très expérimental.
    
+    d'éviter les PUSHes pour ces dernières, mais aucune norme n’a émergé avant
+    que push ne devienne obsolète.
    
     
    L'
-    en-tête Accept-Push-Policy est un autre dispositif expérimental
+    en-tête Accept-Push-Policy est un dispositif expérimental
     implémenté dans mod_http2 ; il permet au client de définir pour
-    chaque requête quels genres de PUSHes il accepte.
    
-  
-
+    chaque requête quels genres de PUSHes il accepte. Ce dispositif a été
+    abandonné et n’a jamais été adopté.
    
     
    
     La fonctionnalité PUSH n'apportera pas toujours le gain de performances dans
     l'obtention de réponses aux requêtes. Vous trouverez plusieurs études sur ce
@@ -372,7 +380,7 @@
     d'exposer les cookies là où ils ne sont pas censés être visibles.
    
   
    top
    
 
    
-
    Suggestions précoces 
    
+
    EarlyHints 
    
     
     
    A l'instar des ressources PUSHées, une autre méthode consiste à envoyer
     des en-têtes Link au client avant même que la réponse ne soit
@@ -380,18 +388,18 @@
     précoces" (Early Hints) décrite dans la RFC 8297.
    
     
    Pour utiliser cette fonctionnalité, vous devez l'activer explicitement
     sur le serveur via :
    
-    
    H2EarlyHints on
    
-
+
    H2EarlyHints on
    
+
    
     
    Elle n'est en effet pas activée par défaut car certains navigateurs
     anciens perdent pied avec de telles réponses.
    
     
    Une fois cette fonctionnalité activée, vous pouvez utiliser la directive
     H2PushResource pour déclencher les
     suggestions précoces et les PUSHes de ressources :
    
-    
    <Location /xxx.html>
-    H2PushResource /xxx.css
-    H2PushResource /xxx.js
+
    <Location /xxx.html>
+H2PushResource /xxx.css
+H2PushResource /xxx.js
 </Location>
    
-
+
    
     
    Le serveur enverra alors au client une réponse "103 Early
     Hints" dès qu'il commencera à traiter la requête. Selon
     votre application web, cet envoi peut intervenir beaucoup plus tôt que le
diff --git a/docs/manual/howto/http2.xml.meta b/docs/manual/howto/http2.xml.meta
index 9b93a6fba0..cd0a8de064 100644
--- a/docs/manual/howto/http2.xml.meta
+++ b/docs/manual/howto/http2.xml.meta
@@ -9,6 +9,6 @@
   
     en
     es
-    fr
+    fr
   
 
diff --git a/docs/manual/howto/public_html.html.fr.utf8 b/docs/manual/howto/public_html.html.fr.utf8
index e61a7206c5..5cbd9a5e11 100644
--- a/docs/manual/howto/public_html.html.fr.utf8
+++ b/docs/manual/howto/public_html.html.fr.utf8
@@ -30,8 +30,6 @@
  ko  |
  tr 
    
 
    
-
    Cette traduction peut être périmée. Vérifiez la version
-            anglaise pour les changements récents.
    
 
 
    Sur les systèmes multi-utilisateurs, on peut permettre à chaque
 utilisateur d'avoir un site web dans son répertoire home à l'aide de la
@@ -40,18 +38,25 @@ visiteurs de l'URL http://example.com/~nom_utilisateur/
 recevront un contenu situé dans le répertoire home de l'utilisateur
 "nom_utilisateur", et dans le sous-répertoire spécifié par
 la directive UserDir.
    
-
    Notez que par défaut, l'accès à ces répertoires n'est
+
    Par défaut, l'accès à ces répertoires n'est
 pas permis. Vous pouvez en permettre l'accès à l'aide
 de la directive UserDir en
 décommentant la ligne :
    
-    
    #Include conf/extra/httpd-userdir.conf
    
-
+
    #Include conf/extra/httpd-userdir.conf
    
+
    
     
    dans le fichier de configuration par défaut
     conf/httpd.conf, et en adaptant le
     fichier httpd-userdir.conf selon vos besoins, ou en
     incluant les directives appropriées dans une section
     <Directory> du fichier de
     configuration principal.
    
+
+    
    Les distributions tierces de httpd (fournies par le fabricant de votre
+    OS ou par le gestionnaire de paquets) placent souvent la configuration de
+    mod_userdir dans un fichier séparé, et peuvent l’activer
+    par défaut. Consultez la documentation de votre distribution pour les
+    spécificités. Les exemples de ce document présupposent une construction par
+    défaut à partir des sources de httpd.
    
 
    
 
     interprété comme chemin relatif au répertoire home de l'utilisateur
     considéré. Par exemple, avec cette configuration :
    
 
-    
    UserDir public_html
    
-
+
    UserDir public_html
    
+
    
 
     
    l'URL http://example.com/~rbowen/fichier.html
     correspondra au chemin fichier
@@ -93,9 +98,8 @@ avec le système de fichiers
    
     sera construit en utilisant ce chemin, suivi du nom de l'utilisateur
     considéré. Par exemple, avec cette configuration :
    
 
-    
    UserDir /var/html
    
-
-
+
    UserDir /var/html
    
+
    
     
    l'URL http://example.com/~rbowen/fichier.html
     correspondra au chemin fichier
     /var/html/rbowen/fichier.html
    
@@ -104,8 +108,8 @@ avec le système de fichiers
    
     remplacé par le nom de l'utilisateur dans le chemin du fichier
     correspondant. Par exemple, avec cette configuration :
    
 
-    
    UserDir /var/www/*/docs
    
-
+
    UserDir /var/www/*/docs
    
+
    
 
     
    l'URL http://example.com/~rbowen/fichier.html
     correspondra au chemin fichier
@@ -114,14 +118,14 @@ avec le système de fichiers
     
    On peut aussi définir plusieurs répertoires ou chemins de
     répertoires.
    
 
-    
    UserDir public_html /var/html
    
-
+
    UserDir public_html /var/html
    
+
    
 
-    
    Avec l'URL http://example.com/~rbowen/fichier.html,
-    Apache va rechercher ~rbowen. S'il ne le trouve pas,
-    Apache va rechercher rbowen dans
-    /var/html. S'il le trouve, l'URL ci-dessus correspondra
-    au chemin fichier /var/html/rbowen/file.html
    
+    
    Les arguments sont pris en compte selon l’ordre dans lequel ils
+    apparaissent. Pour l’URL http://example.com/~rbowen/file.html,
+    httpd recherchera d’abord ~rbowen. Si ce dernier n’est pas
+    trouvé, httpd cherchera rbowen dans /var/html. Le
+    fichier sera servi depuis le premier emplacement trouvé.
    
 
   
    top
    
 
    
@@ -130,8 +134,8 @@ avec le système de fichiers
    
     
    On peut utiliser la directive UserDir pour rediriger les requêtes
     relatives aux répertoires utilisateurs vers des URLs externes.
    
 
-    
    UserDir http://example.org/users/*/
    
-
+
    UserDir http://example.org/users/*/
    
+
    
 
     
    L'exemple ci-dessus va rediriger une requête pour
     http://example.com/~bob/abc.html vers
@@ -146,8 +150,8 @@ avec le système de fichiers
     vous pouvez définir quels utilisateurs sont autorisés à utiliser
     cette fonctionnalité :
    
 
-    
    UserDir disabled root jro fish
    
-
+
    UserDir disabled root jro fish
    
+
    
 
     
    La configuration ci-dessus va autoriser l'utilisation de la
     fonctionnalité pour tous les utilisateurs, à l'exception de ceux
@@ -156,10 +160,9 @@ avec le système de fichiers
     utilisateurs sauf certains d'entre eux en utilisant une
     configuration du style :
    
 
-    
    UserDir disabled
+
    UserDir disabled
 UserDir enabled rbowen krietz
    
-
-
+
    
     
    Vous trouverez d'autres exemples dans la documentation de
     UserDir.
    
 
@@ -172,12 +175,11 @@ UserDir enabled rbowen krietz
    
    vous pouvez utiliser une section <Directory> pour activer CGI dans un
    sous-répertoire particulier d'un répertoire home utilisateur.
    
 
-    
    <Directory "/home/*/public_html/cgi-bin/">
-    Options ExecCGI
-    SetHandler cgi-script
+
    <Directory "/home/*/public_html/cgi-bin/">
+Options ExecCGI
+SetHandler cgi-script
 </Directory>
    
-
-
+
    
     
    Avec la configuration ci-dessus, et en supposant que
     UserDir est défini à public_html, un
     programme CGI exemple.cgi pourra être chargé depuis ce
diff --git a/docs/manual/howto/public_html.xml.meta b/docs/manual/howto/public_html.xml.meta
index 837b62daaf..b9f5ce5a8f 100644
--- a/docs/manual/howto/public_html.xml.meta
+++ b/docs/manual/howto/public_html.xml.meta
@@ -9,7 +9,7 @@
   
     en
     es
-    fr
+    fr
     ja
     ko
     tr
diff --git a/docs/manual/howto/reverse_proxy.html.fr.utf8 b/docs/manual/howto/reverse_proxy.html.fr.utf8
index 0586c43f24..700dd57b06 100644
--- a/docs/manual/howto/reverse_proxy.html.fr.utf8
+++ b/docs/manual/howto/reverse_proxy.html.fr.utf8
@@ -27,30 +27,20 @@
  es  |
  fr 
    
 
-
    Cette traduction peut être périmée. Vérifiez la version
-            anglaise pour les changements récents.
    
-
-    
    En plus de ses fonctions de serveur web "basique", à savoir fournir du
-    contenu statique et dynamique à l'utilisateur, Apache httpd (comme la
-    plupart des autres serveurs web) peut aussi assurer les fonctions de serveur
-    mandataire inverse, connu aussi sous le nom de serveur "passerelle".
    
-
-    
    Dans un tel scénario, httpd ne génère et n'héberge pas lui-même les
-    données, le contenu étant en général obtenu à partir d'un ou plusieurs serveurs
-    d'arrière-plan qui n'ont normalement aucune connexion directe avec le réseau
-    externe. Lorsque httpd reçoit une requête en provenance d'un client, la
-    requête proprement dite est mandatée vers un de ces serveurs
-    d'arrière-plan qui traite la requête, génère le contenu et l'envoie à httpd,
-    ce dernier générant la véritable réponse HTTP à destination du client.
    
-
-    
    De nombreuses raisons peuvent vous motiver à utiliser cette
-    fonctionnalité, mais elles sont souvent du domaine de la sécurité, de
-    la haute disponibilité, de la répartition de charge et de
-    l'authentification/autorisation centralisée. Il est alors indispensable que
-    l'organisation, la conception et l'architecture de l'infrastructure
-    d'arrière-plan (les serveurs qui traitent au sens propre les requêtes) soient
-    isolées et protégées de l'extérieur ; vu du client, le serveur mandataire
-    inverse est le seul serveur accessible pouvant lui fournir du
+
+    
    En plus de servir directement du contenu statique et dynamique, Apache
+    httpd peut remplir les fonctions d’un serveur mandataire inverse (parfois
+    appelé passerelle).
    
+
+    
    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.
    
+
+    
    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 est la seule source de tout
     contenu.
    
 
     
    Voici un exemple typique d'implémentation de cette fonctionnalité :
    
@@ -59,12 +49,12 @@
   
 
 
    top
    
@@ -86,26 +76,25 @@
       unique :
     
    
 
-    
    ProxyPass "/"  "http://www.example.com/"
    
-
+
    ProxyPass "/"  "http://www.example.com/"
    
+
    
 
     
    
-      Pour être sur que cette redirection soit effectuée et que les en-têtes
-      Location: générés par le serveur d'arrière-plan soient
-      modifiés pour pointer vers le mandataire inverse, et non vers le serveur
-      d'arrière-plan, la directive ProxyPassReverse est souvent requise :
+      Pour s’assurer que les en-têtes Location: 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 ProxyPassReverse est en général requise :
     
    
 
-    
    ProxyPass "/"  "http://www.example.com/"
+
    ProxyPass "/"  "http://www.example.com/"
 ProxyPassReverse "/"  "http://www.example.com/"
    
+
    
 
-
-    
    Seules des URIs spécifiques peuvent être mandatées, comme le montre
+    
    Il est possible de spécifier les URIs qui peuvent être mandatés, comme le montre
     l'exemple suivant :
    
 
-    
    ProxyPass "/images"  "http://www.example.com/"
+
    ProxyPass "/images"  "http://www.example.com/"
 ProxyPassReverse "/images"  "http://www.example.com/"
    
-
+
    
 
     
    Dans l'exemple précédent, si le chemin d'une requête commence par
     /images, elle sera redirigée vers le serveur d'arrière-plan
@@ -113,39 +102,38 @@ ProxyPassReverse "/images"  "http://www.example.com/"
    
     
    
   
    top
    
 
    
-
    Clusters et Balancers 
    
+
    Grappes et répartiteurs de charge 
    
     
 
     
    
-      Utiliser un serveur d'arrière-plan unique n'est cependant pas une solution
-      idéale car ce dernier peut devenir indisponible ou surchargé, et le
-      mandatement inverse vers ce serveur ne présente alors plus aucun avantage.
-      La solution réside dans la définition d'un groupe de serveurs
-      d'arrière-plan qui vont se partager le traitement des requêtes via un
-      mécanisme de répartition de charge et de gestion des indisponibilités pris
-      en charge par le mandataire. Ce groupe de répartition est plus connu sous le nom de
-      cluster, mais dans la terminologie d'Apache httpd, on utilise
-      plutôt le terme de balancer. Un balancer se définit en
-      utilisant les directives <Proxy> et BalancerMember comme suit :
+       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é grappe
+       (cluster) ; Apache httpd le nomme répartiteur de charge
+       (balancer). Un répartiteur de charge se définit en utilisant les
+       directives <Proxy>
+       et BalancerMember :
     
    
 
-    
    <Proxy balancer://myset>
-    BalancerMember http://www2.example.com:8080
-    BalancerMember http://www3.example.com:8080
-    ProxySet lbmethod=bytraffic
+
    <Proxy balancer://myset>
+BalancerMember http://www2.example.com:8080
+BalancerMember http://www3.example.com:8080
+ProxySet lbmethod=bytraffic
 </Proxy>
 
 ProxyPass "/images/"  "balancer://myset/"
 ProxyPassReverse "/images/"  "balancer://myset/"
    
-
+
    
 
     
    
       Le protocole balancer:// indique à httpd que l'on souhaite
-      créer un balancer nommé myset. Ce balancer comporte deux serveurs
+      créer un répartiteur de charge nommé myset. Ce répartiteur comporte deux serveurs
       d'arrière-plan référencés dans la terminologie httpd sous le nom de
       BalancerMembers. Avec cet exemple, toute requête dont le chemin
       commence par /images sera mandatée vers un des deux
-      serveurs d'arrière-plan. La directive ProxySet définit ici pour le balancer
+      serveurs d'arrière-plan. La directive ProxySet définit ici pour le répartiteur
       myset un algorithme de
       répartition de charge basé sur le trafic entrées/sorties.
     
    
@@ -159,25 +147,25 @@ ProxyPassReverse "/images/"  "balancer://myset/"
    
 
   
    top
    
 
    
-
    Configuration du Balancer et des BalancerMembers 
    
+
    Configuration du répartiteur de charge et de ses membres (workers) 
    
     
 
     
    
-      Vous pouvez configurer de manière détaillée les balancers et
-      workers via les nombreux paramètres de la directive ProxyPass. Par exemple, si vous souhaitez
-      que http://www3.example.com:8080 traite avec un facteur 3 le
-      trafic avec un timeout d'une seconde, utilisez la configuration suivante :
+      Les répartiteurs de charge et leurs membres sont configurés à l’aide de
+      paramètres de la directive ProxyPass. Par exemple, pour que
+      http://www3.example.com:8080 gère le trafic avec un facteur 3
+      et un délai d’une seconde :
     
    
 
-    
    <Proxy balancer://myset>
-    BalancerMember http://www2.example.com:8080
-    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
-    ProxySet lbmethod=bytraffic
+
    <Proxy balancer://myset>
+BalancerMember http://www2.example.com:8080
+BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+ProxySet lbmethod=bytraffic
 </Proxy>
 
 ProxyPass "/images"  "balancer://myset/"
 ProxyPassReverse "/images"  "balancer://myset/"
    
-
+
    
 
   
    top
    
 
    
@@ -185,9 +173,9 @@ ProxyPassReverse "/images"  "balancer://myset/"
    
     
 
     
    
-      Vous pouvez aussi définir finement des scénarios pour les cas
-      d'indisponibilité d'un ou plusieurs serveurs d'arrière-plan en spécifiant
-      quels serveurs doivent alors prendre le relai. Dans l'exemple suivant,
+      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 : 
     
    
     
      
@@ -216,30 +204,29 @@ ProxyPassReverse "/images"  "balancer://myset/"
    
       ou de standby pour chaque jeu de serveurs du répartiteur de charge.
     
        
 
-    
    <Proxy balancer://myset>
-    BalancerMember http://www2.example.com:8080
-    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
-    BalancerMember http://spare1.example.com:8080 status=+R
-    BalancerMember http://spare2.example.com:8080 status=+R
-    BalancerMember http://hstandby.example.com:8080 status=+H
-    BalancerMember http://bkup1.example.com:8080 lbset=1
-    BalancerMember http://bkup2.example.com:8080 lbset=1
-    ProxySet lbmethod=byrequests
+
    <Proxy balancer://myset>
+BalancerMember http://www2.example.com:8080
+BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+BalancerMember http://spare1.example.com:8080 status=+R
+BalancerMember http://spare2.example.com:8080 status=+R
+BalancerMember http://hstandby.example.com:8080 status=+H
+BalancerMember http://bkup1.example.com:8080 lbset=1
+BalancerMember http://bkup2.example.com:8080 lbset=1
+ProxySet lbmethod=byrequests
 </Proxy>
 
 ProxyPass "/images/"  "balancer://myset/"
 ProxyPassReverse "/images/"  "balancer://myset/"
    
-
+
    
 
     
    
       Les serveurs de remplacement à chaud remplacent les serveurs indisponibles
-      du même jeu de serveurs du répartiteur de charge. Un serveur est
-      considéré comme indisponible s'il est en maintenance, arrêté ou en erreur.
-      Les serveurs de standby à chaud sont utilisés si tous les serveurs et
-      serveurs de remplacement du jeu de serveurs du répartiteur de charge sont
-      indisponibles. Les jeux de serveurs du répartiteur de charge (avec leurs
-      serveurs de standby et de remplacement à chaud respectifs) sont toujours
-      sollicités dans l'ordre du plus bas lbset vers le plus haut.
+      (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.
     
    
 
   
    top
    
@@ -248,21 +235,19 @@ ProxyPassReverse "/images/"  "balancer://myset/"
    
     
 
     
    
-     L'application balancer-manager fournie avec le mandataire inverse
-     d'Apache httpd en est un des outils les plus utiles. Comme
-     mod_status, balancer-manager affiche la
-     configuration et l'activité actuelles des balancers actifs. L'affichage de
-     ces informations n'est cependant pas sa seule fonction ; il permet aussi de
-     modifier la plupart d'entre elles et même d'ajouter des membres au groupe
-     de répartition de charge en temps réel. Pour activer ces fonctionnalités,
-     vous devez ajouter les lignes suivantes à votre fichier de configuration : 
+      Apache httpd comporte un gestionnaire de répartiteur de charge
+      (balancer-manager) intégré. Comme mod_status, 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 :
     
    
 
-    
    <Location "/balancer-manager">
-    SetHandler balancer-manager
-    Require host localhost
+
    <Location "/balancer-manager">
+SetHandler balancer-manager
+Require host localhost
 </Location>
    
-
+
    
 
     
    Avertissement
    
       
    N'activez le balancer-manager que si vous avez déjà sécurisé votre serveur.
@@ -277,9 +262,9 @@ ProxyPassReverse "/images/"  "balancer://myset/"
    
     
    balancer-manager page
    
 
     
    
-      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 : 
     
    
     
    balancer-manager page
    
@@ -298,16 +283,15 @@ ProxyPassReverse "/images/"  "balancer://myset/"
    
   
    top
    
 
    
 
    Vérification dynamique du bon fonctionnement d'un serveur
-    d'arrière-plan 
    
+    dorsal 
     
 
     
    
-      Avant que le mandataire httpd ne fasse appel à un serveur d'arrière-plan, il
-      peut "tester" si ce dernier est disponible en définissant le
-      paramètre ping de ce serveur via la directive ProxyPass. Cependant, il est souvent plus
+      Avant de mandater une requête, httpd peut "tester" si le serveur
+      dorsal est disponible en définissant le paramètre ping de ce
+      serveur via la directive ProxyPass. Cependant, il est souvent plus
       judicieux de vérifier le bon fonctionnement d'un serveur hors
-      bande et de manière dynamique via le module
-      mod_proxy_hcheck d'Apache httpd.
+      ibande via le module mod_proxy_hcheck.
     
    
 
   
    top
    
diff --git a/docs/manual/howto/reverse_proxy.xml.meta b/docs/manual/howto/reverse_proxy.xml.meta
index e1b2d0688e..81e38878e9 100644
--- a/docs/manual/howto/reverse_proxy.xml.meta
+++ b/docs/manual/howto/reverse_proxy.xml.meta
@@ -9,6 +9,6 @@
   
     en
     es
-    fr
+    fr
   
 
diff --git a/docs/manual/logs.html.fr.utf8 b/docs/manual/logs.html.fr.utf8
index 0c853ba020..8095502d16 100644
--- a/docs/manual/logs.html.fr.utf8
+++ b/docs/manual/logs.html.fr.utf8
@@ -29,8 +29,6 @@
  ko  |
  tr 
    
 
-
    Cette traduction peut être périmée. Vérifiez la version
-            anglaise pour les changements récents.
    
 
     
    Pour véritablement gérer un serveur web,
     il est nécessaire de disposer d'un
@@ -85,7 +83,7 @@
     certainement avoir accès à l'uid sous lequel le serveur est démarré, en
     l'occurrence habituellement root. N'accordez PAS aux utilisateurs
     l'accès en écriture au répertoire dans lequel les journaux sont stockés
-    sans savoir exactement quelles en seraient les conséquences ; voir le
+ sans savoir exactement quelles en seraient les conséquences ; voir le
     document conseils sur la sécurité
     pour plus de détails.
    
 
@@ -182,8 +180,8 @@
     
    Pour ce faire, vous devez spécifier le nom du module dans votre
     directive LogLevel :
    
 
-    
    LogLevel info rewrite:trace5
    
-
+
    LogLevel info rewrite:trace5
    
+
    
 
     
    Dans cet exemple, le niveau de journalisation général est défini
     à info, et à trace5 pour mod_rewrite.
    
@@ -235,9 +233,9 @@
 
       
    Voici une configuration typique pour le journal des accès :
    
 
-      
    LogFormat "%h %l %u %t \"%r\" %>s %b" common
+
    LogFormat "%h %l %u %t \"%r\" %>s %b" common
 CustomLog "logs/access_log" common
    
-
+
    
 
       
    Ici est définie l'identité common qui est
       ensuite associée à une chaîne de format de journalisation particulière.
@@ -386,9 +384,9 @@ CustomLog "logs/access_log" common
    
       "Combined Log Format" (Format de journalisation combiné). Il s'utilise
       comme suit :
    
 
-      
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
+
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
 CustomLog "log/access_log" combined
    
-
+
    
 
       
    Ce format est identique au Common Log Format, avec deux champs
       supplémentaires. Chacun de ces deux champs utilise la directive
@@ -437,11 +435,11 @@ CustomLog "log/access_log" combined
    
       comment simuler les effets des directives ReferLog et
       AgentLog.
    
 
-      
    LogFormat "%h %l %u %t \"%r\" %>s %b" common
+
    LogFormat "%h %l %u %t \"%r\" %>s %b" common
 CustomLog "logs/access_log" common
 CustomLog "logs/referer_log" "%{Referer}i -> %U"
 CustomLog "logs/agent_log" "%{User-agent}i"
    
-
+
    
 
       
    Cet exemple montre aussi qu'il n'est pas obligatoire d'associer
       une chaîne de format à un alias au moyen de la directive
@@ -466,31 +464,31 @@ CustomLog "logs/agent_log" "%{User-agent}i"
    
       la variable d'environnement est définie.
       Quelques exemples :
    
 
-      
    # 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
 SetEnvIf Request_URI "^/robots\.txt$" dontlog
 # Journalise toutes les autres requêtes
 CustomLog "logs/access_log" common env=!dontlog
    
-
+
    
 
       
    Autre exemple, imaginons l'enregistrement des requêtes en provenance
       d'utilisateurs de langue anglaise dans un journal, et celles des autres
       utilisateurs dans un autre journal.
    
 
-      
            SetEnvIf Accept-Language "en" english
-        CustomLog "logs/english_log" common env=english
-        CustomLog "logs/non_english_log" common env=!english
    
-
+
    SetEnvIf Accept-Language "en" english
+CustomLog "logs/english_log" common env=english
+CustomLog "logs/non_english_log" common env=!english
    
+
    
 
 	
    Dans le contexte d'une mise en cache, il peut être
 	intéressant de connaître l'efficacité du cache. Pour y parvenir,
 	on pourrait utiliser cette méthode simple :
    
 
-      
    SetEnv CACHE_MISS 1
+
    SetEnv CACHE_MISS 1
 LogFormat "%h %l %u %t "%r " %>s %b %{CACHE_MISS}e" common-cache
 CustomLog "logs/access_log" common-cache
    
-
+
    
 
       
    mod_cache va s'exécuter avant
       mod_env, et si son action est couronnée de
@@ -503,9 +501,9 @@ CustomLog "logs/access_log" common-cache
    
       valeurs de journalisation conditionnelles basées sur le code de la
       réponse HTTP :
    
 
-      
    LogFormat "%400,501{User-agent}i" browserlog
+
    LogFormat "%400,501{User-agent}i" browserlog
 LogFormat "%!200,304,302{Referer}i" refererlog
    
-
+
    
 
       
    Dans le premier exemple, le User-agent sera
       enregistré si le code d'état HTTP est 400 ou 501. Dans le cas
@@ -673,9 +671,9 @@ ErrorLog  "|/usr/local/apache/bin/rotatelogs /var/log/httpd/error_log 86400"
 
-    
    LogFormat "%v %p %h %l %u %t \"%r\" %>s %b" commonvhost
+
    LogFormat "%v %p %h %l %u %t \"%r\" %>s %b" commonvhost
 CustomLog "logs/access_log" commonvhost
    
-
+
    
 
     
    Le champ %v sert à enregistrer le nom de l'hôte virtuel qui
     traite la requête. Un programme tel que split-logfile peut ensuite être utilisé
diff --git a/docs/manual/logs.xml.ja b/docs/manual/logs.xml.ja
index 85b744ee6f..a60a63a468 100644
--- a/docs/manual/logs.xml.ja
+++ b/docs/manual/logs.xml.ja
@@ -1,7 +1,7 @@
 
 
 
-
+
 
 
+
 
 
+