--- /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"?>
+<!-- $LastChangedRevision: 1752104 $ -->
+<!-- English Revision : 1752104 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- $LastChangedRevision: 2017021901 $ -->
+
+<!--
+ 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_crypto.xml.meta">
+
+<name>mod_crypto</name>
+<description>Support du chiffrement/déchiffrement symétrique</description>
+<status>Extension</status>
+<sourcefile>mod_crypto.c</sourcefile>
+<identifier>crypto_module</identifier>
+<compatibility>Disponible à partir de la version 2.5 du serveur HTTP Apache</compatibility>
+
+<summary>
+ <p>Ce module permet de <strong>chiffrer et déchiffrer</strong> les données au
+ niveau des piles de filtrage en entrée et en sortie.</p>
+
+ <p>En particulier, il permet d'effectuer un <strong>chiffrement HLS à la
+ volée</strong> comme décrit dans le document <a
+ href="http://www.ietf.org/id/draft-pantos-http-live-streaming-19.txt">draft-pantos-http-live-streaming-19</a>.</p>
+
+ <p>Mais il peut aussi assurer la livraison sécurisée de données via un CDN
+ non sécurisé aux clients qui le supportent.</p>
+
+ <p>Selon les besoins, on peut ajouter le filtre crypto à la pile de filtrage
+ en entrée ou en sortie via les directives <directive
+ module="core">SetInputFilter</directive>, <directive
+ module="core">SetOutputFilter</directive>, <directive
+ module="mod_mime">AddOutputFilter</directive> ou <directive
+ module="mod_filter">AddOutputFilterByType</directive>.</p>
+
+</summary>
+<seealso><a href="../filter.html">Filtres</a></seealso>
+
+<section id="format">
+ <title>Format du flux de données</title>
+
+ <p>Le flux de données chiffrées comporte un bloc IV optionnel suivi des
+ données chiffrées avec l'algorithme de chiffrement choisi. Le bloc final est
+ éventuellement complété par bourrage avant d'être écrit. La taille des blocs
+ est déterminée par l'algorithme de chiffrement choisi.</p>
+
+ <p>Lorsque le bloc IV est spécifié via la directive <directive
+ module="mod_crypto">CryptoIV</directive>, il est utilisé, mais n'est pas
+ injecté dans le flux d'entrée/sortie.</p>
+
+</section>
+
+<section id="config">
+ <title>Clés et blocs IV</title>
+
+ <p>Les directives <directive module="mod_crypto">CryptoKey</directive> et
+ <directive module="mod_crypto">CryptoIV</directive> acceptent comme
+ arguments des valeurs binaires qui peuvent être spécifiées comme indiqué
+ ci-après. Les bits les plus significatifs de ces valeurs sont utilisés, et
+ si les valeurs sont trop petites, elles sont complétées par bourrage avec
+ des bits à 0 par la gauche.
+ </p>
+
+ <dl>
+ <dt>file:</dt><dd>La valeur est lue directement depuis le fichier spécifié.</dd>
+ <dt>hex:</dt><dd>Interprète l'expression en tant que valeur hexadécimale qui
+ peut contenir des caractères ':' comme séparateurs.</dd>
+ <dt>decimal:</dt><dd>Interprète l'expression en tant que valeur décimale.</dd>
+ <dt>base64:</dt><dd>Interprète l'expression en tant que valeur codée en
+ base64.</dd>
+ <dt>none</dt><dd>Aucune valeur n'est spécifiée.</dd>
+ </dl>
+
+ <p>Si le IV n'est pas spécifié, un IV aléatoire sera généré au cours du
+ chiffrement et écrit comme premier bloc. Lors du déchiffrement, le premier
+ bloc sera interprété en tant que IV.
+ </p>
+
+ <p>A l'exception du format file:, les directives <directive
+ module="mod_crypto">CryptoKey</directive> et <directive
+ module="mod_crypto">CryptoIV</directive> supportent la <a
+ href="../expr.html">syntaxe des expressions</a> qui fournit plus de
+ flexibilité pour définir les valeurs. Les clés et IVs peuvent ainsi être
+ initialisées aléatoirement via des valeurs disponibles au niveau du serveur
+ web comme REMOTE_USER ou l'URL.
+ </p>
+
+</section>
+
+<section id="handler">
+ <title>Gestionnaire de clé de chiffrement</title>
+
+ <p>Le gestionnaire <strong>crypto-key</strong> permet de fournir la clé aux
+ clients autorisés qui le supportent sans avoir à stocker cette dernière dans
+ l'arborescence du serveur web. La même <a href="../expr.html">syntaxe
+ d'expression</a> peut ainsi être utilisée afin d'obtenir la clé pour les
+ clients et pour le contenu chiffré.</p>
+
+ <example><title>Gestionnaire de clé de chiffrement avec un fichier</title>
+ <Location /key><br />
+ <indent>
+ SetHandler crypto-key<br />
+ CryptoCipher aes128<br />
+ CryptoKey file:/path/to/file.key<br />
+ AuthType basic<br />
+ ...<br />
+ </indent>
+ </Location><br />
+ </example>
+
+</section>
+
+<section id="hls">
+ <title>HTTP Live Streaming (HLS)</title>
+
+ <p>Le protocole HLS supporte les flux chiffrés qui utilisent l'algorithme de
+ chiffrement AES-128 et une clé correspondante. On autorise l'accès au flux
+ en partageant la clé avec le client HLS en général via une connexion
+ sécurisée.</p>
+
+ <p>Le IV utilisé pour le chiffrement de chaque segment de media est spécifié
+ dans HLS de deux manières :</p>
+
+ <ul>
+ <li>
+ Spécifié explicitement via un attribut IV dans le tag EXT-X-KEY sous
+ la forme d'une valeur <strong>hexadécimale</strong>.
+ </li>
+ <li>
+ Spécifié implicitement en interprétant la valeur
+ <strong>décimale</strong> du tag EXT-X-MEDIA-SEQUENCE.
+ </li>
+ </ul>
+
+ <p>La valeur de la séquence de media est en générale incorporée dans les
+ noms de segment de média et peut être recherchée en utilisant des
+ expressions rationnelles nommées comme dans l'exemple ci-dessous.
+ </p>
+
+ <example><title>Exemple HLS - IV de la séquence de média</title>
+ <LocationMatch (?<SEQUENCE>[\d]+)[^\d^/]+$><br />
+ <indent>
+ SetOutputFilter ENCRYPT<br />
+ CryptoCipher aes128<br />
+ CryptoKey file:/path/to/file.key<br />
+ CryptoIV decimal:%{env:MATCH_SEQUENCE}<br />
+ </indent>
+ </LocationMatch><br />
+ </example>
+
+</section>
+
+<directivesynopsis>
+<name>CryptoDriver</name>
+<description>Nom du pilote crypto à utiliser</description>
+<syntax>CryptoDriver name</syntax>
+<default>CryptoDriver openssl</default>
+<contextlist><context>server config</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive module="mod_crypto">CryptoDriver</directive>
+ permet de spécifier le nom du pilote crypto à utiliser. Un pilote recommandé
+ par défaut est en général défini pour chaque plateforme. Les pilotes
+ supportés sont <strong>openssl</strong>, <strong>commoncrypto</strong> et
+ <strong>nss</strong>.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CryptoCipher</name>
+<description>L'algorithme de chiffrement que le filtre crypto doit utiliser</description>
+<syntax>CryptoCipher name</syntax>
+<default>CryptoCipher aes256</default>
+<contextlist><context>server config</context>
+<context>virtual host</context>
+<context>directory</context>
+<context>.htaccess</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive>CryptoCipher</directive> permet de spécifier
+ l'algorithme de chiffrement à utiliser au cours des phases de chiffrement et
+ de déchiffrement. L'algorithme de chiffrement par défaut est
+ <code>aes256</code>.</p>
+
+ <p>C'est le pilote crypto utilisé qui détermine l'étendue du choix des algorithmes de
+ chiffrement parmi les valeurs possibles suivantes :</p>
+
+ <ul><li>3des192</li><li>aes128</li><li>aes192</li><li>aes256</li></ul>
+
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CryptoIV</name>
+<description>Le Vecteur d'Initialisation IV (Initialisation Vector) que le
+filtre crypto doit utiliser</description>
+<syntax>CryptoIV value</syntax>
+<default>CryptoIV none</default>
+<contextlist><context>server config</context>
+<context>virtual host</context>
+<context>directory</context>
+<context>.htaccess</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive>CryptoIV</directive> permet de spécifier le IV
+ (Initialisation Vector) pour l'espace d'URL considéré. Le IV peut être lu à
+ partir d'un fichier ou défini via l'<a href="../expr.html">interpréteur
+ d'expressions</a>, ce qui confère plus de souplesse aux scénarios de
+ définition des clés.</p>
+
+ <p>Les valeurs possibles peuvent être lues depuis un fichier ou exprimées
+ sous une forme hexadécimale, décimale ou en base64 en fonction des préfixes
+ suivants :</p>
+
+ <ul><li>file:</li><li>hex:</li><li>decimal:</li><li>base64:</li></ul>
+
+ <p>La valeur 'none' désactive la définition du IV. Dans ce cas, un IV
+ aléatoire sera généré durant le chiffrement et inséré en tant que premier
+ bloc ; au cours du déchiffrement, le premier bloc sera interprété comme bloc
+ IV.</p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CryptoKey</name>
+<description>Clé que le filtre crypto doit utiliser</description>
+<syntax>CryptoKey value</syntax>
+<default>CryptoKey none</default>
+<contextlist><context>server config</context>
+<context>virtual host</context>
+<context>directory</context>
+<context>.htaccess</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive>CryptoKey</directive> permet de spécifier la clé
+ de chiffrement/déchiffrement pour l'espace d'URL considéré. La clé peut être
+ lue depuis un fichier ou défini via l'<a href="../expr.html">interpréteur
+ d'expressions</a>, ce qui confère plus de souplesse aux scénarios de
+ définition des clés.</p>
+
+ <p>Les valeurs possibles peuvent être lues depuis un fichier ou exprimées
+ sous une forme hexadécimale, décimale ou en base64 en fonction des préfixes
+ suivants :</p>
+
+ <ul><li>file:</li><li>hex:</li><li>decimal:</li><li>base64:</li></ul>
+
+ <p>La valeur 'none' désactive la clé. Toute requête pour obtenir sans clé un fichier
+ via les filtres ENCRYPT ou DECRYPT se soldera alors par un échec. </p>
+</usage>
+</directivesynopsis>
+
+<directivesynopsis>
+<name>CryptoSize</name>
+<description>Taille maximale en octets du tampon utilisé par le filtre crypto</description>
+<syntax>CryptoSize integer</syntax>
+<default>CryptoSize 131072</default>
+<contextlist><context>server config</context>
+<context>virtual host</context>
+<context>directory</context>
+<context>.htaccess</context>
+</contextlist>
+
+<usage>
+ <p>La directive <directive module="mod_crypto">CryptoSize</directive> permet
+ de spécifier la quantité de données en octets qui sera mise en tampon pour
+ chaque requête avant d'être chiffrée ou déchiffrée. La valeur par défaut est
+ 128 Ko.</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 : 1673947 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- $LastChangedRevision: 2015042601 $ -->
+
+<!--
+ 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_firehose.xml.meta">
+
+<name>mod_firehose</name>
+<description>Multiplexage des entrées/sorties vers un fichier ou un pipe.</description>
+<status>Extension</status>
+<sourcefile>mod_firehose.c</sourcefile>
+<identifier>firehose_module</identifier>
+
+<summary>
+ <p><code>mod_firehose</code> fournit un mécanisme permettant
+ d'enregistrer les données transmises entre le serveur httpd et le
+ client au niveau élémentaire de la connexion dans un fichier ou un
+ pipe, de façon à ce que les données puissent être analysées ou
+ rejouées ultérieurement par le serveur. Il s'apparente à un "tcpdump
+ pour httpd".</p>
+
+ <p>Les connexions sont enregistrées après décodage de la couche SSL,
+ et peuvent ainsi être utilisées dans le cadre d'une réquisition
+ légale.</p>
+
+ <p>L'utilitaire <program>firehose</program> permet en retour de
+ démultiplexer le flux enregistré dans des fichiers individuels pour
+ analyse ou rejeu via des outils tels que <code>netcat</code>.</p>
+
+ <note><title>AVERTISSEMENT</title>Ce module ignore tout mécanisme
+ invoqué au niveau de la requête pour rendre les données privées. Il
+ est donc de la responsabilité de l'administrateur de s'assurer que
+ les données privées ne seront pas compromises par son utilisation.
+ </note>
+
+</summary>
+<seealso><program>firehose</program></seealso>
+
+<section id="enable">
+ <title>Activation de la "Lance à incendie" (Firehose)</title>
+
+ <p>Pour activer ce module, il doit être compilé et chargé via la
+ configuration de votre instance httpd courante, et les directives
+ ci-dessous permettent de sélectionner les données que vous souhaitez
+ enregistrer.</p>
+
+ <p>Il est possible d'enregistrer les données entrantes et sortantes
+ dans le même fichier, car la direction du flux est indiquée dans
+ chaque fragment.</p>
+
+ <p>Il est possible d'écrire vers des fichiers normaux ou des listes
+ fifos (pipes). Dans le cas des listes fifos, mod_firehose fait en
+ sorte que la taille des paquets ne dépasse pas la valeur de PIPE_BUF
+ afin de s'assurer que l'écriture de ces derniers s'effectue en une
+ seule fois.</p>
+
+ <p>Si une liste fifo sous forme de pipe doit être utilisée, pour que
+ cette dernière soit ouverte en écriture, certaines données doivent
+ en être extraites avant le démarrage de httpd. Si l'ouverture du
+ pipe échoue, mod_firehose ne sera pas activé, et le serveur sera
+ lancé normalement.</p>
+
+ <p>Par défaut, toute tentative d'écriture bloque le serveur. Si le
+ serveur a été compilé avec APR version 2.0 ou supérieure, et si le
+ paramètre "nonblock" a été spécifié, les écritures dans les fichiers
+ seront non blocantes, et tout dépassement de tampon entraînera la
+ perte des données de débogage. Dans ce cas, il est possible donner
+ la priorité à l'exécution du serveur sur l'enregistrement des
+ données firehose.</p>
+
+</section>
+
+<section id="format">
+ <title>Format du flux</title>
+
+ <p>En général, le serveur gère plusieurs connexions simultanément,
+ et de ce fait, les requêtes et les réponses doivent être
+ multiplexées avant d'être écrites dans le firehose.</p>
+
+ <p>Chaque fragment se présente sous la forme d'un texte en clair
+ de façon à ce qu'un firehose puisse être ouvert et inspecté par un
+ éditeur de texte standard. Il est aussi possible d'utiliser
+ l'utilitaire <program>firehose</program> pour démultiplexer le
+ firehose en requêtes ou connexions individuelles.</p>
+
+ <p>La taille maximale des fragments multiplexés est définie par la
+ variable PIPE_BUF. Elle correspond à la taille maximale d'un
+ élément que le système peut écrire. Si la taille des fragments
+ multiplexés reste en dessous de PIPE_BUF, le module garantit que les
+ contenus des différents fragments ne se recouperont pas. La valeur
+ de PIPE_BUF varie en fonction du système d'exploitation.</p>
+
+ <p>La BNF du format du fragment est la suivante :</p>
+
+ <pre>
+ stream = 0*(fragment)
+
+ fragment = header CRLF body CRLF
+
+ header = length SPC timestamp SPC ( request | response ) SPC uuid SPC count
+
+ length = <longueur de fragment sur 16 octets hexadécimaux>
+ timestamp = <temps depuis 1970 en microsecondes sur 16 octets hexadécimaux>
+ request = "<"
+ response = ">"
+ uuid = <uuid formaté de la connexion>
+ count = <numéro hexadécimal du fragment dans la connexion>
+
+ body = <contenu binaire du fragment>
+
+ SPC = <un espace>
+ CRLF = <un retour chariot suivi d'une nouvelle ligne>
+ </pre>
+
+ <p>Tous les fragments d'une connexion ou d'une requête partagent le
+ même UUID, selon que les connexions ou les requêtes sont
+ enregistrées ou non. Si les connexions sont enregistrées, plusieurs
+ requêtes peuvent apparaître dans la même connexion. Un fragment de
+ longueur nulle indique la fin de la connexion.</p>
+
+ <p>Certains fragments peuvent manquer ou être supprimés si le
+ processus qui les lit est trop lent. Si cela se produit, il y aura
+ des trous dans le comptage des connections. Un avertissement
+ indiquant l'UUID et le numéro du fragment supprimé sera enregistré
+ dans le journal des erreurs.</p>
+
+ <p>En cas de crash ou d'arrêt forcé du processus httpd, il est
+ possible que le fragment vide de terminaison n'apparaisse pas. Cela
+ peut aussi se produire si le processus qui lit les fragments n'est
+ pas assez rapide.</p>
+
+</section>
+
+<directivesynopsis>
+
+<name>FirehoseConnectionInput</name>
+<description>Capture le trafic entrant dans le serveur à chaque
+connexion.</description>
+<syntax>FirehoseConnectionInput <var>[ block | nonblock ]</var> <var>filename</var></syntax>
+<default>none</default>
+<contextlist><context>server config</context></contextlist>
+<compatibility>Disponible à partir de la version 2.5.0 du serveur HTTP
+Apache.</compatibility>
+
+<usage>
+ <p>Capture le trafic entrant dans le serveur à chaque connexion.
+ Plusieurs requêtes seront capturées pour la même connexion si les
+ connexions persistantes sont activées.</p>
+
+ <example><title>Exemple</title>
+ <highlight language="config">
+ FirehoseConnectionInput connection-input.firehose
+ </highlight>
+ </example>
+</usage>
+
+</directivesynopsis>
+
+<directivesynopsis>
+
+<name>FirehoseConnectionOutput</name>
+<description>Capture le trafic sortant du serveur à chaque connexion</description>
+<syntax>FirehoseConnectionOutput <var>[ block | nonblock ]</var> <var>filename</var></syntax>
+<default>none</default>
+<contextlist><context>server config</context></contextlist>
+<compatibility>Disponible à partir de la version 2.5.0 du serveur HTTP
+Apache.</compatibility>
+
+<usage>
+ <p>Capture le trafic sortant du serveur à chaque connexion.
+ Plusieurs requêtes seront capturées pour la même connexion si les
+ connexions persistantes sont activées.
+ </p>
+
+ <example><title>Exemple</title>
+ <highlight language="config">
+ FirehoseConnectionOutput connection-output.firehose
+ </highlight>
+ </example>
+</usage>
+
+</directivesynopsis>
+
+<directivesynopsis>
+
+<name>FirehoseRequestInput</name>
+<description>Capture le trafic entrant dans le serveur à chaque requête</description>
+<syntax>FirehoseRequestInput <var>[ block | nonblock ]</var> <var>filename</var></syntax>
+<default>none</default>
+<contextlist><context>server config</context></contextlist>
+<compatibility>Disponible à partir de la version 2.5.0 du serveur HTTP
+Apache.</compatibility>
+
+<usage>
+ <p>Capture le trafic entrant dans le serveur à chaque requête. Les
+ requêtes sont capturées séparément, que les connexions persistantes
+ soient activées ou non.</p>
+
+ <example><title>Exemple</title>
+ <highlight language="config">
+ FirehoseRequestInput request-input.firehose
+ </highlight>
+ </example>
+</usage>
+
+</directivesynopsis>
+
+<directivesynopsis>
+
+<name>FirehoseRequestOutput</name>
+<description>Capture le trafic sortant du serveur à chaque requête</description>
+<syntax>FirehoseRequestOutput <var>[ block | nonblock ]</var> <var>filename</var></syntax>
+<default>none</default>
+<contextlist><context>server config</context></contextlist>
+<compatibility>Disponible à partir de la version 2.5.0 du serveur HTTP
+Apache.</compatibility>
+
+<usage>
+ <p>Capture le trafic sortant du serveur à chaque requête. Les
+ requêtes sont capturées séparément, que les connexions persistantes
+ soient activées ou non.</p>
+
+ <example><title>Exemple</title>
+ <highlight language="config">
+ FirehoseRequestOutput request-output.firehose
+ </highlight>
+ </example>
+</usage>
+
+</directivesynopsis>
+
+<directivesynopsis>
+
+<name>FirehoseProxyConnectionInput</name>
+<description>Capture le trafic entrant dans mod_proxy</description>
+<syntax>FirehoseProxyConnectionInput <var>[ block | nonblock ]</var> <var>filename</var></syntax>
+<default>none</default>
+<contextlist><context>server config</context></contextlist>
+<compatibility></compatibility>
+
+<usage>
+ <p>Capture le trafic reçu par mod_proxy.</p>
+
+ <example><title>Exemple</title>
+ <highlight language="config">
+ FirehoseProxyConnectionInput proxy-input.firehose
+ </highlight>
+ </example>
+</usage>
+
+</directivesynopsis>
+
+<directivesynopsis>
+
+<name>FirehoseProxyConnectionOutput</name>
+<description>Capture le trafic envoyé par mod_proxy</description>
+<syntax>FirehoseProxyConnectionOutput <var>[ block | nonblock ]</var> <var>filename</var></syntax>
+<default>none</default>
+<contextlist><context>server config</context></contextlist>
+<compatibility>Disponible à partir de la version 2.5.0 du serveur HTTP
+Apache.</compatibility>
+
+<usage>
+ <p>Capture le trafic envoyé par mod_proxy.</p>
+
+ <example><title>Exemple</title>
+ <highlight language="config">
+ FirehoseProxyConnectionOutput proxy-output.firehose
+ </highlight>
+ </example>
+</usage>
+
+</directivesynopsis>
+
+</modulesynopsis>
--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
+<!-- English Revision : 1793934 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- $LastChangedRevision: 2017050601 $ -->
+
+<!--
+ 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>
+
+ <note type="warning"><title>Avertissement</title>
+ <p>Ce module en est au stade expérimental. Ses comportements,
+ directives et valeurs par défaut sont susceptibles d'évoluer
+ au fur et à mesure de la parution de ses futures différentes
+ versions en relation avec les autres modules standards. Les
+ utilisateurs sont fortement encouragés à consulter le fichier
+ "CHANGES" pour les éventuelles mises à jour.</p>
+ </note>
+
+ <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>
+ <override>FileInfo</override>
+ <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>
+ <override>FileInfo</override>
+ <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>