diff options
| -rw-r--r-- | docs/manual/mod/mod_crypto.xml.fr | 292 | ||||
| -rw-r--r-- | docs/manual/mod/mod_crypto.xml.meta | 1 | ||||
| -rw-r--r-- | docs/manual/mod/mod_firehose.xml.fr | 294 | ||||
| -rw-r--r-- | docs/manual/mod/mod_firehose.xml.meta | 1 | ||||
| -rw-r--r-- | docs/manual/mod/mod_http2.xml.fr | 1201 | ||||
| -rw-r--r-- | docs/manual/mod/mod_http2.xml.meta | 1 |
6 files changed, 1790 insertions, 0 deletions
diff --git a/docs/manual/mod/mod_crypto.xml.fr b/docs/manual/mod/mod_crypto.xml.fr new file mode 100644 index 0000000000..62d28026f7 --- /dev/null +++ b/docs/manual/mod/mod_crypto.xml.fr @@ -0,0 +1,292 @@ +<?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> diff --git a/docs/manual/mod/mod_crypto.xml.meta b/docs/manual/mod/mod_crypto.xml.meta index 6e247337bd..4872ae3416 100644 --- a/docs/manual/mod/mod_crypto.xml.meta +++ b/docs/manual/mod/mod_crypto.xml.meta @@ -8,5 +8,6 @@ <variants> <variant>en</variant> + <variant>fr</variant> </variants> </metafile> diff --git a/docs/manual/mod/mod_firehose.xml.fr b/docs/manual/mod/mod_firehose.xml.fr new file mode 100644 index 0000000000..d0b7f54d62 --- /dev/null +++ b/docs/manual/mod/mod_firehose.xml.fr @@ -0,0 +1,294 @@ +<?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> diff --git a/docs/manual/mod/mod_firehose.xml.meta b/docs/manual/mod/mod_firehose.xml.meta index af0e693035..a4d9b06666 100644 --- a/docs/manual/mod/mod_firehose.xml.meta +++ b/docs/manual/mod/mod_firehose.xml.meta @@ -8,5 +8,6 @@ <variants> <variant>en</variant> + <variant>fr</variant> </variants> </metafile> diff --git a/docs/manual/mod/mod_http2.xml.fr b/docs/manual/mod/mod_http2.xml.fr new file mode 100644 index 0000000000..7a6025db53 --- /dev/null +++ b/docs/manual/mod/mod_http2.xml.fr @@ -0,0 +1,1201 @@ +<?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> diff --git a/docs/manual/mod/mod_http2.xml.meta b/docs/manual/mod/mod_http2.xml.meta index 500e9da4cb..0e02fed505 100644 --- a/docs/manual/mod/mod_http2.xml.meta +++ b/docs/manual/mod/mod_http2.xml.meta @@ -8,5 +8,6 @@ <variants> <variant>en</variant> + <variant>fr</variant> </variants> </metafile> |