From: Lucien Gentis Date: Wed, 1 Jul 2026 15:20:23 +0000 (+0000) Subject: fr doc XML files updates. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=fbf5d96aa736c871883798e67ae5643333db606f;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML files updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1935772 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/env.xml.fr b/docs/manual/env.xml.fr index 405f7f0120..52a92b4569 100644 --- a/docs/manual/env.xml.fr +++ b/docs/manual/env.xml.fr @@ -1,7 +1,7 @@ - + @@ -329,8 +329,10 @@ Variables d'environnement de CGI

La spécification sur les CGIs (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/howto/access.xml.fr b/docs/manual/howto/access.xml.fr index 9986bf0a77..0c348d7529 100644 --- a/docs/manual/howto/access.xml.fr +++ b/docs/manual/howto/access.xml.fr @@ -1,7 +1,7 @@ - + @@ -46,9 +46,8 @@

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.

@@ -75,10 +74,12 @@ client

Les directives Require s'utilisent comme suit :

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

Dans la première forme, nom-hôte est un nom de domaine pleinement qualifié (fqdn), ou un nom de domaine partiel ; vous @@ -89,12 +90,29 @@ 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 @@ -104,29 +122,37 @@ 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 +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 host phishers.example.com badguys.example Require not host gov - + +

Les directives RequireAll, fonction du user-agent (le type de navigateur), vous pouvez spécifier ceci :

- + + <If "%{HTTP_USER_AGENT} == 'BadBot'"> - Require all denied +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' - + + Avertissement :

Contrôler l'accès en fonction de l'en-tête @@ -185,12 +215,14 @@ d'accès

Par exemple, pour bloquer l'accès à une ressources entre 20h et 7h du matin, vous pouvez utiliser mod_rewrite :

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

Toute requête arrivant après 20h ou avant 7h du matin provoquera l'envoi d'une réponse de type 403 Forbidden. Vous pouvez utiliser diff --git a/docs/manual/howto/auth.xml.fr b/docs/manual/howto/auth.xml.fr index d9d611e184..b9a5721bf6 100644 --- a/docs/manual/howto/auth.xml.fr +++ b/docs/manual/howto/auth.xml.fr @@ -1,7 +1,7 @@ - + @@ -135,10 +135,14 @@ 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 @@ -211,14 +215,16 @@ module de chaque groupe.

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

- + + 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 @@ -322,15 +328,17 @@ plusieurs personnes

Maintenant, vous devez modifier votre fichier .htaccess comme suit :

- + + 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 @@ -341,7 +349,11 @@ 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 à @@ -394,15 +406,17 @@ 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 +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.

@@ -420,16 +434,18 @@ d'authentification conjointement les fournisseurs d'authentification file et LDAP :

- + + <Directory "/www/docs/private"> - AuthName "Private" - AuthType Basic - AuthBasicProvider file ldap - AuthUserFile "/usr/local/apache/passwd/passwords" - AuthLDAPURL ldap://ldaphost/o=yourorg - Require valid-user +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 @@ -447,18 +463,20 @@ d'authentification autorisation à base de fichier de groupes et une autorisation à base de groupes LDAP.

- + + <Directory "/www/docs/private"> - AuthName "Private" - AuthType Basic - AuthBasicProvider file - AuthUserFile "/usr/local/apache/passwd/passwords" - AuthLDAPURL ldap://ldaphost/o=yourorg - AuthGroupFile "/usr/local/apache/passwd/groups" - Require group GroupName - Require ldap-group cn=mygroup,o=yourorg +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

Utilisation de fournisseurs d'autorisation pour le contrôle d'accès -

La vérification du nom d'utilisateur et du mot de passe ne - constituent qu'un aspect des méthodes d'authentification. - Souvent, le contrôle d'accès à certaines personnes n'est pas - basé sur leur identité ; il peut dépendre, par exemple de leur - provenance.

- -

Les fournisseurs d'autorisation all, - env, host et ip vous - permettent d'accorder ou refuser l'accès en - fonction de critères tels que le nom d'hôte ou l'adresse - IP de la machine qui effectue la requête.

- -

L'utilisation de ces fournisseurs est spécifiée à l'aide de - la directive Require. Cette directive - permet d'enregistrer quels fournisseurs d'autorisation - seront appelés dans le processus d'autorisation au cours du - traitement de la requête. Par exemple :

- - Require ip address - -

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

- - Require host domain_name - -

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

- -

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

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

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

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

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

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

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

+

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.

@@ -643,17 +598,14 @@ autorisation
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.

Pour aller plus loin . . . diff --git a/docs/manual/howto/htaccess.xml.fr b/docs/manual/howto/htaccess.xml.fr index 7a70c739f5..aca671fc44 100644 --- a/docs/manual/howto/htaccess.xml.fr +++ b/docs/manual/howto/htaccess.xml.fr @@ -1,7 +1,7 @@ - + @@ -56,7 +56,7 @@ modifier les fichiers de configuration principaux du serveur.

AuthName AuthUserFile AuthGroupFile - Require + Require @@ -81,9 +81,11 @@ modifier les fichiers de configuration principaux du serveur.

.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 @@ -102,7 +104,7 @@ modifier les fichiers de configuration principaux du serveur.

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 @@ -159,26 +161,26 @@ modifier les fichiers de configuration principaux du serveur.

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

@@ -187,7 +189,7 @@ modifier les fichiers de configuration principaux du serveur.

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 @@ -204,46 +206,58 @@ modifier les fichiers de configuration principaux du serveur.

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 # 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 - <code>/www/htdocs/exemple</code> - AddType text/example ".exm" + /www/htdocs/example + + +AddType text/example ".exm" + + Section de votre fichier <code>httpd.conf</code> - + + <Directory "/www/htdocs/example"> - AddType text/example ".exm" +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 + +
Comment sont appliquées les directives ? @@ -251,7 +265,7 @@ AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCond

Les directives de configuration situées dans un fichier .htaccess s'appliquent au répertoire dans lequel ce fichier .htaccess se trouve, ainsi qu'à tous ses - sous-répertoires. Cependant, il est important de garder à l'esprit + 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 @@ -268,18 +282,26 @@ AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCond

Dans 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 @@ -304,15 +326,17 @@ AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCond définition de toute autre option dans les fichiers .htaccess, vous pouvez utiliser :

- + + <Directory "/www/htdocs"> - AllowOverride All +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 @@ -331,16 +355,18 @@ AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCond

Contenu du fichier .htaccess :

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

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

+ 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 @@ -355,15 +381,17 @@ Includes - SSI) on utilise les directives de configuration suivantes, placées dans un fichier .htaccess enregistré dans le répertoire considéré :

- + + Options +Includes AddType text/html "shtml" AddHandler server-parsed shtml - + + -

Notez que AllowOverride Options et AllowOverride + 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 SSI pour une description plus détaillée des SSI.

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

+ # Dans httpd.conf RewriteRule "^/images/(.+)\.jpg" "/images/$1.png" @@ -388,6 +417,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 @@ -398,7 +428,7 @@ la chaîne /images/ disparaît de cette même valeur de remplacement. Il doit donc en être de même dans votre expression rationnelle.

-

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.

@@ -422,23 +452,27 @@ 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 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 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 @@ -460,9 +494,11 @@ SetHandler cgi-script dénué de sens dans votre ficher .htaccess et de recharger la page :

- + + TestMe - + +

Si aucune erreur (HTTP 500) n'est générée par le serveur, il est pratiquement certain qu'une directive @@ -474,13 +510,15 @@ TestMe 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 @@ -489,9 +527,11 @@ TestMe

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/reverse_proxy.xml.fr b/docs/manual/howto/reverse_proxy.xml.fr index 0447142cb3..4fd3db51d1 100644 --- a/docs/manual/howto/reverse_proxy.xml.fr +++ b/docs/manual/howto/reverse_proxy.xml.fr @@ -1,7 +1,7 @@ - + - + - +