Serveur HTTP Apache Version 2.5

Apache > Serveur HTTP > Documentation > Version 2.5 > Modules

# Module Apache mod_http2

Cette traduction peut être périmée. Vérifiez la version anglaise pour les changements récents.

Description: | Support de la couche transport HTTP/2
Statut: | Extension
Identificateur de Module: | http2_module
Fichier Source: | mod_http2.c
Compatibilité: | Disponible à partir de la version 2.4.17 du serveur HTTP Apache

### Sommaire

Ce module ajoute le support de HTTP/2 (RFC 7540) au serveur HTTP Apache.

Il s'appuie sur la bibliothèque libnghttp2 pour implémenter le moteur de base http/2.

Pour mettre en oeuvre les fonctionnalités décrites dans ce document, vous devez activer HTTP/2 en utilisant la directive `Protocols`. HTTP/2 n'imposant pas de chiffrement, deux protocoles sont disponibles : `h2` (HTTP/2 avec TLS) at `h2c` (HTTP/2 avec TCP).

Voici deux types de configuration courant :

### HTTP/2 dans un contexte de serveur virtuel (TLS seulement)

    Protocols h2 http/1.1

Permet une négociation HTTP/2 (h2) via TLS ALPN au sein d'un `<VirtualHost>` sécurisé. La vérification du préambule HTTP/2 (mode direct, voir `H2Direct`) est désactivée par défaut pour `h2`.

### HTTP/2 dans un contexte de serveur (TLS et texte pur)

    Protocols h2 h2c http/1.1

Permet une négociation HTTP/2 (h2) via TLS ALPN au sein d'un `<VirtualHost>` 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 `H2Direct`).

Si vous avez besoin d'informations supplémentaires à propos du protocole, veuillez vous reporter à la HTTP/2 FAQ.

### Sujets

- Comment ça marche ?

### Directives

### Traitement des bugs

- Journal des modifications de httpd
- Problèmes connus
- Signaler un bug

## Comment ça marche ? ¶

### Quantification des ressources supplémentaires nécessaires à HTTP/2

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.

HTTP/2 attribue à chaque requête qu'il reçoit son propre thread de travail 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.

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 `mod_status`. De même, ils ne seront pas pris en compte par les directives du style `ThreadsPerChild`. Par contre, ils utilisent par défaut la valeur de `ThreadsPerChild` si vous n'avez pas spécifié d'autres valeurs via `H2MinWorkers` et `H2MaxWorkers`.

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 : `H2MaxSessionStreams`, `H2WindowSize` et `H2StreamMaxMemSize`.

La directive `H2MaxSessionStreams` 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.

La directive `H2WindowSize` 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.

En outre, la directive `H2StreamMaxMemSize` 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.

### Serveurs virtuels et requêtes mal redirigées

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.

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.

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.

Dans le cas contraire, Apache httpd le détectera et renverra au client un code de réponse spécial, 421 Misdirected Request.

### Variables d'environnement

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 `%{VAR_NAME}e`).

Nom variable : | Type : | Description :
--- | --- | ---
`HTTPe` | drapeau | HTTP/2 est utilisé.
`H2PUSH` | drapeau | La fonctionnalité HTTP/2 Server Push est activée pour cette requête et supportée par le client.
`H2_PUSH` | drapeau | autre nom pour `H2PUSH`
`H2_PUSHED` | chaîne | vide ou `PUSHED` pour une requête pushée par le serveur.
`H2_PUSHED_ON` | nombre | numéro du flux HTTP/2 qui a déclenché le push de cette requête.
`H2_STREAM_ID` | nombre | numéro du flux HTTP/2 de cette requête.
`H2_STREAM_TAG` | chaîne | 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 `-`.

## Directive H2CopyFiles ¶

Description: | Contrôle la gestion des fichiers dans les réponses
Syntaxe: | `H2CopyFiles on|off`
Défaut: | `H2CopyFiles off`
Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées: | FileInfo
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.4.24 du serveur HTTP Apache.

Cette directive permet de définir la manière de gérer les contenus de fichiers dans les réponses. Lorsqu'elle est à `off` (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.

Lorsqu'elle est à `on`, 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.

Un exemple de ces modules tiers : `mod_wsgi` 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 `mod_http2` est probablement encore loin d'en avoir fini avec eux.

## Directive H2Direct ¶

Description: | Activation du protocole H2 Direct
Syntaxe: | `H2Direct on|off`
Défaut: | `H2Direct on pour h2c, off pour le protocole h2`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2

Cette directive permet d'activer/désactiver l'utilisation du mode HTTP/2 Direct. Elle doit être située dans une section `<VirtualHost>` afin d'activer la communication directe HTTP/2 pour le serveur virtuel considéré.

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.

Lorsque le protocole h2 ou h2c n'est pas activé via la directive `Protocols`, la recherche d'un en-tête HTTP/2 n'est jamais effectuée au sein d'une connexion. La directive `H2Direct` 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.

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.

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.

### Exemple

    H2Direct on

## Directive H2EarlyHint ¶

Description: | Ajoute un en-tête de réponse à consulter dans le code de retour 103 Early Hints
Syntaxe: | `H2EarlyHint name value`
Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.5.1 du serveur HTTP Apache.

La directive `H2EarlyHint` permet d'ajouter un en-tête de réponse avant le démarrage du traitement proprement dit de la requête. Les en-têtes de ce style sont consultables dans les réponses intermédiaires "103 Early Hints" et ils ont pour but principal d'envoyer des informations de "préchargement" aux navigateurs clients.

name et value doivent être des champs d'en-tête HTTP valables sous peine de provoquer des échecs de réponse. La directive `H2EarlyHints` doit encore être activée pour permettre l'envoi de réponses intermédiaires de code 103. Elle peut être répétée plusieurs fois et les champs d'en-tête de même nom s'ajoutent.

### Exemple

    H2EarlyHint Link "</my.css>;rel=preload;as=style"

## Directive H2EarlyHints ¶

Description: | Contrôle l'envoi de codes d'état 103
Syntaxe: | `H2EarlyHints on|off`
Défaut: | `H2EarlyHints off`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.4.24 du serveur HTTP Apache.

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.

Lorsque cette directive est définie à `on`, les ressources PUSHées définie par la directive `H2PushResource` déclenchent une réponse intermédiaire 103 avant la réponse finale. Cette réponse 103 comporte des en-têtes `Link` qui provoquent le `préchargement` des ressources considérées.

## Directive H2MaxDataFrameLen ¶

Description: | Nombre maximal d'octets dans une trame HTTP/2 DATA
Syntaxe: | `H2MaxDataFrameLen n`
Défaut: | `H2MaxDataFrameLen 0`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.5.1 du serveur HTTP Apache.

La directive `H2MaxDataFrameLen` permet de définir le nombre maximal d'octets du corps de réponse que l'on peut placer dans une seule trame HTTP/2 DATA. La valeur 0 signifie aucune limite (mais la taille maximale permise par le protocole est respectée).

Par défaut, le module essaie d'utiliser la taille maximale possible qui est d'environ 16 Ko. Il s'agit cependant de la taille maximale, et lorsque la taille des données de la réponse est inférieure, les trames envoyées sont plus courtes.

## Directive H2MaxHeaderBlockLen ¶

Description: | Taille maximale des en-têtes d’une réponse
Syntaxe: | `H2MaxHeaderBlockLen n`
Défaut: | `H2MaxHeaderBlockLen 0`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.5.1 du serveur HTTP Apache.

La directive `H2MaxHeaderBlockLen` permet de définir la taille maximale globale des en-têtes d’une réponse. Définir cette directive à 0 implique une taille maximale de 64 ko dans nghttp2, ce qui correspond à la valeur par défaut.

Les réponses dont la somme des tailles de tous les en-têtes est supérieure à la valeur de cette directive ne seront pas traitées et provoqueront une réinitialisation du flux.

## Directive H2MaxSessionStreams ¶

Description: | Nombre maximal de flux actifs par session HTTP/2.
Syntaxe: | `H2MaxSessionStreams n`
Défaut: | `H2MaxSessionStreams 100`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2

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 `en attente` ni `fermé`.

### Exemple

    H2MaxSessionStreams 20

## Directive H2MaxStreamErrors ¶

Description: | Nombre maximal toléré d’erreurs dues au client
Syntaxe: | `H2MaxStreamErrors n`
Défaut: | `H2MaxStreamErrors 8`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.5.1 du serveur HTTP Apache.

La directive `H2MaxStreamErrors` permet de définir le nombre maximal toléré d’erreurs de flux HTTP/2 causées par le client. Si cette limite est dépassée, la connexion sera fermée. Les erreurs de flux sont des violations du protocole sur un flux HTTP/2 individuel pour lesquelles la spécification du protocole n’exige pas de fermeture de la connexion, mais qui peuvent être un signe d’activité malveillante de la part du client.

Définissez cette directive à 0 pour vous prémunir contre les clients qui provoquent des erreurs.

## Directive H2MaxWorkerIdleSeconds ¶

Description: | Nombre maximal de secondes pendant lequel une unité de traitement h2 pourra rester inactive sans être arrêtée.
Syntaxe: | `H2MaxWorkerIdleSeconds n`
Défaut: | `H2MaxWorkerIdleSeconds 600`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_http2

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 `H2MinWorkers`.

### Exemple

    H2MaxWorkerIdleSeconds 20

## Directive H2MaxWorkers ¶

Description: | Nombre maximal de threads à utiliser pour chaque processus enfant.
Syntaxe: | `H2MaxWorkers n`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_http2

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, `mod_http2` choisira une valeur appropriée en fonction du module `mpm` 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, `mod_http2` will chose a value suitable for the `mpm` module loaded.

### Exemple

    H2MaxWorkers 20

## Directive H2MinWorkers ¶

Description: | Nombre minimal de threads à utiliser pour chaque processus enfant.
Syntaxe: | `H2MinWorkers n`
Contexte: | configuration globale
Statut: | Extension
Module: | mod_http2

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, `mod_http2` choisira une valeur appropriée en fonction du module `mpm` utilisé.

### Exemple

    H2MinWorkers 10

## Directive H2ModernTLSOnly ¶

Description: | Impose les connexions HTTP/2 en mode "TLS moderne" seulement
Syntaxe: | `H2ModernTLSOnly on|off`
Défaut: | `H2ModernTLSOnly on`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.4.18 du serveur HTTP Apache.

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 `<VirtualHost>`.

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.

Le nom provient des définitions Mozilla Security/Server Side TLS 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.

Un des buts de ces vérifications dans `mod_http2` 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.

En fin de compte, la sécurité de la connexion TLS est déterminée par les directives de configuration du serveur pour `mod_ssl`.

### Exemple

    H2ModernTLSOnly off

## Directive H2OutputBuffering ¶

Description: | Contrôle la mise en tampon du flux de sortie
Syntaxe: | `H2OutputBuffering on|off`
Défaut: | `H2OutputBuffering on`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.4.48 du serveur HTTP Apache.

La directive `H2OutputBuffering` permet de contrôler la mise en tampon du flux de sortie. La valeur par défaut est on, ce qui correspond au comportement des versions précédentes. Lorsqu'elle est à off, chaque octet est immédiatement disponible pour envoi au client via la connexion principale. Ceci permet de résoudre les problèmes d'inter-opérations avec certaines versions de gRPC.

## Directive H2Padding ¶

Description: | Spécifie un intervalle de nombres d'octets de bourrage à ajouter aux trames utiles
Syntaxe: | `H2Padding numbits`
Défaut: | `H2Padding 0`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.4.39 du serveur HTTP Apache.

La valeur par défaut 0 indique qu'aucun octet de bourrage ne sera ajouté aux trames utiles comme HEADERS, DATA et PUSH_PROMISE. Ceci correspond au comportement des versions précédentes. Dans ce cas et sous certaines conditions, un observateur du trafic réseau pourra alors déterminer la longueur de ces trames dans le flux TLS.

Si on attribue à numbits la valeur 1-8, un nombre aléatoire d'octets entre 0 et 2^numbits sont ajoutés à chaque trame. Une valeur aléatoire d'octets de bourrage est attribué indépendamment à chaque trame que le module renvoie au client.

Pour améliorer la dissimulation de la longueur des trames, on peut augmenter le nombre moyen d'octets de bourrage, mais cela augmente d'autant le trafic réseau. Le nombre optimal d'octets de bourrage dépend donc du type de trafic web que le serveur engendre.

La valeur par défaut de 0 (aucun octet de bourrage) a été choisie dans un but de compatibilité ascendante. Il peut en effet exister des installations où les octets de bourrage ne sont pas souhaités ou sont néfastes. La cause principale peut provenir d'un client dont l'implémentation comporte des erreurs.

## Directive H2ProxyRequests ¶

Description: | Active/Désactive les requêtes sous mandat direct via HTTP/2
Syntaxe: | `H2ProxyRequests on|off`
Défaut: | `H2ProxyRequests off`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.5.1 du serveur HTTP Apache

La directive `H2ProxyRequests` permet d'activer ou de désactiver la gestion des requêtes HTTP/2 dans un contexte de mandat direct.

Similaire à `ProxyRequests`, cette directive déclenche le traitement nécessaire des requêtes lorsque HTTP/2 est activé dans un contexte de mandat direct.

## Directive H2Push ¶

Description: | Activation/désactivation du server push H2
Syntaxe: | `H2Push on|off`
Défaut: | `H2Push on`
Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.4.18 du serveur HTTP Apache.

Cette directive permet d'activer/désactiver l'utilisation de la fonctionnalité server push du protocole HTTP/2.

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.

Les server pushes sont détectés en inspectant les en-têtes `Link` 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 `rel=preload`, il est considéré comme devant faire l'objet d'un push.

Les en-têtes link des réponses sont soit définis par l'application, soit configurés via la directive `H2PushResource` ou en utilisant `mod_headers` comme suit :

### Exemple de configuration d'en-tête link via mod_headers

    <Location /index.html>
        Header add Link "</css/site.css>;rel=preload"
        Header add Link "</images/logo.jpg>;rel=preload"
    </Location>

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.

Les PUSH HTTP/2 sont activés par défaut. Vous pouvez activer/désactiver cette fonctionnalité pour toute connexion au serveur au niveau global ou serveur virtuel. Vous pouvez en outre désactiver PUSH pour un jeu de ressources dans une section Directory/Location. Notez que ceci permet de contrôler quelles ressources peuvent déclencher un PUSH, mais pas les ressources qui peuvent être envoyées via PUSH.

### Exemple

    H2Push off

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 autorité que celle de la réponse originale.

## Directive H2PushDiarySize ¶

Description: | Taille du journal des Pushes H2
Syntaxe: | `H2PushDiarySize n`
Défaut: | `H2PushDiarySize 256`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.4.19 du serveur HTTP Apache.

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 `<VirtualHost>` afin de définir le nombre de pushes pour le serveur virtuel considéré.

Le journal des pushes enregistre un condensé 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.

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.

Si cette directive est définie à 0, le journal des pushes est désactivé.

## Directive H2PushPriority ¶

Description: | Priorité des pushes H2
Syntaxe: | `H2PushPriority mime-type [after|before|interleaved] [weight]`
Défaut: | `H2PushPriority * After 16`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | 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.

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.

Les pushes HTTP/2 sont toujours liés à une requête client. Chaque paire requête/réponse de cette sorte, ou flux, possède une dépendance et un poids qui définissent la priorité du flux.

Lorsqu'un flux dépend 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.

Lorsque plusieurs flux dépendent d'un même autre flux, disons X1 et X2 dépendent tous deux de Y, le poids 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.

En fin de compte, tout flux dépend du flux racine 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.

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.

Seul le fait de savoir qu'un flux implique un PUSH permet au serveur de décider quelle est la priorité initiale 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.

La règle de priorité par défaut est :

### Règle de priorité par défaut

    H2PushPriority * After 16

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.

### Règle de priorité entrelacée

    H2PushPriority text/css Interleaved 256

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 : `P1ew = Xw * (P1w / 256)`. 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.

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.

### Règle de priorité Before

    H2PushPriority application/json Before

Dans cet exemple, tout flux PUSHé dont le contenu est de type 'application/json' sera envoyé avant 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.

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.

Enfin et surtout, il convient de tenir compte de certaines particularités de la syntaxe de cette directive :

1. '*' est la seule expression permettant de remplacer tout type de contenu. 'image/*' ne fonctionnera pas.
2. La dépendance par défaut est 'After'.
3. Il existe aussi des poids par défaut : pour 'After' le poids est de 16, alors que pour 'interleaved' il est de 256.

### Exemples de règles

    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

## Directive H2PushResource ¶

Description: | Déclare des ressources à proposer ("pusher") au client
Syntaxe: | `H2PushResource [add] path [critical]`
Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess
Surcharges autorisées: | FileInfo
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.4.24 du serveur HTTP Apache.

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.

Cette directive propose des ressources beaucoup plus tôt que les en-têtes `Link` de `mod_headers`. `mod_http2` présente ces ressources au client via une réponse intermédiaire `103 Early Hints`. Ceci implique que les clients qui ne supportent pas PUSH recevront quand-même rapidement des propositions de préchargement.

A la différence de la définition d'en-têtes de réponse `Link` via `mod_headers`, cette directive n'aura d'effet que pour les connexions HTTP/2.

En ajoutant l'option `critical` à 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.

## Directive H2SerializeHeaders ¶

Description: | Active/désactive la sérialisation du traitement des requêtes/réponses
Syntaxe: | `H2SerializeHeaders on|off`
Défaut: | `H2SerializeHeaders off`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2

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 `httpd`, ou si les données binaires reçues doivent être passées directement aux `request_rec`s.

La sérialisation dégrade les performances, mais garantit une meilleure compatibilité ascendante lorsque des filtres ou programmes accroche personnalisés en ont besoin.

### Exemple

    H2SerializeHeaders on

## Directive H2StreamMaxMemSize ¶

Description: | Quantité maximale de données en sortie mises en tampon par flux.
Syntaxe: | `H2StreamMaxMemSize bytes`
Défaut: | `H2StreamMaxMemSize 65536`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2

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.

### Exemple

    H2StreamMaxMemSize 128000

## Directive H2StreamTimeout ¶

Description: | Temps d'attente maximum lors de l'envoi/réception de données pour le traitement d'un flux
Syntaxe: | `H2StreamTimeout time-interval[s]`
Défaut: | `La valeur de la directive `Timeout``
Contexte: | configuration globale, serveur virtuel, répertoire
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.5.1 du serveur HTTP Apache.

`H2StreamTimeout` permet de spécifier le temps maximum pendant lequel un flux en cours de traitement attendra pour l'envoi/réception de ses données.

## Directive H2TLSCoolDownSecs ¶

Description: | Durée d'inactivité d'une connexion TLS avant diminution de la taille des paquets
Syntaxe: | `H2TLSCoolDownSecs seconds`
Défaut: | `H2TLSCoolDownSecs 1`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.4.18 du serveur HTTP Apache.

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 `<serveur virtuel>` spécifique.

Voir la directive `H2TLSWarmUpSize` pour une description du "préchauffage" de TLS. La directive `H2TLSCoolDownSecs` 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.

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.

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.

### Exemple

    H2TLSCoolDownSecs 0

## Directive H2TLSWarmUpSize ¶

Description: | Taille des paquets durant la phase initiale de la connexion TLS
Syntaxe: | `H2TLSWarmUpSize amount`
Défaut: | `H2TLSWarmUpSize 1048576`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.4.18 du serveur HTTP Apache.

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 `<Serveurs virtuels>` spécifiques.

Les mesures effectuées par les laboratoires de performances de Google 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 totalité d'un enregistrement d'entrer dans un paquet IP.

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.

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.

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".

Dans l'exemple suivant, la phase de chauffage est effectivement désactivée en définissant la directive à 0.

### Exemple

    H2TLSWarmUpSize 0

## Directive H2Upgrade ¶

Description: | Activation/Désactivation du protocole de mise à jour H2
Syntaxe: | `H2Upgrade on|off`
Défaut: | `H2Upgrade on pour h2c, off pour h2`
Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess
Statut: | Extension
Module: | mod_http2

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 `<VirtualHost>` afin d'activer la mise à jour vers HTTP/2 pour le serveur virtuel considéré.

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.

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.

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 `H2Direct` pour envisager une alternative à Upgrade.

Cette directive n'a d'effet que si h2 ou h2c est activé via la directive `Protocols`.

### Exemple

    H2Upgrade on

## Directive H2WebSockets ¶

Description: | Active/désactive les WebSockets via HTTP/2
Syntaxe: | `H2WebSockets on|off`
Défaut: | `H2WebSockets off`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2
Compatibilité: | Disponible à partir de la version 2.5.1 du serveur HTTP Apache

La directive `H2WebSockets` permet d'activer ou de désactiver l'amorçage des WebSockets via le protocole HTTP/2. Cette extension du protocole est définie dans la RFC 8441.

Ces requêtes sont similaires à CONNECT, mais elles possèdent l'en-tête supplémentaire ':protocol'. Elles sont transformées au sein du module en leurs équivalents HTTP/1.1 avant d'être soumises au traitement interne.

Cela signifie que les WebSockets HTTP/2 peuvent être utilisés dans le cadre d'une directive `ProxyPass` avec le paramètre 'upgrade=websocket' sans autres modifications.

Pour les modules tiers qui gèrent les WebSockets directement dans le serveur, l'amorçage du protocole lui-même fonctionnera aussi. Dans le cas de HTTP/2 cependant, le transfert de données nécessite une prise en charge supplémentaire. Le WebSocket négocié sera incapable d'utiliser le socket de connexion du client pour examiner les évènements d'entrée/sortie concernés.

Cette fonctionnalité étant susceptible de briser la compatibilité ascendante pour de tels modules tiers, elle n'est pas activée par défaut.

## Directive H2WindowSize ¶

Description: | Taille maximale des paquets de données pour les transmissions client vers serveur.
Syntaxe: | `H2WindowSize bytes`
Défaut: | `H2WindowSize 65535`
Contexte: | configuration globale, serveur virtuel
Statut: | Extension
Module: | mod_http2

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).

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.

### Exemple

    H2WindowSize 128000