You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by lg...@apache.org on 2019/11/09 16:34:57 UTC
svn commit: r1869607 - in /httpd/httpd/trunk/docs/manual: configuring.xml.fr
misc/security_tips.xml.fr mod/mod_auth_form.xml.fr mod/mod_md.xml.fr
mod/mod_ssl.xml.fr
Author: lgentis
Date: Sat Nov 9 16:34:55 2019
New Revision: 1869607
URL: http://svn.apache.org/viewvc?rev=1869607&view=rev
Log:
fr doc XML updates.
Modified:
httpd/httpd/trunk/docs/manual/configuring.xml.fr
httpd/httpd/trunk/docs/manual/misc/security_tips.xml.fr
httpd/httpd/trunk/docs/manual/mod/mod_auth_form.xml.fr
httpd/httpd/trunk/docs/manual/mod/mod_md.xml.fr
httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml.fr
Modified: httpd/httpd/trunk/docs/manual/configuring.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/configuring.xml.fr?rev=1869607&r1=1869606&r2=1869607&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/configuring.xml.fr [utf-8] (original)
+++ httpd/httpd/trunk/docs/manual/configuring.xml.fr [utf-8] Sat Nov 9 16:34:55 2019
@@ -1,4 +1,4 @@
-<?xml version="1.0" ?>
+<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
@@ -27,7 +27,7 @@
<title>Fichiers de configuration</title>
<summary>
-<p>Ce document décrit les fichiers utilisés pour configurer
+<p>Ce document décrit les fichiers utilisés pour configurer
le Serveur HTTP Apache.</p>
</summary>
@@ -44,26 +44,26 @@ le Serveur HTTP Apache.</p>
</directivelist>
</related>
- <p>La configuration du serveur HTTP Apache est effectuée en plaçant des <a
+ <p>La configuration du serveur HTTP Apache est effectuée en plaçant des <a
href="mod/directives.html">directives</a> dans des fichiers de
configuration au format texte. Le fichier de configuration principal se nomme
- en général
- <code>httpd.conf</code>. La localisation de ce fichier est définie
- à la compilation, mais peut être redéfinie à l'aide de l'option
+ en général
+ <code>httpd.conf</code>. La localisation de ce fichier est définie
+ à la compilation, mais peut être redéfinie à l'aide de l'option
de ligne de commande <code>-f</code>. En outre, d'autres fichiers de
- configuration peuvent être ajoutés à l'aide de la directive
- <directive module="core">Include</directive>, et des caractères de
+ configuration peuvent être ajoutés à l'aide de la directive
+ <directive module="core">Include</directive>, et des caractères de
remplacement
- peuvent être utilisés pour inclure de nombreux fichiers de configuration.
- Des directives de tous types peuvent être placées dans chacun de ces fichiers
+ peuvent être utilisés pour inclure de nombreux fichiers de configuration.
+ Des directives de tous types peuvent être placées dans chacun de ces fichiers
de configuration. Les modifications dans les fichiers de configuration
principaux ne sont prises en compte par httpd que lorsque le serveur
- est démarré ou redémarré.</p>
+ est démarré ou redémarré.</p>
<p>Le serveur lit aussi un fichier contenant les types de document mime;
- ce fichier est défini par la directive <directive
+ ce fichier est défini par la directive <directive
module="mod_mime">TypesConfig</directive>,
- et se nomme <code>mime.types</code> par défaut.</p>
+ et se nomme <code>mime.types</code> par défaut.</p>
</section>
<section id="syntax">
@@ -71,70 +71,70 @@ le Serveur HTTP Apache.</p>
<p>Les fichiers de configuration de httpd contiennent une directive
par ligne.
- On peut utiliser l'anti-slash "\" comme dernier caractère d'une ligne
- pour indiquer que la directive continue à la ligne suivante.
- Il ne doit y avoir aucun caractère ni espace entre l'anti-slash et
+ On peut utiliser l'anti-slash "\" comme dernier caractère d'une ligne
+ pour indiquer que la directive continue à la ligne suivante.
+ Il ne doit y avoir aucun caractère ni espace entre l'anti-slash et
la fin de la ligne.</p>
- <p>Les arguments des directives sont séparés les uns des autres par
- des espaces. Si un argument contient des espaces, il doit être
- entouré de guillemets.</p>
+ <p>Les arguments des directives sont séparés les uns des autres par
+ des espaces. Si un argument contient des espaces, il doit être
+ entouré de guillemets.</p>
<p>Les directives dans les fichiers de configuration ne sont pas
- sensibles à la casse, mais leurs arguments le sont souvent. Les lignes
- qui débutent par le caractère "#" sont interprétées comme des
- commentaires, et sont ignorées. Les commentaires ne doivent
- <strong>pas</strong> apparaître sur la même ligne qu'une directive
- de configuration. Les espaces précédant une directive
- sont ignorés; vous pouvez par conséquent indenter les directives
- afin d'améliorer la lisibilité. Les lignes vides sont
- aussi ignorées.</p>
+ sensibles à la casse, mais leurs arguments le sont souvent. Les lignes
+ qui débutent par le caractère "#" sont interprétées comme des
+ commentaires, et sont ignorées. Les commentaires ne doivent
+ <strong>pas</strong> apparaître sur la même ligne qu'une directive
+ de configuration. Les espaces précédant une directive
+ sont ignorés; vous pouvez par conséquent indenter les directives
+ afin d'améliorer la lisibilité. Les lignes vides sont
+ aussi ignorées.</p>
<p>Les valeurs des variables d'environnement ou des variables
- définies via la directive <directive
- module="core">Define</directive> peuvent être utilisées dans le
+ définies via la directive <directive
+ module="core">Define</directive> peuvent être utilisées dans le
fichier de configuration en utilisant la syntaxe
<code>${VAR}</code>. Si "VAR" est le nom d'une variable valide, la
- valeur de la variable est alors substituée à la chaîne
+ valeur de la variable est alors substituée à la chaîne
<code>${VAR}</code>, et le processus de lecture du fichier de
- configuration continue comme si la chaîne correspondant à la valeur
- de la variable s'y était trouvée littéralement. Les variables définies
+ configuration continue comme si la chaîne correspondant à la valeur
+ de la variable s'y était trouvée littéralement. Les variables définies
via la directive <directive module="core">Define</directive>
l'emportent sur les autres variables d'environnement du shell. Si la
- variable "VAR" n'est pas trouvée, la chaîne <code>${VAR}</code>
- n'est pas modifiée, et un avertissement est enregistré dans le
- journal. Le caractère ":" est interdit dans les noms de variables
- afin d'éviter tout conflit avec la syntaxe de la directive <directive
+ variable "VAR" n'est pas trouvée, la chaîne <code>${VAR}</code>
+ n'est pas modifiée, et un avertissement est enregistré dans le
+ journal. Le caractère ":" est interdit dans les noms de variables
+ afin d'éviter tout conflit avec la syntaxe de la directive <directive
module="mod_rewrite">RewriteMap</directive>.</p>
- <p>Seules les variables d'environnement du shell définies avant le démarrage
- du serveur peuvent être utilisées dans les extensions.
+ <p>Seules les variables d'environnement du shell définies avant le démarrage
+ du serveur peuvent être utilisées en extension.
Les variables d'environnement
- définies dans le fichier de configuration lui-même, par exemple avec <directive
+ définies dans le fichier de configuration lui-même, par exemple avec <directive
module="mod_env">SetEnv</directive>, prennent effet trop tard pour
- pouvoir être utilisées dans les extensions au sein du fichier de
+ pouvoir être utilisées en extension au sein du fichier de
configuration.</p>
<p>La longueur maximale d'une ligne dans un fichier de configuration
- normal, après substitution des variables et fusion des lignes
+ normal, après substitution des variables et fusion des lignes
interrompues, est approximativement de 16 Mo. Dans les <a
href="configuring.html#htaccess">fichiers .htaccess</a>, la longueur
- maximale est de 8190 caractères.</p>
+ maximale est de 8190 caractères.</p>
- <p>Vous pouvez vérifier l'absence d'erreurs de syntaxe dans vos fichiers
- de configuration sans démarrer le serveur à l'aide de la commande
+ <p>Vous pouvez vérifier l'absence d'erreurs de syntaxe dans vos fichiers
+ de configuration sans démarrer le serveur à l'aide de la commande
<code>apachectl configtest</code> ou de l'option de ligne de commande
<code>-t</code>.</p>
- <p>Vous pouvez utiliser la définition <code>-DDUMP_CONFIG</code> de
+ <p>Vous pouvez utiliser la définition <code>-DDUMP_CONFIG</code> de
<module>mod_info</module> pour afficher la configuration avec tous
- les fichiers inclus et les variables d'environnement évaluées, tous
+ les fichiers inclus et les variables d'environnement évaluées, tous
les commentaires et les sections <directive module="core"
type="section">IfDefine</directive> et <directive module="core"
type="section">IfModule</directive> non actives ayant
- été supprimés. Cependant, la sortie ne reflète
- pas les fusions ou écrasements pouvant intervenir en cas de
- définitions multiples de directives.</p>
+ été supprimés. Cependant, la sortie ne reflète
+ pas les fusions ou écrasements pouvant intervenir en cas de
+ définitions multiples de directives.</p>
</section>
<section id="modules">
@@ -151,29 +151,29 @@ le Serveur HTTP Apache.</p>
</related>
<p>httpd est un serveur modulaire. Ceci implique que seules les
- fonctionnalités les plus courantes sont incluses dans le serveur de base.
- Les fonctionnalités étendues sont fournies à l'aide de <a
- href="mod/">modules</a> qui peuvent être chargés dans httpd.
- Par défaut, un jeu de <a
+ fonctionnalités les plus courantes sont incluses dans le serveur de base.
+ Les fonctionnalités étendues sont fournies à l'aide de <a
+ href="mod/">modules</a> qui peuvent être chargés dans httpd.
+ Par défaut, un jeu de <a
href="mod/module-dict.html#Status">modules de base</a> est inclus dans le
- serveur à la compilation. Si le serveur est compilé de façon à utiliser
- les <a href="dso.html">modules chargés dynamiquement</a>,
- alors les modules peuvent être compilés séparément et chargés à
- n'importe quel moment à l'aide de la directive
+ serveur à la compilation. Si le serveur est compilé de façon à utiliser
+ les <a href="dso.html">modules chargés dynamiquement</a>,
+ alors les modules peuvent être compilés séparément et chargés à
+ n'importe quel moment à l'aide de la directive
<directive module="mod_so">LoadModule</directive>.
- Dans le cas contraire, httpd doit être recompilé pour ajouter ou
+ Dans le cas contraire, httpd doit être recompilé pour ajouter ou
supprimer des modules.
- Les directives de configuration peuvent être incluses de manière
- conditionnelle selon la présence ou l'absence d'un module particulier
- en les plaçant dans un bloc <directive
+ Les directives de configuration peuvent être incluses de manière
+ conditionnelle selon la présence ou l'absence d'un module particulier
+ en les plaçant dans un bloc <directive
module="core" type="section">IfModule</directive>.</p>
- <p>Pour voir quels modules ont été compilés avec le serveur,
+ <p>Pour voir quels modules ont été compilés avec le serveur,
vous pouvez utiliser l'option de ligne de commande <code>-l</code>.</p>
</section>
<section id="scope">
- <title>Portée des directives</title>
+ <title>Portée des directives</title>
<related>
<directivelist>
@@ -187,10 +187,10 @@ le Serveur HTTP Apache.</p>
</directivelist>
</related>
- <p>Les directives placées dans les fichiers de configuration principaux
+ <p>Les directives placées dans les fichiers de configuration principaux
s'appliquent au serveur dans son ensemble. Si vous souhaitez modifier la
configuration d'une partie du serveur seulement, vous pouvez limiter la
- portée de vos directives en les plaçant dans une section
+ portée de vos directives en les plaçant dans une section
<directive module="core"
type="section">Directory</directive>, <directive module="core"
type="section">DirectoryMatch</directive>, <directive module="core"
@@ -199,25 +199,25 @@ le Serveur HTTP Apache.</p>
type="section">Location</directive>, ou <directive module="core"
type="section">LocationMatch</directive>.
Ces sections limitent le champ d'application des directives qu'elles
- contiennent à des URls ou des portions du système de fichiers particulières.
- Elles peuvent aussi être imbriquées, ce qui permet
- une configuration très fine.</p>
-
- <p>httpd peut servir simultanément de nombreux sites web au travers des
- <a href="vhosts/">Hôtes Virtuels</a>. La portée des directives peut ainsi
- être limitée en les plaçant dans des sections
+ contiennent à des URls ou des portions du système de fichiers particulières.
+ Elles peuvent aussi être imbriquées, ce qui permet
+ une configuration très fine.</p>
+
+ <p>httpd peut servir simultanément de nombreux sites web au travers des
+ <a href="vhosts/">Hôtes Virtuels</a>. La portée des directives peut ainsi
+ être limitée en les plaçant dans des sections
<directive module="core" type="section">VirtualHost</directive>,
- afin qu'elles ne s'appliquent qu'aux requêtes
+ afin qu'elles ne s'appliquent qu'aux requêtes
pour un site web particulier.</p>
- <p>Bien que la plupart des directives puissent être placées dans
+ <p>Bien que la plupart des directives puissent être placées dans
chacune de ces sections, certaines d'entre elles n'ont aucun sens
dans certains contextes.
- Par exemple, les directives qui contrôlent la création des processus
- n'ont de sens que dans le contexte du serveur principal. Pour déterminer
- quelles directives peuvent être placées dans quelles sections, consultez
+ Par exemple, les directives qui contrôlent la création des processus
+ n'ont de sens que dans le contexte du serveur principal. Pour déterminer
+ quelles directives peuvent être placées dans quelles sections, consultez
le <a href="mod/directive-dict.html#Context">Contexte</a> de la
- directive. Pour plus d'informations, nous fournissons des détails dans
+ directive. Pour plus d'informations, nous fournissons des détails dans
<a href="sections.html">Comment fonctionnent les sections Directory,
Location et Files</a>.</p>
</section>
@@ -232,29 +232,29 @@ le Serveur HTTP Apache.</p>
</directivelist>
</related>
- <p>httpd permet la gestion décentralisée de la configuration
- via des fichiers spéciaux placés dans l'arborescence du site web.
- Ces fichiers spéciaux se nomment en général <code>.htaccess</code>,
- mais tout autre nom peut être spécifié à l'aide de la directive
+ <p>httpd permet la gestion décentralisée de la configuration
+ via des fichiers spéciaux placés dans l'arborescence du site web.
+ Ces fichiers spéciaux se nomment en général <code>.htaccess</code>,
+ mais tout autre nom peut être spécifié à l'aide de la directive
<directive module="core">AccessFileName</directive>.
- Les directives placées dans les fichiers <code>.htaccess</code>
- s'appliquent au répertoire dans lequel vous avez placé le fichier,
- ainsi qu'à tous ses sous-répertoires.
- La syntaxe des fichiers <code>.htaccess</code> est la même que celle
+ Les directives placées dans les fichiers <code>.htaccess</code>
+ s'appliquent au répertoire dans lequel vous avez placé le fichier,
+ ainsi qu'à tous ses sous-répertoires.
+ La syntaxe des fichiers <code>.htaccess</code> est la même que celle
des fichiers de configuration principaux. Comme les fichiers
- <code>.htaccess</code> sont lus à chaque requête, les modifications de
- ces fichiers prennent effet immédiatement.</p>
+ <code>.htaccess</code> sont lus à chaque requête, les modifications de
+ ces fichiers prennent effet immédiatement.</p>
- <p>Pour déterminer quelles directives peuvent être placées
+ <p>Pour déterminer quelles directives peuvent être placées
dans les fichiers <code>.htaccess</code>, consultez le
<a href="mod/directive-dict.html#Context">Contexte</a> de la
- directive. L'administrateur du serveur peut contrôler quelles
- directives peuvent être placées dans les fichiers
- <code>.htaccess</code> en définissant la directive
+ directive. L'administrateur du serveur peut contrôler quelles
+ directives peuvent être placées dans les fichiers
+ <code>.htaccess</code> en définissant la directive
<directive module="core">AllowOverride</directive>
dans les fichiers de configuration principaux.</p>
<p>Pour plus d'informations sur les fichiers <code>.htaccess</code>,
- se référer au <a href="howto/htaccess.html">tutoriel .htaccess</a>.</p>
+ se référer au <a href="howto/htaccess.html">tutoriel .htaccess</a>.</p>
</section>
</manualpage>
Modified: httpd/httpd/trunk/docs/manual/misc/security_tips.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/misc/security_tips.xml.fr?rev=1869607&r1=1869606&r2=1869607&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/misc/security_tips.xml.fr [utf-8] (original)
+++ httpd/httpd/trunk/docs/manual/misc/security_tips.xml.fr [utf-8] Sat Nov 9 16:34:55 2019
@@ -1,7 +1,7 @@
-<?xml version="1.0" ?>
+<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1673932 -->
+<!-- English Revision: 1869062 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
@@ -25,122 +25,122 @@
<manualpage metafile="security_tips.xml.meta">
<parentdocument href="./">Documentations diverses</parentdocument>
- <title>Conseils sur la sécurité</title>
+ <title>Conseils sur la sécurité</title>
<summary>
<p>Ce document propose quelques conseils et astuces concernant les
- problèmes de sécurité liés
- à l'installation d'un serveur web. Certaines suggestions seront à caractère
- général, tandis que d'autres seront spécifiques à Apache.</p>
+ problèmes de sécurité liés
+ à l'installation d'un serveur web. Certaines suggestions seront à caractère
+ général, tandis que d'autres seront spécifiques à Apache.</p>
</summary>
- <section id="uptodate"><title>Maintenez votre serveur à jour</title>
+ <section id="uptodate"><title>Maintenez votre serveur à jour</title>
- <p>Le serveur HTTP Apache a une bonne réputation en matière de sécurité
- et possède une communauté de développeurs très sensibilisés aux problèmes
- de sécurité. Mais il est inévitable de trouver certains problèmes
- -- petits ou grands -- une fois le logiciel mis à disposition. C'est pour
- cette raison qu'il est crucial de se tenir informé des mises à jour. Si
+ <p>Le serveur HTTP Apache a une bonne réputation en matière de sécurité
+ et possède une communauté de développeurs très sensibilisés aux problèmes
+ de sécurité. Mais il est inévitable de trouver certains problèmes
+ -- petits ou grands -- une fois le logiciel mis à disposition. C'est pour
+ cette raison qu'il est crucial de se tenir informé des mises à jour. Si
vous avez obtenu votre version du serveur HTTP directement depuis Apache,
- nous vous conseillons grandement de vous abonner à la <a
+ nous vous conseillons grandement de vous abonner à la <a
href="http://httpd.apache.org/lists.html#http-announce">Liste de diffusion
des annonces du serveur HTTP</a> qui vous informera de
- la parution des nouvelles versions et des mises à jour de sécurité. La
+ la parution des nouvelles versions et des mises à jour de sécurité. La
plupart des distributeurs tiers d'Apache fournissent des services
similaires.</p>
- <p>Gardez cependant à l'esprit que lorsqu'un serveur web est compromis, le
- code du serveur HTTP n'est la plupart du temps pas en cause. Les problèmes
- proviennent plutôt de code ajouté, de scripts CGI, ou du système
- d'exploitation sous-jacent. Vous devez donc vous tenir informé des
- problèmes et mises à jour concernant tous les logiciels présents sur
- votre système.</p>
+ <p>Gardez cependant à l'esprit que lorsqu'un serveur web est compromis, le
+ code du serveur HTTP n'est la plupart du temps pas en cause. Les problèmes
+ proviennent plutôt de code ajouté, de scripts CGI, ou du système
+ d'exploitation sous-jacent. Vous devez donc vous tenir informé des
+ problèmes et mises à jour concernant tous les logiciels présents sur
+ votre système.</p>
</section>
<section id="dos">
- <title>Attaques de type "Déni de service"
+ <title>Attaques de type "Déni de service"
(Denial of Service - DoS)</title>
- <p>Tous les services réseau peuvent faire l'objet d'attaques de type
- "Déni de service" qui tentent de les empêcher de répondre aux clients en
- saturant leurs ressources. Il est impossible de se prémunir totalement
+ <p>Tous les services réseau peuvent faire l'objet d'attaques de type
+ "Déni de service" qui tentent de les empêcher de répondre aux clients en
+ saturant leurs ressources. Il est impossible de se prémunir totalement
contre ce type d'attaques, mais vous pouvez accomplir certaines actions
- afin de minimiser les problèmes qu'elles créent.</p>
+ afin de minimiser les problèmes qu'elles créent.</p>
- <p>Souvent, l'outil anti-DoS le plus efficace sera constitué par le
- pare-feu ou certaines configurations du système d'exploitation. Par
- exemple, la plupart des pare-feu peuvent être configurés de façon à
- limiter le nombre de connexions simultanées depuis une adresse IP ou un
- réseau, ce qui permet de prévenir toute une gamme d'attaques simples.
- Bien sûr, ceci n'est d'aucun secours contre les attaques de type
- "Déni de service" distribuées (DDoS).</p>
+ <p>Souvent, l'outil anti-DoS le plus efficace sera constitué par le
+ pare-feu ou certaines configurations du système d'exploitation. Par
+ exemple, la plupart des pare-feu peuvent être configurés de façon à
+ limiter le nombre de connexions simultanées depuis une adresse IP ou un
+ réseau, ce qui permet de prévenir toute une gamme d'attaques simples.
+ Bien sûr, ceci n'est d'aucun secours contre les attaques de type
+ "Déni de service" distribuées (DDoS).</p>
- <p>Certains réglages de la configuration d'Apache peuvent aussi
- minimiser les problèmes :</p>
+ <p>Certains réglages de la configuration d'Apache peuvent aussi
+ minimiser les problèmes :</p>
<ul>
<li>La directive <directive
module="mod_reqtimeout">RequestReadTimeout</directive> permet de
- limiter le temps que met le client pour envoyer sa requête.</li>
+ limiter le temps que met le client pour envoyer sa requête.</li>
<li>La valeur de la directive
- <directive module="core">TimeOut</directive> doit être diminuée sur les
+ <directive module="core">TimeOut</directive> doit être diminuée sur les
sites sujets aux attaques DoS. Une valeur de quelques secondes devrait
convenir. Cependant, comme <directive module="core">TimeOut</directive>
- est actuellement concerné par de nombreuses opérations différentes, lui
- attribuer une valeur trop faible peut provoquer des problèmes avec les
- scripts CGI qui présentent un long temps de réponse.</li>
+ est actuellement concerné par de nombreuses opérations différentes, lui
+ attribuer une valeur trop faible peut provoquer des problèmes avec les
+ scripts CGI qui présentent un long temps de réponse.</li>
<li>La valeur de la directive
- <directive module="core">KeepAliveTimeout</directive> doit aussi être
- diminuée sur les sites sujets aux attaques DoS. Certains sites
- désactivent même complètement le "maintien en vie" (keepalives)
- à l'aide de la directive
- <directive module="core">KeepAlive</directive>, ce qui bien sûr
- présente des inconvénients en matière de performances.</li>
+ <directive module="core">KeepAliveTimeout</directive> doit aussi être
+ diminuée sur les sites sujets aux attaques DoS. Certains sites
+ désactivent même complètement le "maintien en vie" (keepalives)
+ à l'aide de la directive
+ <directive module="core">KeepAlive</directive>, ce qui bien sûr
+ présente des inconvénients en matière de performances.</li>
- <li>Les valeurs des différentes directives fournies par d'autres modules
- et en rapport avec des délais doivent aussi être vérifiées.</li>
+ <li>Les valeurs des différentes directives fournies par d'autres modules
+ et en rapport avec des délais doivent aussi être vérifiées.</li>
<li>Les directives
<directive module="core">LimitRequestBody</directive>,
<directive module="core">LimitRequestFields</directive>,
<directive module="core">LimitRequestFieldSize</directive>,
<directive module="core">LimitRequestLine</directive>, et
- <directive module="core">LimitXMLRequestBody</directive> doivent être
- configurées avec prudence afin de limiter la consommation de ressources
+ <directive module="core">LimitXMLRequestBody</directive> doivent être
+ configurées avec prudence afin de limiter la consommation de ressources
induite par les demandes des clients.
</li>
- <li>Sur les systèmes d'exploitation qui le supportent, assurez-vous que
+ <li>Sur les systèmes d'exploitation qui le supportent, assurez-vous que
la directive <directive module="core">AcceptFilter</directive> est
- activée afin de déléguer une partie du traitement des requêtes au
- système d'exploitation. Elle est activée par défaut dans le démon httpd
- d'Apache, mais peut nécessiter une reconfiguration de votre noyau.</li>
+ activée afin de déléguer une partie du traitement des requêtes au
+ système d'exploitation. Elle est activée par défaut dans le démon httpd
+ d'Apache, mais peut nécessiter une reconfiguration de votre noyau.</li>
<li>Optimisez la directive <directive
- module="mpm_common">MaxRequestWorkers</directive> de façon à définir le nombre
- maximum de connexions simultanées au dessus duquel les ressources
- s'épuisent. Voir aussi la <a
+ module="mpm_common">MaxRequestWorkers</directive> de façon à définir le nombre
+ maximum de connexions simultanées au dessus duquel les ressources
+ s'épuisent. Voir aussi la <a
href="perf-tuning.html">documentation sur l'optimisation des
performances</a>.</li>
- <li>L'utilisation d'un <a href="../mpm.html">module mpm</a> threadé
- vous permet de traiter d'avantage de connexions simultanées, ce qui
+ <li>L'utilisation d'un <a href="../mpm.html">module mpm</a> threadé
+ vous permet de traiter d'avantage de connexions simultanées, ce qui
minimise l'effet des attaques DoS. Dans le futur, le module mpm
<module>event</module> utilisera un traitement asynchrone afin de ne pas
- dédier un thread à chaque connexion. De par la
- nature de la bibliothèque OpenSSL, le module mpm <module>event</module> est actuellement incompatible
+ dédier un thread à chaque connexion. De par la
+ nature de la bibliothèque OpenSSL, le module mpm <module>event</module> est actuellement incompatible
avec le module <module>mod_ssl</module> ainsi que d'autres filtres
- en entrée. Dans ces cas, son comportement se ramène à celui
+ en entrée. Dans ces cas, son comportement se ramène à celui
du module mpm <module>worker</module>.</li>
- <li>Il existe de nombreux modules tiers disponibles à <a
+ <li>Il existe de nombreux modules tiers disponibles à <a
href="http://modules.apache.org/">http://modules.apache.org/</a> qui
peuvent retreindre les comportements de certains clients et ainsi
- minimiser les problèmes de DoS.</li>
+ minimiser les problèmes de DoS.</li>
</ul>
@@ -149,17 +149,17 @@
<section id="serverroot">
- <title>Permissions sur les répertoires de la racine du serveur</title>
+ <title>Permissions sur les répertoires de la racine du serveur</title>
- <p>Typiquement, Apache est démarré par l'utilisateur root, puis il devient
- la propriété de l'utilisateur défini par la directive <directive
- module="mod_unixd">User</directive> afin de répondre aux demandes. Comme
- pour toutes les commandes exécutées par root, vous devez vous assurer
+ <p>Typiquement, Apache est démarré par l'utilisateur root, puis il devient
+ la propriété de l'utilisateur défini par la directive <directive
+ module="mod_unixd">User</directive> afin de répondre aux demandes. Comme
+ pour toutes les commandes exécutées par root, vous devez vous assurer
qu'elle n'est pas modifiable par les utilisateurs autres que root. Les
- fichiers eux-mêmes, mais aussi les répertoires ainsi que leurs parents ne
- doivent être modifiables que par root. Par exemple, si vous avez choisi de
- placer la racine du serveur dans <code>/usr/local/apache</code>, il est conseillé de
- créer le répertoire en tant que root, avec des commandes du style :</p>
+ fichiers eux-mêmes, mais aussi les répertoires ainsi que leurs parents ne
+ doivent être modifiables que par root. Par exemple, si vous avez choisi de
+ placer la racine du serveur dans <code>/usr/local/apache</code>, il est conseillé de
+ créer le répertoire en tant que root, avec des commandes du style :</p>
<example>
mkdir /usr/local/apache <br />
@@ -172,8 +172,8 @@
<p>Nous supposerons que <code>/</code>, <code>/usr</code> et
<code>/usr/local</code> ne sont modifiables que par
- root. Quand vous installez l'exécutable <program>httpd</program>, vous
- devez vous assurer qu'il possède des protections similaires :</p>
+ root. Quand vous installez l'exécutable <program>httpd</program>, vous
+ devez vous assurer qu'il possède des protections similaires :</p>
<example>
cp httpd /usr/local/apache/bin <br />
@@ -182,65 +182,65 @@
chmod 511 /usr/local/apache/bin/httpd
</example>
- <p>Vous pouvez créer un sous-répertoire htdocs modifiable par d'autres
- utilisateurs -- car root ne crée ni exécute aucun fichier dans ce
- sous-répertoire.</p>
+ <p>Vous pouvez créer un sous-répertoire htdocs modifiable par d'autres
+ utilisateurs -- car root ne crée ni exécute aucun fichier dans ce
+ sous-répertoire.</p>
- <p>Si vous permettez à des utilisateurs non root de modifier des fichiers
- que root écrit ou exécute, vous exposez votre système à une compromission
+ <p>Si vous permettez à des utilisateurs non root de modifier des fichiers
+ que root écrit ou exécute, vous exposez votre système à une compromission
de l'utilisateur root. Par exemple, quelqu'un pourrait remplacer le binaire
- <program>httpd</program> de façon à ce que la prochaine fois que vous le
- redémarrerez, il exécutera un code arbitraire. Si le répertoire des
- journaux a les droits en écriture (pour un utilisateur non root), quelqu'un
+ <program>httpd</program> de façon à ce que la prochaine fois que vous le
+ redémarrerez, il exécutera un code arbitraire. Si le répertoire des
+ journaux a les droits en écriture (pour un utilisateur non root), quelqu'un
pourrait remplacer un fichier journal par un lien symbolique vers un autre
- fichier système, et root pourrait alors écraser ce fichier avec des données
- arbitraires. Si les fichiers journaux eux-mêmes ont des droits en
- écriture (pour un utilisateur non root), quelqu'un pourrait
- modifier les journaux eux-mêmes avec des données fausses.</p>
+ fichier système, et root pourrait alors écraser ce fichier avec des données
+ arbitraires. Si les fichiers journaux eux-mêmes ont des droits en
+ écriture (pour un utilisateur non root), quelqu'un pourrait
+ modifier les journaux eux-mêmes avec des données fausses.</p>
</section>
<section id="ssi">
- <title>Inclusions côté serveur</title>
+ <title>Inclusions côté serveur</title>
- <p>Les inclusions côté serveur (Server Side Includes - SSI) exposent
- l'administrateur du serveur à de nombreux risques potentiels en matière de
- sécurité.</p>
+ <p>Les inclusions côté serveur (Server Side Includes - SSI) exposent
+ l'administrateur du serveur à de nombreux risques potentiels en matière de
+ sécurité.</p>
<p>Le premier risque est l'augmentation de la charge du serveur. Tous les
- fichiers où SSI est activé doivent être analysés par Apache, qu'ils
+ fichiers où SSI est activé doivent être analysés par Apache, qu'ils
contiennent des directives SSI ou non. L'augmentation de la charge induite
est minime, mais peut devenir significative dans le contexte d'un
- serveur partagé.</p>
+ serveur partagé.</p>
- <p>Les fichiers SSI présentent les mêmes risques que les scripts CGI en
- général. Les fichiers où SSI est activé peuvent exécuter tout script CGI
- ou autre programme à l'aide de la commande <code>"exec cmd"</code> avec les permissions
- des utilisateur et groupe sous lesquels Apache s'exécute, comme défini
+ <p>Les fichiers SSI présentent les mêmes risques que les scripts CGI en
+ général. Les fichiers où SSI est activé peuvent exécuter tout script CGI
+ ou autre programme à l'aide de la commande <code>"exec cmd"</code> avec les permissions
+ des utilisateur et groupe sous lesquels Apache s'exécute, comme défini
dans <code>httpd.conf</code>.</p>
- <p>Des méthodes existent pour améliorer la sécurité des fichiers SSI, tout
- en tirant parti des bénéfices qu'ils apportent.</p>
+ <p>Des méthodes existent pour améliorer la sécurité des fichiers SSI, tout
+ en tirant parti des bénéfices qu'ils apportent.</p>
<p>Pour limiter les dommages qu'un fichier SSI agressif pourrait causer,
l'administrateur du serveur peut activer<a href="../suexec.html">suexec</a>
- comme décrit dans la section <a href="#cgi">Les CGI en général</a>.</p>
+ comme décrit dans la section <a href="#cgi">Les CGI en général</a>.</p>
- <p>L'activation des SSI pour des fichiers possédant des extensions
+ <p>L'activation des SSI pour des fichiers possédant des extensions
<code>.html</code> ou
- <code>.htm</code> peut s'avérer dangereux. Ceci est particulièrement vrai dans un
- environnement de serveur partagé ou étant le siège d'un traffic élevé. Les
- fichiers où SSI est activé doivent posséder une extension spécifique, telle
+ <code>.htm</code> peut s'avérer dangereux. Ceci est particulièrement vrai dans un
+ environnement de serveur partagé ou étant le siège d'un traffic élevé. Les
+ fichiers où SSI est activé doivent posséder une extension spécifique, telle
que la conventionnelle <code>.shtml</code>. Ceci permet de limiter la charge du serveur
- à un niveau minimum et de simplifier la gestion des risques.</p>
+ à un niveau minimum et de simplifier la gestion des risques.</p>
- <p>Une autre solution consiste à interdire l'exécution de scripts et
- programmes à partir de pages SSI. Pour ce faire, remplacez
+ <p>Une autre solution consiste à interdire l'exécution de scripts et
+ programmes à partir de pages SSI. Pour ce faire, remplacez
<code>Includes</code> par <code>IncludesNOEXEC</code> dans la directive
<directive module="core">Options</directive>. Notez que les utilisateurs
- pourront encore utiliser <code><--#include virtual="..." --></code> pour exécuter
- des scripts CGI si ces scripts sont situés dans des répertoires spécifiés
+ pourront encore utiliser <code><--#include virtual="..." --></code> pour exécuter
+ des scripts CGI si ces scripts sont situés dans des répertoires spécifiés
par une directive
<directive module="mod_alias">ScriptAlias</directive>.</p>
@@ -248,25 +248,25 @@
<section id="cgi">
- <title>Les CGI en général</title>
+ <title>Les CGI en général</title>
- <p>Tout d'abord, vous devez toujours garder à l'esprit que vous devez
- faire confiance aux développeurs de scripts ou programmes CGI ainsi qu'à
- vos compétences pour déceler les trous de sécurité potentiels dans les
- CGI, que ceux-ci soient délibérés ou accidentels. Les scripts CGI peuvent
- essentiellement exécuter des commandes arbitraires sur votre système avec
- les droits de l'utilisateur du serveur web, et peuvent par conséquent être
- extrèmement dangereux s'ils ne sont pas vérifiés avec soin.</p>
-
- <p>Tous les scripts CGI s'exécutent sous le même utilisateur, il peuvent
- donc entrer en conflit (accidentellement ou délibérément) avec d'autres
- scripts. Par exemple, l'utilisateur A hait l'utilisateur B, il écrit donc
- un script qui efface la base de données CGI de l'utilisateur B. Vous pouvez
+ <p>Tout d'abord, vous devez toujours garder à l'esprit que vous devez
+ faire confiance aux développeurs de scripts ou programmes CGI ainsi qu'à
+ vos compétences pour déceler les trous de sécurité potentiels dans les
+ CGI, que ceux-ci soient délibérés ou accidentels. Les scripts CGI peuvent
+ essentiellement exécuter des commandes arbitraires sur votre système avec
+ les droits de l'utilisateur du serveur web, et peuvent par conséquent être
+ extrèmement dangereux s'ils ne sont pas vérifiés avec soin.</p>
+
+ <p>Tous les scripts CGI s'exécutent sous le même utilisateur, il peuvent
+ donc entrer en conflit (accidentellement ou délibérément) avec d'autres
+ scripts. Par exemple, l'utilisateur A hait l'utilisateur B, il écrit donc
+ un script qui efface la base de données CGI de l'utilisateur B. Vous pouvez
utiliser le programme <a href="../suexec.html">suEXEC</a> pour faire en
- sorte que les scripts s'exécutent sous des utilisateurs différents. Ce
+ sorte que les scripts s'exécutent sous des utilisateurs différents. Ce
programme est inclus dans la distribution d'Apache depuis la version 1.2
- et est appelé à partir de certaines portions de code du serveur Apache. Une
- autre méthode plus connue est l'utilisation de
+ et est appelé à partir de certaines portions de code du serveur Apache. Une
+ autre méthode plus connue est l'utilisation de
<a href="http://cgiwrap.sourceforge.net/">CGIWrap</a>.</p>
</section>
@@ -275,17 +275,17 @@
<title>CGI sans alias de script</title>
- <p>Vous ne devez permettre aux utilisateurs d'exécuter des scripts CGI
- depuis n'importe quel répertoire que dans l'éventualité où :</p>
+ <p>Vous ne devez permettre aux utilisateurs d'exécuter des scripts CGI
+ depuis n'importe quel répertoire que dans l'éventualité où :</p>
<ul>
- <li>Vous faites confiance à vos utilisateurs pour ne pas écrire de
- scripts qui vont délibérément ou accidentellement exposer votre
- système à une attaque.</li>
- <li>Vous estimez que le niveau de sécurité dans les autres parties de
- votre site est si faible qu'un trou de sécurité de plus ou de moins
- n'est pas très important.</li>
- <li>Votre système ne comporte aucun utilisateur, et personne ne visite
+ <li>Vous faites confiance à vos utilisateurs pour ne pas écrire de
+ scripts qui vont délibérément ou accidentellement exposer votre
+ système à une attaque.</li>
+ <li>Vous estimez que le niveau de sécurité dans les autres parties de
+ votre site est si faible qu'un trou de sécurité de plus ou de moins
+ n'est pas très important.</li>
+ <li>Votre système ne comporte aucun utilisateur, et personne ne visite
jamais votre site.</li>
</ul>
@@ -295,15 +295,15 @@
<title>CGI avec alias de script</title>
- <p>Le confinement des CGI dans des répertoires spécifiques permet à
- l'administrateur de contrôler ce que l'on met dans ces répertoires. Ceci
- est bien entendu mieux sécurisé que les CGI sans alias de script, mais
- seulement à condition que les utilisateurs avec les droits en écriture sur
- les répertoires soient dignes de confiance, et que l'administrateur ait la
- volonté de tester chaque programme ou script CGI à la recherche d'éventuels
- trous de sécurité.</p>
+ <p>Le confinement des CGI dans des répertoires spécifiques permet à
+ l'administrateur de contrôler ce que l'on met dans ces répertoires. Ceci
+ est bien entendu mieux sécurisé que les CGI sans alias de script, mais
+ seulement à condition que les utilisateurs avec les droits en écriture sur
+ les répertoires soient dignes de confiance, et que l'administrateur ait la
+ volonté de tester chaque programme ou script CGI à la recherche d'éventuels
+ trous de sécurité.</p>
- <p>La plupart des sites choisissent cette approche au détriment des CGI
+ <p>La plupart des sites choisissent cette approche au détriment des CGI
sans alias de script.</p>
</section>
@@ -313,25 +313,25 @@
<title>Autres sources de contenu dynamique</title>
<p>
- Les options de scripting intégrées qui s'exécutent en tant que partie du
- serveur lui-même, comme <code>mod_php</code>, <code>mod_perl</code>,
+ Les options de scripting intégrées qui s'exécutent en tant que partie du
+ serveur lui-même, comme <code>mod_php</code>, <code>mod_perl</code>,
<code>mod_tcl</code>, et <code>mod_python</code>,
- s'exécutent sous le même utilisateur que le serveur (voir la directive
- <directive module="mod_unixd">User</directive>), et par conséquent,
- les scripts que ces moteurs exécutent peuvent accéder aux mêmes ressources
+ s'exécutent sous le même utilisateur que le serveur (voir la directive
+ <directive module="mod_unixd">User</directive>), et par conséquent,
+ les scripts que ces moteurs exécutent peuvent accéder aux mêmes ressources
que le serveur. Certains moteurs de scripting peuvent proposer des
- restrictions, mais pour plus de sûreté, il vaut mieux partir du principe
+ restrictions, mais pour plus de sûreté, il vaut mieux partir du principe
que ce n'est pas le cas.</p>
</section>
<section id="systemsettings">
- <title>Protection de la configuration du système</title>
+ <title>Protection de la configuration du système</title>
- <p>Pour contrôler étroitement votre serveur, vous pouvez interdire
+ <p>Pour contrôler étroitement votre serveur, vous pouvez interdire
l'utilisation des fichiers <code>.htaccess</code> qui permettent de
- passer outre les fonctionnalités de sécurité que vous avez configurées.
+ passer outre les fonctionnalités de sécurité que vous avez configurées.
Voici un moyen pour y parvenir :</p>
<p>Ajoutez dans le fichier de configuration du serveur</p>
@@ -343,32 +343,32 @@
</highlight>
<p>Ceci interdit l'utilisation des fichiers <code>.htaccess</code> dans
- tous les répertoires, sauf ceux pour lesquels c'est explicitement
- autorisé.</p>
+ tous les répertoires, sauf ceux pour lesquels c'est explicitement
+ autorisé.</p>
- <p>Notez que c'est la configuration par défaut depuis Apache 2.3.9.</p>
+ <p>Notez que c'est la configuration par défaut depuis Apache 2.3.9.</p>
</section>
<section id="protectserverfiles">
- <title>Protection par défaut des fichiers du serveur</title>
+ <title>Protection par défaut des fichiers du serveur</title>
- <p>Le concept d'accès par défaut est un aspect d'Apache qui est parfois mal
- compris. C'est à dire que, à moins que vous ne changiez explicitement ce
+ <p>Le concept d'accès par défaut est un aspect d'Apache qui est parfois mal
+ compris. C'est à dire que, à moins que vous ne changiez explicitement ce
comportement, si le serveur trouve son chemin vers un fichier en suivant
- les règles normales de correspondance URL - fichier, il peut le retourner
+ les règles normales de correspondance URL - fichier, il peut le retourner
aux clients.</p>
- <p>Considérons l'exemple suivant :</p>
+ <p>Considérons l'exemple suivant :</p>
<example>
# cd /; ln -s / public_html <br />
- puis accès à <code>http://localhost/~root/</code>
+ puis accès à <code>http://localhost/~root/</code>
</example>
- <p>Ceci permettrait aux clients de parcourir l'ensemble du système de
- fichiers. Pour l'éviter, ajoutez le bloc suivant à la configuration
+ <p>Ceci permettrait aux clients de parcourir l'ensemble du système de
+ fichiers. Pour l'éviter, ajoutez le bloc suivant à la configuration
de votre serveur :</p>
<highlight language="config">
@@ -377,10 +377,10 @@
</Directory>
</highlight>
- <p>ceci va interdire l'accès par défaut à tous les fichiers du système de
+ <p>ceci va interdire l'accès par défaut à tous les fichiers du système de
fichiers. Vous devrez ensuite ajouter les blocs
- <directive module="core">Directory</directive> appropriés correspondant
- aux répertoires auxquels vous voulez autorisez l'accès. Par exemple,</p>
+ <directive module="core">Directory</directive> appropriés correspondant
+ aux répertoires auxquels vous voulez autorisez l'accès. Par exemple,</p>
<highlight language="config">
<Directory "/usr/users/*/public_html">
@@ -391,15 +391,15 @@
</Directory>
</highlight>
- <p>Portez une attention particulière aux interactions entre les directives
+ <p>Portez une attention particulière aux interactions entre les directives
<directive module="core">Location</directive> et
<directive module="core">Directory</directive> ; par exemple, si une
- directive <code><Directory "/"></code> interdit un accès, une
+ directive <code><Directory "/"></code> interdit un accès, une
directive <code><Location "/"></code> pourra passer outre.</p>
- <p>De même, soyez méfiant en jouant avec la directive
- <directive module="mod_userdir">UserDir</directive> ; la positionner à
- <code>"./"</code> aurait le même effet, pour root, que le premier exemple plus haut.
+ <p>De même, soyez méfiant en jouant avec la directive
+ <directive module="mod_userdir">UserDir</directive> ; la positionner à
+ <code>"./"</code> aurait le même effet, pour root, que le premier exemple plus haut.
Nous vous conseillons
fortement d'inclure la ligne suivante dans le fichier de configuration de
votre serveur :</p>
@@ -412,12 +412,12 @@
<title>Surveillez vos journaux</title>
- <p>Pour vous tenir informé de ce qui se passe réellement dans votre
+ <p>Pour vous tenir informé de ce qui se passe réellement dans votre
serveur, vous devez consulter vos
- <a href="../logs.html">fichiers journaux</a>. Même si les fichiers journaux
- ne consignent que des évènements qui se sont déjà produits, ils vous
- informeront sur la nature des attaques qui sont lancées contre le serveur
- et vous permettront de vérifier si le niveau de sécurité nécessaire est
+ <a href="../logs.html">fichiers journaux</a>. Même si les fichiers journaux
+ ne consignent que des évènements qui se sont déjà produits, ils vous
+ informeront sur la nature des attaques qui sont lancées contre le serveur
+ et vous permettront de vérifier si le niveau de sécurité nécessaire est
atteint.</p>
<p>Quelques exemples :</p>
@@ -428,10 +428,10 @@
</example>
<p>Le premier exemple listera les attaques essayant d'exploiter la
- <a href="http://online.securityfocus.com/bid/4876/info/">vulnérabilité
+ <a href="http://online.securityfocus.com/bid/4876/info/">vulnérabilité
d'Apache Tomcat pouvant provoquer la divulgation d'informations par des
- requêtes Source.JSP mal formées</a>, le second donnera la liste des dix
- dernières interdictions client ; par exemple :</p>
+ requêtes Source.JSP mal formées</a>, le second donnera la liste des dix
+ dernières interdictions client ; par exemple :</p>
<example>
[Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied
@@ -439,14 +439,14 @@
</example>
<p>Comme vous le voyez, les fichiers journaux ne consignent que ce qui
- s'est déjà produit ; ainsi, si le client a pu accéder au fichier
+ s'est déjà produit ; ainsi, si le client a pu accéder au fichier
<code>.htpasswd</code>, vous devriez avoir quelque chose du style :</p>
<example>
foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
</example>
- <p>dans votre <a href="../logs.html#accesslog">journal des accès</a> ; ce
+ <p>dans votre <a href="../logs.html#accesslog">journal des accès</a> ; ce
qui signifie que vous avez probablement mis en commentaire ce qui suit dans
le fichier de configuration de votre serveur :</p>
@@ -461,18 +461,18 @@
<title>Fusion des sections de configuration</title>
- <p>La fusion des sections de configuration est complexe et dépend
- souvent des directives utilisées. Vous devez systématiquement tester
- vos modifications pour vérifier la manière dont les directives sont
- fusionnées.</p>
-
- <p>Concernant les modules qui n'implémentent aucune logique de
- fusion, comme <directive>mod_access_compat</directive>, le
- comportement des sections suivantes est tributaire de la présence
- dans ces dernières de directives appartenant à ces modules. La
- configuration est héritée jusqu'à ce qu'une modification soit
- effectuée ; à ce moment, la configuration est <em>remplacée</em> et
- non fusionnée.</p>
+ <p>La fusion des sections de configuration est complexe et dépend
+ souvent des directives utilisées. Vous devez systématiquement tester
+ vos modifications pour vérifier la manière dont les directives sont
+ fusionnées.</p>
+
+ <p>Concernant les modules qui n'implémentent aucune logique de
+ fusion, comme <module>mod_access_compat</module>, le
+ comportement des sections suivantes est tributaire de la présence
+ dans ces dernières de directives appartenant à ces modules. La
+ configuration est héritée jusqu'à ce qu'une modification soit
+ effectuée ; à ce moment, la configuration est <em>remplacée</em> et
+ non fusionnée.</p>
</section>
</manualpage>
Modified: httpd/httpd/trunk/docs/manual/mod/mod_auth_form.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_auth_form.xml.fr?rev=1869607&r1=1869606&r2=1869607&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_auth_form.xml.fr [utf-8] (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_auth_form.xml.fr [utf-8] Sat Nov 9 16:34:55 2019
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1793934 -->
+<!-- English Revision: 1869053 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
@@ -476,7 +476,7 @@ des modules de plus bas niveau</descript
<description>Le nom du champ de formulaire qui contient le nom de
connexion</description>
<syntax>AuthFormUsername <var>nom du champ</var></syntax>
-<default>httpd_username</default>
+<default>AuthFormUsername httpd_username</default>
<contextlist><context>directory</context>
</contextlist>
<override>AuthConfig</override>
@@ -495,7 +495,7 @@ connexion</description>
<description>Le nom du champ de formulaire qui contient le mot de passe
de connexion</description>
<syntax>AuthFormPassword <var>nom du champ</var></syntax>
-<default>httpd_password</default>
+<default>AuthFormPassword httpd_password</default>
<contextlist><context>directory</context>
</contextlist>
<override>AuthConfig</override>
@@ -515,7 +515,7 @@ de connexion</description>
laquelle l'utilisateur sera redirigé en cas de connexion
réussie</description>
<syntax>AuthFormLocation <var>nom du champ</var></syntax>
-<default>httpd_location</default>
+<default>AuthFormLocation httpd_location</default>
<contextlist><context>directory</context>
</contextlist>
<override>AuthConfig</override>
@@ -535,7 +535,7 @@ réussie</description>
<description>Le nom du champ de formulaire contenant la méthode de la
requête à effectuer en cas de connexion réussie</description>
<syntax>AuthFormMethod <var>nom du champ</var></syntax>
-<default>httpd_method</default>
+<default>AuthFormMethod httpd_method</default>
<contextlist><context>directory</context>
</contextlist>
<override>AuthConfig</override>
@@ -563,7 +563,7 @@ requête à effectuer en cas de connexio
corps de la requête à effectuer en cas de connexion
réussie</description>
<syntax>AuthFormMimetype <var>nom du champ</var></syntax>
-<default>httpd_mimetype</default>
+<default>AuthFormMimetype httpd_mimetype</default>
<contextlist><context>directory</context>
</contextlist>
<override>AuthConfig</override>
@@ -590,7 +590,7 @@ réussie</description>
<description>Le nom du champ de formulaire contenant le corps de la
requête à effectuer en cas de connexion réussie</description>
<syntax>AuthFormBody <var>nom du champ</var></syntax>
-<default>httpd_body</default>
+<default>AuthFormBody httpd_body</default>
<contextlist><context>directory</context>
</contextlist>
<override>AuthConfig</override>
@@ -617,7 +617,7 @@ requête à effectuer en cas de connexio
<description>La taille maximale en octets du formulaire dont seront
extraites les informations de connexion</description>
<syntax>AuthFormSize <var>taille</var></syntax>
-<default>8192</default>
+<default>AuthFormSize 8192</default>
<contextlist><context>directory</context>
</contextlist>
<compatibility>Disponible depuis la version 2.3.0 du serveur HTTP Apache</compatibility>
@@ -709,7 +709,7 @@ depuis la version 2.4.4.</compatibility>
<directivesynopsis>
<name>AuthFormFakeBasicAuth</name>
<description>Simule une en-tête d'authentification de base</description>
-<syntax>AuthFormFakeBasicAuth <var>On|Off</var></syntax>
+<syntax>AuthFormFakeBasicAuth On|Off</syntax>
<default>AuthFormFakeBasicAuth Off</default>
<contextlist><context>directory</context>
</contextlist>
@@ -778,7 +778,7 @@ depuis la version 2.4.4.</compatibility>
<name>AuthFormDisableNoStore</name>
<description>Désactive l'en-tête CacheControl no-store sur la page de
connexion</description>
-<syntax>AuthFormDisableNoStore <var>On|Off</var></syntax>
+<syntax>AuthFormDisableNoStore On|Off</syntax>
<default>AuthFormDisableNoStore Off</default>
<contextlist><context>directory</context>
</contextlist>
Modified: httpd/httpd/trunk/docs/manual/mod/mod_md.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_md.xml.fr?rev=1869607&r1=1869606&r2=1869607&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_md.xml.fr [utf-8] (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_md.xml.fr [utf-8] Sat Nov 9 16:34:55 2019
@@ -2,7 +2,7 @@
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
-<!-- English Revision: 1868506 -->
+<!-- English Revision: 1869000 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
@@ -1335,7 +1335,7 @@ MDMessageCmd /etc/apache/md-message
<name>MDStapleOthers</name>
<description>Active l'agrafage pour les certificats non gérés par
mod_md.</description>
- <syntax>MDStaplingOthers on|off</syntax>
+ <syntax>MDStapleOthers on|off</syntax>
<default>on</default>
<contextlist>
<context>server config</context>
Modified: httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml.fr?rev=1869607&r1=1869606&r2=1869607&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml.fr [utf-8] (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_ssl.xml.fr [utf-8] Sat Nov 9 16:34:55 2019
@@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1861442 -->
+<!-- English Revision: 1869606 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
@@ -740,7 +740,7 @@ disponibles</description>
Cette directive permet de définir quelles versions du protocole SSL/TLS
seront acceptées lors de l'initialisation d'une nouvelle connexion.</p>
<p>
-Les <em>protocole</em>s disponibles sont les suivants (sensibles à la
+Les <em>protocoles</em> disponibles sont les suivants (sensibles à la
casse) :</p>
<ul>
<li><code>SSLv3</code>
@@ -775,8 +775,8 @@ casse) :</p>
<li><code>all</code>
<p>
- C'est un raccourci pour ``<code>+SSLv3 +TLSv1</code>'' ou - à partir
- de la version 1.0.1 d'OpenSSL - ``<code>+SSLv3 +TLSv1 +TLSv1.1
+ C'est un raccourci pour ``<code>+SSLv3 +TLSv1</code>'' ou, à partir
+ de la version 1.0.1 d'OpenSSL, ``<code>+SSLv3 +TLSv1 +TLSv1.1
+TLSv1.2</code>'' (sauf si OpenSSL a été compilé avec l'option
``no-ssl3'', auquel cas <code>all</code> n'inclura pas
<code>+SSLv3</code>).</p></li>
@@ -786,6 +786,34 @@ casse) :</p>
SSLProtocol TLSv1
</highlight>
</example>
+<note>
+<title>La directive <directive>SSLProtocol</directive> et les serveurs virtuels
+basés sur le nom</title>
+<p>
+Avant OpenSSL 1.1.1, et même si l'indication du nom de serveur (Server Name
+Indication ou SNI) permettait de déterminer le serveur virtuel cible assez tôt
+au cours de la négociation TLS, il était impossible de changer de version de
+protocole TLS à ce point, si bien que le <directive>SSLProtocol</directive>
+négocié se basait toujours sur celui du <em>serveur virtuel de base</em> (le
+premier serveur virtuel déclaré avec le couple <code>IP:port</code> de la
+connexion).
+</p>
+<p>
+A partir de la version 2.5.1, si le serveur HTTP Apache est compilé avec une
+version 1.1.1. ou supérieure d'OpenSSL, et si le client fournit la SNI dans la
+négociation TLS, le <directive>SSLProtocol</directive> de chaque serveur virtuel
+(basé sur le nom) pourra être pris en compte et le sera.
+</p>
+<p>
+A des fins de compatibilité avec les versions précédentes, si un serveur virtuel
+basé sur le nom n'a aucune directive <directive>SSLProtocol</directive> définie,
+c'est le protocole du serveur virtuel de base qui s'appliquera, <strong>à
+moins</strong> qu'une directive <directive>SSLProtocol</directive> ne soit
+configurée au niveau global, auquel cas c'est le protocole défini par cette
+directive qui s'appliquera (ce dernier cas relève cependant plus d'un
+comportement logique que d'un souci de compatibilité).
+</p>
+</note>
</usage>
</directivesynopsis>