From: Lucien Gentis
Les en-têtes link des réponses sont soit définis par
l'application, soit configurés via
+
- 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é. + 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.
+ 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. +
+négociation est prise en compte à partir de la version 2.4.39.
Cette directive permet de définir différents délais pour la - réception des en-têtes et corps des requêtes en provenance du - client. Si le client ne parvient pas à respecter ces délais, un code +
Cette directive permet de définir différents timeouts pour la négociation
+ TLS, la réception des en-têtes et/ou corps des requêtes en provenance du
+ client. Si le client ne parvient pas à respecter ces timeouts, un code
d'erreur 408 REQUEST TIME OUT est envoyé.
Pour les serveurs virtuels SSL, le délai concernant les en-têtes - inclut le temps nécessaire à la négociation SSL initiale. Si le - navigateur du client est configuré pour demander des listes de - révocations de certificats, et si le serveur correspondant n'est pas - disponible, le délai avant lequel le navigateur va abandonner son - attente de CRL au cours de la négociation SSL initiale peut être - assez important. Par conséquent, les valeurs de délais d'en-têtes ne - doivent pas être trop basses pour les serveurs virtuels SSL. Le délai - concernant le corps inclut le temps nécessaire à la renégociation - SSL (si elle est nécessaire).
- -Lorsqu'une directive httpready est défini). Le
- délai configuré pour les en-têtes via la directive
-
Il existe deux méthodes pour spécifier le délai (pour l'en-tête - ou le corps) : +
Pour les serveurs virtuels SSL, la valeur de timeout pour la
+ négociation correspond au temps nécessaire pour la négociation
+ SSL initiale. Si le navigateur du client est configuré pour demander des
+ listes de révocations de certificats, et si le serveur correspondant n'est
+ pas disponible, le timeout avant lequel le navigateur va abandonner son
+ attente de CRL au cours de la négociation SSL initiale peut être assez
+ important. Par conséquent, les valeurs de timeouts pour la
+ négociation doivent prendre en compte un temps supplémentaire
+ pour les serveurs virtuels SSL (si nécessaire). Le timeout concernant le
+ corps inclut le temps nécessaire à la renégociation SSL (si elle est
+ nécessaire).
Lorsqu'une directive httpready est défini). Les
+ timeouts configurés pour la négociation et les en-têtes via la directive
+
Il existe trois méthodes pour spécifier le timeout pour chacune des trois + phases (négociation, en-tête ou corps) :
Le temps en secondes alloué pour la lecture des en-têtes ou du - corps de la requête. La valeur 0 signifie aucune limite.
+Le temps en secondes alloué pour terminer l'ensemble de la phase + (négociation, lecture de tous les en-têtes de la requête ou du corps de + cette dernière). La valeur 0 signifie aucune limite.
Avec cet exemple, le module
handshake=0 correspond à la
+ valeur par défaut et peut donc être omis).
Identique à ce qui précède, mais chaque fois que des données sont - reçues, la valeur du délai est augmentée en fonction du taux-mini + reçues, la valeur du timeout est augmentée en fonction du MinRate spécifié (en octets par seconde).
Identique à ce qui précède, mais le délai n'augmentera pas au - delà de la borne supérieure du délai spécifiée.
+Identique à ce qui précède, mais le timeout n'augmentera pas au + delà de la borne supérieure du timeout spécifiée.