--- /dev/null
+<?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 : 1832609 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="reverse_proxy.xml.meta">
+<parentdocument href="./">Recettes / Tutoriels</parentdocument>
+
+ <title>Guide de configuration d'un mandataire inverse</title>
+
+ <summary>
+ <p>En plus de ses fonctions de serveur web "basique", à savoir fournir du
+ contenu statique et dynamique à l'utilisateur, Apache httpd (comme la
+ plupart des autres serveurs web) peut aussi assurer les fonctions de serveur
+ mandataire inverse, connu aussi sous le nom de serveur "passerelle".</p>
+
+ <p>Dans un tel scénario, httpd ne génère et n'héberge pas lui-même les
+ données, le contenu étant en général obtenu à partir d'un ou plusieurs serveurs
+ d'arrière-plan qui n'ont normalement aucune connexion directe avec le réseau
+ externe. Lorsque httpd reçoit une requête en provenance d'un client, la
+ requête proprement dite est <em>mandatée</em> vers un de ces serveurs
+ d'arrière-plan qui traite la requête, génère le contenu et l'envoie à httpd,
+ ce dernier générant la véritable réponse HTTP à destination du client.</p>
+
+ <p>De nombreuses raisons peuvent vous motiver à utiliser cette
+ fonctionnalité, mais elles sont souvent du domaine de la sécurité, de
+ la haute disponibilité, de la répartition de charge et de
+ l'authentification/autorisation centralisée. Il est alors indispensable que
+ l'organisation, la conception et l'architecture de l'infrastructure
+ d'arrière-plan (les serveurs qui traitent au sens propre les requêtes) soient
+ isolées et protégées de l'extérieur ; vu du client, le serveur mandataire
+ inverse <em>est</em> le seul serveur accessible pouvant lui fournir du
+ contenu.</p>
+
+ <p>Voici un exemple typique d'implémentation de cette fonctionnalité :</p>
+ <p class="centered"><img src="../images/reverse-proxy-arch.png" alt="reverse-proxy-arch" /></p>
+
+ </summary>
+
+
+ <section id="related">
+ <title>Mandataire inverse</title>
+ <related>
+ <modulelist>
+ <module>mod_proxy</module>
+ <module>mod_proxy_balancer</module>
+ <module>mod_proxy_hcheck</module>
+ </modulelist>
+ <directivelist>
+ <directive module="mod_proxy">ProxyPass</directive>
+ <directive module="mod_proxy">BalancerMember</directive>
+ </directivelist>
+ </related>
+ </section>
+
+ <section id="simple">
+ <title>Mandatement inverse simple</title>
+
+ <p>
+ La directive <directive module="mod_proxy">ProxyPass</directive> permet de
+ rediriger les requêtes entrantes vers un serveur d'arrière-plan (ou un
+ cluster de serveurs plus connu sous le nom de groupe
+ <code>Balancer</code>). Dans cet exemple le plus simple, toutes les
+ requêtes (<code>"/"</code>) sont redirigées vers un serveur d'arrière-plan
+ unique :
+ </p>
+
+ <highlight language="config">
+ProxyPass "/" "http://www.example.com/"
+ </highlight>
+
+ <p>
+ Pour être sur que cette redirection soit effectuée et que les en-têtes
+ <code>Location:</code> générés par le serveur d'arrière-plan soient
+ modifiés pour pointer vers le mandataire inverse, et non vers le serveur
+ d'arrière-plan, la directive <directive
+ module="mod_proxy">ProxyPassReverse</directive> est souvent requise :
+ </p>
+
+ <highlight language="config">
+ProxyPass "/" "http://www.example.com/"
+ProxyPassReverse "/" "http://www.example.com/"
+ </highlight>
+
+ <p>Seules des URIs spécifiques peuvent être mandatées, comme le montre
+ l'exemple suivant :</p>
+
+ <highlight language="config">
+ProxyPass "/images" "http://www.example.com/"
+ProxyPassReverse "/images" "http://www.example.com/"
+ </highlight>
+
+ <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
+ spécifié ; dans le cas contraire, elle sera traitée localement.
+ </p>
+ </section>
+
+ <section id="cluster">
+ <title>Clusters et Balancers</title>
+
+ <p>
+ Utiliser un serveur d'arrière-plan unique n'est cependant pas une solution
+ idéale car ce dernier peut devenir indisponible ou surchargé, et le
+ mandatement inverse vers ce serveur ne présente alors plus aucun avantage.
+ La solution réside dans la définition d'un groupe de serveurs
+ d'arrière-plan qui vont se partager le traitement des requêtes via un
+ mécanisme de répartition de charge et de gestion des indisponibilités pris
+ en charge par le mandataire. Ce groupe de répartition est plus connu sous le nom de
+ <em>cluster</em>, mais dans la terminologie d'Apache httpd, on utilise
+ plutôt le terme de <em>balancer</em>. Un balancer se définit en
+ utilisant les directives <directive module="mod_proxy"
+ type="section">Proxy</directive> et <directive
+ module="mod_proxy">BalancerMember</directive> comme suit :
+ </p>
+
+ <highlight language="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/"
+ </highlight>
+
+ <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
+ d'arrière-plan référencés dans la terminologie httpd sous le nom de
+ <em>BalancerMembers</em>. Avec cet exemple, toute requête dont le chemin
+ commence par <code>/images</code> sera mandatée vers <em>un</em> des deux
+ serveurs d'arrière-plan. La directive <directive
+ module="mod_proxy">ProxySet</directive> définit ici pour le balancer
+ <em>myset</em> un algorithme de
+ répartition de charge basé sur le trafic entrées/sorties.
+ </p>
+
+ <note type="hint"><title>Remarque</title>
+ <p>
+ Les <em>BalancerMembers</em> sont aussi souvent référencés sous le terme
+ <em>workers</em>.
+ </p>
+ </note>
+
+ </section>
+
+ <section id="config">
+ <title>Configuration du Balancer et des BalancerMembers</title>
+
+ <p>
+ Vous pouvez configurer de manière détaillée les <em>balancers</em> et
+ <em>workers</em> via les nombreux paramètres de la directive <directive
+ module="mod_proxy">ProxyPass</directive>. Par exemple, si vous souhaitez
+ que <code>http://www3.example.com:8080</code> traite avec un facteur 3 le
+ trafic avec un timeout d'une seconde, utilisez la configuration suivante :
+ </p>
+
+ <highlight language="config">
+<Proxy balancer://myset>
+ BalancerMember http://www2.example.com:8080
+ BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+ ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images" "balancer://myset/"
+ProxyPassReverse "/images" "balancer://myset/"
+ </highlight>
+
+ </section>
+
+ <section id="failover">
+ <title>Gestion des indisponibilités (Failover)</title>
+
+ <p>
+ Vous pouvez aussi définir finement des scénarios pour les cas
+ d'indisponibilité d'un ou plusieurs serveurs d'arrière-plan en spécifiant
+ quels serveurs doivent alors prendre le relai. Dans l'exemple suivant,
+ trois scénarios sont envisagés :
+ </p>
+ <ol>
+ <li>
+ <code>http://spare1.example.com:8080</code> et
+ <code>http://spare2.example.com:8080</code> ne sont sollicités que si
+ <code>http://www2.example.com:8080</code> ou
+ <code>http://www3.example.com:8080</code> est indisponible (un serveur
+ de remplacement sera utilisé à la place d'un membre indisponible du même
+ jeu de serveurs cibles).
+ </li>
+ <li>
+ <code>http://hstandby.example.com:8080</code> n'est sollicité que si
+ tous les autres serveurs cibles du jeu de serveurs <code>0</code> sont
+ indisponibles.
+ </li>
+ <li>
+ Les serveurs <code>http://bkup1.example.com:8080</code> et
+ <code>http://bkup2.example.com:8080</code> du jeu <code>1</code> ne seront sollicités que si
+ tous les serveurs du jeu <code>0</code>, tous les serveurs de
+ remplacement et tous les serveurs de standby sont indisponibles.
+ </li>
+ </ol>
+ <p>
+ Il est ainsi possible de définir un ou plusieurs serveurs de remplacement
+ ou de standby pour chaque jeu de serveurs du répartiteur de charge.
+ </p>
+
+ <highlight language="config">
+<Proxy balancer://myset>
+ BalancerMember http://www2.example.com:8080
+ BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+ BalancerMember http://spare1.example.com:8080 status=+R
+ BalancerMember http://spare2.example.com:8080 status=+R
+ BalancerMember http://hstandby.example.com:8080 status=+H
+ BalancerMember http://bkup1.example.com:8080 lbset=1
+ BalancerMember http://bkup2.example.com:8080 lbset=1
+ ProxySet lbmethod=byrequests
+</Proxy>
+
+ProxyPass "/images/" "balancer://myset/"
+ProxyPassReverse "/images/" "balancer://myset/"
+ </highlight>
+
+ <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.
+ </p>
+
+ </section>
+
+ <section id="manager">
+ <title>Gestion du répartiteur de charge</title>
+
+ <p>
+ L'application <em>balancer-manager</em> fournie avec le mandataire inverse
+ d'Apache httpd en est un des outils les plus utiles. Comme
+ <module>mod_status</module>, <em>balancer-manager</em> affiche la
+ configuration et l'activité actuelles des balancers actifs. L'affichage de
+ ces informations n'est cependant pas sa seule fonction ; il permet aussi de
+ modifier la plupart d'entre elles et même d'ajouter des membres au groupe
+ de répartition de charge en temps réel. Pour activer ces fonctionnalités,
+ vous devez ajouter les lignes suivantes à votre fichier de configuration :
+ </p>
+
+ <highlight language="config">
+<Location "/balancer-manager">
+ SetHandler balancer-manager
+ Require host localhost
+</Location>
+ </highlight>
+
+ <note type="warning"><title>Avertissement</title>
+ <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>.
+ Assurez-vous en particulier que l'accès à l'URL soit fortement restreint.</p>
+ </note>
+
+ <p>
+ Lorsque vous accédez au serveur mandataire avec une adresse du style
+ <code>http://rproxy.example.com/balancer-manager/</code>, la page suivante
+ s'affiche :
+ </p>
+ <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
+ 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>
+
+ <p>
+ Si on clique sur un membre du groupe de répartition de charge, la page
+ suivante s'affiche :
+ </p>
+ <p class="centered"><img src="../images/bal-man-w.png" alt="balancer-manager page" /></p>
+
+ <p>
+ Si vous souhaitez que ces modifications soient conservées après un
+ redémarrage du serveur, assurez-vous que la directive <directive
+ module="mod_proxy">BalancerPersist</directive> soit définie à On.
+ </p>
+
+ </section>
+
+ <section id="health-check">
+ <title>Vérification dynamique du bon fonctionnement d'un serveur
+ d'arrière-plan</title>
+
+ <p>
+ Avant que le mandataire httpd ne fasse appel à un serveur d'arrière-plan, il
+ peut <em>"tester"</em> si ce dernier est disponible en définissant le
+ paramètre <code>ping</code> de ce serveur via la directive <directive
+ module="mod_proxy">ProxyPass</directive>. Cependant, il est souvent plus
+ judicieux de vérifier le bon fonctionnement d'un serveur <em>hors
+ bande</em> et de manière dynamique via le module
+ <module>mod_proxy_hcheck</module> d'Apache httpd.
+ </p>
+
+ </section>
+
+ <section id="status">
+ <title>Drapeaux d'état d'un membre du groupe de répartition de charge</title>
+
+ <p>
+ <em>balancer-manager</em> permet d'afficher et de modifier l'état d'un
+ membre du groupe de répartition de charge. Les différents états et leurs
+ significations sont les suivants :
+ </p>
+ <table border="1">
+ <tr><th>Drapeau</th><th>Sigle</th><th>Description</th></tr>
+ <tr><td> </td><td><em>Ok</em></td><td>Le serveur est disponible</td></tr>
+ <tr><td> </td><td><em>Init</em></td><td>Le serveur a été initialisé</td></tr>
+ <tr><td><code>D</code></td><td><em>Dis</em></td><td>Le serveur est
+ désactivé et n'accepte aucune requête ; il sera retesté automatiquement.</td></tr>
+ <tr><td><code>S</code></td><td><em>Stop</em></td><td>Le serveur a été
+ arrêté par l'administrateur ; il n'accepte aucune requête et il ne sera
+ pas retesté automatiquement.</td></tr>
+ <tr><td><code>I</code></td><td><em>Ign</em></td><td>Les erreurs
+ concernant ce serveur sont ignorées et il sera donc toujours considéré
+ comme disponible.</td></tr>
+ <tr><td><code>R</code></td><td><em>Spar</em></td><td>Le serveur cible sert de remplaçant à
+ chaud. Lorsqu'un serveur cible avec un lbset donné est inutilisable
+ (maintenance, arrêt, en erreur, etc...), un serveur de remplacement à
+ chaud libre de même lbset sera utilisé à sa place. Les remplaçants à
+ chaud permettent de s'assurer qu'un nombre déterminé de serveurs cibles
+ sera toujours disponible pour un répartiteur de charge.</td></tr>
+ <tr><td><code>H</code></td><td><em>Stby</em></td><td>Le serveur est en
+ mode hot-standby et ne sera donc utilisé que si aucun autre serveur ou
+ serveur de remplacement n'est disponible dans le jeu de serveurs du
+ répartiteur de charge.</td></tr>
+ <tr><td><code>E</code></td><td><em>Err</em></td><td>Le serveur est en
+ erreur, en général suite à un test préalable à une requête ; aucune
+ requête ne lui sera soumise, mais il sera retesté en fonction de la
+ valeur de son paramètre <code>retry</code>.</td></tr>
+ <tr><td><code>N</code></td><td><em>Drn</em></td><td>Le serveur est en
+ mode drain ; il n'acceptera de requêtes que dans le cadre des sessions
+ persistantes qui lui sont réservées et ignorera toutes les autres.</td></tr>
+ <tr><td><code>C</code></td><td><em>HcFl</em></td><td>Le serveur a échoué
+ au test dynamique de bon fonctionnement et ne sera utilisé que lorsqu'il
+ aura réussi un test ultérieur.</td></tr>
+ </table>
+ </section>
+
+</manualpage>
--- /dev/null
+<?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 : 1727318 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_authnz_fcgi.xml.meta">
+
+<name>mod_authnz_fcgi</name>
+<description>Permet à une application d'autorisation FastCGI de gérer
+l'authentification et l'autorisation httpd.</description>
+<status>Extension</status>
+<sourcefile>mod_authnz_fcgi.c</sourcefile>
+<identifier>authnz_fcgi_module</identifier>
+<compatibility>Disponible à partir de la version 2.4.10 du serveur HTTP
+Apache</compatibility>
+
+<summary>
+ <p>Ce module permet aux applications d'autorisation FastCGI
+ d'authentifier les utilisateurs et de contrôler leur accès aux
+ ressources. Il supporte les systèmes d'autorisation FastCGI
+ génériques qui participent en une seule phase à l'authentification
+ et à l'autorisation, ainsi que les processus d'authentification et
+ d'autorisation spécifiques à Apache httpd qui interviennent en une
+ ou plusieurs phases.</p>
+
+ <p>Les processus d'autorisation FastCGI peuvent authentifier un
+ utilisateur via son identificateur et son mot de passe comme dans le
+ processus d'authentification basique, ou via un mécanisme
+ arbitraire.</p>
+</summary>
+
+<seealso><a href="../howto/auth.html">Authentification, autorisation et
+contrôle d'accès</a></seealso>
+<seealso><module>mod_auth_basic</module></seealso>
+<seealso><program>fcgistarter</program></seealso>
+<seealso><module>mod_proxy_fcgi</module></seealso>
+
+<section id="invocations"><title>Modes d'invocation</title>
+
+ <p>Les modes d'invocation des processus d'autorisation FastCGI que
+ ce module supporte se distinguent par deux caractéristiques : le
+ <em>type</em> et le <em>mécanisme</em> d'authentification.</p>
+
+ <p>Le <em>Type</em> est simplement <code>authn</code> pour
+ l'authentification, <code>authz</code> pour l'autorisation et
+ <code>authnz</code> l'authentification et l'autorisation.</p>
+
+ <p>Le <em>mécanisme</em> d'authentification fait référence aux
+ mécanismes d'authentification et aux phases de traitement de la
+ configuration de Apache httpd, et peut être
+ <code>AuthBasicProvider</code>, <code>Require</code>, ou
+ <code>check_user_id</code>. Les deux premiers mécanismes
+ correspondent aux directives utilisées pour participer aux phases de
+ traitement appropriées.</p>
+
+ <p>Description de chaque mode:</p>
+
+ <dl>
+ <dt><em>Type</em> <code>authn</code>, <em>mechanism</em>
+ <code>AuthBasicProvider</code></dt>
+
+ <dd>Dans ce mode, la variable <code>FCGI_ROLE</code> est définie à
+ <code>AUTHORIZER</code>, et la variable
+ <code>FCGI_APACHE_ROLE</code> à <code>AUTHENTICATOR</code>.
+ L'application doit être spécifiée en tant que fournisseur de type
+ <em>authn</em> via la directive <directive
+ module="mod_authnz_fcgi">AuthnzFcgiDefineProvider</directive>, et
+ activée via la directive <directive
+ module="mod_auth_basic">AuthBasicProvider</directive>. Lorsqu'elle
+ est invoquée, l'application est censée authentifier le client à
+ l'aide de l'identifiant et du mot de passe de l'utilisateur.
+ Exemple d'application :
+
+<highlight language="perl">
+#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+ die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHENTICATOR";
+ die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
+ die if !$ENV{'REMOTE_PASSWD'};
+ die if !$ENV{'REMOTE_USER'};
+
+ print STDERR "This text is written to the web server error log.\n";
+
+ if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
+ $ENV{'REMOTE_PASSWD'} eq "bar" ) {
+ print "Status: 200\n";
+ print "Variable-AUTHN_1: authn_01\n";
+ print "Variable-AUTHN_2: authn_02\n";
+ print "\n";
+ }
+ else {
+ print "Status: 401\n\n";
+ }
+}
+</highlight>
+
+ Exemple de configuration httpd :
+<highlight language="config">
+AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10102/
+<Location "/protected/">
+ AuthType Basic
+ AuthName "Restricted"
+ AuthBasicProvider FooAuthn
+ Require ...
+</Location>
+</highlight>
+ </dd>
+
+ <dt><em>Type</em> <code>authz</code>, <em>mechanism</em>
+ <code>Require</code></dt>
+ <dd>Dans ce mode, la variable <code>FCGI_ROLE</code> est définie à
+ <code>AUTHORIZER</code> et <code>FCGI_APACHE_ROLE</code> à
+ <code>AUTHORIZER</code>. L'application doit être spécifiée en tant
+ que fournisseur de type <em>authz</em> via la directive <directive
+ module="mod_authnz_fcgi">AuthnzFcgiDefineProvider</directive>.
+ Lorsqu'elle est invoquée, l'application est censée contrôler les
+ accès du client à l'aide de l'identifiant utilisateur et d'autres
+ données contenues dans la requête. Exemple d'application :
+<highlight language="perl">
+#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+ die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHORIZER";
+ die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
+ die if $ENV{'REMOTE_PASSWD'};
+
+ print STDERR "This text is written to the web server error log.\n";
+
+ if ($ENV{'REMOTE_USER'} eq "foo1") {
+ print "Status: 200\n";
+ print "Variable-AUTHZ_1: authz_01\n";
+ print "Variable-AUTHZ_2: authz_02\n";
+ print "\n";
+ }
+ else {
+ print "Status: 403\n\n";
+ }
+}
+</highlight>
+
+ Exemple de configuration httpd :
+<highlight language="config">
+AuthnzFcgiDefineProvider authz FooAuthz fcgi://localhost:10103/
+<Location "/protected/">
+ AuthType ...
+ AuthName ...
+ AuthBasicProvider ...
+ Require FooAuthz
+</Location>
+</highlight>
+ </dd>
+
+ <dt><em>Type</em> <code>authnz</code>, <em>mechanism</em>
+ <code>AuthBasicProvider</code> <em>+</em> <code>Require</code></dt>
+
+ <dd>Dans ce mode qui supporte le protocole d'autorisation web
+ server-agnostic FastCGI, la variable <code>FCGI_ROLE</code> est
+ définie à <code>AUTHORIZER</code> et <code>FCGI_APACHE_ROLE</code>
+ n'est pas définie. L'application doit être spécifiée en tant que
+ fournisseur de type <em>authnz</em> via la directive <directive
+ module="mod_authnz_fcgi">AuthnzFcgiDefineProvider</directive>.
+ L'application est censée assurer l'authentification et
+ l'autorisation au cours d'une même invocation à l'aide de
+ l'identifiant et du mot de passe de l'utilisateur et d'autres
+ données contenues dans la requête. L'invocation de l'application
+ intervient au cours de la phase d'authentification de l'API Apache
+ httpd. Si l'application renvoie le code 200, et si le même
+ fournisseur est invoqué au cours de la phase d'autorisation (via
+ une directive <directive>Require</directive>), mod_authnz_fcgi
+ renverra un code de type success pour la phase d'autorisation sans
+ invoquer l'application. Exemple d'application :
+<highlight language="perl">
+#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+ die if $ENV{'FCGI_APACHE_ROLE'};
+ die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
+ die if !$ENV{'REMOTE_PASSWD'};
+ die if !$ENV{'REMOTE_USER'};
+
+ print STDERR "This text is written to the web server error log.\n";
+
+ if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
+ $ENV{'REMOTE_PASSWD'} eq "bar" &&
+ $ENV{'REQUEST_URI'} =~ m%/bar/.*%) {
+ print "Status: 200\n";
+ print "Variable-AUTHNZ_1: authnz_01\n";
+ print "Variable-AUTHNZ_2: authnz_02\n";
+ print "\n";
+ }
+ else {
+ print "Status: 401\n\n";
+ }
+}
+</highlight>
+
+ Exemple de configuration httpd :
+<highlight language="config">
+AuthnzFcgiDefineProvider authnz FooAuthnz fcgi://localhost:10103/
+<Location "/protected/">
+ AuthType Basic
+ AuthName "Restricted"
+ AuthBasicProvider FooAuthnz
+ Require FooAuthnz
+</Location>
+</highlight>
+ </dd>
+
+ <dt><em>Type</em> <code>authn</code>, <em>mechanism</em>
+ <code>check_user_id</code></dt>
+
+ <dd>Dans ce mode, la variable <code>FCGI_ROLE</code> est définie à
+ <code>AUTHORIZER</code> et <code>FCGI_APACHE_ROLE</code> à
+ <code>AUTHENTICATOR</code>. L'application doit être spécifiée en
+ tant que fournisseur de type <em>authn</em> via une directive
+ <directive
+ module="mod_authnz_fcgi">AuthnzFcgiDefineProvider</directive>. La
+ directive <directive
+ module="mod_authnz_fcgi">AuthnzFcgiCheckAuthnProvider</directive>
+ permet de l'invoquer. Exemple d'application :
+<highlight language="perl">
+#!/usr/bin/perl
+use FCGI;
+my $request = FCGI::Request();
+while ($request->Accept() >= 0) {
+ die if $ENV{'FCGI_APACHE_ROLE'} ne "AUTHENTICATOR";
+ die if $ENV{'FCGI_ROLE'} ne "AUTHORIZER";
+
+ # This authorizer assumes that the RequireBasicAuth option of
+ # AuthnzFcgiCheckAuthnProvider is On:
+ die if !$ENV{'REMOTE_PASSWD'};
+ die if !$ENV{'REMOTE_USER'};
+
+ print STDERR "This text is written to the web server error log.\n";
+
+ if ( ($ENV{'REMOTE_USER' } eq "foo" || $ENV{'REMOTE_USER'} eq "foo1") &&
+ $ENV{'REMOTE_PASSWD'} eq "bar" ) {
+ print "Status: 200\n";
+ print "Variable-AUTHNZ_1: authnz_01\n";
+ print "Variable-AUTHNZ_2: authnz_02\n";
+ print "\n";
+ }
+ else {
+ print "Status: 401\n\n";
+ # If a response body is written here, it will be returned to
+ # the client.
+ }
+}
+</highlight>
+
+ Exemple de configuration httpd :
+<highlight language="config">
+AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10103/
+<Location "/protected/">
+ AuthType ...
+ AuthName ...
+ AuthnzFcgiCheckAuthnProvider FooAuthn \
+ Authoritative On \
+ RequireBasicAuth Off \
+ UserExpr "%{reqenv:REMOTE_USER}"
+ Require ...
+</Location>
+</highlight>
+ </dd>
+
+ </dl>
+
+</section>
+
+<section id="examples"><title>Exemples supplémentaires</title>
+
+ <ol>
+ <li>Si votre application supporte séparément les rôles
+ d'authentification et d'autorisation (<code>AUTHENTICATOR</code> et
+ <code>AUTHORIZER</code>), vous pouvez définir des fournisseurs
+ séparés comme suit, même s'ils correspondent à la même application :
+
+<highlight language="config">
+AuthnzFcgiDefineProvider authn FooAuthn fcgi://localhost:10102/
+AuthnzFcgiDefineProvider authz FooAuthz fcgi://localhost:10102/
+</highlight>
+
+ Spécifie le fournisseur authn via la directive
+ <directive module="mod_auth_basic">AuthBasicProvider</directive>
+ et le fournisseur authz via la directive
+ <directive module="mod_authz_core">Require</directive>:
+
+<highlight language="config">
+AuthType Basic
+AuthName "Restricted"
+AuthBasicProvider FooAuthn
+Require FooAuthz
+</highlight>
+ </li>
+
+ <li>Si votre application supporte le rôle générique
+ <code>AUTHORIZER</code> (authentification et autorisation en une
+ seule invocation), vous pouvez définir un fournisseur unique comme
+ suit :
+
+<highlight language="config">
+AuthnzFcgiDefineProvider authnz FooAuthnz fcgi://localhost:10103/
+</highlight>
+
+ Spécifie le fournisseur authnz via les directives
+ <directive>AuthBasicProvider</directive> et
+ <directive>Require</directive> :
+
+<highlight language="config">
+AuthType Basic
+AuthName "Restricted"
+AuthBasicProvider FooAuthnz
+Require FooAuthnz
+</highlight>
+ </li>
+</ol>
+</section>
+
+<section id="limitations"><title>Limitations</title>
+
+ <p>Les fonctionnalités suivantes ne sont pas encore implémentées :</p>
+
+ <dl>
+ <dt>Vérificateur d'accès d'Apache httpd</dt>
+ <dd>La phase <em>access check</em> de l'API Apache httpd est
+ distincte des phases d'authentification et d'autorisation.
+ Certaines autres implémentations de FastCGI supportent cette phase
+ et lorsque c'est le cas, la variable <code>FCGI_APACHE_ROLE</code>
+ est définie à <code>ACCESS_CHECKER</code>.</dd>
+
+ <dt>Redirections (pipes) ou sockets locaux (Unix)</dt>
+ <dd>Seuls les sockets TCP sont actuellement supportés.</dd>
+
+ <dt>Support de mod_authn_socache</dt>
+ <dd>Le support de l'interaction avec mod_authn_socache pour les
+ applications qui interviennent dans le processus
+ d'authentification d'Apache httpd serait souhaitable.</dd>
+
+ <dt>Support de l'authentification de type digest à l'aide de AuthDigestProvider</dt>
+ <dd>Cette limitation ne sera probablement jamais franchie car il
+ n'existe aucun flux de données d'autorisation capable de lire dans
+ un condensé de type hash.</dd>
+
+ <dt>Gestion des processus applicatifs</dt>
+ <dd>Cette fonctionnalité restera probablement hors de portée de ce
+ module. Il faudra donc gérer les processus applicatifs d'une autre
+ manière ; par exemple, <program>fcgistarter</program> permet de
+ les démarrer.</dd>
+
+ <dt>AP_AUTH_INTERNAL_PER_URI</dt>
+ <dd>Tous les fournisseurs sont actuellement enregistrés en tant
+ que AP_AUTH_INTERNAL_PER_CONF, ce qui signifie que les
+ vérifications ne sont pas effectuées pour les
+ sous-requêtes internes avec la même configuration de contrôle
+ d'accès que la requête initiale.</dd>
+
+ <dt>Conversion du jeu de caractères des données de protocole</dt>
+ <dd>Si mod_authnz_fcgi s'exécute dans un environnement de
+ compilation EBCDIC, toutes les données de protocole FastCGI sont
+ écrites en EBCDIC et doivent être disponibles en EBCDIC.</dd>
+
+ <dt>Plusieurs requêtes pour une connexion</dt>
+ <dd>Actuellement, la connexion au fournisseur d'autorisation
+ FastCGI est fermée après chaque phase de traitement. Par exemple,
+ si le fournisseur d'autorisation gère séparément les phases
+ <em>authn</em> et <em>authz</em>, deux connexions seront
+ nécessaires.</dd>
+
+ <dt>Redirection de certains URIs</dt>
+ <dd>Les URIs en provenance des clients ne peuvent pas être
+ redirigés selon une table de redirection, comme avec la directive
+ <directive>ProxyPass</directive> utilisée avec les répondeurs
+ FastCGI.</dd>
+
+ </dl>
+
+</section>
+
+<section id="logging"><title>Journalisation</title>
+
+ <ol>
+ <li>Les erreurs de traitement sont journalisées à un niveau
+ <code>error</code> ou supérieur.</li>
+ <li>Les messages envoyés par l'application sont journalisés au
+ niveau <code>warn</code>.</li>
+ <li>Les messages de deboguage à caractère général sont
+ journalisés au niveau <code>debug</code>.</li>
+ <li>Les variables d'environnement transmises à l'application
+ sont journalisées au niveau <code>trace2</code>. La valeur de la
+ variable <code>REMOTE_PASSWD</code> sera occultée, mais
+ <strong>toute autre donnée sensible sera visible dans le
+ journal</strong>.</li>
+ <li>Toutes les entrées/sorties entre le module et l'application
+ FastCGI, y compris les variables d'environnement, seront
+ journalisées au format imprimable et hexadécimal au niveau
+ <code>trace5</code>. <strong>Toutes les données sensibles seront
+ visibles dans le journal.</strong></li>
+ </ol>
+
+ <p>La directive <directive module="core">LogLevel</directive> permet
+ de configurer un niveau de journalisation spécifique à
+ mod_authnz_fcgi. Par exemple :</p>
+
+<highlight language="config">
+LogLevel info authnz_fcgi:trace8
+</highlight>
+
+</section>
+
+<directivesynopsis>
+<name>AuthnzFcgiDefineProvider</name>
+<description>Définit une application FastCGI en tant que fournisseur
+d'authentification et/ou autorisation</description>
+<syntax>AuthnzFcgiDefineProvider <em>type</em> <em>provider-name</em>
+<em>backend-address</em></syntax>
+<default>none</default>
+<contextlist><context>server config</context></contextlist>
+<usage>
+ <p>Cette directive permet de définir une application FastCGI en tant
+ que fournisseur pour une phase particulière d'authentification ou
+ d'autorisation.</p>
+
+ <dl>
+ <dt><em>type</em></dt>
+ <dd>Les valeurs de ce paramètre sont <em>authn</em> pour
+ l'authentification, <em>authz</em> pour l'autorisation, ou
+ <em>authnz</em> pour un fournisseur d'autorisation générique
+ FastCGI qui effectue les deux vérifications.</dd>
+
+ <dt><em>provider-name</em></dt>
+ <dd>Ce paramètre permet d'associer un nom au fournisseur ; ce nom
+ pourra être utilisé dans des directives comme <directive
+ module="mod_auth_basic">AuthBasicProvider</directive> et
+ <directive module="mod_authz_core">Require</directive>.</dd>
+
+ <dt><em>backend-address</em></dt>
+ <dd>Ce paramètre permet de spécifier l'adresse de l'application
+ sous la forme <em>fcgi://hostname:port/</em>. Le ou les processus
+ de l'application doivent être gérés indépendamment comme avec
+ <program>fcgistarter</program>.</dd>
+ </dl>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>AuthnzFcgiCheckAuthnProvider</name>
+<description>Permet à une application FastCGI de gérer l'accroche
+d'authentification check_authn.</description>
+<syntax>AuthnzFcgiCheckAuthnProvider <em>provider-name</em>|<code>None</code>
+<em>option</em> ...</syntax>
+<default>none</default>
+<contextlist><context>directory</context></contextlist>
+<usage>
+ <p>Cette directive permet de confier à une application FastCGI la
+ gestion d'une phase spécifique du processus d'authentification ou
+ d'autorisation.</p>
+
+ <p>Certaines fonctionnalités des fournisseurs d'autorisation FastCGI
+ nécessitent cette directive en lieu et place de
+ <directive>AuthBasicProvider</directive> pour pouvoir être activées :</p>
+
+ <ul>
+ <li>L'authentification de type autre que basique ; en général,
+ détermination de l'identifiant utilisateur et renvoi de sa valeur
+ depuis le fournisseur d'autorisation ; voir l'option
+ <code>UserExpr</code> ci-dessous</li>
+ <li>Sélection d'un code de réponse personnalisé ; en cas de
+ code de réponse autre que 200 en provenance du fournisseur
+ d'autorisation, c'est ce code qui sera utilisé comme code d'état
+ de la réponse</li>
+ <li>Définition du corps d'une réponse autre que 200 ; si le
+ fournisseur d'autorisation renvoie un corps de réponse avec un
+ code autre que 200, c'est ce corps de réponse qui sera renvoyé au
+ client ; la longueur du texte est limitée à 8192 octets</li>
+ </ul>
+
+ <dl>
+ <dt><em>provider-name</em></dt>
+ <dd>C'est le nom du fournisseur défini au préalable via la
+ directive <directive>AuthnzFcgiDefineProvider</directive>.</dd>
+
+ <dt><code>None</code></dt>
+ <dd>Spécifiez <code>None</code> pour désactiver un fournisseur
+ activé avec cette même directive dans une autre portée, par
+ exemple dans un répertoire parent.</dd>
+
+ <dt><em>option</em></dt>
+ <dd>Les options suivantes sont supportées :
+
+ <dl>
+ <dt>Authoritative On|Off (par défaut On)</dt>
+ <dd>Cette option permet de définir si l'appel à d'autres
+ modules est autorisé lorsqu'un fournisseur d'autorisation FastCGI a
+ été configuré et si la requête échoue.</dd>
+
+ <dt>DefaultUser <em>id utilisateur</em></dt>
+ <dd>Lorsque le fournisseur d'autorisation donne son accord, et
+ si <code>UserExpr</code> est défini et correspond à une chaîne
+ vide, (par exemple, si le fournisseur d'autorisation ne renvoie
+ aucune variable), c'est cette valeur qui sera utilisée comme id
+ utilisateur par défaut. Cela se produit souvent lorsqu'on se trouve dans
+ un contexte d'invité, ou d'utilisateur non authentifié ;
+ les utilisateurs et invités se voient alors attribué un id
+ utilisateur spécifique qui permettra de se connecter et
+ d'accéder à certaines ressources.</dd>
+
+ <dt>RequireBasicAuth On|Off (par défaut Off)</dt>
+ <dd>Cette option permet de définir si l'authentification
+ basique est requise avant de transmettre la requête au
+ fournisseur d'autorisation. Dans l'affirmative, le fournisseur
+ d'autorisation ne sera invoqué qu'en présence d'un id
+ utilisateur et d'un mot de passe ; si ces deux éléments ne sont
+ pas présents, un code d'erreur 401 sera renvoyé</dd>
+
+ <dt>UserExpr <em>expr</em> (pas de valeur par défaut)</dt>
+ <dd>Lorsque le client ne fournit pas l'authentification basique
+ et si le fournisseur d'autorisation détermine l'id utilisateur,
+ cette expression, évaluée après l'appel au fournisseur
+ d'autorisation, permet de déterminer l'id utilisateur. Cette
+ expression se conforme à la <a href="../expr.html">syntaxe
+ ap_expr</a> et doit correspondre à une chaîne de caractères.
+ Une utilisation courante consiste à référencer la définition
+ d'une <code>Variable-<em>XXX</em></code> renvoyée par le
+ fournisseur d'autorisation via une option du style
+ <code>UserExpr "%{reqenv:<em>XXX</em>}"</code>. Si cette option
+ est spécifiée, et si l'id utilisateur ne peut pas être définie
+ via l'expression après une authentification réussie, la requête
+ sera rejetée avec un code d'erreur 500.</dd>
+
+ </dl>
+ </dd>
+ </dl>
+</usage>
+</directivesynopsis>
+
+</modulesynopsis>
--- /dev/null
+<?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 : 1794162 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_brotli.xml.meta">
+
+<name>mod_brotli</name>
+<description>Compression du contenu via Brotli avant sa livraison au client</description>
+<status>Extension</status>
+<sourcefile>mod_brotli.c</sourcefile>
+<identifier>brotli_module</identifier>
+<compatibility>Disponible à partir de la version 2.4.26 du serveur HTTP Apache</compatibility>
+
+<summary>
+ <p>Le module <module>mod_brotli</module> fournit le filtre en sortie
+ <code>BROTLI_COMPRESS</code> qui permet de compresser un contenu avant sa
+ livraison au client en utilisant la bibliothèque brotli. Ce filtre est
+ implémenté en utilisant la bibliothèque Brotli que l'on peut trouver à <a
+ href="https://github.com/google/brotli">https://github.com/google/brotli</a>.</p>
+</summary>
+<seealso><a href="../filter.html">Filters</a></seealso>
+
+<section id="recommended"><title>Exemples de configurations</title>
+ <note type="warning"><title>Compression et TLS</title>
+ <p>Certaines applications web sont vulnérables à une attaque de type vol
+ d'informations lorsqu'une connexion TLS transmet des données
+ compressées. Pour plus d'informations, étudiez en détail la famille
+ d'attaques "BREACH".</p>
+ </note>
+ <p>Voici une configuration simple qui compresse des types de contenus
+ courants au format texte :</p>
+
+ <example><title>Compression de certains types seulement</title>
+ <highlight language="config">
+AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/xml text/css text/javascript application/javascript
+ </highlight>
+ </example>
+
+</section>
+
+<section id="enable"><title>Activation de la compression</title>
+ <note type="warning"><title>Compression et TLS</title>
+ <p>Certaines applications web sont vulnérables à une attaque de type vol
+ d'informations lorsqu'une connexion TLS transmet des données
+ compressées. Pour plus d'informations, étudiez en détail la famille
+ d'attaques "BREACH".</p>
+ </note>
+
+ <section id="output"><title>Compression en sortie</title>
+ <p>La compression est implémentée par le <a
+ href="../filter.html">filtre</a> <code>BROTLI_COMPRESS</code>. La
+ directive suivante active la compression pour les documents correspondant
+ au conteneur dans lequel elle est placée :</p>
+
+ <highlight language="config">
+SetOutputFilter BROTLI_COMPRESS
+SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-brotli
+ </highlight>
+
+ <p>Si vous voulez restreindre la compression à certains types MIME
+ particuliers, vous pouvez utiliser la directive <directive
+ module="mod_filter">AddOutputFilterByType</directive>. Dans l'exemple
+ suivant, l'activation de la compression est restreinte aux fichiers html
+ de la documentation d'Apache :</p>
+
+ <highlight language="config">
+<Directory "/your-server-root/manual">
+ AddOutputFilterByType BROTLI_COMPRESS text/html
+</Directory>
+ </highlight>
+
+ <note><title>Note</title>
+ Le filtre <code>BROTLI_COMPRESS</code> est toujours inséré après les
+ filtres RESOURCE comme PHP ou SSI. Il n'affecte jamais les sous-requêtes
+ internes.
+ </note>
+ <note><title>Note</title>
+ Définie via <directive module="mod_env">SetEnv</directive>, la variable
+ d'environnement <code>no-brotli</code> permet de désactiver la
+ compression brotli pour une requête particulière, et ceci même si elle
+ est supportée par le client.
+ </note>
+
+ </section>
+
+</section>
+
+<section id="proxies"><title>Interaction avec les serveurs mandataires</title>
+
+ <p>Le module <module>mod_brotli</module> envoie un en-tête de réponse HTTP
+ <code>Vary:Accept-Encoding</code> pour indiquer aux mandataires qu'une
+ réponse mise en cache ne doit être envoyée qu'aux clients qui envoient
+ l'en-tête de requête <code>Accept-Encoding</code> approprié. Ceci permet
+ d'éviter d'envoyer du contenu compressé à un client qui ne sera pas en
+ mesure de le décompresser.</p>
+
+ <p>Si vous utilisez des exclusions spéciales dépendant, par exemple, de
+ l'en-tête <code>User-Agent</code>, vous devez faire un ajout manuel à
+ l'en-tête <code>Vary</code> afin d'informer les mandataires des restrictions
+ supplémentaires. Par exemple, dans une configuration typique où l'addition
+ du filtre <code>BROTLI_COMPRESS</code> dépend de l'en-tête <code>User-Agent</code>,
+ vous devez ajouter :</p>
+
+ <highlight language="config">
+Header append Vary User-Agent
+ </highlight>
+
+ <p>Si votre décision d'utiliser la compression ou non dépend d'autres
+ informations que le contenu d'en-têtes de requêtes (par exemple la version
+ HTTP), vous devez affecter la valeur <code>*</code> à l'en-tête
+ <code>Vary</code>. Ceci permet d'éviter que des mandataires qui le
+ supportent n'effectuent une mise en cache intégrale.</p>
+
+ <example><title>Exemple</title>
+ <highlight language="config">
+Header set Vary *
+ </highlight>
+ </example>
+</section>
+
+<section id="precompressed"><title>Servir un contenu pré-compressé</title>
+
+ <p>comme <module>mod_brotli</module> compresse systématiquement un contenu
+ pour chaque requête le concernant, il est possible d'obtenir un gain en
+ performance en pré-compressant le contenu et en disant à mod_brotli de le
+ servir sans le recompresser. Pour cela, vous pouvez utiliser une
+ configuration du style :</p>
+
+ <highlight language="config">
+<IfModule mod_headers.c>
+ # Sert des fichiers CSS compressés par brotli, s'ils existent
+ # et si le client supporte brotli.
+ RewriteCond "%{HTTP:Accept-encoding}" "br"
+ RewriteCond "%{REQUEST_FILENAME}\.br" "-s"
+ RewriteRule "^(.*)\.css" "$1\.css\.br" [QSA]
+
+ # Sert des fichiers JS compressés par brotli, s'ils existent
+ # et si le client supporte brotli.
+ RewriteCond "%{HTTP:Accept-encoding}" "br"
+ RewriteCond "%{REQUEST_FILENAME}\.br" "-s"
+ RewriteRule "^(.*)\.js" "$1\.js\.br" [QSA]
+
+
+ # Sert des types de contenu corrects, et évite la double compression.
+ RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-brotli:1]
+ RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-brotli:1]
+
+
+ <FilesMatch "(\.js\.br|\.css\.br)$">
+ # Sert un type d'encodage correct.
+ Header append Content-Encoding br
+
+ # Force les mandataires à mettre en cache séparément les fichiers css/js
+ # compressés ou non par brotli.
+ Header append Vary Accept-Encoding
+ </FilesMatch>
+</IfModule>
+ </highlight>
+
+</section>
+
+<directivesynopsis>
+<name>BrotliFilterNote</name>
+<description>Enregistre le taux de compression dans une note à des fins de
+journalisation</description>
+<syntax>BrotliFilterNote [<var>type</var>] <var>notename</var></syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive>BrotliFilterNote</directive> permet d'indiquer
+ qu'une note à propos du taux de compression doit être attachée à la
+ requête. L'argument <var>notename</var> permet de spécifier le nom de la
+ note. Vous pouvez utiliser cette note à des fins de statistiques en ajoutant
+ l'information correspondante à votre <a href="../logs.html#accesslog">access
+ log</a>.</p>
+
+ <example><title>Exemple</title>
+ <highlight language="config">
+BrotliFilterNote ratio
+
+LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' brotli
+CustomLog "logs/brotli_log" brotli
+ </highlight>
+ </example>
+
+ <p>Si vous souhaitez que l'information enregistrée dans vos journaux soit
+ plus pertinente, vous pouvez renseigner l'argument optionnel <var>type</var>
+ afin de spécifier le type de données à enregistrer dans la note à
+ journaliser. L'argument <var>type</var> accepte les valeurs suivantes :</p>
+
+ <dl>
+ <dt><code>Input</code></dt>
+ <dd>Enregistre dans la note le nombre d'octets contenus dans le flux
+ d'entrée du filtre.</dd>
+
+ <dt><code>Output</code></dt>
+ <dd>Enregistre dans la note le nombre d'octets contenus dans le flux
+ de sortie du filtre.</dd>
+
+ <dt><code>Ratio</code></dt>
+ <dd>Enregistre dans la note le taux de compression (<code>output/input *
+ 100</code>). Il s'agit de l'option par défaut si l'argument
+ <var>type</var> est omis.</dd>
+ </dl>
+
+ <p>Vous pouvez alors configurer vos journaux de la manière suivante :</p>
+
+ <example><title>Journalisation spécifique</title>
+ <highlight language="config">
+BrotliFilterNote Input instream
+BrotliFilterNote Output outstream
+BrotliFilterNote Ratio ratio
+
+LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' brotli
+CustomLog "logs/brotli_log" brotli
+ </highlight>
+ </example>
+</usage>
+<seealso><module>mod_log_config</module></seealso>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>BrotliCompressionQuality</name>
+<description>Qualité de la compression</description>
+<syntax>BrotliCompressionQuality <var>value</var></syntax>
+<default>BrotliCompressionQuality 5</default>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive>BrotliCompressionQuality</directive> permet de
+ spécifier la qualité de la compression (une valeur entre 0 et
+ 11). Les valeurs les plus hautes correspondent à une compression de
+ meilleure qualité mais plus lente.
+ </p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>BrotliCompressionWindow</name>
+<description>Taille de la fenêtre de compression glissante brotli</description>
+<syntax>BrotliCompressionWindow <var>value</var></syntax>
+<default>BrotliCompressionWindow 18</default>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive>BrotliCompressionWindow</directive> permet de
+ spécifier la taille de la fenêtre de compression glissante brotli (une
+ valeur comprise entre 10 et 24). Une taille de fenêtre plus grande peut
+ améliorer la qualité de la compression mais consomme d'avantage de mémoire.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+
+<name>BrotliCompressionMaxInputBlock</name>
+<description>Taille maximale du bloc de données en entrée</description>
+<syntax>BrotliCompressionMaxInputBlock <var>value</var></syntax>
+<default>(automatic)</default>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive>BrotliCompressionMaxInputBlock</directive> permet
+ de spécifier la taille maximale du bloc de données en entrée entre 16 et 24,
+ sachant que plus cette taille sera grande, plus grande sera la quantité de
+ mémoire consommée.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>BrotliAlterETag</name>
+<description>Comment l'en-tête de réponse ETag doit être modifié au cours de la
+compression</description>
+<syntax>BrotliAlterETag AddSuffix|NoChange|Remove</syntax>
+<default>BrotliAlterETag AddSuffix</default>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive>BrotliAlterETag</directive> permet d'indiquer
+ comment l'en-tête ETag doit être modifié lorsqu'une réponse est compressée.</p>
+ <dl>
+ <dt>AddSuffix</dt>
+ <dd><p>Ajoute la méthode de compression à la fin de l'en-tête ETag, ce qui
+ implique que les représentations compressées et non compressées possèderont
+ des en-têtes ETag uniques. C'était le comportement par défaut depuis la
+ version 2.4.0 avec un autre module de compression dynamique,
+ mod-deflate. Ce paramètre permet d'éviter l'envoi de messages
+ "HTTP Not Modified" (304) en réponse aux requêtes conditionnelles pour des
+ contenus compressés.</p></dd>
+ <dt>NoChange</dt>
+ <dd><p>Ne modifie pas l'en-tête ETag d'une réponse compressée. C'était le
+ comportement par défaut depuis la version 2.4.0 avec un autre module de
+ compression dynamique, mod-deflate. Ce paramètre ne respecte pas la
+ propriété HTTP/1.1 selon laquelle toutes les représentations d'une même
+ ressource ont des en-têtes ETag uniques.</p></dd>
+ <dt>Remove</dt>
+ <dd><p>Supprime l'en-tête ETag des réponses compressées, ce qui rend
+ impossibles certaines requêtes conditionnelles, mais évite les inconvénients
+ des options précédentes.</p></dd>
+ </dl>
+</usage>
+</directivesynopsis>
+
+</modulesynopsis>
--- /dev/null
+<?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 : 1798481 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+ -->
+
+<modulesynopsis metafile="mod_http2.xml.meta">
+
+ <name>mod_http2</name>
+ <description>Support de la couche transport HTTP/2</description>
+ <status>Extension</status>
+ <sourcefile>mod_http2.c</sourcefile>
+ <identifier>http2_module</identifier>
+ <compatibility>Disponible à partir de la version 2.4.17 du serveur
+ HTTP Apache</compatibility>
+
+ <summary>
+ <p>Ce module ajoute le support de HTTP/2 (<a
+ href="https://tools.ietf.org/html/rfc7540">RFC 7540</a>) au serveur HTTP
+ Apache.</p>
+
+ <p>Il s'appuie sur la bibliothèque <a
+ href="http://nghttp2.org/">libnghttp2</a> pour implémenter le
+ moteur de base http/2.</p>
+
+ <p>Pour mettre en oeuvre les fonctionnalités décrites dans ce
+ document, vous devez activer HTTP/2 en utilisant la directive
+ <directive module="core">Protocols</directive>. HTTP/2 <a
+ href="https://http2.github.io/faq/#does-http2-require-encryption">n'imposant
+ pas</a> de chiffrement, deux protocoles sont disponibles :
+ <code>h2</code> (HTTP/2 avec TLS) at <code>h2c</code> (HTTP/2 avec TCP).</p>
+
+ <p>Voici deux types de configuration courant :</p>
+
+ <note><title>HTTP/2 dans un contexte de serveur virtuel (TLS seulement)</title>
+ <highlight language="config">
+ Protocols h2 http/1.1
+ </highlight>
+ <p>Permet une négociation HTTP/2 (h2) via TLS ALPN au sein d'un
+ <directive module="core" type="section">VirtualHost</directive>
+ sécurisé. La vérification du préambule HTTP/2 (mode direct, voir
+ <directive module="mod_http2">H2Direct</directive>) est désactivée par
+ défaut pour <code>h2</code>.</p>
+ </note>
+
+ <note><title>HTTP/2 dans un contexte de serveur (TLS et texte pur)</title>
+ <highlight language="config">
+Protocols h2 h2c http/1.1
+ </highlight>
+ <p>Permet une négociation HTTP/2 (h2) via TLS ALPN au sein d'un
+ <directive module="core" type="section">VirtualHost</directive>
+ sécurisé. Permet aussi une négociation HTTP/2 en texte pur (h2c) en
+ effectuant une mise à jour depuis une connexion initiale HTTP/1.1 ou via
+ une vérification du préambule HTTP/2 (mode direct, voir
+ <directive module="mod_http2">H2Direct</directive>).</p>
+ </note>
+
+ <p>Si vous avez besoin d'informations supplémentaires à propos du
+ protocole, veuillez vous reporter à la <a
+ href="https://http2.github.io/faq">HTTP/2 FAQ</a>.</p>
+
+
+ </summary>
+
+ <section id="how-it-works"><title>Comment ça marche ?</title>
+
+ <section id="dimensioning"><title>Quantification des ressources
+ supplémentaires nécessaires à HTTP/2</title>
+ <p>
+ Activer HTTP/2 sur votre serveur Apache a un impact sur la
+ consommation de ressources, et si votre site est très actif, il est
+ conseillé d'en prendre sérieusement en compte les implications.
+ </p>
+ <p>
+ HTTP/2 attribue à chaque requête qu'il reçoit son propre <em>thread
+ de travail</em> pour son traitement, la collecte des résultats et
+ l'envoie de ces derniers au client. Pour y parvenir, il lui faut
+ lancer des threads supplémentaires, et ceci constituera le premier
+ effet notable de l'activation de HTTP/2.
+ </p>
+ <p>
+ Dans l'implémentation actuelle, ces threads de travail font partie
+ d'un jeu de threads distinct de celui des threads de travail du MPM
+ avec lequel vous êtes familié. Il s'agit simplement du mode de
+ fonctionnement actuel, et il n'en sera pas obligatoirement toujours
+ ainsi (il est cependant probable que la situation restera inchangée
+ avec la version 2.4.x). De par ce mode de fonctionnement, les
+ threads de travail HTTP/2, ou plus simplement H2 ne seront pas
+ affichés par <module>mod_status</module>. De même, ils ne seront pas
+ pris en compte par les directives du style <directive
+ module="mpm_common">ThreadsPerChild</directive>. Par contre, ils
+ utilisent par défaut la valeur de <directive
+ module="mpm_common">ThreadsPerChild</directive> si vous n'avez pas
+ spécifié d'autres valeurs via <directive
+ module="mod_http2">H2MinWorkers</directive> et <directive
+ module="mod_http2">H2MaxWorkers</directive>.
+ </p>
+ <p>
+ Autre changement à surveiller : la consommation de mémoire. En
+ effet, comme HTTP/2 conserve plus d'informations sur le serveur pour
+ gérer toutes les requêtes en cours, leurs priorités et
+ interdépendances, il aura toujours besoin de plus de mémoire que
+ pour un traitement en HTTP/1.1. Trois directives permettent de
+ limiter l'empreinte mémoire d'une connexion HTTP/2 : <directive
+ module="mod_http2">H2MaxSessionStreams</directive>, <directive
+ module="mod_http2">H2WindowSize</directive> et <directive
+ module="mod_http2">H2StreamMaxMemSize</directive>.
+ </p>
+ <p>
+ La directive <directive
+ module="mod_http2">H2MaxSessionStreams</directive> permet de limiter
+ le nombre de requêtes simultanées qu'un client peut envoyer sur une
+ connexion HTTP/2. La valeur que vous allez définir dépend de votre
+ site. La valeur par défaut qui est de 100 est largement suffisante,
+ et à moins que vous ne soyez un peu juste en mémoire, je vous
+ conseille de ne pas la modifier. La plupart des requêtes qu'envoie
+ un client sont des requêtes de type GET sans corps qui n'utilisent
+ que très peu de mémoire en attendant le démarrage du traitement.
+
+ </p>
+ <p>
+ La directive <directive module="mod_http2">H2WindowSize</directive>
+ permet de définir la taille maximale que peut avoir le corps d'une
+ requête que le client envoie avant d'attendre que le serveur
+ en demande d'avantage. En d'autres termes, il s'agit de la quantité
+ de données que le serveur peut stocker dans son tampon, valable pour
+ une requête.
+ </p>
+ <p>
+ En outre, la directive <directive
+ module="mod_http2">H2StreamMaxMemSize</directive> permet de définir
+ la quantité de données de la réponse qui doit être mise en tampon.
+ Chaque requête étant prise en charge par un thread H2Worker et
+ produisant des données que le serveur tente de transmettre au client
+ via une connexion HTTP/2, si le client n'est pas en mesure de lire
+ ces données assez rapidement, la connexion les mettra en tampon et
+ interrompra l'exécution du thread H2Worker correspondant.
+ </p>
+
+ </section>
+
+ <section id="misdirected"><title>Serveurs virtuels et requêtes mal
+ redirigées</title>
+ <p>
+ De nombreux site utilisent le même certificat TLS pour plusieurs
+ serveurs virtuels. Ce certificat référence un nom de serveur
+ générique comme '*.example.org' ou plusieurs noms de serveur
+ différents. Les navigateurs qui utilisent HTTP/2 détectent ce
+ comportement et réutilisent une connexion déjà ouverte pour ces
+ serveurs.
+ </p>
+ <p>
+ Ceci améliore considérablement les performances, mais il y a un prix
+ à payer : il faut accorder un soin tout particulier à la
+ configuration de tels serveurs virtuels. Le problème réside dans le
+ fait que plusieurs requêtes pour plusieurs serveurs virtuels vont se
+ partager la même connexion TLS, et ceci empêche toute renégociation
+ car le standard HTTP/2 l'interdit.
+ </p>
+ <p>
+ Ainsi, lorsque plusieurs de vos serveurs virtuels utilisent le même
+ certificat et si vous souhaitez utiliser HTTP/2 pour y accéder, vous
+ devez vous assurer que tous vos serveurs virtuels possèdent
+ exactement la même configuration SSL. En particulier, ils doivent
+ utiliser les mêmes protocole, algorithme de chiffrement et
+ configuration pour la vérification du client.
+ </p>
+ <p>
+ Dans le cas contraire, Apache httpd le détectera et renverra au
+ client un code de réponse spécial, 421 Misdirected Request.
+ </p>
+ </section>
+
+ <section id="envvars"><title>Variables d'environnement</title>
+
+ <p>Ce module peut être configuré pour fournir des informations en
+ rapport avec HTTP/2 sous la forme de variables d'environnement
+ supplémentaires dans l'espace de nommage SSI et CGI, ainsi que dans les
+ configurations personnalisées de le journalisation (voir
+ <code>%{VAR_NAME}e</code>).
+ </p>
+
+ <table border="1">
+ <columnspec><column width=".3"/><column width=".2"/><column width=".5"/>
+ </columnspec>
+ <tr>
+ <th><a name="table3">Nom variable :</a></th>
+ <th>Type :</th>
+ <th>Description :</th>
+ </tr>
+ <tr><td><code>HTTPe</code></td><td>drapeau</td><td>HTTP/2 est utilisé.</td></tr>
+ <tr><td><code>H2PUSH</code></td><td>drapeau</td><td>La
+ fonctionnalité HTTP/2 Server Push est activée pour cette requête et
+ supportée par le client.</td></tr>
+ <tr><td><code>H2_PUSH</code></td><td>drapeau</td><td>autre nom pour <code>H2PUSH</code></td></tr>
+ <tr><td><code>H2_PUSHED</code></td><td>chaîne</td><td>vide ou
+ <code>PUSHED</code> pour une requête pushée par le serveur.</td></tr>
+ <tr><td><code>H2_PUSHED_ON</code></td><td>nombre</td><td>numéro du
+ flux HTTP/2 qui a déclenché le push de cette requête.</td></tr>
+ <tr><td><code>H2_STREAM_ID</code></td><td>nombre</td><td>numéro du
+ flux HTTP/2 de cette requête.</td></tr>
+ <tr><td><code>H2_STREAM_TAG</code></td><td>chaîne</td><td>identifiant
+ de flux unique du processus HTTP/2 composé de l'identifiant de la
+ connexion et de l'identifiant du flux séparés par <code>-</code>.</td></tr>
+ </table>
+ </section>
+
+ </section>
+
+ <directivesynopsis>
+ <name>H2Direct</name>
+ <description>Activation du protocole H2 Direct</description>
+ <syntax>H2Direct on|off</syntax>
+ <default>H2Direct on pour h2c, off pour le protocole h2</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+
+ <usage>
+ <p>
+ Cette directive permet d'activer/désactiver
+ l'utilisation du mode HTTP/2 Direct. Elle doit être
+ située dans une section <directive module="core"
+ type="section">VirtualHost</directive> afin d'activer la
+ communication directe HTTP/2 pour le serveur virtuel
+ considéré.
+ </p>
+ <p>
+ La notion de communication directe signifie que si les
+ premiers octets reçus par le serveur correspondent à un
+ en-tête HTTP/2, le protocole HTTP/2 est utilisé sans
+ négociation supplémentaire. Ce mode est défini pour
+ les transmissions en clair (h2c) dans la RFC 7540. Son
+ utilisation avec les connexions TLS n'est pas
+ officiellement supportée.
+ </p>
+ <p>
+ Lorsque le protocole h2 ou h2c n'est pas activé via la
+ directive <directive module="core">Protocols</directive>, la recherche d'un en-tête HTTP/2 n'est
+ jamais effectuée au sein d'une connexion. La directive
+ <directive>H2Direct</directive> ne produit alors aucun effet. Ceci est
+ important pour les connexions qui utilisent un protocole
+ pour lequel une lecture initiale peut entraîner un
+ blocage définitif comme NNTP.
+ </p>
+ <p>
+ Pour un client qui sait qu'un serveur supporte h2c, la
+ communication directe HTTP/2 dispense le client d'une
+ mise à jour HTTP/1.1, ce qui entraîne une amélioration
+ des performances et évite les restrictions sur les corps
+ de requête suite à une mise à jour.
+ </p>
+ <p>
+ Cette directive rend aussi h2c plus attractif pour les
+ communications de serveur à serveur lorsque la connexion
+ est sure ou peut être sécurisée d'une manière ou d'une
+ autre.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2Direct on
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2Push</name>
+ <description>Activation/désactivation du server push H2</description>
+ <syntax>H2Push on|off</syntax>
+ <default>H2Push on</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <compatibility>Disponible à partir de la version 2.4.18 du serveur HTTP
+ Apache.</compatibility>
+
+ <usage>
+ <p>
+ Cette directive permet d'activer/désactiver
+ l'utilisation de la fonctionnalité server push du
+ protocole HTTP/2.
+ </p>
+ <p>
+ Lorsqu'un client demande une ressource particulière, le
+ protocole HTTP/2 permet au serveur de lui fournir des
+ ressources supplémentaires. Ceci s'avère utile lorsque
+ ces ressources sont reliées entre elles, ce qui peut
+ laisser supposer que le client va probablement les
+ demander dans un délai plus ou moins long. Le mécanisme
+ de pushing permet alors au client d'économiser le temps
+ qu'il lui aurait fallu pour demander ces ressources
+ supplémentaires lui-même. Par contre, fournir au client
+ des ressources dont il n'a pas besoin ou qu'il possède
+ déjà constitue une perte de bande passante.
+ </p>
+ <p>
+ Les server pushes sont détectés en inspectant les
+ en-têtes <code>Link</code> des réponses (voir
+ https://tools.ietf.org/html/rfc5988 pour la
+ spécification). Lorsqu'un lien spécifié de cette manière
+ possède l'attribut <code>rel=preload</code>, il est
+ considéré comme devant faire l'objet d'un push.
+ </p>
+ <p>
+ Les en-têtes link des réponses sont soit définis par
+ l'application, soit configurés via
+ <module>mod_headers</module> comme suit :
+ </p>
+ <example><title>Exemple de configuration d'en-tête link via mod_headers</title>
+ <highlight language="config">
+<Location /index.html>
+ Header add Link "</css/site.css>;rel=preload"
+ Header add Link "</images/logo.jpg>;rel=preload"
+</Location>
+ </highlight>
+ </example>
+ <p>
+ Comme le montre l'exemple, il est possible d'ajouter
+ autant d'en-têtes link que l'on souhaite à une réponse, ce qui déclenchera
+ autant de pushes. Cette fonctionnalité doit donc être
+ utilisée avec prudence car le module ne vérifie pas si
+ une ressource n'a pas déjà été "pushée" vers un client.
+ </p>
+ <p>
+ Les server pushes HTTP/2 sont activés par défaut. Cette
+ directive permet de désactiver cette fonctionnalité pour
+ le serveur virtuel ou non considéré.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2Push off
+ </highlight>
+ </example>
+ <p>
+ Enfin, il est important de savoir que les pushes ne se
+ produisent que si le client en manifeste le désir ; la
+ plupart des navigateurs le font, mais certains, comme
+ Safari 9, ne le font pas. En outre, les pushes ne se produisent que
+ pour les ressources de la même <em>autorité</em> que celle de la
+ réponse originale.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2PushDiarySize</name>
+ <description>Taille du journal des Pushes H2</description>
+ <syntax>H2PushDiarySize n</syntax>
+ <default>H2PushDiarySize 256</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <compatibility>Disponible à partir de la version 2.4.19 du serveur HTTP
+ Apache.</compatibility>
+
+ <usage>
+ <p>
+ Cette directive permet de définir le nombre maximum de pushes
+ qui seront enregistrés pour une connexion HTTP/2. Elle peut être
+ placée dans une section <directive module="core"
+ type="section">VirtualHost</directive> afin de définir le nombre
+ de pushes pour le serveur virtuel considéré.
+ </p>
+ <p>
+ Le journal des pushes enregistre un condensé (sous la forme d'un
+ nombre de 64 bits) des ressources préchargées (leurs URLs) afin
+ d'éviter les duplications de pushes pour une même connexion.
+ Cependant, ces données ne sont pas conservées, et les clients
+ qui ouvrent une nouvelle connexion se verront à nouveau affecter les
+ mêmes pushes. A ce titre, une étude est en cours pour permettre
+ au client de supprimer le condensé des ressources qu'il possède
+ déjà, et par là-même de réinitialiser le journal des pushes à
+ chaque nouvelle connexion.
+ </p>
+ <p>
+ Si la taille maximale est atteinte, les nouvelles entrées
+ remplacent les plus anciennes. Une entrée du journal nécessitant
+ 8 octets, un journal de 256 entrées consomme 2 Ko de mémoire.
+ </p>
+ <p>
+ Si cette directive est définie à 0, le journal des pushes est
+ désactivé.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2PushPriority</name>
+ <description>Priorité des pushes H2</description>
+ <syntax>H2PushPriority mime-type [after|before|interleaved] [weight]</syntax>
+ <default>H2PushPriority * After 16</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <compatibility>Disponible à partir de la version 2.4.18 du serveur HTTP
+ Apache. Nécessite la bibliothèque nghttp2 version 1.5.0 ou supérieure.</compatibility>
+
+ <usage>
+ <p>
+ Cette directive permet de définir une gestion de priorité des
+ pushes en fonction du type de contenu de la réponse. Elle est en
+ général définie au niveau du serveur principal, mais peut aussi
+ l'être au niveau d'un serveur virtuel.
+ </p>
+ <p>
+ Les pushes HTTP/2 sont toujours liés à une requête client.
+ Chaque paire requête/réponse de cette sorte, ou <em>flux</em>,
+ possède une dépendance et un poids qui définissent la
+ <em>priorité</em> du flux.
+ </p>
+ <p>
+ Lorsqu'un flux <em>dépend</em> d'un autre, disons X dépend de Y,
+ alors Y reçoit toute la bande passante avant que X n'en reçoive
+ ne serait-ce qu'une partie. Notez que cela ne signifie en rien
+ que Y bloque X ; en effet, si Y n'a aucune donnée à envoyer,
+ toute la bande passante qui lui est allouée peut être utilisée
+ par X.
+ </p>
+ <p>
+ Lorsque plusieurs flux dépendent d'un même autre flux, disons X1
+ et X2 dépendent tous deux de Y, le <em>poids</em> détermine la
+ bande passante allouée. Ainsi, si X1 et X2 possèdent le même
+ poids, ils recevront tous deux la moitié de la bande passante
+ disponible. Si le poids de X1 est égal au double de celui de X2,
+ X1 recevra une bande passante double de celle de X2.
+
+ </p>
+ <p>
+ En fin de compte, tout flux dépend du flux <em>racine</em> qui
+ reçoit toute la bande passante disponible mais n'envoie jamais
+ de données. Cette bande passante est ainsi répartie entre les flux
+ enfants selon leur poids. Ces derniers l'utilisent alors pour
+ envoyer leurs données ou pour la répartir entre leurs propres
+ flux enfants, et ainsi de suite. Si aucun des flux enfants n'a
+ de données à envoyer, la bande passante est attribuée à d'autres
+ flux selon les mêmes règles.
+ </p>
+ <p>
+ Ce système de priorités a été conçu de façon a toujours pouvoir
+ utiliser la bande passante disponible tout en définissant des
+ priorités et en attribuant des poids aux différents flux. Ainsi,
+ tous les flux sont en général initialisés par le client qui
+ lui-même définit les priorités.
+ </p>
+ <p>
+ Seul le fait de savoir qu'un flux implique un PUSH permet au
+ serveur de décider quelle est la priorité <em>initiale</em> d'un
+ tel flux. Dans les exemples ci-dessous, X est le flux client. Il
+ dépend de Y et le serveur décide de "PUSHer" les flux P1 et P2
+ sur X.
+ </p>
+ <p>
+ La règle de priorité par défaut est :
+ </p>
+ <example><title>Règle de priorité par défaut</title>
+ <highlight language="config">
+ H2PushPriority * After 16
+ </highlight>
+ </example>
+ <p>
+ Elle peut se traduire par "Envoyer un flux PUSH avec tout type
+ de contenu et dépendant du flux client avec le poids 16". P1 et
+ P2 seront alors envoyés après X, et comme leurs poids sont
+ identiques, il se verront allouer la même quantité de bande
+ passante.
+ </p>
+ <example><title>Règle de priorité entrelacée</title>
+ <highlight language="config">
+ H2PushPriority text/css Interleaved 256
+ </highlight>
+ </example>
+ <p>
+ Ce qui peut se traduire par "Envoyer toute ressource CSS dans la
+ même dépendance et avec le même poids que le flux client". Si le
+ type de contenu de P1 est "text/css", il dépendra de Y (comme X)
+ et son poids effectif sera calculé selon la formule : <code>P1ew
+ = Xw * (P1w / 256)</code>. Si P1w est de 256, Le poids effectif
+ de P1 sera le même que celui de X. Si X et P1 ont des données à
+ envoyer, il se verront allouer la même quantité de bande
+ passante.
+ </p>
+ <p>
+ Avec un Pw de 512, un flux entrelacé et PUSHé aura un poids
+ double de celui de X. Avec un poids de 128, son poids ne sera
+ que la moitié de celui de X. Notez que les poids effectifs sont
+ toujours plafonnés à 256.
+
+ </p>
+ <example><title>Règle de priorité Before</title>
+ <highlight language="config">
+ H2PushPriority application/json Before
+ </highlight>
+ </example>
+ <p>
+ Dans cet exemple, tout flux PUSHé dont le contenu est de type
+ 'application/json' sera envoyé <em>avant</em> X, ce qui rend P1
+ dépendant de Y et X dépendant de P1. Ainsi, X sera mis en
+ attente aussi longtemps que P1 aura des données à envoyer. Le
+ poids effectif est hérité du flux client, et l'attribution d'un
+ poids spécifique n'est pas autorisée.
+ </p>
+ <p>
+ Vous devez garder à l'esprit que les spécifications en matière
+ de priorités sont limitées par les ressources disponibles du
+ serveur. Si un serveur ne dispose d'aucun processus/thread de
+ travail pour les flux PUSHés, les données du flux considéré ne
+ seront envoyées que lorsque les autres flux auront terminé
+ l'envoi des leurs.
+ </p>
+ <p>
+ Enfin et surtout, il convient de tenir compte de certaines
+ particularités de la syntaxe de cette directive :
+ </p>
+ <ol>
+ <li>'*' est la seule expression permettant de remplacer tout
+ type de contenu. 'image/*' ne fonctionnera pas.</li>
+ <li>La dépendance par défaut est 'After'.</li>
+ <li>Il existe aussi des poids par défaut : pour 'After' le poids
+ est de 16, alors que pour 'interleaved' il est de 256.
+ </li>
+ </ol>
+ <example><title>Exemples de règles</title>
+ <highlight language="config">
+H2PushPriority application/json 32 # une règle de priorité 'After'
+H2PushPriority image/jpeg before # poid hérité
+H2PushPriority text/css interleaved # poids de 256 par défaut
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2Upgrade</name>
+ <description>Activation/Désactivation du protocole de mise à jour H2</description>
+ <syntax>H2Upgrade on|off</syntax>
+ <default>H2Upgrade on pour h2c, off pour h2</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+
+ <usage>
+ <p>
+ Cette directive permet d'activer/désactiver l'utilisation de la
+ méthode de mise à jour pour passer de HTTP/1.1 à HTTP/2. Elle
+ doit être placée dans une section <directive module="core"
+ type="section">VirtualHost</directive> afin d'activer la mise à
+ jour vers HTTP/2 pour le serveur virtuel considéré.
+ </p>
+ <p>
+ Cette méthode de changement de protocole est définie dans
+ HTTP/1.1 et utilise l'en-tête "Upgrade" (d'où son nom) pour
+ indiquer l'intention d'utiliser un autre protocole. Cet en-tête
+ peut être présent dans toute requête sur une connexion HTTP/1.1.
+ </p>
+ <p>
+ Elle activée par défaut pour les transmissions en clair
+ (h2c), et désactivée avec TLS (h2), comme préconisé par la RFC
+ 7540.
+ </p>
+ <p>
+ Sachez cependant que les mises à jour ne sont acceptées que pour
+ les requêtes qui ne possèdent pas de corps. Le requêtes de type
+ POST et PUT avec un contenu ne feront jamais l'objet d'une mise
+ à jour vers HTTP/2. Se référer à la documentation de la
+ directive <directive module="mod_http2">H2Direct</directive> pour
+ envisager une alternative à Upgrade.
+ </p>
+ <p>
+ Cette directive n'a d'effet que si h2 ou h2c est activé via la
+ directive <directive module="core">Protocols</directive>.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2Upgrade on
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2MaxSessionStreams</name>
+ <description>Nombre maximal de flux actifs par session HTTP/2.</description>
+ <syntax>H2MaxSessionStreams <em>n</em></syntax>
+ <default>H2MaxSessionStreams 100</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <usage>
+ <p>
+ Cette directive permet de définir le nombre maximal de flux
+ actifs par session (connexion) HTTP/2 accepté par le serveur.
+ Selon la RFC 7540, un flux est considéré comme actif s'il n'est
+ ni <code>en attente</code> ni <code>fermé</code>.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2MaxSessionStreams 20
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2StreamMaxMemSize</name>
+ <description>Quantité maximale de données en sortie mises en tampon par
+ flux.</description>
+ <syntax>H2StreamMaxMemSize <em>bytes</em></syntax>
+ <default>H2StreamMaxMemSize 65536</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <usage>
+ <p>
+ Cette directive permet de définir la quantité maximale de
+ données en sortie mises en tampon mémoire pour un flux actif. Ce
+ tampon mémoire n'est pas alloué pour chaque flux en tant que
+ tel. Les quantités de mémoire sont définies en fonction de
+ cette limite lorsqu'elles sont sur le point d'être allouées. Le
+ flux s'arrête lorsque la limite a été atteinte, et ne reprendra
+ que lorsque les données du tampon auront été transmises au
+ client.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2StreamMaxMemSize 128000
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2WindowSize</name>
+ <description>Taille maximale des paquets de données pour les transmissions client
+ vers serveur.</description>
+ <syntax>H2WindowSize <em>bytes</em></syntax>
+ <default>H2WindowSize 65535</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <usage>
+ <p>
+ Cette directive permet de définir la taille maximale des paquets
+ de données envoyés par le client au serveur, et
+ limite la quantité de données que le serveur doit mettre en
+ tampon. Le client arrêtera d'envoyer des données sur un flux
+ lorsque cette limite sera atteinte jusqu'à ce que le serveur
+ indique qu'il dispose d'un espace suffisant (car il aura traité
+ une partie des données).
+ </p><p>
+ Cette limite n'affecte que les corps de requêtes, non les
+ métadonnées comme les en-têtes. Par contre, elle n'affecte pas
+ les corps de réponses car la taille maximale de ces derniers est
+ gérée au niveau des clients.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2WindowSize 128000
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2MinWorkers</name>
+ <description>Nombre minimal de threads à utiliser pour chaque processus
+ enfant.</description>
+ <syntax>H2MinWorkers <em>n</em></syntax>
+ <contextlist>
+ <context>server config</context>
+ </contextlist>
+ <usage>
+ <p>
+ Cette directive permet de définir le nombre minimal de threads à
+ lancer pour le traitement HTTP/2 de chaque processus enfant. Si
+ cette directive n'est pas définie, <module>mod_http2</module>
+ choisira une valeur appropriée en fonction du module <code>mpm</code>
+ utilisé.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2MinWorkers 10
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2MaxWorkers</name>
+ <description>Nombre maximal de threads à utiliser pour chaque processus
+ enfant.</description>
+ <syntax>H2MaxWorkers <em>n</em></syntax>
+ <contextlist>
+ <context>server config</context>
+ </contextlist>
+ <usage>
+ <p>
+ Cette directive permet de définir le nombre maximal de threads à
+ lancer pour le traitement HTTP/2 de chaque processus enfant. Si
+ cette directive n'est pas définie, <module>mod_http2</module>
+ choisira une valeur appropriée en fonction du module <code>mpm</code>
+ utilisé.
+
+ This directive sets the maximum number of worker threads to spawn
+ per child process for HTTP/2 processing. If this directive is not used,
+ <code>mod_http2</code> will chose a value suitable for the <code>mpm</code>
+ module loaded.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2MaxWorkers 20
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2MaxWorkerIdleSeconds</name>
+ <description>Nombre maximal de secondes pendant lequel une unité de
+ traitement h2 pourra rester inactive sans être arrêtée.</description>
+ <syntax>H2MaxWorkerIdleSeconds <em>n</em></syntax>
+ <default>H2MaxWorkerIdleSeconds 600</default>
+ <contextlist>
+ <context>server config</context>
+ </contextlist>
+ <usage>
+ <p>
+ Cette directive permet de définir le nombre maximal de secondes
+ pendant lequel une unité de traitement h2 pourra rester inactive
+ avant de s'arrêter elle-même. Cet arrêt ne peut cependant se
+ produire que si le nombre d'unités de traitement h2 dépasse
+ <directive module="mod_http2">H2MinWorkers</directive>.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2MaxWorkerIdleSeconds 20
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2SerializeHeaders</name>
+ <description>Active/désactive la sérialisation du traitement des
+ requêtes/réponses</description>
+ <syntax>H2SerializeHeaders on|off</syntax>
+ <default>H2SerializeHeaders off</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <usage>
+ <p>
+ Cette directive permet de définir si les requêtes HTTP/2 doivent
+ être sérialisées au format HTTP/1.1 pour être traitées par le
+ noyau de <code>httpd</code>, ou si les données binaires reçues
+ doivent être passées directement aux <code>request_rec</code>s.
+ </p>
+ <p>
+ La sérialisation dégrade les performances, mais garantit une
+ meilleure compatibilité ascendante lorsque des filtres ou
+ programmes accroche personnalisés en ont besoin.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2SerializeHeaders on
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2ModernTLSOnly</name>
+ <description>Impose les connexions HTTP/2 en mode "TLS moderne"
+ seulement</description>
+ <syntax>H2ModernTLSOnly on|off</syntax>
+ <default>H2ModernTLSOnly on</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <compatibility>Disponible à partir de la version 2.4.18 du serveur HTTP
+ Apache.</compatibility>
+
+ <usage>
+ <p>
+ Cette directive permet de définir si les vérifications de
+ sécurité sur les connexions HTTP/2 doivent être exclusivement en
+ mode TLS (https:). Elle peut être placée au niveau du serveur
+ principal ou dans une section <directive module="core"
+ type="section">VirtualHost</directive>.
+ </p>
+ <p>
+ Les vérifications de sécurité nécessitent TLSv1.2 au minimum et
+ l'absence de tout algorithme de chiffrement listé dans la RFC
+ 7540, Appendix A. Ces vérifications seront étendues lorsque de
+ nouveaux prérequis en matière de sécurité seront mis en place.
+ </p>
+ <p>
+ Le nom provient des définitions Mozilla <a
+ href="https://wiki.mozilla.org/Security/Server_Side_TLS">Security/Server
+ Side TLS</a> où il est question de "modern compatibility".
+ Mozilla Firefox et d'autres navigateurs imposent la "modern
+ compatibility" pour les connexions HTTP/2. Comme toute chose en
+ matière de sécurité opérationnelle, c'est une cible mouvante
+ susceptible d'évoluer dans le futur.
+ </p>
+ <p>
+ Un des buts de ces vérifications dans <module>mod_http2</module> tend à imposer
+ ce niveau de sécurité pour toutes les connexions, et non
+ seulement celles en provenance des navigateurs web. Un autre but
+ est l'interdiction d'utiliser HTTP/2 en tant que protocole dans
+ les négociations si les prérequis ne sont pas respectés.
+ </p>
+ <p>
+ En fin de compte, la sécurité de la connexion TLS est déterminée
+ par les directives de configuration du serveur pour <module>mod_ssl</module>.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2ModernTLSOnly off
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2TLSWarmUpSize</name>
+ <description></description>
+ <syntax>H2TLSWarmUpSize <em>amount</em></syntax>
+ <default>H2TLSWarmUpSize 1048576</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <compatibility>Disponible à partir de la version 2.4.18 du serveur HTTP
+ Apache.</compatibility>
+
+ <usage>
+ <p>
+ Cette directive permet de définir le nombre d'octets à envoyer
+ dans les petits enregistrements TLS (~1300 octets) avant
+ d'atteindre leur taille maximale de 16 ko pour les connexions
+ https: HTTP/2. Elle peut être définie au niveau du serveur
+ principal ou pour des <directive module="core"
+ type="section">Serveurs virtuels</directive> spécifiques.
+ </p>
+ <p>
+ Les mesures effectuées par les <a
+ href="https://www.igvita.com">laboratoires de performances de
+ Google</a> montrent que les meilleurs performances sont atteintes
+ pour les connexions TLS si la taille initiale des
+ enregistrements reste en deça du niveau du MTU afin de permettre
+ à la totatlité d'un enregistrement d'entrer dans un paquet IP.
+ </p>
+ <p>
+ Comme TCP ajuste son contrôle de flux et sa taille de fenêtre,
+ des enregistrements TLS trop longs peuvent rester en file
+ d'attente ou même être perdus et devoir alors être réémis. Ceci
+ est bien entendu vrai pour tous les paquets ; cependant, TLS a
+ besoin de la totalité de l'enregistrement pour pouvoir le
+ déchiffrer. Tout octet manquant rendra impossible l'utilisation
+ de ceux qui ont été reçus.
+ </p>
+ <p>
+ Lorqu'un nombre suffisant d'octets a été transmis avec succès,
+ la connexion TCP est stable, et la taille maximale (16 ko) des
+ enregistrements TLS peut être utilisée pour des performances
+ optimales.
+ </p>
+ <p>
+ Dans les architectures où les serveurs sont atteints par des
+ machines locales ou pour les connexions de confiance seulement,
+ la valeur de cette directive peut être définie à 0, ce qui a
+ pour effet de désactiver la "phase de chauffage".
+ </p>
+ <p>
+ Dans l'exemple suivant, la phase de chauffage est effectivement
+ désactivée en définissant la directive à 0.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2TLSWarmUpSize 0
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2TLSCoolDownSecs</name>
+ <description></description>
+ <syntax>H2TLSCoolDownSecs <em>seconds</em></syntax>
+ <default>H2TLSCoolDownSecs 1</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <compatibility>Disponible à partir de la version 2.4.18 du serveur HTTP
+ Apache.</compatibility>
+
+ <usage>
+ <p>
+ Cette directive permet de spécifier le nombre de secondes avant
+ lequel une connexion TLS inactive va diminuer
+ la taille des paquets de données à une valeur inférieure (~1300
+ octets). Elle peut être définie au niveau du serveur principal
+ ou pour un <directive module="core" type="section">serveur
+ virtuel</directive> spécifique.
+ </p>
+ <p>
+ Voir la directive <directive module="mod_http2">H2TLSWarmUpSize</directive> pour une description
+ du "préchauffage" de TLS. La directive <directive>H2TLSCoolDownSecs</directive> met en
+ lumière le fait que les connexions peuvent se détériorer au bout
+ d'un certain temps (et au fur et à mesure des corrections du
+ flux TCP), et cela même si elle sont inactives. Pour ne pas
+ détériorer les performances d'une manière générale, il est par
+ conséquent préférable de revenir à la phase de préchauffage
+ lorsqu'aucune donnée n'a été transmise pendant un certain nombre
+ de secondes.
+ </p>
+ <p>
+ Dans les situations où les connexions peuvent être considérées
+ comme fiables, ce délai peut être désactivé en définissant cette
+ directive à 0.
+ </p>
+ <p>
+ Dans l'exemple suivant, la directive est définie à 0, ce qui
+ désactive tout retour à une phase de préchauffage des connexions
+ TLS. Les connexions TLS déjà préchauffées conservent donc toujours
+ leur taille de paquet de données maximale.
+ </p>
+ <example><title>Exemple</title>
+ <highlight language="config">
+ H2TLSCoolDownSecs 0
+ </highlight>
+ </example>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2Timeout</name>
+ <description>Délai (en secondes) pour les connexions HTTP/2</description>
+ <syntax>H2Timeout secondes</syntax>
+ <default>H2Timeout 5</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <compatibility>Disponible à partir de la version 2.4.19 du serveur HTTP
+ Apache.</compatibility>
+
+ <usage>
+ <p>
+ Cette directive permet de définir un délai pour les opérations
+ de lecture/écriture lorsqu'une connexion HTTP/2 a été
+ négociée. Elle peut être définie pour l'ensemble du serveur ou
+ pour un <directive module="core" type="section">serveur
+ virtuel</directive> spécifique.
+ </p>
+ <p>
+ Elle est similaire à la directive <directive module="core"
+ type="section">Timeout</directive>, mais elle ne s'applique
+ qu'aux connexions HTTP/2.
+ </p>
+ <p>
+ Une valeur de 0 signifie qu'aucun délai n'est imposé.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2KeepAliveTimeout</name>
+ <description>Durée de vie en secondes des connexions HTTP/2 inactives</description>
+ <syntax>H2KeepAliveTimeout secondes</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <compatibility>Disponible à partir de la version 2.4.19 du serveur HTTP
+ Apache.</compatibility>
+
+ <usage>
+ <p>
+ Cette directive permet de définir la durée de vie des connexions
+ HTTP/2 inactives. Sa portée peut s'étendre à l'ensemble du
+ serveur, ou seulement à un <directive module="core"
+ type="section">VirtualHost</directive> spécifique.
+ </p>
+ <p>
+ Cette directive est équivalente à la directive <directive
+ module="core" type="section">KeepAliveTimeout</directive>, mais
+ elle ne s'applique qu'aux connexions HTTP/2. Une connexion
+ HTTP/2 est considérée comme inactive lorsqu'aucun flux n'est
+ ouvert, autrement dit lorsqu'aucune requête n'est sur le point
+ d'être traitée.
+ </p>
+ <p>
+ Pour les MPMs non-asynch (prefork, worker), la durée de vie
+ sera par défaut égale à H2Timeout. Pour les MPMs async, il
+ semble qu'aucune action ne soit à entreprendre pour la durée de
+ vie des connexions HTTP/1.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2StreamTimeout</name>
+ <description>Durée de vie en secondes des connexions HTTP/2 inactives</description>
+ <syntax>H2StreamTimeout secondes</syntax>
+ <default>H2StreamTimeout 0</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <compatibility>Disponible à partir de la version 2.4.19 du serveur HTTP
+ Apache.</compatibility>
+
+ <usage>
+ <p>
+ Cette directive permet de définir la durée de vie des flux
+ HTTP/2 pour les requêtes individuelles. Sa portée peut s'étendre
+ à l'ensemble du serveur, ou seulement à un <directive
+ module="core" type="section">VirtualHost</directive> spécifique
+ </p>
+ <p>
+ De par la nature de HTTP/2 qui transmet plusieurs requêtes sur
+ une seule connexion et gère une planification des priorités, les
+ flux individuels ne sont pas susceptibles de recevoir des
+ données en entrée beaucoup plus longtemps qu'une connexion
+ HTTP/1.1.
+ </p>
+ <p>
+ Si cette directive est définie à 0, la durée de vie des flux
+ HTTP/2 n'a aucune limite, et il peuvent attendre indéfiniment
+ l'arrivée de données à lire ou écrire. Cela expose cependant le
+ serveur à atteindre sa limite en nombre de threads.
+ </p>
+ <p>
+ Un site peut nécessiter une augmentation de cette valeur en
+ fonction de votre gestion des flux PUSHés, des priorités et de
+ la réactivité générale. Par exemple, si vous PUSHez une
+ ressource de taille importante <em>avant</em> celle qui a fait
+ l'objet d'une requête, le flux initiale n'effectuera aucune
+ écriture jusqu'à ce que la ressource PUSHée ne soit envoyée dans
+ son intégralité.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2CopyFiles</name>
+ <description>Contrôle la gestion des fichiers dans les réponses</description>
+ <syntax>H2CopyFiles on|off</syntax>
+ <default>H2CopyFiles off</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ <context>directory</context>
+ <context>.htaccess</context>
+ </contextlist>
+ <compatibility>Disponible à partir de la version 2.4.24 du serveur HTTP
+ Apache.</compatibility>
+
+ <usage>
+ <p>
+ Cette directive permet de définir la manière de gérer les
+ contenus de fichiers dans les réponses. Lorsqu'elle est à <code>off</code>
+ (sa valeur par défaut), les descripteurs de fichiers sont
+ transmis par le processus de traitement de la requête vers la
+ connexion principale en utilisant le système habituel de mise en
+ réserve d'Apache pour gérer le durée de vie du fichier.
+ </p>
+ <p>
+ Lorsqu'elle est à <code>on</code>, le contenu du fichier est
+ recopier pendant le traitement de la requête et ces données
+ mises en tampon sont transmises vers la connexion principale, ce
+ qui s'avère avantageux lorsqu'un module tiers injecte dans la
+ réponse des fichiers possédant des durées de vie différentes.
+ </p>
+ <p>
+ Un exemple de ces modules tiers : <code>mod_wsgi</code> qui peut
+ injecter des descripteurs de fichiers dans la réponse. Ces
+ fichiers sont fermés lorsque Python estime que le traitement est
+ terminé, alors que <module>mod_http2</module> est probablement
+ encore loin d'en avoir fini avec eux.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2PushResource</name>
+ <description>Déclare des ressources à proposer ("pusher") au client</description>
+ <syntax>H2PushResource [add] path [critical]</syntax>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ <context>directory</context>
+ <context>.htaccess</context>
+ </contextlist>
+ <compatibility>Disponible à partir de la version 2.4.24 du serveur HTTP
+ Apache.</compatibility>
+
+ <usage>
+ <p>
+ Lorsqu'il sont activés pour un répertoire, les PUSHes HTTP/2 seront
+ tentés pour tous les chemins ajoutés via cette directive. Cette
+ dernière peut être utilisée plusieurs fois pour le même
+ répertoire.
+ </p>
+ <p>
+ Cette directive propose des ressources beaucoup plus tôt que les
+ en-têtes <code>Link</code> de <module>mod_headers</module>.
+ <module>mod_http2</module> présente ces ressources au client via
+ une réponse intermédiaire <code>103 Early Hints</code>. Ceci
+ implique que les clients qui ne supportent pas PUSH recevront
+ quand-même rapidement des propositions de préchargement.
+ </p>
+ <p>
+ A la différence de la définition d'en-têtes de réponse
+ <code>Link</code> via <module>mod_headers</module>, cette
+ directive n'aura d'effet que pour les connexions HTTP/2.
+ </p>
+ <p>
+ En ajoutant l'option <code>critical</code> à une telle
+ ressource, le serveur la traitera prioritairement, et une fois
+ les données disponibles, ces dernières seront envoyées avant les
+ données de la requête principale.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+ <directivesynopsis>
+ <name>H2EarlyHints</name>
+ <description>Contrôle l'envoi de codes d'état 103</description>
+ <syntax>H2EarlyHints on|off</syntax>
+ <default>H2EarlyHints off</default>
+ <contextlist>
+ <context>server config</context>
+ <context>virtual host</context>
+ </contextlist>
+ <compatibility>Disponible à partir de la version 2.4.24 du serveur HTTP
+ Apache.</compatibility>
+
+ <usage>
+ <p>
+ Cette directive permet de définir si les réponses intermédiaires
+ contenant un code d'état HTTP 103 doivent être envoyées au
+ client ou non. Par défaut ce n'est actuellement pas le cas car
+ certains clients ont encore des problèmes avec les réponses
+ intermédiaires inattendues.
+ </p>
+ <p>
+ Lorsque cette directive est définie à <code>on</code>, les
+ ressources PUSHées définie par la directive
+ <code>H2PushResource</code> déclenchent une réponse
+ intermédiaire 103 avant la réponse finale. Cette réponse 103
+ comporte des en-têtes <code>Link</code> qui provoquent le
+ <code>préchargement</code> des ressources considérées.
+ </p>
+ </usage>
+ </directivesynopsis>
+
+</modulesynopsis>
--- /dev/null
+<?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: 1832295 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_proxy_hcheck.xml.meta">
+
+<name>mod_proxy_hcheck</name>
+<description>Check up dynamique des membres du groupe de répartition de charge
+(équipiers) pour <module>mod_proxy</module></description>
+<status>Extension</status>
+<sourcefile>mod_proxy_hcheck.c</sourcefile>
+<identifier>proxy_hcheck_module</identifier>
+<compatibility>Disponible à partir de la version 2.4.21 du serveur HTTP Apache</compatibility>
+
+<summary>
+ <p>Ce module permet d'effectuer un check up dynamique des membres du groupe
+ de répartition de charge (équipiers). Ce check up peut être activé pour un
+ ou plusieurs équipiers et il est indépendant des requêtes de mandataire
+ inverse proprement dites.</p>
+
+ <p>Pour fonctionner, ce module <em>nécessite</em> le chargement préalable de
+ <module>mod_watchdog</module>.</p>
+
+<note><title>Paramètres</title>
+ <p>Le mécanisme de check up est activé via l'utilisation de paramètres
+ supplémentaires de la directive <directive
+ module="mod_proxy">BalancerMember</directive> configurés de manière standard
+ via la directive <directive module="mod_proxy">ProxyPass</directive> :</p>
+
+ <p>Ce module définit un nouveau drapeau d'état <a
+ href="mod_proxy.html#status_table">status</a> pour BalancerMember :
+ "<code>C</code>". Lorsque l'équipier est mis hors service suite à un
+ disfonctionnement déterminé par le module de check up, ce drapeau est activé
+ et peut être lu (et modifié) via le <code>balancer-manager</code>.</p>
+
+ <table>
+ <tr><th>Paramètre</th>
+ <th>Défaut</th>
+ <th>Description</th></tr>
+ <tr><td>hcmethod</td>
+ <td>None</td>
+ <td>Aucun check up dynamique n'est effectué. Les choix possibles sont :
+ <table>
+ <tr><th>Method</th><th>Description</th><th>Note</th></tr>
+ <tr><td>None</td><td>Aucun check up dynamique effectué</td><td></td></tr>
+ <tr><td>TCP</td><td>Vérifie qu'un socket vers le serveur
+ d'arrière-plan peut être créé ; par exemple "es-tu en
+ état de fonctionner"</td><td></td></tr>
+ <tr><td>OPTIONS</td><td>Envoie une requête <code>HTTP
+ OPTIONS</code> au serveur d'arrière-plan</td><td>*</td></tr>
+ <tr><td>HEAD</td><td>Envoie une requête <code>HTTP
+ HEAD</code> au serveur d'arrière-plan</td><td>*</td></tr>
+ <tr><td>GET</td><td>Envoie une requête <code>HTTP
+ GET</code> au serveur d'arrière-plan</td><td>*</td></tr>
+<!--
+ <tr><td>CPING</td><td><strong>AJP only</strong> Do <code>CPING/CPONG</code> check</td><td></td></tr>
+ <tr><td>PROVIDER</td><td>Name of <code>provider</code> to be used to check health</td><td></td></tr>
+-->
+ <tr><td colspan="3"></td></tr>
+ <tr><td colspan="3">*: si hcexpr n'est pas
+ utilisé, un retour HTTP 2xx ou 3xx sera
+ interprété comme un passage avec succès du check
+ up.</td></tr>
+ </table>
+ </td></tr>
+ <tr><td>hcpasses</td>
+ <td>1</td>
+ <td>Nombre de check up à passer avec succès avant de remettre en service
+ l'équipier</td></tr>
+ <tr><td>hcfails</td>
+ <td>1</td>
+ <td>Nombre de check up échoués avant mettre hors service l'équipier</td></tr>
+ <tr><td>hcinterval</td>
+ <td>30</td>
+ <td>Intervalle entre deux check up en secondes (par défaut effectué
+ toutes les 30 secondes)</td></tr>
+ <tr><td>hcuri</td>
+ <td> </td>
+ <td>URI supplémentaire à ajouter à l'URL de l'équipier pour le check up.</td></tr>
+ <tr><td>hctemplate</td>
+ <td> </td>
+ <td>Nom du modèle créé via <directive module="mod_proxy_hcheck">ProxyHCTemplate</directive> à
+ utiliser pour définir les paramètres de check up de cet équipier</td></tr>
+ <tr><td>hcexpr</td>
+ <td> </td>
+ <td>Nom de l'expression créée via <directive module="mod_proxy_hcheck">ProxyHCExpr</directive>
+ utilisée pour analyser les en-têtes de la réponse du check up.<br/>
+ <em>Si ce paramètre est absent, un état HTTP de 2xx à 3xx est
+ interprété comme un check up réussi.</em></td></tr>
+ </table>
+</note>
+
+</summary>
+<seealso><module>mod_proxy</module></seealso>
+
+<section id="examples">
+
+ <title>Exemples d'utilisation</title>
+ <p>L'exemple suivant montre comment configurer le check up pour différents
+ serveurs d'arrière-plan :</p>
+
+ <!-- This section should probably be extended with more, useful examples -->
+ <highlight language="config">
+ProxyHCExpr ok234 {%{REQUEST_STATUS} =~ /^[234]/}
+ProxyHCExpr gdown {%{REQUEST_STATUS} =~ /^[5]/}
+ProxyHCExpr in_maint {hc('body') !~ /Under maintenance/}
+
+<Proxy balancer://foo>
+ BalancerMember http://www.example.com/ hcmethod=GET hcexpr=in_maint hcuri=/status.php
+ BalancerMember http://www2.example.com/ hcmethod=HEAD hcexpr=ok234 hcinterval=10
+ BalancerMember http://www3.example.com/ hcmethod=TCP hcinterval=5 hcpasses=2 hcfails=3
+ BalancerMember http://www4.example.com/
+</Proxy>
+
+ProxyPass "/" "balancer://foo"
+ProxyPassReverse "/" "balancer://foo"
+</highlight>
+
+<p>Dans ce scénario, on teste l'équipier <code>http://www.example.com/</code> en lui
+envoyant une requête <code>GET /status.php</code> et en regardant si la réponse
+contient la chaîne <em>Under maintenance</em>. Si c'est le cas, le check up est
+considéré comme ayant échoué et l'équipier est mis hors service. Ce check up
+dynamique est effectué toutes les 30 secondes, ce qui correspond à la valeur par
+défaut.</p>
+
+<p>On teste l'équipier <code>http://www2.example.com/</code> en lui envoyant
+simplement une requête <code>HEAD</code> toutes les 10 secondes et en vérifiant
+que la réponse HTTP est bien un code d'état de 2xx, 3xx ou 4xx. On teste
+l'équipier <code>http://www3.example.com/</code> en vérifiant simplement toutes
+les 5 secondes que le socket vers ce serveur est bien opérationnel. Si ce
+serveur est marqué "hors service", il lui faudra 2 check up réussis pour être
+réactivé et participer à nouveau à la répartition de charge. Si à ce moment-là
+il échoue à 3 check up successifs, il sera à nouveau mis hors service. Enfin,
+l'équipier <code>http://www4.example.com/</code> ne fait l'objet d'aucun check
+up.</p>
+
+</section>
+
+<directivesynopsis>
+<name>ProxyHCExpr</name>
+<description>Crée et nomme une expression conditionnelle à utiliser pour
+déterminer la santé d'un serveur d'arrière-plan en fonction de sa valeur</description>
+<syntax>ProxyHCExpr <em>name</em> {<em>ap_expr expression</em>}</syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive>ProxyHCExpr</directive> permet de créer et nommer
+ une expression conditionnelle dont la valeur calculée en fonction des
+ en-têtes de la réponse du serveur d'arrière-plan permettra d'évaluer la
+ santé de ce dernier. Cette expression nommée peut alors être assignée aux
+ serveurs d'arrière-plan via le paramètre <code>hcexpr</code>.</p>
+
+ <example><title>ProxyHCExpr: interprète les réponses 2xx/3xx/4xx comme des
+ check up réussis</title>
+ <highlight language="config">
+ProxyHCExpr ok234 {%{REQUEST_STATUS} =~ /^[234]/}
+ProxyPass "/apps" "balancer://foo"
+
+<Proxy balancer://foo>
+ BalancerMember http://www2.example.com/ hcmethod=HEAD hcexpr=ok234 hcinterval=10
+</Proxy>
+ </highlight>
+ </example>
+
+ <note>
+ L'<a href="../expr.html">expression</a> peut utiliser des accolades ("{}")
+ comme délimiteurs en plus des guillemets normaux.
+ </note>
+
+ <p>Si l'on utilise une méthode de check up (par exemple <code>GET</code>)
+ qui génère un corps de réponse, ce corps peut lui-même être ausculté via
+ <code>ap_expr</code> en utilisant la fonction associée aux expressions
+ <code>hc()</code> spécifique à ce module.</p>
+
+ <p>Dans l'exemple suivant, on envoie une requête <code>GET</code> au serveur
+ d'arrière-plan, et si le corps de la réponse contient la chaîne <em>Under
+ maintenance</em>, ce serveur d'arrière-plan est mis hors service.</p>
+
+ <example><title>ProxyHCExpr: auscultation du corps de la réponse</title>
+ <highlight language="config">
+ProxyHCExpr in_maint {hc('body') !~ /Under maintenance/}
+ProxyPass "/apps" "balancer://foo"
+
+<Proxy balancer://foo>
+ BalancerMember http://www.example.com/ hcexpr=in_maint hcmethod=get hcuri=/status.php
+</Proxy>
+ </highlight>
+ </example>
+
+ <p><em>NOTE:</em> Comme le corps de la réponse peut être assez grand, il est
+ recommandé de privilégier un check up basé sur les codes d'état.</p>
+</usage>
+</directivesynopsis>
+
+
+<directivesynopsis>
+<name>ProxyHCTemplate</name>
+<description>Crée et nomme un modèle permettant de définir différents
+paramètres de check up</description>
+<syntax>ProxyHCTemplate <em>name</em> <em>parameter</em>=<em>setting</em> [...]</syntax>
+<contextlist><context>server config</context><context>virtual host</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive>ProxyHCTemplate</directive> permet de créer et
+ nommer un modèle de paramètres de check up qui peut alors être assigné aux
+ équipiers via le paramètre <code>hctemplate</code>.</p>
+
+ <example><title>ProxyHCTemplate</title>
+ <highlight language="config">
+ProxyHCTemplate tcp5 hcmethod=tcp hcinterval=5
+ProxyPass "/apps" "balancer://foo"
+
+<Proxy balancer://foo>
+ BalancerMember http://www2.example.com/ hctemplate=tcp5
+</Proxy>
+ </highlight>
+ </example>
+
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>ProxyHCTPsize</name>
+<description>Définit la taille totale, pour l'ensemble du
+serveur, du jeu de threads utilisé pour le check up des
+équipiers</description>
+<syntax>ProxyHCTPsize <em>size</em></syntax>
+<contextlist><context>server config</context>
+</contextlist>
+
+<usage>
+ <p>Si Apache httpd et APR ont été compilés avec le support des threads, le
+ module de check up peut confier ce travail à un jeu de threads associé au
+ processus Watchdog, ce qui permet l'exécution des check up en parallèle. La
+ directive <directive>ProxyHCTPsize</directive> permet de déterminer la
+ taille de ce jeu de threads. Une valeur de <code>0</code> signifie qu'aucun
+ jeu de threads ne sera utilisé, et le check up des différents équipiers sera
+ alors effectué séquentiellement. La taille par défaut du jeu de threads est
+ de 16.</p>
+
+ <example><title>ProxyHCTPsize</title>
+ <highlight language="config">
+ProxyHCTPsize 32
+ </highlight>
+ </example>
+
+</usage>
+</directivesynopsis>
+
+</modulesynopsis>
--- /dev/null
+<?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 : 1798491 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_proxy_http2.xml.meta">
+
+<name>mod_proxy_http2</name>
+<description>Support de HTTP/2 pour <module>mod_proxy</module></description>
+<status>Extension</status>
+<sourcefile>mod_proxy_http2.c</sourcefile>
+<identifier>proxy_http2_module</identifier>
+
+<summary>
+ <p><module>mod_proxy_http2</module> ne
+ supporte que HTTP/2 et ne permet pas de rétrogradation vers HTTP/1.1. Cela
+ signifie que le serveur d'arrière-plan doit supporter HTTP/2 car HTTP/1.1 ne
+ pourra alors pas être utilisé.</p>
+
+ <p>Ce module <em>nécessite</em> la présence de <module>mod_proxy</module> ;
+ pour pouvoir traiter les requêtes mandatées HTTP/2,
+ <module>mod_proxy</module> et <module>mod_proxy_http2</module> doivent donc
+ être chargés par le serveur.</p>
+
+ <p><module>mod_proxy_http2</module> travaille avec des requêtes entrantes en
+ HTTP/1.1 ou HTTP/2. Dans les deux cas, les requêtes vers le même serveur
+ d'arrière-plan sont envoyées
+ via une seule connexion TCP, dans la mesure du possible (autrement dit
+ lorsque la connexion peut être réutilisée).</p>
+
+ <p>Avertissement : il ne sera effectué aucune tentative de fusion de
+ plusieurs requêtes entrantes HTTP/1 (devant être mandatées vers le même
+ serveur d'arrière-plan) vers des flux HTTP/2 appartenant à la même requête
+ HTTP/2. Chaque requête HTTP/1 entrante sera mandatée vers le serveur
+ d'arrière-plan en utilisant une requête HTTP/2 séparée (tout en réutilisant
+ si possible la même connexion TCP).</p>
+
+ <p>Ce module s'appuie sur <a href="http://nghttp2.org/">libnghttp2</a> pour
+ fournir le moteur central http/2.</p>
+
+ <note type="warning"><title>Avertissement</title>
+ <p>Ce module en est au
+ stade expérimental. Ses comportement, directives et valeurs par défauts sont
+ donc susceptibles de modifications d'une version à l'autre plus fréquentes
+ que pour les autres modules. A ce titre, il est fortement conseillé aux
+ utilisateurs de consulter le fichier "CHANGES" pour prendre connaissance de
+ ces modifications.</p> </note>
+
+ <note type="warning"><title>Avertissement</title>
+ <p>N'activez pas le mandatement avant d'avoir <a
+ href="mod_proxy.html#access">sécurisé votre serveur</a>. Les serveurs
+ mandataires ouverts sont dangereux non seulement pour votre propre réseau,
+ mais aussi pour l'Internet au sens large.</p>
+ </note>
+</summary>
+<seealso><module>mod_http2</module></seealso>
+<seealso><module>mod_proxy</module></seealso>
+<seealso><module>mod_proxy_connect</module></seealso>
+
+ <section id="examples"><title>Exemples de base</title>
+
+ <p>Les exemples ci-dessous montrent comment configurer HTTP/2 pour des
+ connexions d'arrière-plan vers un mandataire inverse.</p>
+
+ <example><title>HTTP/2 (TLS)</title>
+ <highlight language="config">
+ProxyPass "/app" "h2://app.example.com"
+ProxyPassReverse "/app" "https://app.example.com"
+ </highlight>
+ </example>
+
+ <example><title>HTTP/2 (non sécurisé)</title>
+ <highlight language="config">
+ProxyPass "/app" "h2c://app.example.com"
+ProxyPassReverse "/app" "http://app.example.com"
+ </highlight>
+ </example>
+
+ <note>
+ <p>Pour mandater en inverse les protocoles <code>h2</code> ou
+ <code>h2c</code>, on utilise la directive
+ <directive>ProxyPassReverse</directive> avec les schèmes habituels
+ <code>https</code> et respectivement
+ <code>http</code> qui sont connus et utilisés par l'agent utilisateur.</p>
+ </note>
+ </section> <!-- /examples -->
+
+<section id="notes"><title>Informations sur les requêtes</title>
+ <p><module>mod_proxy_http</module> fournit les informations sur les requêtes
+ suivantes pour enregistrement dans les journaux en utilisant le format
+ <code>%{VARNAME}n</code> avec les directives <directive
+ module="mod_log_config">LogFormat</directive> ou <directive
+ module="core">ErrorLogFormat</directive> :
+ </p>
+ <dl>
+ <dt>proxy-source-port</dt>
+ <dd>Le numéro de port local utilisé pour la connexion vers le serveur
+ d'arrière-plan.</dd>
+ <dt>proxy-status</dt>
+ <dd>Le statut HTTP/2 en provenance du serveur d'arrière-plan.</dd>
+ </dl>
+</section>
+
+</modulesynopsis>
--- /dev/null
+<?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 : 1808698 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_proxy_wstunnel.xml.meta">
+
+<name>mod_proxy_wstunnel</name>
+<description>Module pour <module>mod_proxy</module> supportant les
+websockets</description>
+<status>Extension</status>
+<sourcefile>mod_proxy_wstunnel.c</sourcefile>
+<identifier>proxy_wstunnel_module</identifier>
+<compatibility>Disponible à partir de la version 2.4.5 du serveur HTTP
+Apache</compatibility>
+
+<summary>
+ <p>Pour utiliser ce module, <module>mod_proxy</module> doit être
+ chargé. Il fournit le support du tunnelling pour les connexions
+ websocket vers un serveur websockets d'arrière-plan. La connexion
+ est automatiquement promue en connexion websocket :</p>
+
+ <example><title>Réponse HTTP</title>
+ <highlight language="config">
+Upgrade: WebSocket
+Connection: Upgrade
+ </highlight>
+ </example>
+
+<p>Le mandatement des requêtes vers un serveur websockets comme
+<code>echo.websocket.org</code> peut être configuré via la directive <directive
+type="ProxyPass" module="mod_proxy">ProxyPass</directive> :</p>
+ <highlight language="config">
+ProxyPass "/ws2/" "ws://echo.websocket.org/"
+ProxyPass "/wss2/" "wss://echo.websocket.org/"
+ </highlight>
+
+<p>La répartition de charge entre plusieurs serveurs d'arrière-plan peut être
+configurée via le module <module>mod_proxy_balancer</module>.</p>
+
+<p>En fait, ce module permet d'accepter d'autres protocoles ; vous pouvez à cet
+effet utiliser le paramètre <code>upgrade</code> de la directive <directive
+type="ProxyPass" module="mod_proxy">ProxyPass</directive>. La valeur NONE
+signifie que vous court-circuitez la consultation de l'en-tête, mais que vous
+autorisez quand-même WebSocket. La valeur ANY signifie que <code>Upgrade</code>
+va lire les en-têtes de la requête et les utilisera dans l'en-tête
+<code>Upgrade</code> de la réponse.</p>
+</summary>
+
+<seealso><module>mod_proxy</module></seealso>
+</modulesynopsis>
--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
+<!-- English Revision : 1334026 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_version.xml.meta">
+<name>mod_version</name>
+<description>Configuration dépendant de la version</description>
+<status>Extension</status>
+<sourcefile>mod_version.c</sourcefile>
+<identifier>version_module</identifier>
+<compatibility>Disponible depuis la version 2.0.56
+d'Apache</compatibility>
+
+<summary>
+ <p>Ce module a été conçu pour être utilisé dans les suites de tests
+ et les grands réseaux qui doivent prendre en compte différentes
+ versions de httpd et différentes configurations. Il fournit un
+ nouveau conteneur -- <directive type="section"
+ module="mod_version">IfVersion</directive>, qui apporte une grande
+ souplesse dans la vérification de version en permettant une
+ comparaison numérique et l'utilisation d'expressions
+ rationnelles.</p>
+
+ <example><title>Exemples</title>
+ <highlight language="config">
+<IfVersion 2.4.2>
+ # la version actuelle de httpd est exactement 2.4.2
+</IfVersion>
+
+<IfVersion >= 2.5>
+ # utilise vraiment les nouvelles fonctionnalités :-)
+</IfVersion>
+ </highlight>
+ </example>
+
+ <p>Voir ci-dessous pour d'autres exemples.</p>
+</summary>
+
+<directivesynopsis type="section">
+<name>IfVersion</name>
+<description>Contient des portions de configuration dépendantes de la
+version</description>
+<syntax><IfVersion [[!]<var>opérateur</var>] <var>version</var>> ...
+</IfVersion></syntax>
+<contextlist><context>server config</context><context>serveur
+virtuel</context>
+<context>directory</context><context>.htaccess</context></contextlist>
+<override>All</override>
+
+<usage>
+ <p>La section <directive type="section">IfVersion</directive>
+ rassemble des directives de configuration qui ne sont exécutées que
+ si la version de httpd satisfait aux critères spécifiés. Pour une
+ comparaison normale (numérique), l'argument <var>version</var> doit
+ être spécifié sous le format
+ <code><var>majeur</var>[.<var>mineur</var>[.<var>patch</var>]]</code>,
+ comme par exemple <code>2.1.0</code> ou <code>2.2</code>.
+ <var>mineur</var> et <var>patch</var> sont optionnels. Si ces
+ numéros sont absents, il se voient affectée implicitement la valeur
+ 0. Les <var>opérateur</var>s numériques suivants sont autorisés
+ :</p>
+
+ <table style="zebra" border="1">
+ <tr><th><var>opérateur</var></th><th>description</th></tr>
+ <tr><td><code>=</code> ou <code>==</code></td>
+ <td>La version de httpd est égale à la valeur
+ spécifiée</td></tr>
+ <tr><td><code>></code></td>
+ <td>La version de httpd est supérieure à la valeur
+ spécifiée</td></tr>
+ <tr><td><code>>=</code></td>
+ <td>La version de httpd est supérieure ou égale à la valeur
+ spécifiée</td></tr>
+ <tr><td><code><</code></td>
+ <td>La version de httpd est inférieure à la valeur
+ spécifiée</td></tr>
+ <tr><td><code><=</code></td>
+ <td>La version de httpd est inférieure ou égale à la valeur
+ spécifiée</td></tr>
+ </table>
+
+ <example><title>Exemple</title>
+ <highlight language="config">
+<IfVersion >= 2.3>
+ # la condition n'est satisfaite que pour les versions de httpd
+ # supérieures ou égales à 2.3
+</IfVersion>
+ </highlight>
+ </example>
+
+ <p>En plus d'une comparaison numérique, il est possible de comparer
+ la version de httpd avec une <glossary ref="regex">expression
+ rationnelle</glossary>. Il existe deux méthodes pour spécifier cette
+ dernière :</p>
+
+ <table style="zebra" border="1">
+ <tr><th><var>opérateur</var></th><th>description</th></tr>
+ <tr><td><code>=</code> ou <code>==</code></td>
+ <td><var>version</var> est de la forme
+ <code>/<var>regex</var>/</code></td></tr>
+ <tr><td><code>~</code></td>
+ <td><var>version</var> est de la forme
+ <code><var>regex</var></code></td></tr>
+ </table>
+
+ <example><title>Exemple</title>
+ <highlight language="config">
+<IfVersion = /^2.4.[01234]$/>
+ # exemple de contournement pour les versions boguées
+</IfVersion>
+ </highlight>
+ </example>
+
+ <p>Pour inverser la condition, tous les opérateurs peuvent être
+ préfixés par un point d'exclamation (<code>!</code>) :</p>
+
+ <example>
+ <highlight language="config">
+<IfVersion !~ ^2.4.[01234]$>
+ # pas pour ces versions
+</IfVersion>
+ </highlight>
+ </example>
+
+ <p>Si <var>opérateur</var> est absent, sa valeur implicite est
+ <code>=</code>.</p>
+</usage>
+</directivesynopsis>
+
+</modulesynopsis>
--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
+<!-- English Revision : 1231443 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_watchdog.xml.meta">
+<name>mod_watchdog</name>
+<description>Fournit une infrastructure permettant à d'autres modules
+d'exécuter des tâches périodiques.</description>
+<status>Base</status>
+<sourcefile>mod_watchdog.c</sourcefile>
+<identifier>watchdog_module</identifier>
+<compatibility>Disponible à partir de la version 2.3 du serveur HTTP
+Apache</compatibility>
+
+<summary>
+<p>Le module <module>mod_watchdog</module> définit des
+branchements (hooks) programmés pour permettre à d'autres modules
+d'exécuter des tâches périodiques. Ces modules peuvent enregistrer des
+gestionnaires (handlers) pour les branchements de
+<module>mod_watchdog</module>. Actuellement, seuls les modules suivants
+de la distribution Apache utilisent cette fonctionnalité :</p>
+<ul>
+<li><module>mod_heartbeat</module></li>
+<li><module>mod_heartmonitor</module></li>
+</ul>
+<note type="warning">
+Pour qu'un module puisse utiliser la fonctionnalité de
+<module>mod_watchdog</module>, ce dernier doit être lié statiquement
+avec le serveur httpd ; s'il a été lié dynamiquement, il doit être
+chargé avant l'appel au module qui doit utiliser sa fonctionnalité.
+</note>
+</summary>
+
+<directivesynopsis>
+<name>WatchdogInterval</name>
+<description>Intervalle Watchdog en secondes</description>
+<syntax>WatchdogInterval <var>number-of-seconds</var></syntax>
+<default>WatchdogInterval 1</default>
+<contextlist><context>server config</context></contextlist>
+
+<usage>
+<p>Cette directive permet de définir l'intervalle entre chaque exécution
+du branchement watchdog. La valeur par défaut est de 1 seconde.</p>
+</usage>
+</directivesynopsis>
+</modulesynopsis>
+
--- /dev/null
+<?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 : 1562488 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="log_server_status.xml.meta">
+<parentdocument href="./">Programs</parentdocument>
+
+<title>log_server_status - Enregistrement périodique de l'état du serveur</title>
+
+<summary>
+ <p>Ce script perl a été conçu pour être exécuté à intervalles
+ réguliers via un déclencheur de type cron. Il se connecte au serveur
+ pour en extraire des informations quant à son état. Il formate ces
+ informations sous la forme d'une seule ligne qu'il enregistre dans
+ un fichier. Vous devez éditer la valeur des variables en tête de
+ script afin de définir le chemin du fichier de sortie. Pour que ce
+ script puisse fonctionner, <module>mod_status</module> doit au
+ préalable être chargé et configuré.</p>
+</summary>
+
+<section id="configure"><title>Mode d'emploi</title>
+
+<p>Le script contient les sections suivantes :</p>
+
+<highlight language="perl">
+my $wherelog = "/usr/local/apache2/logs/"; # Le fichier de sortie sera
+ # du style "/usr/local/apache2/logs/19960312"
+my $server = "localhost"; # Nom du serveur, par exemple "www.foo.com"
+my $port = "80"; # Port d'écoute du serveur
+my $request = "/server-status/?auto"; # Requête à soumettre
+</highlight>
+
+<p>Ces variables doivent contenir des valeurs correctes, et le
+gestionnaire <code>/server-status</code> doit être configuré pour le
+répertoire considéré. En outre, l'utilisateur qui exécute le script doit
+avoir les droits d'écriture sur le chemin du fichier de sortie.</p>
+
+<p>L'exécution périodique du script via cron permet d'obtenir un jeu de
+rapports d'état qui pourra être utilisé à des fins d'analyse
+statistique.</p>
+
+</section>
+
+</manualpage>
--- /dev/null
+<?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 : 1562488 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="split-logfile.xml.meta">
+<parentdocument href="./">Programs</parentdocument>
+
+<title>split-logfile - Eclatement des journaux en fonction des serveurs
+virtuels</title>
+
+<summary>
+ <p>Ce script perl permet d'extraire un journal pour chaque serveur
+ virtuel à partir d'un journal d'accès global du serveur web. Pour
+ que ce script fonctionne, le premier champ de chaque ligne du
+ journal global doit contenir l'identité du serveur virtuel ; ce
+ champ aura été ajouté à la directive <directive
+ module="mod_log_config">LogFormat</directive> via la variable
+ "<code>%v</code>".
+ </p>
+</summary>
+
+<section id="split-logfile"><title>Mode d'emploi</title>
+
+ <p>Création d'un fichier journal comportant l'identité du serveur
+ virtuel considéré :</p>
+
+ <highlight language="config">
+LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined_plus_vhost
+CustomLog logs/access_log combined_plus_vhost
+ </highlight>
+
+ <p>Un fichier journal sera créé dans le répertoire à partir duquel
+ vous exécutez le script pour chaque serveur virtuel qui apparaît
+ dans le journal global. Ces fichiers journaux seront nommés à partir
+ du nom du serveur virtuel considéré, avec l'extension
+ <code>.log</code>.</p>
+
+ <p>Le fichier journal global est lu depuis l'entrée standard stdin.
+ Les entrées de ce journal sont alors ajoutées au journal du serveur
+ virtuel correspondant.</p>
+
+ <example>split-logfile < access_log</example>
+
+
+</section>
+
+</manualpage>
--- /dev/null
+<?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 : 1498321 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="suexec.xml.meta">
+<parentdocument href="./">Programs</parentdocument>
+
+<title>suexec - Change d'utilisateur avant l'exécution d'un programme
+externe</title>
+
+<summary>
+ <p><code>suexec</code> permet au serveur HTTP Apache de changer
+ d'utilisateur avant d'exécuter un programme CGI. Pour ce faire, il
+ doit être exécuté par <code>root</code>. A cet effet, comme le
+ démon HTTP ne s'exécute en général pas en tant que
+ <code>root</code>, l'exécutable <code>suexec</code> doit posséder
+ le bit setuid et avoir comme propriétaire <code>root</code>. Seul
+ <code>root</code> doit en posséder les droits en écriture.</p>
+
+ <p>Pour plus d'informations à propos des concepts et du modèle de
+ sécurité du programme suexec, veuillez vous reporter à sa
+ documentation : <a
+ href="http://httpd.apache.org/docs/&httpd.docs;/suexec.html"
+ >http://httpd.apache.org/docs/&httpd.docs;/suexec.html</a>.</p>
+</summary>
+
+<section id="synopsis"><title>Synopsis</title>
+ <p><code><strong>suexec</strong> -<strong>V</strong></code></p>
+</section>
+
+<section id="options"><title>Options</title>
+
+<dl>
+<dt><code>-V</code></dt>
+
+<dd>Si vous êtes <code>root</code>, cette option permet d'afficher les
+options de compilation du programme <code>suexec</code>. Pour des
+raisons de sécurité, toutes les options de configuration ne sont
+modifiables qu'à la compilation.</dd>
+
+</dl>
+</section>
+
+</manualpage>
projects / apache / commitdiff