<a href="./ko/env.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
<a href="./tr/env.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<p>Deux types de variables d'environnement affectent le serveur
HTTP Apache.</p>
<p>La spécification sur les CGIs (<a href="https://www.rfc-editor.org/rfc/rfc3875#section-4.1">RFC 3875</a>) 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
<variants>
<variant>en</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
<variant outdated="yes">ja</variant>
<variant outdated="yes">ko</variant>
<variant outdated="yes">tr</variant>
<a href="../es/howto/access.html" hreflang="es" rel="alternate" title="Español"> es </a> |
<a href="../fr/howto/access.html" title="Français"> fr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<p>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'<a href="auth.html">authentification et d'autorisation</a>.</p>
<h2 id="host">Contrôle d'accès en fonction de l'hôte du
client <a title="Lien permanent" href="#host" class="permalink">¶</a></h2>
<p>
- Si vous souhaitez restreindre l'accès à certaines parties de votre
- site web en fonction de l'adresse de l'hôte de vos visiteurs, le
- plus simple pour y parvenir consiste à utiliser le module
+ Si vous souhaitez restreindre l'accès à certaines parties de votre site web
+ en fonction de l'adresse de l'hôte de vos visiteurs, utilisez le module
<code class="module"><a href="../mod/mod_authz_host.html">mod_authz_host</a></code>.
</p>
<p>Les directives Require s'utilisent comme suit :</p>
-
<pre class="prettyprint lang-config">Require host <var>address</var>
+
<div class="example"><pre class="prettyprint lang-config">Require host <var>address</var>
Require ip <var>ip.address</var>
- </pre>
-
+</pre>
+</div>
<p>Dans la première forme, <var>nom-hôte</var> est un nom de domaine
pleinement qualifié (fqdn), ou un nom de domaine partiel ; vous
sous-réseau ou une spécification CIDR de la forme réseau/nnn. Il est
possible de spécifier des adresses IPv4 ou IPv6.</p>
+<div class="example"><h3>Exemples de formats d’adresse IP</h3><pre class="prettyprint lang-config"># Adresse IP complète
+Require ip 10.2.3.4
+# Adresse IP partielle (correspond à tout hôte dans la tranche 172.20.0.0/16)
+Require ip 172.20
+# Paire réseau/masque
+Require ip 192.168.1.0/255.255.255.0
+# Spécification réseau/CIDR
+Require ip 192.168.1.0/24
+# Adresse IPv6
+Require ip 2001:db8::a00:20ff:fea7:ccea
+# Adresse IPv6 avec CIDR
+Require ip 2001:db8:1::/48</pre>
+</div>
+
<p>Voir <a href="../mod/mod_authz_host.html#requiredirectives">la
documentation de mod_authz_host</a> pour d'autres exemples de cette
syntaxe.</p>
<p>Vous pouvez insérer le mot-clé <code>not</code> pour inverser un
- critère particulier. Notez que le mot <code>not</code> réalise la
+ critère particulier. Le mot <code>not</code> réalise la
négation sur la valeur, et ne peut pas être utilisé seul pour autoriser
ou interdire une requête, car <em>non vrai</em> ne
veut pas ici forcément dire <em>faux</em>. Ainsi, pour interdire la
spamer votre forum, vous pouvez ajouter cette ligne pour lui refuser
l'accès :</p>
-
<pre class="prettyprint lang-config"><RequireAll>
- Require all granted
- Require not ip 10.252.46.165
+
<div class="example"><pre class="prettyprint lang-config"><RequireAll>
+Require all granted
+Require not ip 10.252.46.165
</RequireAll></pre>
-
+</div>
<p>Les visiteurs possédant cette adresse (<code>10.252.46.165</code>) ne pourront pas voir le
contenu concerné par cette directive. Si vous voulez interdir
l'accès à une machine en fonction de son nom, vous pouvez ajouter
ceci :</p>
- <pre class="prettyprint lang-config">Require not host <var>host.example.com</var></pre>
-
+<div class="example"><pre class="prettyprint lang-config">Require not host <var>host.example.com</var>
+</pre>
+</div>
<p>Et si vous voulez interdire l'accès à un domaine particulier,
vous pouvez spécifier des adresses IP partielles ou des noms de
domaine, comme ceci :</p>
-
<pre class="prettyprint lang-config">Require not ip 192.168.205
-Require not host phishers.example.com moreidiots.example
+
<div class="example"><pre class="prettyprint lang-config">Require not ip 192.168.205
+Require not host phishers.example.com badguys.example
Require not host gov</pre>
-
+</div>
<p>Les directives <code class="directive"><a href="../mod/mod_authz_core.html#requireall">RequireAll</a></code>, <code class="directive"><a href="../mod/mod_authz_core.html#requireany">RequireAny</a></code>, et <code class="directive"><a href="../mod/mod_authz_core.html#requirenone">RequireNone</a></code> ouvrent le champ à des
critères d'accès plus complexes.</p>
fonction du user-agent (le type de navigateur), vous pouvez
spécifier ceci :</p>
-
<pre class="prettyprint lang-config"><If "%{HTTP_USER_AGENT} == 'BadBot'">
- Require all denied
+
<div class="example"><pre class="prettyprint lang-config"><If "%{HTTP_USER_AGENT} == 'BadBot'">
+Require all denied
</If></pre>
-
+</div>
<p>En utilisant la syntaxe <code>expr</code> de la directive
<code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code>, l'exemple
précédent peut aussi s'écrire :</p>
-
<pre class="prettyprint lang-config">Require expr %{HTTP_USER_AGENT} != 'BadBot'</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">Require expr %{HTTP_USER_AGENT} != 'BadBot'</pre>
+</div>
<div class="note"><h3>Avertissement :</h3>
<p>Contrôler l'accès en fonction de l'en-tête
<p>Par exemple, pour bloquer l'accès à une ressources entre 20h et
7h du matin, vous pouvez utiliser <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> :</p>
-
<pre class="prettyprint lang-config">RewriteEngine On
+
<div class="example"><pre class="prettyprint lang-config">RewriteEngine On
RewriteCond "%{TIME_HOUR}" ">=20" [OR]
RewriteCond "%{TIME_HOUR}" "<07"
RewriteRule "^/fridge" "-" [F]</pre>
-
+</div>
<p>Toute requête arrivant après 20h ou avant 7h du matin provoquera
l'envoi d'une réponse de type 403 Forbidden. Vous pouvez utiliser
<variants>
<variant>en</variant>
<variant outdated="yes">es</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
</variants>
</metafile>
<a href="../ko/howto/auth.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
<a href="../tr/howto/auth.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<p>L'authentification est un processus qui vous permet de vérifier
qu'une personne est bien celle qu'elle prétend être. L'autorisation
d'une directive <code class="directive"><a href="../mod/core.html#allowoverride">AllowOverride</a></code>
du style :</p>
-
<pre class="prettyprint lang-config">AllowOverride AuthConfig</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">AllowOverride AuthConfig</pre>
+</div>
<p>Si vous avez l'intention d'ajouter les directives directement
- dans le fichier de configuration principal, vous devrez bien entendu
+ dans le fichier de configuration principal, vous devrez bien entendu
posséder les droits en écriture sur ce fichier.</p>
<p>Vous devrez aussi connaître un tant soit peu la structure des
fichier <code>httpd.conf</code> à l'intérieur d'une section <Directory
"/usr/local/apache/htdocs/secret"> :</p>
-
<pre class="prettyprint lang-config">AuthType Basic
+
<div class="example"><pre class="prettyprint lang-config">AuthType Basic
AuthName "Restricted Files"
-# (Following line optional)
+# (La ligne suivante est facultative)
AuthBasicProvider file
AuthUserFile "/usr/local/apache/passwd/passwords"
Require user rbowen</pre>
-
+</div>
<p>Examinons ces directives une à une. La directive <code class="directive"><a href="../mod/mod_authn_core.html#authtype">AuthType</a></code> définit la méthode
utilisée pour authentifier l'utilisateur. La méthode la plus
<p>Maintenant, vous devez modifier votre fichier
<code>.htaccess</code> comme suit :</p>
-
<pre class="prettyprint lang-config">AuthType Basic
+
<div class="example"><pre class="prettyprint lang-config">AuthType Basic
AuthName "By Invitation Only"
-# Optional line:
+# Ligne facultative :
AuthBasicProvider file
AuthUserFile "/usr/local/apache/passwd/passwords"
AuthGroupFile "/usr/local/apache/passwd/groups"
Require group GroupName</pre>
-
+</div>
<p>Maintenant, quiconque appartient au groupe
<code>Nom-de-groupe</code>, et possède une entrée dans le fichier
l'accès à plusieurs personnes. Plutôt que de créer un fichier de
groupes, il vous suffit d'ajouter la directive suivante :</p>
-
<pre class="prettyprint lang-config">Require valid-user</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">Require valid-user</pre>
+</div>
<p>Le remplacement de la ligne <code>Require user rbowen</code> par
la ligne <code>Require valid-user</code> autorisera l'accès à
<p>Par exemple, pour sélectionner un fichier dbm à la place d'un
fichier texte :</p>
-
<pre class="prettyprint lang-config"><Directory "/www/docs/private">
- AuthName "Private"
- AuthType Basic
- AuthBasicProvider dbm
- AuthDBMUserFile "/www/passwords/passwd.dbm"
- Require valid-user
+
<div class="example"><pre class="prettyprint lang-config"><Directory "/www/docs/private">
+AuthName "Private"
+AuthType Basic
+AuthBasicProvider dbm
+AuthDBMUserFile "/www/passwords/passwd.dbm"
+Require valid-user
</Directory></pre>
-
+</div>
<p>D'autres options sont disponibles. Consultez la documentation de
<code class="module"><a href="../mod/mod_authn_dbm.html">mod_authn_dbm</a></code> pour plus de détails.</p>
conjointement les fournisseurs d'authentification
file et LDAP :</p>
-
<pre class="prettyprint lang-config"><Directory "/www/docs/private">
- AuthName "Private"
- AuthType Basic
- AuthBasicProvider file ldap
- AuthUserFile "/usr/local/apache/passwd/passwords"
- AuthLDAPURL ldap://ldaphost/o=yourorg
- Require valid-user
+
<div class="example"><pre class="prettyprint lang-config"><Directory "/www/docs/private">
+AuthName "Private"
+AuthType Basic
+AuthBasicProvider file ldap
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthLDAPURL ldap://ldaphost/o=yourorg
+Require valid-user
</Directory></pre>
-
+</div>
<p>Dans cet exemple, le fournisseur file va tenter d'authentifier
l'utilisateur en premier. S'il n'y parvient pas, le fournisseur LDAP
autorisation à base de fichier de groupes et une autorisation à base
de groupes LDAP.</p>
-
<pre class="prettyprint lang-config"><Directory "/www/docs/private">
- AuthName "Private"
- AuthType Basic
- AuthBasicProvider file
- AuthUserFile "/usr/local/apache/passwd/passwords"
- AuthLDAPURL ldap://ldaphost/o=yourorg
- AuthGroupFile "/usr/local/apache/passwd/groups"
- Require group GroupName
- Require ldap-group cn=mygroup,o=yourorg
+
<div class="example"><pre class="prettyprint lang-config"><Directory "/www/docs/private">
+AuthName "Private"
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthLDAPURL ldap://ldaphost/o=yourorg
+AuthGroupFile "/usr/local/apache/passwd/groups"
+Require group GroupName
+Require ldap-group cn=mygroup,o=yourorg
</Directory></pre>
-
+</div>
<p>Pour un scénario d'autorisation un peu plus avancé, des
directives de conteneur d'autorisation comme <code class="directive"><a href="../mod/mod_authz_core.html#requireall"><RequireAll></a></code> et
<h3 id="reqaccessctrl">Utilisation de fournisseurs
d'autorisation pour le contrôle d'accès</h3>
- <p>La vérification du nom d'utilisateur et du mot de passe ne
- constituent qu'un aspect des méthodes d'authentification.
- Souvent, le contrôle d'accès à certaines personnes n'est pas
- basé sur leur identité ; il peut dépendre, par exemple de leur
- provenance.</p>
-
- <p>Les fournisseurs d'autorisation <code>all</code>,
- <code>env</code>, <code>host</code> et <code>ip</code> vous
- permettent d'accorder ou refuser l'accès en
- fonction de critères tels que le nom d'hôte ou l'adresse
- IP de la machine qui effectue la requête.</p>
-
- <p>L'utilisation de ces fournisseurs est spécifiée à l'aide de
- la directive <code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code>. Cette directive
- permet d'enregistrer quels fournisseurs d'autorisation
- seront appelés dans le processus d'autorisation au cours du
- traitement de la requête. Par exemple :</p>
-
- <pre class="prettyprint lang-config">Require ip <var>address</var></pre>
-
-
- <p>où <var>adresse</var> est une adresse IP (ou une adresse IP
- partielle) ou :</p>
-
- <pre class="prettyprint lang-config">Require host <var>domain_name</var></pre>
-
-
- <p>où <var>nom_domaine</var> est un nom de domaine entièrement
- qualifé (ou un nom de domaine partiel) ; vous pouvez indiquer
- plusieurs adresses ou noms de domaines, si vous le désirez.</p>
-
- <p>Par exemple, si vous voulez rejeter les spams dont une
- machine vous inonde, vous pouvez utiliser ceci :</p>
-
- <pre class="prettyprint lang-config"><RequireAll>
- Require all granted
- Require not ip 10.252.46.165
-</RequireAll></pre>
-
-
- <p>Ainsi, les visiteurs en provenance de cette adresse ne
- pourront pas voir le contenu concerné par cette directive. Si,
- par contre, vous connaissez le nom de la machine, vous pouvez
- utiliser ceci :</p>
-
- <pre class="prettyprint lang-config"><RequireAll>
- Require all granted
- Require not host host.example.com
-</RequireAll></pre>
-
-
- <p>Et si vous voulez interdire l'accès à toutes les machines
- d'un domaine, vous pouvez spécifier une partie seulement de
- l'adresse ou du nom de domaine :</p>
-
- <pre class="prettyprint lang-config"><RequireAll>
- Require all granted
- Require not ip 192.168.205
- Require not host phishers.example.com moreidiots.example
- Require not host ke
-</RequireAll></pre>
-
-
- <p>L'utilisation de la directive <code class="directive"><a href="../mod/mod_authz_core.html#requireall"><RequireAll></a></code>
- avec de multiples directives <code class="directive"><a href="../mod/mod_authz_core.html#require"><Require></a></code>, toutes avec la négation
- <code>not</code>, n'accordera l'accès que si toutes les
- conditions négatives sont vérifiées. En d'autres termes, l'accès
- sera refusé si au moins une des conditions négatives n'est pas
- vérifiée.</p>
+ <p>La vérification du nom d'utilisateur et du mot de passe ne
+ constituent qu'un aspect des méthodes d'authentification. Vous pouvez
+ aussi autoriser ou interdire l’accès en fonction d’autres critères tels
+ que l’adresse IP du client ou le nom d’hôte en utilisant les
+ fournisseurs d’autorisation <code>all</code>, <code>env</code>,
+ <code>host</code> et <code>ip</code> avec la directive <code class="directive"><a href="../mod/mod_authz_core.html#require">Require</a></code>.</p>
+
+ <p>Pour des détails complets et des exemples, voir le tutoriel <a href="access.html">Access Control</a>.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="socache">Mise en cache de l'authentification <a title="Lien permanent" href="#socache" class="permalink">¶</a></h2>
- <p>Dans certains cas, l'authentification constitue une charge
- inacceptable pour un fournisseur d'authentification ou votre réseau.
- Ceci est susceptible d'affecter les utilisateurs du module
- <code class="module"><a href="../mod/mod_authn_dbd.html">mod_authn_dbd</a></code> (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,
- <code class="module"><a href="../mod/mod_authn_socache.html">mod_authn_socache</a></code>, qui permet de mettre en cache
- les données d'authentification, et ainsi réduire la charge du/des
- fournisseurs(s) originels.</p>
- <p>Cette mise en cache apportera un gain en performance substantiel
- à certains utilisateurs.</p>
+ <p>Dans certains cas, l'authentification constitue une charge inacceptable
+ pour un fournisseur d'authentification ou votre réseau. Ceci est
+ susceptible d'affecter les utilisateurs du module
+ <code class="module"><a href="../mod/mod_authn_dbd.html">mod_authn_dbd</a></code> (ou les fournisseurs tiers/personnalisés). Le
+ module <code class="module"><a href="../mod/mod_authn_socache.html">mod_authn_socache</a></code> met en cache les données
+ d'authentification, et réduit ainsi la charge du/des fournisseurs(s)
+ originels.</p> <p>Cette mise en cache apportera un gain en performance
+ substantiel à certains utilisateurs.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="moreinformation">Pour aller plus loin . . . <a title="Lien permanent" href="#moreinformation" class="permalink">¶</a></h2>
<variants>
<variant>en</variant>
<variant outdated="yes">es</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
<variant outdated="yes">ja</variant>
<variant outdated="yes">ko</variant>
<variant outdated="yes">tr</variant>
<a href="../ko/howto/htaccess.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
<a href="../pt-br/howto/htaccess.html" hreflang="pt-br" rel="alternate" title="Português (Brasil)"> pt-br </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<p>Les fichiers <code>.htaccess</code> fournissent une méthode pour
modifier la configuration du serveur au niveau de chaque répertoire, sans
<code>.config</code>, vous pouvez mettre ceci dans le fichier de
configuration de votre serveur :</p>
-
<pre class="prettyprint lang-config">AccessFileName ".config"</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">AccessFileName ".config"</pre>
+</div>
</div>
<p>Les directives dans les fichiers <code>.htaccess</code> utilisent la même
directive est permise dans un fichier <code>.htaccess</code>,
la documentation de cette directive contiendra une section Override,
spécifiant quelle valeur doit prendre la directive <code class="directive"><a href="../mod/core.html#allowoverride">AllowOverride</a></code> pour que cette directive
- soit traitée.</p>
+ soit autorisée.</p>
<div class="note">La valeur par défaut de la directive <code class="directive"><a href="../mod/core.html#allowoverride">AllowOverride</a></code> est <code>None</code>. Cela signifie
que les fichiers <code>.htaccess</code> seront complètement ignorés, à moins
<code>.htaccess</code> est chargé en mémoire chaque fois qu'un
document fait l'objet d'une requête.</p>
- <p>Notez aussi que httpd doit rechercher les fichiers
- <code>.htaccess</code> dans tous les répertoires de niveau
- supérieur, afin de rassembler toutes les directives qui s'appliquent
- au répertoire courant (Voir la section <a href="#how">comment sont
- appliquées les directives</a>). Ainsi, si un fichier fait l'objet
- d'une requête à partir d'un répertoire
- <code>/www/htdocs/exemple</code>, httpd doit rechercher les
- fichiers suivants :</p>
+ <p>En outre, httpd doit rechercher des fichiers <code>.htaccess</code> dans
+ tous les répertoires de niveau supérieur pour rassembler la totalité des
+ directives applicables (Voir la section <a href="#how">comment sont
+ appliquées les directives</a>). Ainsi, si un fichier fait l'objet d'une
+ requête à partir d'un répertoire <code>/www/htdocs/exemple</code>, httpd
+ doit rechercher les fichiers suivants :</p>
-
<pre class="prettyprint lang-config">/.htaccess
+
<div class="example"><pre class="prettyprint lang-config">/.htaccess
/www/.htaccess
/www/htdocs/.htaccess
/www/htdocs/example/.htaccess</pre>
-
+</div>
<p>En conséquence, chaque accès à un fichier de ce répertoire
nécessite 4 accès au système de fichiers supplémentaires pour
rechercher des fichiers <code>.htaccess</code>, même si
- aucun de ces fichiers n'est présent. Notez que cet exemple ne peut
+ aucun de ces fichiers n'est présent. Cet exemple ne peut
se produire que si les fichiers <code>.htaccess</code> ont été
autorisés pour le répertoire <code>/</code>, ce qui est rarement le
cas.</p>
utilisateurs de modifier la configuration du serveur, il peut en
résulter des conséquences sur lesquelles vous n'aurez aucun
contrôle. Réfléchissez bien avant de donner ce privilège à vos
- utilisateurs. Notez aussi que ne pas donner aux utilisateurs les
+ utilisateurs. Ne pas donner aux utilisateurs les
privilèges dont ils ont besoin va entraîner une augmentation des
demandes de support technique. Assurez-vous d'avoir informé
clairement vos utilisateurs du niveau de privilèges que vous leur
nommer individuellement les directives autorisées, vous permettant ainsi un
contrôle plus fin que dans le cas de la directive <code class="directive"><a href="../mod/core.html#allowoverride">AllowOverride</a></code> seule :</p>
-
<pre class="prettyprint lang-config"># N’autoriser que des directives spécifiques, pas des catégories entières de
+
<div class="example"><pre class="prettyprint lang-config"># N’autoriser que des directives spécifiques, pas des catégories entières de
# directives
AllowOverride None
AllowOverrideList Redirect RedirectMatch RewriteEngine RewriteRule RewriteCond</pre>
-
+</div>
<p>Avec cette configuration, toute directive non explicitement spécifiée
causera une erreur du serveur si elle est rencontrée dans un fichier
<code>.htaccess</code>. C’est un bon compromis entre possibilité et
impossibilité totales d’outrepasser la configuration globale.</p>
- <p>Notez que mettre un fichier <code>.htaccess</code> contenant une
- directive dans un répertoire <code>/www/htdocs/exemple</code>
- revient exactement au même que mettre la même directive dans une
- section Directory <code><Directory "/www/htdocs/exemple"></code>
- du fichier de configuration de votre serveur principal :</p>
+ <p>Placer une directive dans un fichier <code>.htaccess</code> dans un
+ répertoire <code>/www/htdocs/example</code> équivaut exactement à placer
+ cette même directive dans une section <code><Directory
+ "/www/htdocs/example"></code> de la configuration globale de votre
+ serveur :</p>
- <p>Fichier <code>.htaccess</code> dans
- <code>/www/htdocs/exemple</code> :</p>
+ <p>Fichier <code>.htaccess</code> dans <code>/www/htdocs/example</code>
+ :</p>
<div class="example"><h3>Contenu du fichier .htaccess dans
- <code>/www/htdocs/ex
emple</code></h3><pre class="prettyprint lang-config">AddType text/example ".exm"</pre>
-</div>
+ <code>/www/htdocs/ex
ample</code></h3><div class="example"><pre class="prettyprint lang-config">AddType text/example ".exm"</pre>
+</div></div>
<div class="example"><h3>Section de votre fichier
- <code>httpd.conf</code></h3><pre class="prettyprint lang-config"><Directory "/www/htdocs/example">
- AddType text/example ".exm"
+ <code>httpd.conf</code></h3><div class="example"><pre class="prettyprint lang-config"><Directory "/www/htdocs/example">
+AddType text/example ".exm"
</Directory></pre>
-</div>
+</div></div>
<p>L'utilisation des fichiers <code>.htaccess</code> peut être
entièrement désactivée en définissant la directive <code class="directive"><a href="../mod/core.html#allowoverride">AllowOverride</a></code> à <code>none</code> :</p>
-
<pre class="prettyprint lang-config">AllowOverride None</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">AllowOverride None</pre>
+</div>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="how">Comment sont appliquées les directives ? <a title="Lien permanent" href="#how" class="permalink">¶</a></h2>
<p>Les directives de configuration situées dans un fichier
<code>.htaccess</code> s'appliquent au répertoire dans lequel ce
fichier <code>.htaccess</code> se trouve, ainsi qu'à tous ses
- sous-répertoires. Cependant, il est important de garder à l'esprit
+ sous-répertoires. Cependant, souvenez-vous
qu'il peut y avoir des fichiers <code>.htaccess</code> dans les
répertoires de niveau supérieur. Les directives sont appliquées
selon l'ordre dans lequel elles sont rencontrées. Ainsi, les
<p>Dans le répertoire <code>/www/htdocs/exemple1</code> se trouve un
fichier <code>.htaccess</code> contenant ce qui suit :</p>
-
<pre class="prettyprint lang-config">Options +ExecCGI</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">Options +ExecCGI</pre>
+</div>
- <p>Note : "<code>AllowOverride Options</code>" doit être présent
+ <div class="note">"<code>AllowOverride Options</code>" doit être présent
pour permettre l'utilisation de la directive "<code class="directive"><a href="../mod/core.html#options">Options</a></code>" dans les fichiers
- <code>.htaccess</code>.</p>
+ <code>.htaccess</code>.</div>
<p>Dans le répertoire <code>/www/htdocs/exemple1/exemple2</code> se
trouve un fichier <code>.htaccess</code> contenant ce qui suit
:</p>
-
<pre class="prettyprint lang-config">Options Includes</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">Options Includes</pre>
+</div>
<p>Ainsi, à cause de ce second fichier <code>.htaccess</code> du
répertoire <code>/www/htdocs/exemple1/exemple2</code>, l'exécution
définition de toute autre option dans les fichiers
<code>.htaccess</code>, vous pouvez utiliser :</p>
-
<pre class="prettyprint lang-config"><Directory "/www/htdocs">
- AllowOverride All
+
<div class="example"><pre class="prettyprint lang-config"><Directory "/www/htdocs">
+AllowOverride All
</Directory>
<Location "/">
- Options +IncludesNoExec -ExecCGI
+Options +IncludesNoExec -ExecCGI
</Location></pre>
-
+</div>
<div class="note">Dans cet exemple, on considère que le chemin défini par la
directive <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code> est
<p>Contenu du fichier <code>.htaccess</code> :</p>
-
<pre class="prettyprint lang-config">AuthType Basic
+
<div class="example"><pre class="prettyprint lang-config">AuthType Basic
AuthName "Password Required"
AuthUserFile "/www/passwords/password.file"
AuthGroupFile "/www/passwords/group.file"
Require group admins</pre>
+</div>
-
- <p>Notez que <code>AllowOverride AuthConfig</code> doit être présent
- pour que ces directives produisent leur effet.</p>
+ <div class="note"><code>AllowOverride AuthConfig</code> doit être présent
+ pour que ces directives produisent leur effet.</div>
<p>Vous pouvez vous référer au <a href="auth.html">tutoriel sur
l'authentification</a> pour une description plus détaillée de
on utilise les directives de configuration suivantes, placées dans un
fichier <code>.htaccess</code> enregistré dans le répertoire considéré :</p>
-
<pre class="prettyprint lang-config">Options +Includes
+
<div class="example"><pre class="prettyprint lang-config">Options +Includes
AddType text/html "shtml"
AddHandler server-parsed shtml</pre>
+</div>
-
- <p>Notez que <code>AllowOverride Options</code> et <code>AllowOverride
+ <div class="note"><code>AllowOverride Options</code> et <code>AllowOverride
FileInfo</code> doivent être tous les deux présents pour que ces
- directives puissent produire leur effet.</p>
+ directives puissent produire leur effet.</div>
<p>Vous pouvez vous référer au <a href="ssi.html">tutoriel SSI</a>
pour une description plus détaillée des SSI.</p>
sont relatives au répertoire courant, et non à l'URI original. Considérez
les exemples suivants :</p>
-<pre class="prettyprint lang-config"># Dans httpd.conf
+<div class="example"><pre class="prettyprint lang-config"># Dans httpd.conf
RewriteRule "^/images/(.+)\.jpg" "/images/$1.png"
# Dans un fichier .htaccess situé dans le répertoire racine de vos
# Dans un fichier .htaccess situé dans le répertoire images/
RewriteRule "^(.+)\.jpg" "$1.png"</pre>
-
+</div>
<p>On voit que si le fichier <code>.htaccess</code> se situe à la racine
de vos documents, le slash de tête est supprimé de la valeur de
remplacement. Il doit donc en être de même dans votre expression
rationnelle.</p>
-<p>Notez aussi que dans un contexte <code>.htaccess</code>, les expressions
+<p>Dans un contexte <code>.htaccess</code>, les expressions
rationnelles sont recompilées à chaque requête, alors que dans un contexte de
configuration principale, elle ne sont compilées qu’une seule fois et mises en
cache.</p>
l’exécution de programmes CGI dans un répertoire particulier. Pour y
parvenir, vous pouvez utiliser la configuration suivante :</p>
-
<pre class="prettyprint lang-config">Options +ExecCGI
+
<div class="example"><pre class="prettyprint lang-config">Options +ExecCGI
AddHandler cgi-script "cgi" "py"</pre>
-
+</div>
<p>Alternativement, si vous souhaitez que tous les fichiers d'un
répertoire donné soient considérés comme des programmes CGI, vous
pouvez utiliser la configuration suivante :</p>
-
<pre class="prettyprint lang-config">Options +ExecCGI
+
<div class="example"><pre class="prettyprint lang-config">Options +ExecCGI
SetHandler cgi-script</pre>
+</div>
-
- <p>Notez que <code>AllowOverride Options</code> et <code>AllowOverride
+ <div class="note"><code>AllowOverride Options</code> et <code>AllowOverride
FileInfo</code> doivent être tous les deux présents pour que ces
- directives puissent produire leur effet.</p>
+ directives puissent produire leur effet.</div>
<p>Vous pouvez vous référer au <a href="cgi.html">tutoriel CGI</a>
pour une description plus détaillée de la configuration et de la
dénué de sens dans votre ficher <code>.htaccess</code> et de recharger la
page :</p>
-
<pre class="prettyprint lang-config">TestMe</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">TestMe</pre>
+</div>
<p>Si aucune erreur (HTTP 500) n'est générée par le
serveur, il est pratiquement certain qu'une directive
utilisée dans votre fichier <code>.htaccess</code> n'est pas
permise.</p>
- <pre class="prettyprint lang-config">[Tue May 06 09:12:31.528374 2025] [core:alert] [pid 12345] [client 192.168.1.50:54321] /var/www/html/.htaccess: DirectoryIndex not allowed here</pre>
-
+<div class="example"><pre class="prettyprint lang-config">[Thu Jun 18 09:12:31.528374 2026] [core:alert] [pid 12345] [client 192.168.1.50:54321] /var/www/html/.htaccess: DirectoryIndex not allowed here</pre>
+</div>
<p>Cela signifie soit que vous utilisez une directive qui n'est
jamais permise dans les fichiers <code>.htaccess</code>, soit
- que vous n'avez tout simplement pas défini la directive
+ que vous n'avez pas défini la directive
<code class="directive"><a href="../mod/core.html#allowoverride">AllowOverride</a></code> à un niveau
suffisant pour la directive que vous utilisez. Consultez la
documentation de cette directive pour déterminer quel cas
<p>Le journal des erreurs peut aussi vous signaler une erreur de
syntaxe dans l'usage de la directive elle-même.</p>
- <pre class="prettyprint lang-config">[Tue May 06 09:14:02.946218 2025] [core:alert] [pid 12345] [client 192.168.1.50:54321] /var/www/html/.htaccess: RewriteCond: bad flag delimiters</pre>
-
+<div class="example"><pre class="prettyprint lang-config">[Thu Jun 18 09:14:02.946218 2026] [core:alert] [pid 12345] [client 192.168.1.50:54321] /var/www/html/.htaccess: RewriteCond: bad flag delimiters</pre>
+</div>
<p>Dans ce cas, le message d'erreur sera spécifique à l'erreur
de syntaxe que vous avez commise.</p>
<variants>
<variant>en</variant>
<variant outdated="yes">es</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
<variant outdated="yes">ja</variant>
<variant outdated="yes">ko</variant>
<variant outdated="yes">pt-br</variant>
<a href="../es/howto/http2.html" hreflang="es" rel="alternate" title="Español"> es </a> |
<a href="../fr/howto/http2.html" title="Français"> fr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<p>Ce document est le guide de l'utilisateur de l'implémentation de HTTP/2
dans Apache httpd. Cette fonctionnalité en est au stade
<li><img alt="" src="../images/down.gif"> <a href="#clients">Clients</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#tools">Outils efficaces pour déboguer HTTP/2</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#push">Push serveur</a></li>
-<li><img alt="" src="../images/down.gif"> <a href="#earlyhints">Suggestions précoces</a></li>
+<li><img alt="" src="../images/down.gif"> <a href="#earlyhints">EarlyHints</a></li>
</ul><h3>Voir aussi</h3><ul class="seealso"><li><code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code></li></ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
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.</p>
- <p>Beaucoup a déjà été écrit à propos de HTTP/2 et de son fonctionnement. La
- documentation la plus officielle est bien entendu sa <a href="https://www.rfc-editor.org/rfc/rfc7540">RFC 7540</a> (ou cette version au format plus
- lisible : YMMV (<a href="https://www.rfc-editor.org/rfc/rfc7540">RFC 7540</a>). Vous trouverez ici une description des rouages de HTTP/2 dans
- leurs moindres détails.</p>
- <p>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 <em>ce
- que</em> ce mécanisme est censé faire, et seulement ensuite de lire sa RFC
- pour comprendre <em>comment</em> il fonctionne. <a href="https://daniel.haxx.se/http2/">http2 explained</a> de Daniel Stenberg
- (l'auteur de <a href="https://curl.haxx.se">curl</a>)
- 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 !</p>
- <p>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 :</p>
+ HTTP/1, vous connaissez déjà 95% deHTTP/2.</p>
+
+ <p>Le protocole est définii dans la <a href="https://www.rfc-editor.org/rfc/rfc9113">RFC 9113</a> (qui rend obsolète la
+ <a href="https://www.rfc-editor.org/rfc/rfc7540">RFC 7540</a> originale). Pour une approche plus abordable, voir le
+ document <a href="https://daniel.haxx.se/http2/">http2 explained</a> par Daniel
+ Stenberg, l’auteur de <a href="https://curl.haxx.se">curl</a>. Il couvre les
+ but et conception de HTTP/2 sans nécessiter d’analyse de la notation RFC
+ préalable.</p>
+
+ <p>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 :</p>
+
<ul>
- <li>A la différence de HTTP/1 qui est en texte pur, HTTP/2 est un
- <strong>protocole binaire</strong>, 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 <a href="https://http2.github.io/faq/#why-is-http2-binary">FAQ
- officielle</a> pour plus de détails.</li>
+ <li>À l’opposé de HTTP 1.1 qui est un protocole en texte pur, HTTP/2 est
+ un <strong>protocol binaire</strong>. 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 <a href="https://http2.github.io/faq/#why-is-http2-binary">question</a> de
+ la FAQ officielle.</li>
<li><strong>h2</strong> correspond à HTTP/2 sur TLS (négociation de
protocole via ALPN).</li>
- <li><strong>h2c</strong> correspond à HTTP/2 sur TCP.</li>
- <li>Une <strong>frame</strong> 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 (<a href="https://www.rfc-editor.org/rfc/rfc7540">RFC 7540</a>).</li> <li>Un
- <strong>stream</strong> 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
- (<a href="https://www.rfc-editor.org/rfc/rfc7540">RFC 7540</a>).</li>
- <li>HTTP/2 peut gérer <strong>plusieurs streams</strong> 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)</li>
+ <li><strong>h2c</strong> 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.</li>
+ <li>Une <strong>trame</strong> (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 <a href="https://www.rfc-editor.org/rfc/rfc9113">RFC 9113</a>.</li>
+ <li>Un <strong>flux</strong> (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 <a href="https://www.rfc-editor.org/rfc/rfc9113">RFC 9113</a>.</li>
+ <li>HTTP/2 peut gérer <strong>plusieurs flux</strong> 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).</li>
+
</ul>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<p>Le protocole HTTP/2 est implémenté dans Apache httpd via un module
propre, pertinemment nommé <code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code>. 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 '<code>h2c</code>', et la variante sécurisée
'<code>h2</code>'. <code>h2c</code> peut être en mode <em>direct</em> ou
<code>Upgrade:</code> via une requête initiale en HTTP/1.</p>
- <p><a href="#push">Server Push</a> 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.</p>
+ <p><a href="#push">Server Push</a> était une nouvelle fonctionnalité offerte
+ aux développeurs web par HTTP/2, mais elle est maintenant obsolète. Voir la
+ section <a href="#earlyhints">EarlyHints</a> pour l’alternative
+ recommandée.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="building">Compilation de httpd avec le support de HTTP/2 <a title="Lien permanent" href="#building" class="permalink">¶</a></h2>
<p>Maintenant que vous disposez d'un binaire <code>httpd</code> compilé avec le
module <code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code>, 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 :</p>
-
<pre class="prettyprint lang-config">LoadModule http2_module modules/mod_http2.so</pre>
-
+ module de httpd, vous devez le charger :</p>
+
<div class="example"><pre class="prettyprint lang-config">LoadModule http2_module modules/mod_http2.so</pre>
+</div>
<p>La seconde directive que vous devez ajouter à votre fichier de
configuration est</p>
-
<pre class="prettyprint lang-config">Protocols h2 http/1.1</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">Protocols h2 http/1.1</pre>
+</div>
<p>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 :</p>
-
<pre class="prettyprint lang-config">Protocols h2 h2c http/1.1</pre>
-
- <p>Selon l'endroit où vous placez cette directive, elle affectera l'ensemble
- de votre serveur, ou seulement un ou plusieurs serveurs virtuels. Vous
+
<div class="example"><pre class="prettyprint lang-config">Protocols h2 h2c http/1.1</pre>
+</div>
+ <p>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 :</p>
-
<pre class="prettyprint lang-config">Protocols http/1.1
+
<div class="example"><pre class="prettyprint lang-config">Protocols http/1.1
<VirtualHost ...>
- ServerName test.example.org
- Protocols h2 http/1.1
+ServerName test.example.org
+Protocols h2 http/1.1
</VirtualHost></pre>
+</div>
-
- <p>Seules les connexions en HTTP/1 seront alors permises, sauf pour le serveur
- virtuel <code>test.example.org</code> qui acceptera aussi les connexions SSL
- en HTTP/2.</p>
+ <p>Seules les connexions en HTTP/1 seront alors permises, sauf pour les
+ connexions SSL vers <code>test.example.org</code> qui propose aussi HTTP/2.</p>
<div class="note"><h3>Utilisez une chaîne d'algorithmes de chiffrement forte</h3>
<p>La directive <code class="directive"><a href="../mod/mod_ssl.html#sslciphersuite">SSLCipherSuite</a></code> doit
être définie avec une chaîne d'algorithmes de chiffrement TLS forte. Même si
<p>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</p>
-
<pre class="prettyprint lang-config">Protocols http/1.1 h2</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">Protocols http/1.1 h2</pre>
+</div>
<p>le protocole préféré sera HTTP/1 et il sera toujours sélectionné sauf si
un client ne supporte <em>que</em> h2. Comme nous souhaitons communiquer en
HTTP/2 avec les clients qui le supportent, la meilleure définition de la
directive est</p>
-
<pre class="prettyprint lang-config">Protocols h2 h2c http/1.1</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">Protocols h2 h2c http/1.1</pre>
+</div>
<p>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 :</p>
- <pre class="prettyprint lang-config">ProtocolsHonorOrder Off</pre>
+<div class="example"><pre class="prettyprint lang-config">ProtocolsHonorOrder Off</pre>
+</div>
<p>Avec cette directive, l'ordre des protocoles que <em>vous</em> avez
défini devient caduque et seul l'ordre défini par le client sera pris en
<div class="section">
<h2 id="clients">Clients <a title="Lien permanent" href="#clients" class="permalink">¶</a></h2>
- <p>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 <a href="http://caniuse.com/#search=http2">source</a>).</p>
+ <p>Tous les navigateurs modernes prennent en charge HTTP/2 sur
+ des connexions TLS (<a href="https://caniuse.com/http2">source</a>). La
+ prise en charge est devenue universelle sur les navigateurs principaux à peu
+ près en 2015.</p>
<p>D'autres clients et serveurs sont listés dans le <a href="https://github.com/http2/http2-spec/wiki/Implementations">wiki des
implémentations</a> ; entre autres des implémentations pour c, c++, common
lisp, dart, erlang, haskell, java, nodejs, php, python, perl, ruby, rust,
<p>Le premier d'entre eux est bien entendu <a href="https://curl.haxx.se">curl</a>. Assurez-vous au préalable que votre
version supporte HTTP/2 en vérifiant ses <code>Fonctionnalités</code> :</p>
- <pre class="prettyprint lang-config"> $ 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 <strong>HTTP2</strong>
- </pre>
-
- <div class="note"><h3>homebrew sous Mac OS :</h3>
- brew install curl --with-openssl --with-nghttp2
+<div class="example"><pre class="prettyprint lang-sh">$ 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 <strong>HTTP2</strong>
+</pre>
+</div>
+ <div class="note"><h3>Notes à propos de macOS Homebrew</h3>
+ <p><code>curl</code> de Homebrew inclut par défaut la prise en charge de
+ HTTP/2. Installez le avec la commande <code>brew install curl</code> et
+ suivez les instructions affichées pour le mettre en tête du PATH de votre
+ système.</p>
</div>
<p>Pour une inspection en profondeur : <a href="https://wiki.wireshark.org/HTTP2">wireshark</a>.</p>
<p>Le paquet <a href="https://nghttp2.org">nghttp2</a> inclut aussi des
</ul>
<p>Chrome fournit des journaux détaillés des connexions HTTP/2 via la page
<a href="chrome://net-internals/#http2">special net-internals page</a>. Il y
- a aussi cette extension intéressante pour <a href="https://chrome.google.com/webstore/detail/http2-and-spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin?hl=en">Chrome</a>
- et <a href="https://addons.mozilla.org/en-us/firefox/addon/spdy-indicator/">Firefox</a>
+ a aussi cette extension intéressante pour <a href="https://chromewebstore.google.com/detail/http-indicator/hgcomhbcacfkpffiphlmnlhpppcjgmbl">Chrome</a>
+ et <a href="https://addons.mozilla.org/en-us/firefox/addon/http2-indicator/">Firefox</a>
qui permet d'indiquer que votre navigateur utilise HTTP/2.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="push">Push serveur <a title="Lien permanent" href="#push" class="permalink">¶</a></h2>
+ <div class="warning"><h3>Notification d’obsolescence</h3>
+ <p>Server Push est obsolète dans la <a href="https://www.rfc-editor.org/rfc/rfc9113#section-8.4">RFC 9113</a>. Les
+ navigateurs principaux (Chrome 106+, Edge 106+) ont supprimé sa prise en
+ charge. Bien que <code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code> implémente encore push, les
+ nouveaux déploiements doivent utiliser <a href="#earlyhints">103 Early
+ Hints</a> à titre de méthode plus fiable pour informer les clients à propos
+ des ressources nécessaires.</p>
+ </div>
<p>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
procéder vous-même à ces expérimentations :</p>
<p><code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code> inspecte l'en-tête de la réponse et recherche les
en-têtes <code>Link</code> sous un certain format :</p>
-
<pre class="prettyprint lang-config">Link </xxx.css>;rel=preload, </xxx.js>; rel=preload</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">Link </xxx.css>;rel=preload, </xxx.js>; rel=preload</pre>
+</div>
<p>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</p>
-
<pre class="prettyprint lang-config"><Location /xxx.html>
- Header add Link "</xxx.css>;rel=preload"
- Header add Link "</xxx.js>;rel=preload"
+
<div class="example"><pre class="prettyprint lang-config"><Location /xxx.html>
+Header add Link "</xxx.css>;rel=preload"
+Header add Link "</xxx.js>;rel=preload"
</Location></pre>
-
+</div>
<p>Si vous souhaitez utiliser des liens <code>preload</code> sans déclencher
de PUSH, vous pouvez utiliser le paramètre <code>nopush</code> comme suit :</p>
-
<pre class="prettyprint lang-config">Link </xxx.css>;rel=preload;nopush</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">Link </xxx.css>;rel=preload;nopush</pre>
+</div>
<p>Vous pouvez aussi désactiver les PUSHes pour l'ensemble de votre
serveur via la directive</p>
-
<pre class="prettyprint lang-config">H2Push Off</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">H2Push Off</pre>
+</div>
<p>À savoir aussi :</p>
<p>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
lorsque la connexion est fermée, le journal de ses PUSHes est supprimé.</p>
<p>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.</p>
+ d'éviter les PUSHes pour ces dernières, mais aucune norme n’a émergé avant
+ que push ne devienne obsolète.</p>
<p>L'<a href="https://datatracker.ietf.org/doc/html/draft-ruellan-http-accept-push-policy-00">
- en-tête Accept-Push-Policy</a> est un autre dispositif expérimental
+ en-tête Accept-Push-Policy</a> est un dispositif expérimental
implémenté dans <code class="module"><a href="../mod/mod_http2.html">mod_http2</a></code> ; il permet au client de définir pour
- chaque requête quels genres de PUSHes il accepte.</p>
-
-
+ chaque requête quels genres de PUSHes il accepte. Ce dispositif a été
+ abandonné et n’a jamais été adopté.</p>
<p>
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
d'exposer les cookies là où ils ne sont pas censés être visibles.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
-<h2 id="earlyhints">
Suggestions précoces <a title="Lien permanent" href="#earlyhints" class="permalink">¶</a></h2>
+<h2 id="earlyhints">
EarlyHints <a title="Lien permanent" href="#earlyhints" class="permalink">¶</a></h2>
<p>A l'instar des ressources PUSHées, une autre méthode consiste à envoyer
des en-têtes <code>Link</code> au client avant même que la réponse ne soit
précoces" (Early Hints) décrite dans la <a href="https://www.rfc-editor.org/rfc/rfc8297">RFC 8297</a>.</p>
<p>Pour utiliser cette fonctionnalité, vous devez l'activer explicitement
sur le serveur via :</p>
-
<pre class="prettyprint lang-config">H2EarlyHints on</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">H2EarlyHints on</pre>
+</div>
<p>Elle n'est en effet pas activée par défaut car certains navigateurs
anciens perdent pied avec de telles réponses.</p>
<p>Une fois cette fonctionnalité activée, vous pouvez utiliser la directive
<code class="directive"><a href="../mod/mod_http2.html#h2pushresource">H2PushResource</a></code> pour déclencher les
suggestions précoces et les PUSHes de ressources :</p>
-
<pre class="prettyprint lang-config"><Location /xxx.html>
- H2PushResource /xxx.css
- H2PushResource /xxx.js
+
<div class="example"><pre class="prettyprint lang-config"><Location /xxx.html>
+H2PushResource /xxx.css
+H2PushResource /xxx.js
</Location></pre>
-
+</div>
<p>Le serveur enverra alors au client une réponse <code>"103 Early
Hints"</code> dès qu'il <em>commencera</em> à traiter la requête. Selon
votre application web, cet envoi peut intervenir beaucoup plus tôt que le
<variants>
<variant>en</variant>
<variant outdated="yes">es</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
</variants>
</metafile>
<a href="../ko/howto/public_html.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
<a href="../tr/howto/public_html.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<p>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
recevront un contenu situé dans le répertoire home de l'utilisateur
"<code>nom_utilisateur</code>", et dans le sous-répertoire spécifié par
la directive <code class="directive"><a href="../mod/mod_userdir.html#userdir">UserDir</a></code>.</p>
-<p>Notez que par défaut, l'accès à ces répertoires n'est
+<p>Par défaut, l'accès à ces répertoires n'est
<strong>pas</strong> permis. Vous pouvez en permettre l'accès à l'aide
de la directive <code class="directive"><a href="../mod/mod_userdir.html#userdir">UserDir</a></code> en
décommentant la ligne :</p>
-
<pre class="prettyprint lang-config">#Include conf/extra/httpd-userdir.conf</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">#Include conf/extra/httpd-userdir.conf</pre>
+</div>
<p>dans le fichier de configuration par défaut
<code>conf/httpd.conf</code>, et en adaptant le
fichier <code>httpd-userdir.conf</code> selon vos besoins, ou en
incluant les directives appropriées dans une section
<code class="directive"><a href="../mod/core.html#directory"><Directory></a></code> du fichier de
configuration principal.</p>
+
+ <div class="note">Les distributions tierces de httpd (fournies par le fabricant de votre
+ OS ou par le gestionnaire de paquets) placent souvent la configuration de
+ <code class="module"><a href="../mod/mod_userdir.html">mod_userdir</a></code> 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.</div>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif"> <a href="#related">Répertoires web utilisateurs</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#userdir">Définition du chemin des fichiers avec UserDir</a></li>
interprété comme chemin relatif au répertoire home de l'utilisateur
considéré. Par exemple, avec cette configuration :</p>
-
<pre class="prettyprint lang-config">UserDir public_html</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">UserDir public_html</pre>
+</div>
<p>l'URL <code>http://example.com/~rbowen/fichier.html</code>
correspondra au chemin fichier
sera construit en utilisant ce chemin, suivi du nom de l'utilisateur
considéré. Par exemple, avec cette configuration :</p>
- <pre class="prettyprint lang-config">UserDir /var/html</pre>
-
-
+<div class="example"><pre class="prettyprint lang-config">UserDir /var/html</pre>
+</div>
<p>l'URL <code>http://example.com/~rbowen/fichier.html</code>
correspondra au chemin fichier
<code>/var/html/rbowen/fichier.html</code></p>
remplacé par le nom de l'utilisateur dans le chemin du fichier
correspondant. Par exemple, avec cette configuration :</p>
-
<pre class="prettyprint lang-config">UserDir /var/www/*/docs</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">UserDir /var/www/*/docs</pre>
+</div>
<p>l'URL <code>http://example.com/~rbowen/fichier.html</code>
correspondra au chemin fichier
<p>On peut aussi définir plusieurs répertoires ou chemins de
répertoires.</p>
-
<pre class="prettyprint lang-config">UserDir public_html /var/html</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">UserDir public_html /var/html</pre>
+</div>
- <p>Avec l'URL <code>http://example.com/~rbowen/fichier.html</code>,
- Apache va rechercher <code>~rbowen</code>. S'il ne le trouve pas,
- Apache va rechercher <code>rbowen</code> dans
- <code>/var/html</code>. S'il le trouve, l'URL ci-dessus correspondra
- au chemin fichier <code>/var/html/rbowen/file.html</code></p>
+ <p>Les arguments sont pris en compte selon l’ordre dans lequel ils
+ apparaissent. Pour l’URL <code>http://example.com/~rbowen/file.html</code>,
+ httpd recherchera d’abord <code>~rbowen</code>. Si ce dernier n’est pas
+ trouvé, httpd cherchera <code>rbowen</code> dans <code>/var/html</code>. Le
+ fichier sera servi depuis le premier emplacement trouvé.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<p>On peut utiliser la directive <code class="directive"><a href="../mod/mod_userdir.html#userdir">UserDir</a></code> pour rediriger les requêtes
relatives aux répertoires utilisateurs vers des URLs externes.</p>
-
<pre class="prettyprint lang-config">UserDir http://example.org/users/*/</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">UserDir http://example.org/users/*/</pre>
+</div>
<p>L'exemple ci-dessus va rediriger une requête pour
<code>http://example.com/~bob/abc.html</code> vers
vous pouvez définir quels utilisateurs sont autorisés à utiliser
cette fonctionnalité :</p>
-
<pre class="prettyprint lang-config">UserDir disabled root jro fish</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">UserDir disabled root jro fish</pre>
+</div>
<p>La configuration ci-dessus va autoriser l'utilisation de la
fonctionnalité pour tous les utilisateurs, à l'exception de ceux
utilisateurs sauf certains d'entre eux en utilisant une
configuration du style :</p>
-
<pre class="prettyprint lang-config">UserDir disabled
+
<div class="example"><pre class="prettyprint lang-config">UserDir disabled
UserDir enabled rbowen krietz</pre>
-
-
+</div>
<p>Vous trouverez d'autres exemples dans la documentation de
<code class="directive"><a href="../mod/mod_userdir.html#userdir">UserDir</a></code>.</p>
vous pouvez utiliser une section <code class="directive"><a href="../mod/core.html#directory"><Directory></a></code> pour activer CGI dans un
sous-répertoire particulier d'un répertoire home utilisateur.</p>
-
<pre class="prettyprint lang-config"><Directory "/home/*/public_html/cgi-bin/">
- Options ExecCGI
- SetHandler cgi-script
+
<div class="example"><pre class="prettyprint lang-config"><Directory "/home/*/public_html/cgi-bin/">
+Options ExecCGI
+SetHandler cgi-script
</Directory></pre>
-
-
+</div>
<p>Avec la configuration ci-dessus, et en supposant que
<code>UserDir</code> est défini à <code>public_html</code>, un
programme CGI <code>exemple.cgi</code> pourra être chargé depuis ce
<variants>
<variant>en</variant>
<variant outdated="yes">es</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
<variant outdated="yes">ja</variant>
<variant outdated="yes">ko</variant>
<variant outdated="yes">tr</variant>
<a href="../es/howto/reverse_proxy.html" hreflang="es" rel="alternate" title="Español"> es </a> |
<a href="../fr/howto/reverse_proxy.html" title="Français"> fr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
-
- <p>En plus de ses fonctions de serveur web "basique", à savoir fournir du
- contenu statique et dynamique à l'utilisateur, Apache httpd (comme la
- plupart des autres serveurs web) peut aussi assurer les fonctions de serveur
- mandataire inverse, connu aussi sous le nom de serveur "passerelle".</p>
-
- <p>Dans un tel scénario, httpd ne génère et n'héberge pas lui-même les
- données, le contenu étant en général obtenu à partir d'un ou plusieurs serveurs
- d'arrière-plan qui n'ont normalement aucune connexion directe avec le réseau
- externe. Lorsque httpd reçoit une requête en provenance d'un client, la
- requête proprement dite est <em>mandatée</em> vers un de ces serveurs
- d'arrière-plan qui traite la requête, génère le contenu et l'envoie à httpd,
- ce dernier générant la véritable réponse HTTP à destination du client.</p>
-
- <p>De nombreuses raisons peuvent vous motiver à utiliser cette
- fonctionnalité, mais elles sont souvent du domaine de la sécurité, de
- la haute disponibilité, de la répartition de charge et de
- l'authentification/autorisation centralisée. Il est alors indispensable que
- l'organisation, la conception et l'architecture de l'infrastructure
- d'arrière-plan (les serveurs qui traitent au sens propre les requêtes) soient
- isolées et protégées de l'extérieur ; vu du client, le serveur mandataire
- inverse <em>est</em> le seul serveur accessible pouvant lui fournir du
+
+ <p>En plus de servir directement du contenu statique et dynamique, Apache
+ httpd peut remplir les fonctions d’un serveur mandataire inverse (parfois
+ appelé passerelle).</p>
+
+ <p>Dans ce mode, httpd ne génère pas le contenu lui-même. Il redirige chaque
+ requête client vers un ou plusieurs serveurs dorsaux qui n’ont pas d’accès
+ direct au réseau externe. Le serveur dorsal traite la requête et renvoie le
+ contenu à httpd qui, à son tour, envoie la réponse HTTP au client.</p>
+
+ <p>Les buts courants de ce dispositif comprennent la sécurité, la haute
+ disponibilité, la répartition de charge et l’authentification centralisée.
+ L’infrastructure dorsale doit être isolée du réseau externe ; du point de
+ vue du client, le mandataire inverse <em>est</em> la seule source de tout
contenu.</p>
<p>Voici un exemple typique d'implémentation de cette fonctionnalité :</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif"> <a href="#related">Mandataire inverse</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#simple">Mandatement inverse simple</a></li>
-<li><img alt="" src="../images/down.gif"> <a href="#cluster">Clusters et Balancers</a></li>
-<li><img alt="" src="../images/down.gif"> <a href="#config">Configuration du Balancer et des BalancerMembers</a></li>
+<li><img alt="" src="../images/down.gif"> <a href="#cluster">Grappes et répartiteurs de charge</a></li>
+<li><img alt="" src="../images/down.gif"> <a href="#config">Configuration du répartiteur de charge et de ses membres (workers)</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#failover">Gestion des indisponibilités (Failover)</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#manager">Gestion du répartiteur de charge</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#health-check">Vérification dynamique du bon fonctionnement d'un serveur
- d'arrière-plan</a></li>
+ dorsal</a></li>
<li><img alt="" src="../images/down.gif"> <a href="#status">Drapeaux d'état d'un membre du groupe de répartition de charge</a></li>
</ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
unique :
</p>
-
<pre class="prettyprint lang-config">ProxyPass "/" "http://www.example.com/"</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">ProxyPass "/" "http://www.example.com/"</pre>
+</div>
<p>
- Pour être sur que cette redirection soit effectuée et que les en-têtes
- <code>Location:</code> générés par le serveur d'arrière-plan soient
- modifiés pour pointer vers le mandataire inverse, et non vers le serveur
- d'arrière-plan, la directive <code class="directive"><a href="../mod/mod_proxy.html#proxypassreverse">ProxyPassReverse</a></code> est souvent requise :
+ Pour s’assurer que les en-têtes <code>Location:</code> générés par le
+ serveur dorsal soient modifiés pour pointer vers le mandataire inverse, et
+ non vers le serveur d'arrière-plan, la directive <code class="directive"><a href="../mod/mod_proxy.html#proxypassreverse">ProxyPassReverse</a></code> est en général requise :
</p>
-
<pre class="prettyprint lang-config">ProxyPass "/" "http://www.example.com/"
+
<div class="example"><pre class="prettyprint lang-config">ProxyPass "/" "http://www.example.com/"
ProxyPassReverse "/" "http://www.example.com/"</pre>
+</div>
-
- <p>Seules des URIs spécifiques peuvent être mandatées, comme le montre
+ <p>Il est possible de spécifier les URIs qui peuvent être mandatés, comme le montre
l'exemple suivant :</p>
-
<pre class="prettyprint lang-config">ProxyPass "/images" "http://www.example.com/"
+
<div class="example"><pre class="prettyprint lang-config">ProxyPass "/images" "http://www.example.com/"
ProxyPassReverse "/images" "http://www.example.com/"</pre>
-
+</div>
<p>Dans l'exemple précédent, si le chemin d'une requête commence par
<code>/images</code>, elle sera redirigée vers le serveur d'arrière-plan
</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
-<h2 id="cluster">
Clusters et Balancers <a title="Lien permanent" href="#cluster" class="permalink">¶</a></h2>
+<h2 id="cluster">
Grappes et répartiteurs de charge <a title="Lien permanent" href="#cluster" class="permalink">¶</a></h2>
<p>
- Utiliser un serveur d'arrière-plan unique n'est cependant pas une solution
- idéale car ce dernier peut devenir indisponible ou surchargé, et le
- mandatement inverse vers ce serveur ne présente alors plus aucun avantage.
- La solution réside dans la définition d'un groupe de serveurs
- d'arrière-plan qui vont se partager le traitement des requêtes via un
- mécanisme de répartition de charge et de gestion des indisponibilités pris
- en charge par le mandataire. Ce groupe de répartition est plus connu sous le nom de
- <em>cluster</em>, mais dans la terminologie d'Apache httpd, on utilise
- plutôt le terme de <em>balancer</em>. Un balancer se définit en
- utilisant les directives <code class="directive"><a href="../mod/mod_proxy.html#proxy"><Proxy></a></code> et <code class="directive"><a href="../mod/mod_proxy.html#balancermember">BalancerMember</a></code> comme suit :
+ La configuration à un seul serveur dorsal ci-avant comporte un défaut
+ évident : si ce serveur dorsal est éteint ou surchargé, le contenu
+ mandaté ne sera pas disponible. Ce dont on a besoin ici est un groupe de
+ serveurs dorsaux parmi lesquels le serveur mandataire pourra basculer et
+ répartir la charge. Ce groupe est parfois appelé <em>grappe</em>
+ (cluster) ; Apache httpd le nomme <em>répartiteur de charge</em>
+ (balancer). Un répartiteur de charge se définit en utilisant les
+ directives <code class="directive"><a href="../mod/mod_proxy.html#proxy"><Proxy></a></code>
+ et <code class="directive"><a href="../mod/mod_proxy.html#balancermember">BalancerMember</a></code> :
</p>
-
<pre class="prettyprint lang-config"><Proxy balancer://myset>
- BalancerMember http://www2.example.com:8080
- BalancerMember http://www3.example.com:8080
- ProxySet lbmethod=bytraffic
+
<div class="example"><pre class="prettyprint lang-config"><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/"</pre>
-
+</div>
<p>
Le protocole <code>balancer://</code> indique à httpd que l'on souhaite
- créer un balancer nommé <em>myset</em>. Ce balancer comporte deux serveurs
+ créer un répartiteur de charge nommé <em>myset</em>. Ce répartiteur comporte deux serveurs
d'arrière-plan référencés dans la terminologie httpd sous le nom de
<em>BalancerMembers</em>. Avec cet exemple, toute requête dont le chemin
commence par <code>/images</code> sera mandatée vers <em>un</em> des deux
- serveurs d'arrière-plan. La directive <code class="directive"><a href="../mod/mod_proxy.html#proxyset">ProxySet</a></code> définit ici pour le balancer
+ serveurs d'arrière-plan. La directive <code class="directive"><a href="../mod/mod_proxy.html#proxyset">ProxySet</a></code> définit ici pour le répartiteur
<em>myset</em> un algorithme de
répartition de charge basé sur le trafic entrées/sorties.
</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
-<h2 id="config">Configuration du
Balancer et des BalancerMembers <a title="Lien permanent" href="#config" class="permalink">¶</a></h2>
+<h2 id="config">Configuration du
répartiteur de charge et de ses membres (workers) <a title="Lien permanent" href="#config" class="permalink">¶</a></h2>
<p>
- Vous pouvez configurer de manière détaillée les <em>balancers</em> et
- <em>workers</em> via les nombreux paramètres de la directive <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code>. Par exemple, si vous souhaitez
- que <code>http://www3.example.com:8080</code> traite avec un facteur 3 le
- trafic avec un timeout d'une seconde, utilisez la configuration suivante :
+ Les répartiteurs de charge et leurs membres sont configurés à l’aide de
+ paramètres de la directive <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code>. Par exemple, pour que
+ <code>http://www3.example.com:8080</code> gère le trafic avec un facteur 3
+ et un délai d’une seconde :
</p>
-
<pre class="prettyprint lang-config"><Proxy balancer://myset>
- BalancerMember http://www2.example.com:8080
- BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
- ProxySet lbmethod=bytraffic
+
<div class="example"><pre class="prettyprint lang-config"><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/"</pre>
-
+</div>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<p>
- Vous pouvez aussi définir finement des scénarios pour les cas
- d'indisponibilité d'un ou plusieurs serveurs d'arrière-plan en spécifiant
- quels serveurs doivent alors prendre le relai. Dans l'exemple suivant,
+ Vous pouvez définir finement des scénarios pour les cas d'indisponibilité
+ d'un ou plusieurs serveurs dorsaux en spécifiant quels répartiteurs et
+ leurs membres doivent alors prendre le relai. Dans l'exemple suivant,
trois scénarios sont envisagés :
</p>
<ol>
ou de standby pour chaque jeu de serveurs du répartiteur de charge.
</p>
-
<pre class="prettyprint lang-config"><Proxy balancer://myset>
- BalancerMember http://www2.example.com:8080
- BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
- BalancerMember http://spare1.example.com:8080 status=+R
- BalancerMember http://spare2.example.com:8080 status=+R
- BalancerMember http://hstandby.example.com:8080 status=+H
- BalancerMember http://bkup1.example.com:8080 lbset=1
- BalancerMember http://bkup2.example.com:8080 lbset=1
- ProxySet lbmethod=byrequests
+
<div class="example"><pre class="prettyprint lang-config"><Proxy balancer://myset>
+BalancerMember http://www2.example.com:8080
+BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+BalancerMember http://spare1.example.com:8080 status=+R
+BalancerMember http://spare2.example.com:8080 status=+R
+BalancerMember http://hstandby.example.com:8080 status=+H
+BalancerMember http://bkup1.example.com:8080 lbset=1
+BalancerMember http://bkup2.example.com:8080 lbset=1
+ProxySet lbmethod=byrequests
</Proxy>
ProxyPass "/images/" "balancer://myset/"
ProxyPassReverse "/images/" "balancer://myset/"</pre>
-
+</div>
<p>
Les serveurs de remplacement à chaud remplacent les serveurs indisponibles
- du même jeu de serveurs du répartiteur de charge. Un serveur est
- considéré comme indisponible s'il est en maintenance, arrêté ou en erreur.
- Les serveurs de standby à chaud sont utilisés si tous les serveurs et
- serveurs de remplacement du jeu de serveurs du répartiteur de charge sont
- indisponibles. Les jeux de serveurs du répartiteur de charge (avec leurs
- serveurs de standby et de remplacement à chaud respectifs) sont toujours
- sollicités dans l'ordre du plus bas lbset vers le plus haut.
+ (en phase de vidage, arrêtés ou en état d’erreur) du même jeu de serveurs
+ du répartiteur de charge. Les serveurs de standby à chaud ne sont activés
+ que si tous les serveurs et serveurs de remplacement du jeu de serveurs du
+ répartiteur de charge sont indisponibles. Les jeux de serveurs du
+ répartiteur de charge sont sollicités dans l'ordre du plus bas lbset vers
+ le plus haut.
</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<p>
- L'application <em>balancer-manager</em> fournie avec le mandataire inverse
- d'Apache httpd en est un des outils les plus utiles. Comme
- <code class="module"><a href="../mod/mod_status.html">mod_status</a></code>, <em>balancer-manager</em> affiche la
- configuration et l'activité actuelles des balancers actifs. L'affichage de
- ces informations n'est cependant pas sa seule fonction ; il permet aussi de
- modifier la plupart d'entre elles et même d'ajouter des membres au groupe
- de répartition de charge en temps réel. Pour activer ces fonctionnalités,
- vous devez ajouter les lignes suivantes à votre fichier de configuration :
+ Apache httpd comporte un <em>gestionnaire de répartiteur de charge</em>
+ (balancer-manager) intégré. Comme <code class="module"><a href="../mod/mod_status.html">mod_status</a></code>, il affiche
+ la configuration et l’état actuels de vos répartiteurs de charge et de
+ leurs membres. Il vous permet aussi de les reconfigurer à l’exécution
+ — par exemple pour ajouter de nouveaux membres à un répartiteur existant.
+ Pour l’activer, ajoutez les lignes suivantes à votre configuration :
</p>
-
<pre class="prettyprint lang-config"><Location "/balancer-manager">
- SetHandler balancer-manager
- Require host localhost
+
<div class="example"><pre class="prettyprint lang-config"><Location "/balancer-manager">
+SetHandler balancer-manager
+Require host localhost
</Location></pre>
-
+</div>
<div class="warning"><h3>Avertissement</h3>
<p>N'activez le <em>balancer-manager</em> que si vous avez déjà <a href="../mod/mod_proxy.html#access">sécurisé votre serveur</a>.
<p class="centered"><img src="../images/bal-man.png" alt="balancer-manager page"></p>
<p>
- Ce formulaire permet à l'administrateur de modifier certains paramètres,
- de désactiver ou d'ajouter certains serveurs d'arrière-plan, et de
- modifier les règles de répartition de charge. Par exemple, si on clique
+ Ce formulaire permet de modifier certains paramètres,
+ de désactiver ou d'ajouter des serveurs dorsaux, et de
+ modifier les règles de répartition de charge. Si l’on clique
sur le répartiteur, la page suivante s'affiche :
</p>
<p class="centered"><img src="../images/bal-man-b.png" alt="balancer-manager page"></p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="health-check">Vérification dynamique du bon fonctionnement d'un serveur
- d
'arrière-plan <a title="Lien permanent" href="#health-check" class="permalink">¶</a></h2>
+ d
orsal <a title="Lien permanent" href="#health-check" class="permalink">¶</a></h2>
<p>
- Avant que le mandataire httpd ne fasse appel à un serveur d'arrière-plan, il
- peut <em>"tester"</em> si ce dernier est disponible en définissant le
-
paramètre <code>ping</code> de ce serveur via la directive <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code>. Cependant, il est souvent plus
+ Avant de mandater une requête, httpd peut <em>"tester"</em> si le serveur
+ dorsal est disponible en définissant le paramètre <code>ping</code> de ce
+ serveur via la directive <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code>. Cependant, il est souvent plus
judicieux de vérifier le bon fonctionnement d'un serveur <em>hors
- bande</em> et de manière dynamique via le module
- <code class="module"><a href="../mod/mod_proxy_hcheck.html">mod_proxy_hcheck</a></code> d'Apache httpd.
+ ibande</em> via le module <code class="module"><a href="../mod/mod_proxy_hcheck.html">mod_proxy_hcheck</a></code>.
</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<variants>
<variant>en</variant>
<variant outdated="yes">es</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
</variants>
</metafile>
<a href="./ko/logs.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
<a href="./tr/logs.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<p>Pour véritablement gérer un serveur web,
il est nécessaire de disposer d'un
certainement avoir accès à l'uid sous lequel le serveur est démarré, en
l'occurrence habituellement root. N'accordez <em>PAS</em> aux utilisateurs
l'accès en écriture au répertoire dans lequel les journaux sont stockés
- sans savoir exactement quelles en seraient les conséquences ; voir le
+ sans savoir exactement quelles en seraient les conséquences ; voir le
document <a href="misc/security_tips.html">conseils sur la sécurité</a>
pour plus de détails.</p>
<p>Pour ce faire, vous devez spécifier le nom du module dans votre
directive <code class="directive">LogLevel</code> :</p>
-
<pre class="prettyprint lang-config">LogLevel info rewrite:trace5</pre>
-
+
<div class="example"><pre class="prettyprint lang-config">LogLevel info rewrite:trace5</pre>
+</div>
<p>Dans cet exemple, le niveau de journalisation général est défini
à info, et à <code>trace5</code> pour <code class="module"><a href="./mod/mod_rewrite.html">mod_rewrite</a></code>.</p>
<p>Voici une configuration typique pour le journal des accès :</p>
-
<pre class="prettyprint lang-config">LogFormat "%h %l %u %t \"%r\" %>s %b" common
+
<div class="example"><pre class="prettyprint lang-config">LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog "logs/access_log" common</pre>
-
+</div>
<p>Ici est définie l'<em>identité</em> <code>common</code> qui est
ensuite associée à une chaîne de format de journalisation particulière.
"Combined Log Format" (Format de journalisation combiné). Il s'utilise
comme suit :</p>
-
<pre class="prettyprint lang-config">LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
+
<div class="example"><pre class="prettyprint lang-config">LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog "log/access_log" combined</pre>
-
+</div>
<p>Ce format est identique au Common Log Format, avec deux champs
supplémentaires. Chacun de ces deux champs utilise la directive
comment simuler les effets des directives <code>ReferLog</code> et
<code>AgentLog</code>.</p>
-
<pre class="prettyprint lang-config">LogFormat "%h %l %u %t \"%r\" %>s %b" common
+
<div class="example"><pre class="prettyprint lang-config">LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog "logs/access_log" common
CustomLog "logs/referer_log" "%{Referer}i -> %U"
CustomLog "logs/agent_log" "%{User-agent}i"</pre>
-
+</div>
<p>Cet exemple montre aussi qu'il n'est pas obligatoire d'associer
une chaîne de format à un alias au moyen de la directive
la variable d'environnement est définie.
Quelques exemples :</p>
-
<pre class="prettyprint lang-config"># Marque les requêtes en provenance de l'interface loop-back
+
<div class="example"><pre class="prettyprint lang-config"># Marque les requêtes en provenance de l'interface loop-back
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# Marque les requêtes pour le fichier robots.txt
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# Journalise toutes les autres requêtes
CustomLog "logs/access_log" common env=!dontlog</pre>
-
+</div>
<p>Autre exemple, imaginons l'enregistrement des requêtes en provenance
d'utilisateurs de langue anglaise dans un journal, et celles des autres
utilisateurs dans un autre journal.</p>
- <pre class="prettyprint lang-config"> SetEnvIf Accept-Language "en" english
- CustomLog "logs/english_log" common env=english
- CustomLog "logs/non_english_log" common env=!english</pre>
-
+<div class="example"><pre class="prettyprint lang-config">SetEnvIf Accept-Language "en" english
+CustomLog "logs/english_log" common env=english
+CustomLog "logs/non_english_log" common env=!english</pre>
+</div>
<p>Dans le contexte d'une mise en cache, il peut être
intéressant de connaître l'efficacité du cache. Pour y parvenir,
on pourrait utiliser cette méthode simple :</p>
-
<pre class="prettyprint lang-config">SetEnv CACHE_MISS 1
+
<div class="example"><pre class="prettyprint lang-config">SetEnv CACHE_MISS 1
LogFormat "%h %l %u %t "%r " %>s %b %{CACHE_MISS}e" common-cache
CustomLog "logs/access_log" common-cache</pre>
-
+</div>
<p><code class="module"><a href="./mod/mod_cache.html">mod_cache</a></code> va s'exécuter avant
<code class="module"><a href="./mod/mod_env.html">mod_env</a></code>, et si son action est couronnée de
valeurs de journalisation conditionnelles basées sur le code de la
réponse HTTP :</p>
-
<pre class="prettyprint lang-config">LogFormat "%400,501{User-agent}i" browserlog
+
<div class="example"><pre class="prettyprint lang-config">LogFormat "%400,501{User-agent}i" browserlog
LogFormat "%!200,304,302{Referer}i" refererlog</pre>
-
+</div>
<p>Dans le premier exemple, le <code>User-agent</code> sera
enregistré si le code d'état HTTP est 400 ou 501. Dans le cas
journal, puis de séparer ultérieurement le journal en plusieurs journaux
individuels. Considérons par exemple les directives suivantes :</p>
-
<pre class="prettyprint lang-config">LogFormat "%v %p %h %l %u %t \"%r\" %>s %b" commonvhost
+
<div class="example"><pre class="prettyprint lang-config">LogFormat "%v %p %h %l %u %t \"%r\" %>s %b" commonvhost
CustomLog "logs/access_log" commonvhost</pre>
-
+</div>
<p>Le champ <code>%v</code> sert à enregistrer le nom de l'hôte virtuel qui
traite la requête. Un programme tel que <a href="programs/split-logfile.html">split-logfile</a> peut ensuite être utilisé
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
-<!-- English Revision: 659902:1935724 (outdated) -->
+<!-- English Revision: 659902:1935747 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<?xml version="1.0" encoding="EUC-KR" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
-<!-- English Revision: 105989:1935724 (outdated) -->
+<!-- English Revision: 105989:1935747 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<variants>
<variant>en</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
<variant outdated="yes">ja</variant>
<variant outdated="yes">ko</variant>
<variant outdated="yes">tr</variant>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.tr.xsl"?>
-<!-- English Revision: 1300924:1935724 (outdated) -->
+<!-- English Revision: 1300924:1935747 (outdated) -->
<!-- =====================================================
Translated by: Nilgün Belma Bugüner <nilgun belgeler.org>
Reviewed by: Orhan Berent <berent belgeler.org>
<a href="./tr/mpm.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a> |
<a href="./zh-cn/mpm.html" hreflang="zh-cn" rel="alternate" title="Simplified Chinese"> zh-cn </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<p>Ce document décrit ce qu'est un Module Multi-Processus, ainsi
que la manière dont ces modules sont utilisés par le serveur HTTP Apache.</p>
modifiant la directive <code class="directive"><a href="./mod/mod_so.html#loadmodule">LoadModule</a></code> concernée, sans avoir à
recompiler le serveur.</p>
- <pre class="prettyprint lang-config">LoadModule mpm_prefork_module modules/mod_mpm_prefork.so</pre>
+ <pre class="prettyprint lang-config">LoadModule mpm_event_module modules/mod_mpm_event.so</pre>
<p>Toute tentative de charger plusieurs modules MPM via la directive
<variant outdated="yes">de</variant>
<variant>en</variant>
<variant>es</variant>
- <variant outdated="yes">fr</variant>
+ <variant>fr</variant>
<variant outdated="yes">ja</variant>
<variant outdated="yes">ko</variant>
<variant outdated="yes">tr</variant>
projects / thirdparty / apache / httpd.git / commitdiff
