RFC(F) 7540

From RFC.Wiki
Jump to: navigation, search
Groupe de travail sur l'ingénierie Internet (IETF)             M. Belshe
Demande de commentaires: 7540                                      BitGo
Catégorie: Standards Track                                       R. Peon
ISSN: 2070-1721                                              Google, Inc
                                                         M. Thomson, éd.
                                                                 Mozilla
                                                                Mai 2015


             Protocole de transfert hypertexte version 2 (HTTP / 2)

Abstrait

   Ce [[Fichier: spécification]] décrit une expression optimisée de la sémantique
   du protocole HTTP (Hypertext Transfer Protocol), appelé HTTP
   version 2 (HTTP / 2). HTTP / 2 permet une utilisation plus efficace du réseau
   ressources et une perception réduite de la latence en introduisant l'en-tête
   compression de champ et permettant plusieurs échanges simultanés sur le
   même connexion. Il introduit également une poussée non sollicitée de
   représentations des serveurs aux clients.

   Cette spécification est une alternative, mais n'est pas obsolète, à la
   Syntaxe des messages HTTP / 1.1. La sémantique existante de HTTP reste inchangée.

Statut de ce mémo

   Il s'agit d'un document Internet Standards Track.

   Ce document est un produit de l'Internet Engineering Task Force
   (IETF). Il représente le consensus de la communauté IETF. Il a
   a fait l'objet d'un examen public et a été approuvé pour publication par le
   Groupe de pilotage de l'ingénierie Internet (IESG). Plus d'informations sur
   Internet Standards est disponible dans la section 2 de la RFC 5741.

   Informations sur l'état actuel de ce document, tout errata,
   et comment fournir des commentaires à ce sujet peuvent être obtenus à
   http://www.rfc-editor.org/info/rfc7540.

Copyright

   Copyright (c) 2015 IETF Trust et les personnes identifiées comme
   auteurs de documents. Tous les droits sont réservés.

   Ce document est soumis au BCP 78 et à l'IETF Trust's Legal
   Dispositions relatives aux documents IETF
   (http://trustee.ietf.org/license-info) en vigueur à la date du
   publication de ce document. Veuillez consulter ces documents
   soigneusement, car ils décrivent vos droits et restrictions avec respect
   à ce document. Les composants de code extraits de ce document doivent
   inclure le texte de la licence BSD simplifiée comme décrit dans la section 4.e de
   les dispositions légales de la fiducie et sont fournis sans garantie
   décrit dans la licence BSD simplifiée.

Table des matières

   1. Introduction ............................................... ..... 4
   2. Présentation du protocole HTTP / 2 ........................................ 5
      2.1. Organisation du document ...................................... 6
      2.2. Conventions et terminologie ................................ 6
   3. Démarrage de HTTP / 2 ............................................ .....7
      3.1. Identification de la version HTTP / 2 .............................. 8
      3.2. Démarrage de HTTP / 2 pour les URI "http" ............... 8
           3.2.1. Champ d'en-tête HTTP2-Settings ......................... 9
      3.3. Démarrage de HTTP / 2 pour les URI "https" .......................... 10
      3.4. Démarrage de HTTP / 2 avec des connaissances préalables ................... 10
      3.5. Préface de connexion HTTP / 2 ................................. 11
   4. Trames HTTP .............................................. ...... 12
      4.1. Format de trame .............................................. 12
      4.2. Taille du cadre ................................................ 13
      4.3. Compression et décompression d'en-tête ...................... 14
   5. Flux et multiplexage ....................................... 15
      5.1. États du flux ............................................. 16
           5.1.1. Identificateurs de flux ................................. 21
           5.1.2. Concurrence de flux ................................. 22
      5.2. Contrôle de flux .............................................. 22
           5.2.1. Principes de contrôle de flux ..................... 23
           5.2.2. Utilisation appropriée du contrôle de flux .................... 24
      5.3. Priorité du flux ........................................... 24
           5.3.1. Dépendances de flux ................................ 25
           5.3.2. Pondération des dépendances ............................... 26
           5.3.3. Redéfinition des priorités ................................... 26
           5.3.4. Gestion de l'état des priorités .................... 27
           5.3.5. Priorités par défaut ................................. 28
      5.4. Traitement des erreurs ........................................... 28
           5.4.1. Gestion des erreurs de connexion .......................... 29
           5.4.2. Gestion des erreurs de flux .............................. 29
           5.4.3. Terminaison de la connexion ............................. 30
      5.5. Extension de HTTP / 2 .......................................... 30
   6. Définitions des cadres .............................................. 31
      6.1. LES DONNÉES ................................................. ..... 31
      6.2. EN-TÊTES ................................................. ..32
      6.3. PRIORITÉ ................................................. 0,34
      6.4. RST_STREAM ................................................ 36
      6.5. PARAMÈTRES ................................................. 0,36
           6.5.1. RÉGLAGES Format .................................... 38
           6.5.2. Paramètres SETTINGS définis ........................ 38
           6.5.3. Synchronisation des paramètres ........................... 39
      6.6. PUSH_PROMISE .............................................. 40
      6.7. PING ................................................. ..... 42
      6.8. ALLEZ-VOUS EN ................................................. ... 43
      6.9. WINDOW_UPDATE ............................................. 46
           6.9.1. La fenêtre de contrôle de flux ............................ 47
           6.9.2. Taille initiale de la fenêtre de contrôle de flux ................... 48
           6.9.3. Réduction de la taille de la fenêtre de flux .................... 49
      6.10. SUITE ............................................. 49
   7. Codes d'erreur .............................................. ...... 50
   8. Echanges de messages HTTP ......................................... 51
      8.1. Échange de requête / réponse HTTP ............................ 52
           8.1.1. Mise à niveau à partir de HTTP / 2 .............................. 53
           8.1.2. Champs d'en-tête HTTP ................................. 53
           8.1.3. Exemples ........................................... 57
           8.1.4. Demander des mécanismes de fiabilité dans HTTP / 2 ........... 60
      8.2. Serveur Push ............................................... 60
           8.2.1. Requêtes push .......................................... 61
           8.2.2. Réponses push ..................................... 63
      8.3. La méthode CONNECT ........................................ 64
   9. Exigences / considérations HTTP supplémentaires .................... 65
      9.1. Gestion des connexions ..................................... 65
           9.1.1. Réutilisation de la connexion ...
           9.1.2. Le code d'état 421 (demande mal dirigée) .......... 66
      9.2. Utilisation des fonctionnalités TLS ....................................... 67
           9.2.1. Fonctionnalités TLS 1.2 ............................... 67
           9.2.2. Suites de chiffrement TLS 1.2 .............................. 68
   10. Considérations relatives à la sécurité ....................................... 69
      10.1. Autorité du serveur ......................................... 69
      10.2. Attaques inter-protocoles ....................................... 69
      10.3. Attaques d'encapsulation intermédiaire ................ 70
      10.4. Mise en cache des réponses poussées ......................... 70
      10.5. Considérations relatives au déni de service ......................... 70
           10.5.1. Limites de la taille du bloc d'en-tête ............... 71
           10.5.2. Problèmes de CONNECT .................................... 72
      10.6. Utilisation de la compression ....................................... 72
      10.7. Utilisation du rembourrage ........................................... 73
      10.8. Considérations relatives à la confidentialité ....................................... 73
   11. Considérations relatives à l'IANA ........................................... 74
      11.1. Enregistrement des chaînes d'identification HTTP / 2 ............ 74
      11.2. Registre des types de trames ....................................... 75
      11.3. Registre des paramètres ........................................ 75
      11.4. Registre des codes d'erreur ...................................... 76
      11.5. Enregistrement du champ d'en-tête des paramètres HTTP2 ................. 77
      11.6. Enregistrement de la méthode PRI .................................. 78
      11.7. Le code d'état HTTP 421 (demande mal dirigée) ............ 78
      11.8. Le jeton de mise à niveau h2c .................................... 78
   12. Références ............................................... ..... 79
      12.1. Références normatives ..................................... 79
      12.2. Références informatives ................................... 81
   Annexe A. Liste noire de la suite de chiffrement TLS 1.2 ............... 83
   Remerciements ................................................. 0,95
   Adresses des auteurs ............................................... 0,96

1. Introduction

   Le protocole HTTP (Hypertext Transfer Protocol) est un succès
   protocole. Cependant, la façon dont HTTP / 1.1 utilise le transport sous-jacent
   ([RFC7230], Section 6) a plusieurs caractéristiques qui ont un
   effet global négatif sur les performances des applications aujourd'hui.

   En particulier, HTTP / 1.0 permettait à une seule requête d'être en attente à
   une heure sur une connexion TCP donnée. Ajout du pipelining des requêtes HTTP / 1.1,
   mais cela ne répondait que partiellement à la concurrence des demandes et
   souffre d'un blocage en tête de ligne. Par conséquent, HTTP / 1.0 et HTTP / 1.1
   les clients qui ont besoin de faire de nombreuses demandes utilisent plusieurs connexions à un
   serveur afin d'obtenir la concurrence et ainsi réduire la latence.

   De plus, les champs d'en-tête HTTP sont souvent répétitifs et détaillés,
   provoquant un trafic réseau inutile et provoquant la
   Fenêtre de congestion TCP [TCP] à remplir rapidement. Cela peut entraîner
   latence excessive lorsque plusieurs requêtes sont effectuées sur un nouveau TCP
   lien.

   HTTP / 2 résout ces problèmes en définissant un mappage optimisé de
   Sémantique HTTP à une connexion sous-jacente. Plus précisément, il
   permet l'entrelacement des messages de demande et de réponse sur le même
   connexion et utilise un codage efficace pour les champs d'en-tête HTTP. Il
   permet également de hiérarchiser les demandes, laissant plus important
   les demandes se terminent plus rapidement, ce qui améliore encore les performances.

   Le protocole résultant est plus convivial pour le réseau car moins
   Les connexions TCP peuvent être utilisées par rapport à HTTP / 1.x. Ça signifie
   moins de concurrence avec d'autres flux et des connexions de plus longue durée,
   conduisent à leur tour à une meilleure utilisation de la capacité disponible du réseau.

   Enfin, HTTP / 2 permet également un traitement plus efficace des messages
   grâce à l'utilisation du cadrage de message binaire.

2. Présentation du protocole HTTP / 2

   HTTP / 2 fournit un transport optimisé pour la sémantique HTTP. HTTP / 2
   prend en charge toutes les fonctionnalités de base de HTTP / 1.1 mais vise à être plus
   efficace de plusieurs manières.

   L'unité de protocole de base dans HTTP / 2 est une trame (section 4.1). Chaque
   le type de cadre sert un objectif différent. Par exemple, HEADERS et DATA
   les trames forment la base des requêtes et réponses HTTP (section 8.1);
   d'autres types de trames comme SETTINGS, WINDOW_UPDATE et PUSH_PROMISE sont
   utilisé pour prendre en charge d'autres fonctionnalités HTTP / 2.

   Le multiplexage des requêtes est réalisé en ayant chaque requête HTTP /
   échange de réponse associé à son propre flux (section 5).
   Les flux étant largement indépendants les uns des autres, un
   une demande ou une réponse bloquée n'empêche pas la progression sur d'autres
   ruisseaux.

   Le contrôle de flux et la priorisation garantissent qu'il est possible de
   utiliser efficacement les flux multiplexés. Contrôle de flux (section 5.2)
   permet de garantir que seules les données pouvant être utilisées par un récepteur
   transmis. La hiérarchisation (section 5.3) garantit que des
   les ressources peuvent d'abord être dirigées vers les flux les plus importants.

   HTTP / 2 ajoute un nouveau mode d'interaction dans lequel un serveur peut pousser
   réponses à un client (section 8.2). Serveur push permet à un serveur de
   envoyer spéculativement des données à un client que le serveur anticipe
   le client aura besoin, en échangeant une certaine utilisation du réseau contre un potentiel
   gain de latence. Le serveur le fait en synthétisant une requête, qui
   il envoie comme une trame PUSH_PROMISE. Le serveur est alors en mesure d'envoyer un
   réponse à la requête synthétique sur un flux séparé.

   Parce que les champs d'en-tête HTTP utilisés dans une connexion peuvent contenir
   quantités de données redondantes, les trames qui les contiennent sont compressées
   (Section 4.3). Cela a un impact particulièrement avantageux sur demande
   tailles dans le cas courant, permettant de compresser de nombreuses requêtes
   en un seul paquet.

2.1. Organisation des documents

   La spécification HTTP / 2 est divisée en quatre parties:

   o Le démarrage de HTTP / 2 (Section 3) explique comment une connexion HTTP / 2 est
      initié.

   o Les couches frame (section 4) et stream (section 5) décrivent le
      façon dont les trames HTTP / 2 sont structurées et formées en multiplex
      ruisseaux.

   o Les définitions du cadre (section 6) et d'erreur (section 7) comprennent
      détails des types de trame et d'erreur utilisés dans HTTP / 2.

   o Mappages HTTP (Section 8) et exigences supplémentaires (Section 9)
      décrire comment la sémantique HTTP est exprimée à l'aide de cadres et
      ruisseaux.

   Alors que certains des concepts de couche de trame et de flux sont isolés de
   HTTP, cette spécification ne définit pas une trame complètement générique
   couche. Les couches de trame et de flux sont adaptées aux besoins du
   Protocole HTTP et push serveur.

2.2. Conventions et terminologie

   Les mots clés "DOIT", "NE DOIT PAS", "REQUIS", "DOIT", "NE DOIT PAS",
   «DEVRAIT», «NE DEVRAIT PAS», «RECOMMANDÉ», «PEUT» et «OPTIONNEL» dans ce
   document doivent être interprétés comme décrit dans la RFC 2119 [RFC2119].

   Toutes les valeurs numériques sont dans l'ordre des octets du réseau. Les valeurs ne sont pas signées
   Sauf indication contraire. Les valeurs littérales sont fournies en décimal
   ou hexadécimal selon le cas. Les littéraux hexadécimaux sont préfixés
   avec "0x" pour les distinguer des littéraux décimaux.

   Les termes suivants sont utilisés:

   client: le point de terminaison qui lance une connexion HTTP / 2. Clients
      envoyer des requêtes HTTP et recevoir des réponses HTTP.

   connexion: connexion de couche de transport entre deux points d'extrémité.

   erreur de connexion: une erreur qui affecte l'intégralité de HTTP / 2
      lien.

   endpoint: Soit le client, soit le serveur de la connexion.

   frame: La plus petite unité de communication dans un HTTP / 2
      connexion, composée d'un en-tête et d'une séquence de longueur variable
      d'octets structurés en fonction du type de trame.

   pair: un point de terminaison. Lors de la discussion d'un point de terminaison particulier, "pair"
      fait référence au point de terminaison distant du sujet principal de
      discussion.

   récepteur: un point d'extrémité qui reçoit des trames.

   expéditeur: un point de terminaison qui transmet des trames.

   serveur: le point de terminaison qui accepte une connexion HTTP / 2. Les serveurs
      recevoir des requêtes HTTP et envoyer des réponses HTTP.

   stream: flux bidirectionnel de trames au sein de la connexion HTTP / 2.

   erreur de flux: une erreur sur le flux HTTP / 2 individuel.

   Enfin, les termes «passerelle», «intermédiaire», «proxy» et «tunnel»
   sont définis dans la section 2.3 de la [RFC7230]. Les intermédiaires agissent comme les deux
   client et serveur à des moments différents.

   Le terme «corps de charge utile» est défini dans la section 3.3 de la [RFC7230].

3. Démarrage de HTTP / 2

   Une connexion HTTP / 2 est un protocole de couche application fonctionnant par-dessus
   d'une connexion TCP ([TCP]). Le client est la connexion TCP
   initiateur.

   HTTP / 2 utilise les mêmes schémas d'URI «http» et «https» que ceux utilisés par HTTP / 1.1.
   HTTP / 2 partage les mêmes numéros de port par défaut: 80 pour les URI "http" et
   443 pour les URI "https". En conséquence, le traitement des implémentations
   demandes d'URI de ressources cibles comme "http://example.org/foo" ou
   "https://example.com/bar" sont nécessaires pour découvrir d'abord si le
   serveur en amont (le pair immédiat auquel le client souhaite
   établir une connexion) prend en charge HTTP / 2.

   Le moyen par lequel la prise en charge de HTTP / 2 est déterminée est différent pour
   URI "http" et "https". La découverte des URI "http" est décrite dans
   Section 3.2. La découverte des URI "https" est décrite dans la section 3.3.

3.1. Identification de la version HTTP / 2

   Le protocole défini dans ce document a deux identificateurs.

   o La chaîne "h2" identifie le protocole où HTTP / 2 utilise
      Sécurité de la couche de transport (TLS) [TLS12]. Cet identifiant est utilisé
      dans l'extension de négociation de protocole de couche application (ALPN) TLS
      Champ [TLS-ALPN] et à tout endroit où HTTP / 2 sur TLS est
      identifiés.

      La chaîne "h2" est sérialisée dans un identifiant de protocole ALPN comme
      la séquence de deux octets: 0x68, 0x32.

   o La chaîne "h2c" identifie le protocole sur lequel HTTP / 2 est exécuté
      TCP en clair. Cet identifiant est utilisé dans la mise à niveau HTTP / 1.1
      champ d'en-tête et à tout endroit où HTTP / 2 sur TCP est identifié.

      La chaîne "h2c" est réservée à partir de l'espace d'identifiant ALPN mais
      décrit un protocole qui n'utilise pas TLS.

   Négocier "h2" ou "h2c" implique l'utilisation du transport, de la sécurité,
   le cadrage et la sémantique des messages décrits dans ce document.

3.2. Démarrage de HTTP / 2 pour les URI "http"

   Un client qui demande un URI "http" sans
   la connaissance de la prise en charge de HTTP / 2 lors du prochain saut utilise le protocole HTTP
   Mécanisme de mise à niveau (section 6.7 de la [RFC7230]). Le client le fait en
   faire une requête HTTP / 1.1 qui inclut un champ d'en-tête Upgrade avec
   le jeton "h2c". Une telle demande HTTP / 1.1 DOIT inclure exactement un
   Champ d'en-tête HTTP2-Settings (Section 3.2.1).

   Par exemple:

     GET / HTTP / 1.1
     Hôte: server.example.com
     Connexion: mise à niveau, paramètres HTTP2
     Mise à niveau: h2c
     Paramètres HTTP2: <encodage base64url de la charge utile HTTP / 2 SETTINGS>

   Les demandes qui contiennent un corps de charge utile DOIVENT être envoyées dans leur intégralité
   avant que le client puisse envoyer des trames HTTP / 2. Cela signifie qu'un grand
   request peut bloquer l'utilisation de la connexion jusqu'à ce qu'elle soit complètement
   expédié.

   Si la simultanéité d'une demande initiale avec les demandes suivantes est
   important, une requête OPTIONS peut être utilisée pour effectuer la mise à niveau vers
   HTTP / 2, au prix d'un aller-retour supplémentaire.

   Un serveur qui ne prend pas en charge HTTP / 2 peut répondre à la demande comme
   bien que le champ d'en-tête Upgrade soit absent:

     HTTP / 1.1 200 OK
     Contenu-Longueur: 243
     Type de contenu: texte / html

     ...

   Un serveur DOIT ignorer un jeton "h2" dans un champ d'en-tête Upgrade.
   La présence d'un token avec "h2" implique HTTP / 2 sur TLS, qui est
   au lieu de cela négocié comme décrit dans la section 3.3.

   Un serveur qui prend en charge HTTP / 2 accepte la mise à niveau avec un 101
   (Switching Protocols) réponse. Après la ligne vide qui se termine
   la réponse 101, le serveur peut commencer à envoyer des trames HTTP / 2. Celles-ci
   les trames DOIVENT inclure une réponse à la demande qui a lancé le
   améliorer.

   Par exemple:

     Protocoles de commutation HTTP / 1.1 101
     Connexion: mise à niveau
     Mise à niveau: h2c

     [Connexion HTTP / 2 ...

   La première trame HTTP / 2 envoyée par le serveur DOIT être une connexion serveur
   préface (Section 3.5) constituée d'un cadre SETTINGS (Section 6.5).
   À la réception de la réponse 101, le client DOIT envoyer une connexion
   préface (Section 3.5), qui comprend un cadre PARAMÈTRES.

   La requête HTTP / 1.1 envoyée avant la mise à niveau se voit attribuer un
   identifiant de flux de 1 (voir Section 5.1.1) avec priorité par défaut
   valeurs (section 5.3.5). Le flux 1 est implicitement "semi-fermé" depuis
   le client vers le serveur (voir Section 5.1), puisque la requête est
   complété comme une requête HTTP / 1.1. Après avoir commencé le HTTP / 2
   connexion, le flux 1 est utilisé pour la réponse.

3.2.1. Champ d'en-tête HTTP2-Settings

   Une demande qui passe de HTTP / 1.1 à HTTP / 2 DOIT inclure exactement
   un champ d'en-tête "HTTP2-Settings". Le champ d'en-tête HTTP2-Settings
   est un champ d'en-tête spécifique à la connexion qui inclut des paramètres qui
   régir la connexion HTTP / 2, fournie en prévision du serveur
   accepter la demande de mise à niveau.

     Paramètres HTTP2 = token68

   Un serveur NE DOIT PAS mettre à niveau la connexion vers HTTP / 2 si cet en-tête
   champ n'est pas présent ou si plus d'un est présent. Un serveur DOIT
   PAS envoyer ce champ d'en-tête.

   Le contenu du champ d'en-tête HTTP2-Settings est la charge utile d'un
   Cadre SETTINGS (Section 6.5), codé comme une chaîne base64url (c'est-à-dire
   l'encodage Base64 sécurisé pour les URL et les noms de fichiers décrit dans la section 5 de
   [RFC4648], avec tous les caractères '=' de fin omis). L'ABNF
   [RFC5234] la production de "token68" est définie dans la section 2.1 de
   [RFC7235].

   Étant donné que la mise à niveau est uniquement destinée à s'appliquer à la
   connexion, un client envoyant le champ d'en-tête HTTP2-Settings DOIT
   envoyer également "HTTP2-Settings" comme option de connexion dans la connexion
   champ d'en-tête pour éviter qu'il ne soit transmis (voir la section 6.1 de
   [RFC7230]).

   Un serveur décode et interprète ces valeurs comme tout autre
   Cadre RÉGLAGES. Acquittement explicite de ces paramètres
   (Section 6.5.3) n'est pas nécessaire, car une réponse 101 sert de
   reconnaissance implicite. Fournir ces valeurs dans la mise à niveau
   demande donne à un client la possibilité de fournir des paramètres avant
   recevoir des trames du serveur.

3.3. Démarrage de HTTP / 2 pour les URI "https"

   Un client qui fait une demande à un URI "https" utilise TLS [TLS12] avec
   l'extension de négociation de protocole de couche application (ALPN)
   [TLS-ALPN].

   HTTP / 2 sur TLS utilise l'identifiant de protocole "h2". Le "h2c"
   l'identifiant de protocole NE DOIT PAS être envoyé par un client ou sélectionné par un
   serveur; l'identifiant de protocole "h2c" décrit un protocole qui
   pas utiliser TLS.

   Une fois la négociation TLS terminée, le client et le serveur DOIVENT
   envoyer une préface de connexion (section 3.5).

3.4. Démarrer HTTP / 2 avec des connaissances préalables

   Un client peut apprendre qu'un serveur particulier prend en charge HTTP / 2 par d'autres
   veux dire. Par exemple, [ALT-SVC] décrit un mécanisme de publicité
   cette capacité.

   Un client DOIT envoyer la préface de connexion (section 3.5) puis PEUT
   envoyer immédiatement des trames HTTP / 2 à un tel serveur; les serveurs peuvent identifier
   ces connexions par la présence de la préface de connexion. Ce
   n'affecte que l'établissement de connexions HTTP / 2 en texte clair
   TCP; les implémentations qui prennent en charge HTTP / 2 sur TLS DOIVENT utiliser le protocole
   négociation en TLS [TLS-ALPN].

   De même, le serveur DOIT envoyer une préface de connexion (section 3.5).

   Sans informations supplémentaires, la prise en charge préalable de HTTP / 2 n'est pas
   signal fort qu'un serveur donné prendra en charge HTTP / 2 à l'avenir
   Connexions. Par exemple, il est possible pour les configurations de serveur
   à changer, pour que les configurations diffèrent entre les instances dans
   serveurs en cluster, ou pour que les conditions du réseau changent.

3.5. Préface de connexion HTTP / 2

   Dans HTTP / 2, chaque point de terminaison doit envoyer une préface de connexion comme
   une confirmation finale du protocole utilisé et pour établir le
   paramètres initiaux de la connexion HTTP / 2. Le client et le serveur
   chacun envoie une préface de connexion différente.

   La préface de la connexion client commence par une séquence de 24 octets,
   qui en notation hexadécimale est:

     0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

   Autrement dit, la préface de connexion commence par la chaîne "PRI *
   HTTP / 2.0 \ r \ n \ r \ nSM \ r \ n \ r \ n "). Cette séquence DOIT être suivie d'un
   Cadre RÉGLAGES (Section 6.5), qui PEUT être vide. Le client envoie
   la préface de connexion client dès réception d'un 101
   (Switching Protocols) (indiquant une mise à niveau réussie) ou
   en tant que premiers octets de données d'application d'une connexion TLS. Si
   démarrage d'une connexion HTTP / 2 avec une connaissance préalable de la prise en charge du serveur
   pour le protocole, la préface de connexion client est envoyée dès
   établissement de connexion.

      Remarque: La préface de connexion client est sélectionnée de sorte qu'un grand
      proportion de serveurs et intermédiaires HTTP / 1.1 ou HTTP / 1.0
      n'essayez pas de traiter d'autres images. Notez que cela ne
      répondre aux préoccupations soulevées dans [TALKING].

   La préface de connexion au serveur se compose d'un
   Cadre SETTINGS (Section 6.5) qui DOIT être le premier cadre du serveur
   envoie dans la connexion HTTP / 2.

   Les trames SETTINGS reçues d'un pair dans le cadre de la connexion
   la préface DOIT être acquittée (voir la section 6.5.3) après l'envoi du
   préface de connexion.

   Pour éviter une latence inutile, les clients sont autorisés à envoyer
   trames supplémentaires au serveur immédiatement après l'envoi du client
   préface de connexion, sans attendre de recevoir la connexion au serveur
   préface. Il est cependant important de noter que le serveur
   Le cadre SETTINGS de la préface de connexion peut inclure des paramètres qui
   modifier nécessairement la façon dont un client est censé communiquer avec le
   serveur. À la réception de la trame SETTINGS, le client est censé
   honorer tous les paramètres établis. Dans certaines configurations, c'est
   possible pour le serveur de transmettre les paramètres avant que le client envoie
   cadres supplémentaires, ce qui permet d’éviter ce problème.

   Les clients et les serveurs DOIVENT traiter une préface de connexion invalide comme un
   erreur de connexion (paragraphe 5.4.1) de type PROTOCOL_ERROR. UN GOAWAY
   frame (Section 6.8) PEUT être omis dans ce cas, car un
   La préface indique que l'homologue n'utilise pas HTTP / 2.

4. Cadres HTTP

   Une fois la connexion HTTP / 2 établie, les points de terminaison peuvent commencer
   échange de cadres.

4.1. Format de trame

   Toutes les trames commencent par un en-tête fixe de 9 octets suivi d'une variable-
   longueur de la charge utile.

    + ----------------------------------------------- +
    | Longueur (24) |
    + --------------- + --------------- + --------------- +
    | Type (8) | Drapeaux (8) |
    + - + ------------- + --------------- + ----------------- -------------- +
    | R | Identificateur de flux (31) |
    + = + ================================================= ============== +
    | Charge utile de trame (0 ...) ...
    + ------------------------------------------------- -------------- +

                          Figure 1: Disposition du cadre

   Les champs de l'en-tête de trame sont définis comme:

   Longueur: la longueur de la charge utile de la trame exprimée en tant que non signé
      Entier 24 bits. Les valeurs supérieures à 2 ^ 14 (16,384) NE DOIVENT PAS être
      envoyé sauf si le destinataire a défini une valeur plus élevée pour
      SETTINGS_MAX_FRAME_SIZE.

      Les 9 octets de l'en-tête de trame ne sont pas inclus dans cette valeur.

   Type: le type 8 bits de la trame. Le type de cadre détermine le
      format et sémantique de la trame. Les implémentations DOIVENT ignorer
      et supprimez toute trame dont le type est inconnu.

   Flags: un champ de 8 bits réservé aux indicateurs booléens spécifiques au
      type de cadre.

      Les indicateurs reçoivent une sémantique spécifique au type de trame indiqué.
      Indicateurs qui n'ont pas de sémantique définie pour un type de trame particulier
      DOIT être ignoré et DOIT être laissé non défini (0x0) lors de l'envoi.

   R: Un champ réservé de 1 bit. La sémantique de ce bit n'est pas définie,
      et le bit DOIT rester non mis à 1 (0x0) lors de l'envoi et DOIT être
      ignoré lors de la réception.

   Identificateur de flux: un identificateur de flux (voir la section 5.1.1) exprimé
      sous forme d'entier 31 bits non signé. La valeur 0x0 est réservée pour
      cadres associés à la connexion dans son ensemble
      opposé à un flux individuel.

   La structure et le contenu de la charge utile de la trame dépendent entièrement
   sur le type de cadre.

4.2. Taille du cadre

   La taille d'une charge utile de trame est limitée par la taille maximale qu'un
   récepteur annonce dans le paramètre SETTINGS_MAX_FRAME_SIZE. Ce
   le paramètre peut avoir n'importe quelle valeur entre 2 ^ 14 (16,384) et 2 ^ 24-1
   (16 777 215) octets, inclus.

   Toutes les implémentations DOIVENT être capables de recevoir et au minimum
   traitement de trames jusqu'à 2 ^ 14 octets de longueur, plus la trame de 9 octets
   en-tête (section 4.1). La taille de l'en-tête du cadre n'est pas incluse
   lors de la description des tailles de cadre.

      Remarque: certains types de trames, tels que PING (section 6.7), imposent
      des limites supplémentaires sur la quantité de données utiles autorisées.

   Un point d'extrémité DOIT envoyer un code d'erreur de FRAME_SIZE_ERROR si une trame
   dépasse la taille définie dans SETTINGS_MAX_FRAME_SIZE, dépasse tout
   limite définie pour le type de cadre ou est trop petite pour contenir
   données de trame obligatoires. Une erreur de taille d'image dans une image qui pourrait altérer
   l'état de la connexion entière DOIT être traité comme une connexion
   erreur (section 5.4.1); cela inclut tout cadre portant un en-tête
   block (Section 4.3) (c'est-à-dire HEADERS, PUSH_PROMISE, et
   CONTINUATION), PARAMÈTRES et toute image avec un identificateur de flux de 0.

   Les points d'extrémité ne sont pas obligés d'utiliser tout l'espace disponible dans un cadre.
   La réactivité peut être améliorée en utilisant des cadres plus petits que
   la taille maximale autorisée. L'envoi de trames volumineuses peut entraîner
   retards dans l'envoi de trames sensibles au temps (comme RST_STREAM,
   WINDOW_UPDATE, ou PRIORITY), qui, s'il est bloqué par la transmission de
   un cadre de grande taille peut affecter les performances.

4.3. Compression et décompression d'en-tête

   Tout comme dans HTTP / 1, un champ d'en-tête dans HTTP / 2 est un nom avec un ou
   plus de valeurs associées. Les champs d'en-tête sont utilisés dans la requête HTTP
   et les messages de réponse ainsi que dans les opérations push du serveur (voir
   Section 8.2).

   Les listes d'en-tête sont des collections de zéro ou plusieurs champs d'en-tête. Quand
   transmis via une connexion, une liste d'en-têtes est sérialisée en un
   bloc d'en-tête utilisant la compression d'en-tête HTTP [COMPRESSION]. le
   le bloc d'en-tête sérialisé est ensuite divisé en un ou plusieurs octets
   séquences, appelées fragments de bloc d'en-tête, et transmises dans le
   charge utile de HEADERS (Section 6.2), PUSH_PROMISE (Section 6.6), ou
   CONTINUATION (Section 6.10) cadres.

   Le champ d'en-tête Cookie [COOKIE] est traité spécialement par le HTTP
   cartographie (voir Section 8.1.2.5).

   Un point de terminaison de réception réassemble le bloc d'en-tête en concaténant
   ses fragments puis décompresse le bloc pour reconstruire le
   liste d'en-tête.

   Un bloc d'en-tête complet comprend soit:

   o une seule trame HEADERS ou PUSH_PROMISE, avec l'indicateur END_HEADERS
      ensemble, ou

   o un cadre HEADERS ou PUSH_PROMISE avec l'indicateur END_HEADERS effacé
      et une ou plusieurs trames CONTINUATION, où la dernière CONTINUATION
      frame a l'indicateur END_HEADERS défini.

   La compression d'en-tête est avec état. Un contexte de compression et un
   le contexte de décompression est utilisé pour toute la connexion. Un décodage
   erreur dans un bloc d'en-tête DOIT être traitée comme une erreur de connexion
   (Paragraphe 5.4.1) de type COMPRESSION_ERROR.

   Chaque bloc d'en-tête est traité comme une unité discrète. Blocs d'en-tête
   DOIT être transmis comme une séquence contiguë de trames, sans
   trames entrelacées de tout autre type ou de tout autre flux. le
   la dernière image d'une séquence de cadres HEADERS ou CONTINUATION a le

   Indicateur END_HEADERS défini. La dernière image d'une séquence de PUSH_PROMISE
   ou CONTINUATION frames a l'indicateur END_HEADERS défini. Cela permet un
   bloc d'en-tête pour être logiquement équivalent à une seule trame.

   Les fragments de bloc d'en-tête ne peuvent être envoyés qu'en tant que charge utile de HEADERS,
   Les trames PUSH_PROMISE ou CONTINUATION car ces trames transportent des données
   qui peut modifier le contexte de compression maintenu par un récepteur. Une
   endpoint recevant des trames HEADERS, PUSH_PROMISE ou CONTINUATION
   doit réassembler les blocs d'en-tête et effectuer une décompression même si
   les cadres doivent être jetés. Un récepteur DOIT terminer le
   connexion avec une erreur de connexion (chapitre 5.4.1) de type
   COMPRESSION_ERROR s'il ne décompresse pas un bloc d'en-tête.

5. Flux et multiplexage

   Un "flux" est une séquence bidirectionnelle indépendante de trames
   échangés entre le client et le serveur au sein d'une connexion HTTP / 2.
   Les flux ont plusieurs caractéristiques importantes:

   o Une seule connexion HTTP / 2 peut contenir plusieurs
      flux, avec les trames entrelacées des extrémités de plusieurs
      ruisseaux.

   o Les flux peuvent être établis et utilisés unilatéralement ou partagés par
      soit le client, soit le serveur.

   o Les flux peuvent être fermés par l'un ou l'autre des points de terminaison.

   o L'ordre dans lequel les trames sont envoyées sur un flux est significatif.
      Les destinataires traitent les trames dans l'ordre de leur réception. Dans
      en particulier, l'ordre des trames HEADERS et DATA est sémantiquement
      important.

   o Les flux sont identifiés par un entier. Les identificateurs de flux sont
      affecté aux flux par le point de terminaison qui lance le flux.

5.1. États du flux

   Le cycle de vie d'un flux est illustré à la figure 2.

                                + -------- +
                        envoyer PP | | recv PP
                       , -------- | inactif | --------.
                      / | | \
                     v + -------- + v
              + ---------- + | + ---------- +
              | | | envoyer H / | |
       , ------ | réservé | | recv H | réservé | ------.
       | | (local) | | | (distant) | |
       | + ---------- + v + ---------- + |
       | | + -------- + | |
       | | recv ES | | envoyer ES | |
       | envoyer H | , ------- | ouvert | -------. | recv H |
       | | / | | \ | |
       | vv + -------- + vv |
       | + ---------- + | + ---------- + |
       | | moitié | | | moitié | |
       | | fermé | | envoyer R / | fermé | |
       | | (distant) | | recv R | (local) | |
       | + ---------- + | + ---------- + |
       | | | | |
       | | envoyer ES / | recv ES / | |
       | | envoyer R / v envoyer R / | |
       | | recv R + -------- + recv R | |
       | envoyer R / `-----------> | | <----------- 'envoyer R / |
       | recv R | fermé | recv R |
       `-----------------------> | | <---------------------- '
                                + -------- +

          send: le point final envoie cette trame
          recv: le point final reçoit cette trame

          H: cadre HEADERS (avec CONTINUATIONS implicites)
          PP: cadre PUSH_PROMISE (avec CONTINUATIONS implicites)
          ES: indicateur END_STREAM
          R: trame RST_STREAM

                          Figure 2: États de flux

   Notez que ce diagramme montre les transitions d'état de flux et les trames
   et les indicateurs qui n'affectent que ces transitions. À cet égard,
   Les trames CONTINUATION n'entraînent pas de transitions d'état; elles sont
   fait effectivement partie des HEADERS ou PUSH_PROMISE qu'ils suivent.

   Aux fins des transitions d'état, l'indicateur END_STREAM est
   traité comme un événement distinct de la trame qui le porte; a EN-TÊTES
   frame avec le paramètre END_STREAM défini peut provoquer deux transitions d'état.

   Les deux points de terminaison ont une vue subjective de l'état d'un flux qui
   peut être différent lorsque les cadres sont en transit. Les points de terminaison ne
   coordonner la création de flux; ils sont créés unilatéralement par
   l'un ou l'autre des points de terminaison. Les conséquences négatives d'une inadéquation entre les États
   sont limités à l'état "fermé" après l'envoi de RST_STREAM, où
   des trames peuvent être reçues pendant un certain temps après la fermeture.

   Les flux ont les états suivants:

   tourner au ralenti:
      Tous les flux démarrent à l'état "inactif".

      Les transitions suivantes sont valides à partir de cet état:

      * L'envoi ou la réception d'une trame HEADERS provoque le flux
         devenir "ouvert". L'identifiant de flux est sélectionné comme décrit
         dans la section 5.1.1. Le même cadre HEADERS peut également provoquer un
         flux pour devenir immédiatement "semi-fermé".

      * L'envoi d'une trame PUSH_PROMISE sur un autre flux réserve le
         flux inactif identifié pour une utilisation ultérieure. L'état du flux
         pour les transitions de flux réservées vers "reserved (local)".

      * Recevoir une trame PUSH_PROMISE sur un autre flux réserve un
         flux inactif identifié pour une utilisation ultérieure. L'état du flux
         pour les transitions de flux réservées vers "reserved (remote)".

      * Notez que la trame PUSH_PROMISE n'est pas envoyée sur le flux inactif
         mais fait référence au flux nouvellement réservé dans le flux promis
         Champ ID.

      Recevoir une image autre que HEADERS ou PRIORITY sur un flux dans
      cet état DOIT être traité comme une erreur de connexion (paragraphe 5.4.1)
      de type PROTOCOL_ERROR.

   réservé (local):
      Un flux dans l'état "réservé (local)" est un flux qui a été
      promis en envoyant une trame PUSH_PROMISE. Un cadre PUSH_PROMISE
      réserve un flux inactif en associant le flux à un
      flux qui a été lancé par l'homologue distant (voir Section 8.2).

      Dans cet état, seules les transitions suivantes sont possibles:

      * Le point final peut envoyer une trame HEADERS. Cela provoque le flux
         pour ouvrir dans un état "semi-fermé (distant)".

      * Chaque point de terminaison peut envoyer une trame RST_STREAM pour provoquer le flux
         devenir "fermé". Cela libère la réservation de flux.

      Un point d'extrémité NE DOIT PAS envoyer de type de trame autre que HEADERS,
      RST_STREAM ou PRIORITY dans cet état.

      Une trame PRIORITY ou WINDOW_UPDATE PEUT être reçue dans cet état.
      Réception de tout type de trame autre que RST_STREAM, PRIORITY ou
      WINDOW_UPDATE sur un flux dans cet état DOIT être traité comme un
      erreur de connexion (paragraphe 5.4.1) de type PROTOCOL_ERROR.

   réservé (distant):
      Un flux à l'état "réservé (distant)" a été réservé par un
      pair distant.

      Dans cet état, seules les transitions suivantes sont possibles:

      * La réception d'une trame HEADERS entraîne la transition du flux vers
         "semi-fermé (local)".

      * Chaque point de terminaison peut envoyer une trame RST_STREAM pour provoquer le flux
         devenir "fermé". Cela libère la réservation de flux.

      Un point d'extrémité PEUT envoyer une trame PRIORITAIRE dans cet état à
      redéfinissez la priorité du flux réservé. Un point d'extrémité NE DOIT PAS envoyer de
      type de trame autre que RST_STREAM, WINDOW_UPDATE ou PRIORITY dans
      cet état.

      Réception de tout type de trame autre que HEADERS, RST_STREAM ou
      PRIORITY sur un flux dans cet état DOIT être traité comme une connexion
      erreur (paragraphe 5.4.1) de type PROTOCOL_ERROR.

   ouvert:
      Un flux à l'état "ouvert" peut être utilisé par les deux pairs pour envoyer
      cadres de tout type. Dans cet état, les pairs envoyant observer
      les limites de contrôle de débit annoncées au niveau des cours d'eau (section 5.2).

      À partir de cet état, l'un ou l'autre des points de terminaison peut envoyer une trame avec un
      L'indicateur END_STREAM est défini, ce qui entraîne la transition du flux vers
      l'un des états "semi-fermés". Un point de terminaison envoyant un

      L'indicateur END_STREAM fait que l'état du flux devient "semi-fermé
      (local) "; un point de terminaison recevant un indicateur END_STREAM provoque le
      l'état du flux pour devenir "semi-fermé (distant)".

      Chaque extrémité peut envoyer une trame RST_STREAM à partir de cet état,
      le faisant passer immédiatement à «fermé».

   semi-fermé (local):
      Un flux qui est à l'état "semi-fermé (local)" ne peut pas être utilisé
      pour l'envoi de trames autres que WINDOW_UPDATE, PRIORITY et
      RST_STREAM.

      Un flux passe de cet état à "fermé" lorsqu'une trame qui
      contient un indicateur END_STREAM est reçu ou lorsque l'un des pairs envoie
      une trame RST_STREAM.

      Un point de terminaison peut recevoir n'importe quel type de trame dans cet état.
      Fournir un crédit de contrôle de flux à l'aide de trames WINDOW_UPDATE est
      nécessaire pour continuer à recevoir des trames à flux contrôlé. Dans ce
      état, un récepteur peut ignorer les trames WINDOW_UPDATE, ce qui pourrait
      arriver pour une courte période après une image portant le END_STREAM
      l'indicateur est envoyé.

      Les trames PRIORITY reçues dans cet état sont utilisées pour redéfinir les priorités
      flux qui dépendent du flux identifié.

   demi-fermé (à distance):
      Un flux "à moitié fermé (distant)" n'est plus utilisé par
      l'homologue pour envoyer des trames. Dans cet état, un point de terminaison n'est plus
      obligé de maintenir une fenêtre de contrôle de flux du récepteur.

      Si un point de terminaison reçoit des trames supplémentaires, autres que
      WINDOW_UPDATE, PRIORITY ou RST_STREAM, pour un flux qui se trouve dans
      cet état, il DOIT répondre avec une erreur de flux (section 5.4.2) de
      tapez STREAM_CLOSED.

      Un flux "à moitié fermé (distant)" peut être utilisé par le
      endpoint pour envoyer des trames de tout type. Dans cet état, le point de terminaison
      continue d'observer les limites de contrôle de débit annoncées au niveau du flux
      (Section 5.2).

      Un flux peut passer de cet état à "fermé" en envoyant un
      trame qui contient un indicateur END_STREAM ou lorsque l'un des pairs envoie un
      Cadre RST_STREAM.

   fermé:
      L'état «fermé» est l'état terminal.

      Un point d'extrémité NE DOIT PAS envoyer de trames autres que PRIORITY sur un
      courant. Un point de terminaison qui reçoit une trame autre que PRIORITY
      après avoir reçu un RST_STREAM DOIT traiter cela comme une erreur de flux
      (Section 5.4.2) de type STREAM_CLOSED. De même, un point de terminaison
      qui reçoit des trames après avoir reçu une trame avec le
      Le jeu d'indicateurs END_STREAM DOIT traiter cela comme une erreur de connexion
      (Paragraphe 5.4.1) de type STREAM_CLOSED, sauf si la trame est
      autorisé comme décrit ci-dessous.

      Les trames WINDOW_UPDATE ou RST_STREAM peuvent être reçues dans cet état
      pendant une courte période après une trame DATA ou HEADERS contenant un
      L'indicateur END_STREAM est envoyé. Jusqu'à ce que l'homologue distant reçoive et
      traite RST_STREAM ou la trame portant l'indicateur END_STREAM, il
      peut envoyer des trames de ces types. Les points finaux DOIVENT ignorer
      Les trames WINDOW_UPDATE ou RST_STREAM reçues dans cet état, cependant
      les points finaux PEUVENT choisir de traiter les trames qui arrivent à un
      heure après l'envoi de END_STREAM en tant qu'erreur de connexion
      (Paragraphe 5.4.1) de type PROTOCOL_ERROR.

      Les trames PRIORITY peuvent être envoyées sur des flux fermés pour hiérarchiser
      les flux qui dépendent du flux fermé. Les points finaux DEVRAIENT
      traiter les trames PRIORITY, même si elles peuvent être ignorées si le flux
      a été supprimé de l'arborescence des dépendances (voir Section 5.3.4).

      Si cet état est atteint suite à l'envoi d'un RST_STREAM
      frame, l'homologue qui reçoit le RST_STREAM peut avoir déjà
      envoyés - ou mis en file d'attente pour l'envoi - de trames sur le flux qui
      ne peut pas être retiré. Un point d'extrémité DOIT ignorer les trames qu'il
      reçoit sur des flux fermés après avoir envoyé une trame RST_STREAM.
      Un point final PEUT choisir de limiter la période pendant laquelle il ignore
      et traiter les images qui arrivent après cette heure comme étant
      Erreur.

      Trames contrôlées par flux (c'est-à-dire, DATA) reçues après l'envoi
      RST_STREAM sont comptés dans la fenêtre de contrôle de flux de connexion.
      Même si ces trames peuvent être ignorées, car elles sont envoyées
      avant que l'expéditeur ne reçoive le RST_STREAM, l'expéditeur
      considérez les images à compter dans la fenêtre de contrôle de flux.

      Un point de terminaison peut recevoir une trame PUSH_PROMISE après avoir envoyé
      RST_STREAM. PUSH_PROMISE fait qu'un flux devient "réservé"
      même si le flux associé a été réinitialisé. Par conséquent, un
      RST_STREAM est nécessaire pour fermer un flux promis indésirable.

   En l'absence de directives plus spécifiques ailleurs dans ce document,
   les implémentations DEVRAIENT traiter la réception d'une trame qui n'est pas
   expressément autorisé dans la description d'un état en tant que connexion
   erreur (paragraphe 5.4.1) de type PROTOCOL_ERROR. Notez que PRIORITY peut
   être envoyé et reçu dans n'importe quel état de flux. Cadres de types inconnus
   sont ignorés.

   Un exemple des transitions d'état pour une requête / réponse HTTP
   l'échange se trouve dans la section 8.1. Un exemple de l'état
   les transitions pour le serveur push peuvent être trouvées dans les sections 8.2.1 et 8.2.2.

5.1.1. Identificateurs de flux

   Les flux sont identifiés par un entier 31 bits non signé. Ruisseaux
   lancé par un client DOIT utiliser des identificateurs de flux impairs; ceux
   initiée par le serveur DOIT utiliser des identifiants de flux pairs. UNE
   l'identificateur de flux de zéro (0x0) est utilisé pour le contrôle de connexion
   messages; l'identifiant de flux de zéro ne peut pas être utilisé pour établir un
   nouveau flux.

   Les requêtes HTTP / 1.1 mises à niveau vers HTTP / 2 (voir section 3.2) sont
   répondu avec un identificateur de flux de un (0x1). Après le
   la mise à niveau est terminée, le flux 0x1 est «à moitié fermé (local)» pour le client.
   Par conséquent, le flux 0x1 ne peut pas être sélectionné comme nouvel identifiant de flux
   par un client qui effectue une mise à niveau à partir de HTTP / 1.1.

   L'identifiant d'un flux nouvellement établi DOIT être numérique
   supérieur à tous les flux ouverts par le point de terminaison initiateur ou
   réservé. Cela régit les flux ouverts à l'aide d'un cadre HEADERS
   et les flux réservés à l'aide de PUSH_PROMISE. Un point final qui
   reçoit un identifiant de flux inattendu DOIT répondre par un
   erreur de connexion (paragraphe 5.4.1) de type PROTOCOL_ERROR.

   La première utilisation d'un nouvel identifiant de flux ferme implicitement tout
   flux dans l'état "inactif" qui pourraient avoir été lancés par ce
   pair avec un identifiant de flux de valeur inférieure. Par exemple, si un client
   envoie une trame HEADERS sur le flux 7 sans jamais envoyer de trame sur
   stream 5, puis stream 5 passe à l'état "fermé" lorsque le
   la première trame du flux 7 est envoyée ou reçue.

   Les identificateurs de flux ne peuvent pas être réutilisés. Les connexions de longue durée peuvent
   aboutir à un point final épuisant la plage de flux disponible
   identifiants. Un client qui ne parvient pas à établir un nouveau flux
   L'identifiant peut établir une nouvelle connexion pour les nouveaux flux. Un serveur
   incapable d'établir un nouvel identifiant de flux peut envoyer un GOAWAY
   frame afin que le client soit obligé d'ouvrir une nouvelle connexion pour un nouveau
   ruisseaux.

5.1.2. Concurrence de flux

   Un pair peut limiter le nombre de flux simultanément actifs en utilisant le
   SETTINGS_MAX_CONCURRENT_STREAMS (voir la section 6.5.2) dans
   un cadre PARAMÈTRES. Le paramètre de flux simultanés maximum est spécifique
   à chaque point de terminaison et s'applique uniquement à l'homologue qui reçoit le
   réglage. Autrement dit, les clients spécifient le nombre maximal de
   les flux que le serveur peut lancer et les serveurs spécifient le maximum
   nombre de flux simultanés que le client peut lancer.

   Flux qui sont à l'état «ouvert» ou dans l'un des deux
   fermé "les états comptent dans le nombre maximum de flux qu'un
   Le point final est autorisé à s'ouvrir. Flux dans l'un de ces trois états
   compter dans la limite annoncée dans le
   Paramètre SETTINGS_MAX_CONCURRENT_STREAMS. Flux dans l'un des
   Les états "réservés" ne comptent pas dans la limite de flux.

   Les points d'extrémité NE DOIVENT PAS dépasser la limite fixée par leur homologue. Un point final
   qui reçoit une trame HEADERS qui provoque son concurrent annoncé
   la limite de flux à dépasser DOIT traiter cela comme une erreur de flux
   (Paragraphe 5.4.2) de type PROTOCOL_ERROR ou REFUSED_STREAM. Le choix
   du code d'erreur détermine si le point final souhaite activer
   nouvelle tentative automatique (voir Section 8.1.4) pour plus de détails).

   Un endpoint qui souhaite réduire la valeur de
   SETTINGS_MAX_CONCURRENT_STREAMS à une valeur inférieure à la valeur actuelle
   nombre de flux ouverts peuvent soit fermer les flux qui dépassent le nouveau
   valeur ou permettre aux flux de se terminer.

5.2. Contrôle de flux

   L'utilisation de flux pour le multiplexage introduit des conflits sur l'utilisation du
   Connexion TCP, entraînant des flux bloqués. Un schéma de contrôle de flux
   garantit que les flux sur la même connexion ne sont pas destructifs
   interférer les uns avec les autres. Le contrôle de débit est utilisé pour les deux
   flux et pour la connexion dans son ensemble.

   HTTP / 2 fournit un contrôle de flux via l'utilisation de WINDOW_UPDATE
   cadre (section 6.9).

5.2.1. Principes de contrôle de flux

   Le contrôle de flux de flux HTTP / 2 vise à permettre une variété de contrôle de flux
   algorithmes à utiliser sans nécessiter de changements de protocole. Couler
   Le contrôle dans HTTP / 2 présente les caractéristiques suivantes:

   1. Le contrôle de flux est spécifique à une connexion. Les deux types de flux
       le contrôle se situe entre les extrémités d'un seul bond et non plus
       tout le chemin de bout en bout.

   2. Le contrôle de flux est basé sur des trames WINDOW_UPDATE. Récepteurs
       annoncer le nombre d'octets qu'ils sont prêts à recevoir sur un
       stream et pour toute la connexion. Il s'agit d'un crédit
       schème.

   3. Le contrôle du flux est directionnel et le contrôle global est assuré par le
       destinataire. Un récepteur PEUT choisir de définir n'importe quelle taille de fenêtre
       désirs pour chaque flux et pour toute la connexion. Un expéditeur
       DOIT respecter les limites de contrôle de flux imposées par un récepteur. Clients,
       les serveurs et les intermédiaires annoncent tous indépendamment leurs
       fenêtre de contrôle de flux en tant que récepteur et respecter le contrôle de flux
       limites fixées par leur pair lors de l'envoi.

   4. La valeur initiale de la fenêtre de contrôle de flux est de 65 535 octets.
       pour les nouveaux flux et la connexion globale.

   5. Le type de trame détermine si le contrôle de flux s'applique à un
       Cadre. Parmi les cadres spécifiés dans ce document, seules les données
       les cadres sont soumis au contrôle de flux; tous les autres types de trame ne
       consomme de l'espace dans la fenêtre de contrôle de flux publiée. Ce
       garantit que les cadres de contrôle importants ne sont pas bloqués par le flux
       contrôle.

   6. Le contrôle de flux ne peut pas être désactivé.

   7. HTTP / 2 définit uniquement le format et la sémantique de WINDOW_UPDATE
       cadre (section 6.9). Ce document ne précise pas comment un
       le récepteur décide quand envoyer cette trame ou la valeur qu'elle
       envoie, ni ne spécifie comment un expéditeur choisit d'envoyer des paquets.
       Les implémentations peuvent sélectionner n'importe quel algorithme qui convient à leur
       Besoins.

   Les implémentations sont également chargées de gérer la façon dont les demandes et
   les réponses sont envoyées en fonction de la priorité, en choisissant comment éviter les
   blocage de ligne pour les demandes et gestion de la création de nouveaux flux.
   Les choix d'algorithmes pour ceux-ci pourraient interagir avec n'importe quel contrôle de flux
   algorithme.

5.2.2. Utilisation appropriée du contrôle de flux

   Le contrôle de flux est défini pour protéger les points finaux qui fonctionnent sous
   contraintes de ressources. Par exemple, un proxy doit partager de la mémoire
   entre de nombreuses connexions et peut également avoir un amont lent
   connexion et une connexion rapide en aval. Le contrôle de flux traite des cas
   où le récepteur est incapable de traiter les données sur un flux mais veut
   pour continuer à traiter d'autres flux dans la même connexion.

   Les déploiements qui ne nécessitent pas cette fonctionnalité peuvent annoncer un flux
   fenêtre de contrôle de la taille maximale (2 ^ 31-1) et peut maintenir cette
   fenêtre en envoyant une trame WINDOW_UPDATE lorsque des données sont reçues.
   Cela désactive effectivement le contrôle de flux pour ce récepteur.
   A l'inverse, un expéditeur est toujours soumis à la fenêtre de contrôle de flux
   annoncé par le récepteur.

   Les déploiements avec des ressources limitées (par exemple, la mémoire) peuvent
   utiliser le contrôle de flux pour limiter la quantité de mémoire qu'un pair peut consommer.
   Notez, cependant, que cela peut conduire à une utilisation sous-optimale des
   ressources réseau si le contrôle de flux est activé sans connaissance du
   produit de délai de bande passante (voir [RFC7323]).

   Même avec une parfaite connaissance du produit de retard de bande passante actuel,
   la mise en œuvre du contrôle de flux peut être difficile. Lors de l'utilisation de flow
   contrôle, le récepteur DOIT lire à partir du tampon de réception TCP dans un
   mode opportune. Le non-respect de cette consigne peut entraîner une impasse lorsque
   les trames critiques, telles que WINDOW_UPDATE, ne sont pas lues et traitées.

5.3. Priorité au flux

   Un client peut attribuer une priorité à un nouveau flux en incluant
   les informations de priorisation dans le cadre HEADERS (Section 6.2) qui
   ouvre le flux. À tout autre moment, la trame PRIORITÉ
   (Section 6.3) peut être utilisé pour changer la priorité d'un flux.

   Le but de la priorisation est de permettre à un endpoint d'exprimer comment
   il préférerait que son homologue alloue des ressources lors de la gestion
   flux simultanés. Plus important encore, la priorité peut être utilisée pour sélectionner
   flux pour la transmission de trames lorsque la capacité pour
   Envoi en cours.

   Les flux peuvent être hiérarchisés en les marquant comme dépendants du
   l'achèvement des autres volets (section 5.3.1). Chaque dépendance est
   attribué un poids relatif, un nombre qui est utilisé pour déterminer le
   proportion relative de ressources disponibles affectées à
   flux dépendants du même flux.

   La définition explicite de la priorité d'un flux est entrée dans un
   processus de priorisation. Il ne garantit aucun
   ordre de traitement ou de transmission du flux par rapport à tout autre
   courant. Un point de terminaison ne peut pas forcer un homologue à traiter simultanément
   flux dans un ordre particulier en utilisant la priorité. Exprimer la priorité est
   donc seulement une suggestion.

   Les informations de hiérarchisation peuvent être omises des messages. Par défaut
   sont utilisés avant que des valeurs explicites ne soient fournies (section 5.3.5).

5.3.1. Dépendances de flux

   Chaque flux peut recevoir une dépendance explicite sur un autre flux.
   L'inclusion d'une dépendance exprime une préférence pour l'allocation des ressources
   au flux identifié plutôt qu'au flux dépendant.

   Un flux qui ne dépend d'aucun autre flux reçoit un flux
   dépendance de 0x0. En d'autres termes, le flux 0 inexistant forme
   la racine de l'arbre.

   Un flux qui dépend d'un autre flux est un flux dépendant. le
   le flux dont dépend un flux est un flux parent. UNE
   dépendance sur un flux qui n'est pas actuellement dans l'arborescence - comme un
   stream dans l'état "inactif" - donne à ce flux un
   priorité par défaut (Section 5.3.5).

   Lors de l'attribution d'une dépendance à un autre flux, le flux est ajouté comme
   une nouvelle dépendance du flux parent. Flux dépendants qui partagent
   les mêmes parents ne sont pas ordonnés l'un par rapport à l'autre. Pour
   exemple, si les flux B et C dépendent du flux A, et si le flux
   D est créé avec une dépendance sur le flux A, il en résulte un
   ordre de dépendance de A suivi de B, C et D dans n'importe quel ordre.

       AA
      / \ ==> / | \
     BCBDC

             Figure 3: Exemple de création de dépendance par défaut

   Un drapeau exclusif permet l'insertion d'un nouveau niveau de
   dépendances. L'indicateur exclusif fait que le flux devient le
   seule dépendance de son flux parent, ce qui fait que d'autres dépendances
   devenir dépendant du flux exclusif. Dans l'exemple précédent,
   si le flux D est créé avec une dépendance exclusive sur le flux A, ce
   fait que D devient le parent de dépendance de B et C.

                         UNE
       A |
      / \ ==> D
     AVANT JC / \
                       avant JC

            Figure 4: Exemple de création de dépendance exclusive

   À l'intérieur de l'arborescence de dépendances, un flux dépendant DEVRAIT être uniquement
   ressources allouées si tous les flux dont il dépend
   (la chaîne de flux parents jusqu'à 0x0) sont fermées ou non
   possible de progresser sur eux.

   Un flux ne peut pas dépendre de lui-même. Un point final DOIT traiter cela comme un
   erreur de flux (Section 5.4.2) de type PROTOCOL_ERROR.

5.3.2. Pondération des dépendances

   Tous les flux dépendants reçoivent un poids entier compris entre 1 et
   256 (inclus).

   Les flux avec le même parent DEVRAIENT recevoir des ressources
   proportionnellement à leur poids. Ainsi, si le flux B dépend de
   flux A avec poids 4, flux C dépend du flux A avec poids 12,
   et aucun progrès ne peut être réalisé sur le flux A, le flux B reçoit idéalement
   un tiers des ressources allouées au volet C.

5.3.3. Redéfinition des priorités

   Les priorités de flux sont modifiées à l'aide du cadre PRIORITY. Définition d'un
   la dépendance fait qu'un flux devienne dépendant du
   flux parent.

   Les flux dépendants se déplacent avec leur flux parent si le parent est
   redéfini les priorités. Définition d'une dépendance avec l'indicateur exclusif pour un
   Le flux redéfini provoque toutes les dépendances du nouveau parent
   stream pour devenir dépendant du flux redéfini.

   Si un flux est rendu dépendant de l'une de ses propres dépendances, le
   le flux anciennement dépendant est d'abord déplacé pour être dépendant du
   a redéfini la priorité du parent précédent du flux. La dépendance déplacée conserve
   son poids.

   Par exemple, considérons un arbre de dépendances d'origine où B et C
   dépendent de A, D et E dépendent de C, et F dépend de D. Si A est fait
   dépendante de D, alors D prend la place de A. Toutes les autres dépendances
   les relations restent les mêmes, sauf pour F, qui devient dépendant de
   A si la redéfinition des priorités est exclusive.

       xxxx
       | / \ | |
       AJOUTER
      / \ / / \ / \ |
     BC ==> FBC ==> FA OU A
        / \ | / \ / | \
       DEEBCBCF
       | | |
       FRAIS
                  (intermédiaire) (non exclusif) (exclusif)

                Figure 5: Exemple de réorganisation des dépendances

5.3.4. Gestion de l'état des priorités

   Lorsqu'un flux est supprimé de l'arborescence de dépendances, ses dépendances
   peut être déplacé pour devenir dépendant du parent du flux fermé.
   Les poids des nouvelles dépendances sont recalculés en distribuant le
   poids de la dépendance du flux fermé proportionnellement basé sur
   les poids de ses dépendances.

   Les flux supprimés de l'arborescence des dépendances entraînent
   informations de priorisation à perdre. Les ressources sont partagées entre
   flux avec le même flux parent, ce qui signifie que si un flux dans
   cet ensemble se ferme ou se bloque, toute capacité disponible allouée à un
   stream est distribué aux voisins immédiats du flux.
   Cependant, si la dépendance commune est supprimée de l'arborescence, ces
   les flux partagent des ressources avec des flux au niveau le plus élevé.

   Par exemple, supposons que les flux A et B partagent un parent et que les flux C et
   D dépendent tous deux du flux A. Avant la suppression du flux A, si
   les flux A et D ne peuvent pas continuer, alors le flux C reçoit tous les
   ressources dédiées au flux A. Si le flux A est supprimé du
   arbre, le poids du flux A est divisé entre les flux C et D. Si
   le flux D ne peut toujours pas continuer, il en résulte le flux C
   recevoir une proportion réduite de ressources. Pour un départ égal
   poids, C reçoit un tiers, plutôt que la moitié, des
   Ressources.

   Il est possible qu'un flux se ferme pendant la priorisation
   les informations qui créent une dépendance sur ce flux sont en transit.
   Si un flux identifié dans une dépendance n'a pas de priorité associée
   informations, puis le flux dépendant reçoit à la place une valeur par défaut
   priorité (section 5.3.5). Cela crée potentiellement sous-optimal
   priorisation, puisque le flux pourrait recevoir une priorité qui est
   différent de ce qui est prévu.

   Pour éviter ces problèmes, un point d'extrémité DEVRAIT conserver le flux
   état de priorisation pendant une période après la fermeture des flux. le
   plus l'état est conservé, plus il y a de chances que les flux soient
   assigné des valeurs de priorité incorrectes ou par défaut.

   De même, les flux qui sont à l'état "inactif" peuvent être attribués
   priorité ou devenir parent d’autres flux. Cela permet le
   création d'un nœud de regroupement dans l'arborescence de dépendances, ce qui permet
   expressions de priorité plus flexibles. Les flux inactifs commencent par un
   priorité par défaut (Section 5.3.5).

   La conservation des informations de priorité pour les flux qui ne sont pas
   compté dans la limite fixée par SETTINGS_MAX_CONCURRENT_STREAMS pourrait
   créer une charge d'état importante pour un point de terminaison. Par conséquent, le montant
   de l'état de priorisation qui est conservé PEUT être limité.

   La quantité d'état supplémentaire qu'un point de terminaison conserve pour
   la hiérarchisation pourrait dépendre de la charge; sous forte charge,
   l'état de priorisation peut être ignoré pour limiter les engagements de ressources.
   Dans les cas extrêmes, un point de terminaison peut même ignorer l'état de hiérarchisation
   pour les flux actifs ou réservés. Si une limite est appliquée, les points de terminaison
   DEVRAIT maintenir l'état pour au moins autant de flux que le permet
   leur paramètre pour SETTINGS_MAX_CONCURRENT_STREAMS. Implémentations
   DEVRAIT également essayer de conserver l'état des flux qui sont en
   utiliser dans l'arborescence des priorités.

   S'il a conservé suffisamment d'état pour le faire, un point de terminaison recevant un
   La trame PRIORITY qui change la priorité d'un flux fermé DEVRAIT
   modifier les dépendances des flux qui en dépendent.

5.3.5. Priorités par défaut

   Tous les flux se voient initialement attribuer une dépendance non exclusive sur
   flux 0x0. Les flux poussés (section 8.2) dépendent initialement de leur
   flux associé. Dans les deux cas, les flux reçoivent une valeur par défaut
   poids de 16.

5.4. La gestion des erreurs

   Le cadrage HTTP / 2 autorise deux classes d'erreur:

   o Une condition d'erreur qui rend l'ensemble de la connexion inutilisable est
      une erreur de connexion.

   o Une erreur dans un flux individuel est une erreur de flux.

   Une liste de codes d'erreur est incluse dans la section 7.

5.4.1. Gestion des erreurs de connexion

   Une erreur de connexion est toute erreur qui empêche le traitement ultérieur de
   la couche de cadre ou corrompt tout état de connexion.

   Un point d'extrémité qui rencontre une erreur de connexion DEVRAIT d'abord envoyer un
   Trame GOAWAY (Section 6.8) avec l'identifiant de flux du dernier
   flux qu'il a reçu avec succès de son homologue. Le cadre GOAWAY
   inclut un code d'erreur indiquant pourquoi la connexion est
   se terminant. Après l'envoi de la trame GOAWAY pour une condition d'erreur,
   l'extrémité DOIT fermer la connexion TCP.

   Il est possible que le GOAWAY ne soit pas reçu de manière fiable par le
   récepteur ([RFC7230], Section 6.6 décrit comment un
   la fermeture de la connexion peut entraîner une perte de données). En cas de
   erreur de connexion, GOAWAY fournit uniquement une tentative de
   communiquer avec le pair pour savoir pourquoi la connexion est en cours
   terminé.

   Un point de terminaison peut mettre fin à une connexion à tout moment. En particulier, un
   le point d'extrémité PEUT choisir de traiter une erreur de flux comme une erreur de connexion.
   Les points d'extrémité DEVRAIENT envoyer une trame GOAWAY à la fin d'une connexion,
   à condition que les circonstances le permettent.

5.4.2. Gestion des erreurs de flux

   Une erreur de flux est une erreur liée à un flux spécifique qui ne
   affectent le traitement des autres flux.

   Un point de terminaison qui détecte une erreur de flux envoie une trame RST_STREAM
   (Section 6.4) qui contient l'identifiant de flux du flux où
   l'erreur s'est produite. La trame RST_STREAM comprend un code d'erreur qui
   indique le type d'erreur.

   Un RST_STREAM est la dernière trame qu'un point de terminaison peut envoyer sur un flux.
   L'homologue qui envoie la trame RST_STREAM DOIT être prêt à recevoir
   toutes les trames qui ont été envoyées ou mises en file d'attente pour être envoyées par l'homologue distant.
   Ces cadres peuvent être ignorés, sauf là où ils modifient la connexion
   état (tel que l'état conservé pour la compression d'en-tête
   (Section 4.3) ou contrôle de flux).

   Normalement, une extrémité NE DEVRAIT PAS envoyer plus d'une trame RST_STREAM
   pour n'importe quel flux. Cependant, un point d'extrémité PEUT envoyer des RST_STREAM supplémentaires
   frames s'il reçoit des frames sur un flux fermé après plus d'un
   temps de parcours. Ce comportement est autorisé à gérer un mauvais comportement
   implémentations.

   Pour éviter les boucles, un point d'extrémité NE DOIT PAS envoyer un RST_STREAM en réponse
   à une trame RST_STREAM.

5.4.3. Terminaison de la connexion

   Si la connexion TCP est fermée ou réinitialisée alors que les flux restent
   état "ouvert" ou "semi-fermé", les flux concernés ne peuvent pas être
   réessayé automatiquement (voir Section 8.1.4 pour plus de détails).

5.5. Extension de HTTP / 2

   HTTP / 2 permet l'extension du protocole. Dans les limites
   décrit dans cette section, les extensions de protocole peuvent être utilisées pour fournir
   services supplémentaires ou modifier tout aspect du protocole. Extensions
   ne sont efficaces que dans le cadre d'une seule connexion HTTP / 2.

   Ceci s'applique aux éléments de protocole définis dans ce document. Ce
   n'affecte pas les options existantes pour étendre HTTP, telles que
   définir de nouvelles méthodes, codes d'état ou champs d'en-tête.

   Les extensions sont autorisées à utiliser de nouveaux types de trames (section 4.1),
   paramètres (section 6.5.2) ou de nouveaux codes d'erreur (section 7). Registres
   sont établis pour gérer ces points d'extension: types de trame
   (Section 11.2), paramètres (Section 11.3) et codes d'erreur
   (Section 11.4).

   Les implémentations DOIVENT ignorer les valeurs inconnues ou non prises en charge dans tous
   éléments de protocole extensibles. Les implémentations DOIVENT rejeter les trames
   qui ont des types inconnus ou non pris en charge. Cela signifie que l'un de ces
   les points d'extension peuvent être utilisés en toute sécurité par des extensions sans
   arrangement ou négociation. Cependant, les cadres d'extension qui apparaissent dans
   le milieu d'un bloc d'en-tête (section 4.3) n'est pas autorisé; celles-ci
   DOIT être traité comme une erreur de connexion (section 5.4.1) de type
   ERREUR DE PROTOCOLE.

   Extensions qui pourraient changer la sémantique du protocole existant
   les composants DOIVENT être négociés avant d'être utilisés. Par exemple, un
   l'extension qui modifie la disposition du cadre HEADERS ne peut pas être utilisée
   jusqu'à ce que le pair ait donné un signal positif indiquant que cela est acceptable.
   Dans ce cas, il pourrait également être nécessaire de coordonner le
   mise en page révisée entre en vigueur. Notez que le traitement des cadres
   autres que les trames de données comme le flux contrôlé est un tel changement dans
   sémantique et ne peut se faire que par négociation.

   Ce document ne prescrit pas de méthode spécifique pour négocier le
   utilisation d'une extension mais note qu'un paramètre (Section 6.5.2) pourrait être
   utilisé à cette fin. Si les deux pairs définissent une valeur qui indique
   la volonté d'utiliser l'extension, alors l'extension peut être utilisée. Si
   un paramètre est utilisé pour la négociation d'extension, la valeur initiale DOIT
   être défini de telle manière que l'extension soit initialement
   désactivé.

6. Définitions des cadres

   Cette spécification définit un certain nombre de types de trames, chacun identifié
   par un code de type 8 bits unique. Chaque type de cadre sert une
   finalité dans l'établissement et la gestion soit de la connexion
   dans son ensemble ou de flux individuels.

   La transmission de types de trames spécifiques peut modifier l'état d'un
   lien. Si les points de terminaison ne parviennent pas à maintenir une vue synchronisée du
   état de connexion, une communication réussie au sein de la connexion
   plus être possible. Par conséquent, il est important que les points de terminaison
   avoir une compréhension commune de la façon dont l'État est affecté par l'utilisation
   n'importe quel cadre donné.

6.1. LES DONNÉES

   Les trames DATA (type = 0x0) véhiculent des séquences arbitraires de longueur variable
   octets associés à un flux. Une ou plusieurs trames DATA sont utilisées,
   par exemple, pour transporter des charges utiles de requête ou de réponse HTTP.

   Les trames de données PEUVENT également contenir un remplissage. Un rembourrage peut être ajouté à DATA
   cadres pour masquer la taille des messages. Le rembourrage est une sécurité
   fonctionnalité; voir section 10.7.

    + --------------- +
    | Longueur du tampon? (8) |
    + --------------- + --------------------------------- -------------- +
    | Les données (*) ...
    + ------------------------------------------------- -------------- +
    | Rembourrage (*) ...
    + ------------------------------------------------- -------------- +

                       Figure 6: Charge utile de trame de données

   La trame DATA contient les champs suivants:

   Pad Length: un champ de 8 bits contenant la longueur de la trame
      remplissage en unités d'octets. Ce champ est conditionnel (comme
      signifié par un "?" dans le diagramme) et n'est présent que si le
      L'indicateur PADDED est défini.

   Données: données d'application. La quantité de données est le reste de la
      charge utile de la trame après avoir soustrait la longueur des autres champs
      qui sont présents.

   Padding: octets de remplissage qui ne contiennent aucune valeur sémantique d'application.
      Les octets de remplissage DOIVENT être mis à zéro lors de l'envoi. Un récepteur est
      pas obligé de vérifier le remplissage mais PEUT traiter un remplissage non nul comme
      une erreur de connexion (paragraphe 5.4.1) de type PROTOCOL_ERROR.

   La trame DATA définit les indicateurs suivants:

   END_STREAM (0x1): lorsqu'il est défini, le bit 0 indique que cette trame est la
      le dernier que le point final enverra pour le flux identifié.
      Si vous définissez cet indicateur, le flux entre dans l'un des "demi-
      fermé "ou l'état" fermé "(section 5.1).

   PADDED (0x8): lorsqu'il est défini, le bit 3 indique que le champ Pad Length
      et tout remplissage qu'il décrit sont présents.

   Les trames de données DOIVENT être associées à un flux. Si une trame DATA est
   reçu dont le champ d'identifiant de flux est 0x0, le destinataire DOIT
   répondre avec une erreur de connexion (section 5.4.1) de type
   ERREUR DE PROTOCOLE.

   Les trames DATA sont soumises au contrôle de flux et ne peuvent être envoyées que lorsqu'un
   le flux est à l'état «ouvert» ou «semi-fermé (distant)». L'ensemble
   La charge utile de la trame DATA est incluse dans le contrôle de flux, y compris le Pad
   Champs de longueur et de remplissage si présents. Si une trame DATA est reçue
   dont le flux n'est pas à l'état "ouvert" ou "semi-fermé (local)", le
   le destinataire DOIT répondre avec une erreur de flux (section 5.4.2) de type
   FLUX FERMÉ.

   Le nombre total d'octets de remplissage est déterminé par la valeur du
   Champ Pad Length. Si la longueur du rembourrage est la longueur du
   charge utile de trame ou supérieure, le destinataire DOIT traiter cela comme un
   erreur de connexion (paragraphe 5.4.1) de type PROTOCOL_ERROR.

      Remarque: une trame peut être augmentée en taille d'un octet en incluant un
      Champ Pad Length avec une valeur de zéro.

6.2. EN-TÊTES

   La trame HEADERS (type = 0x1) est utilisée pour ouvrir un flux (Section 5.1),
   et porte en outre un fragment de bloc d'en-tête. Les cadres HEADERS peuvent
   être envoyé sur un flux en mode "inactif", "réservé (local)", "ouvert" ou
   État "semi-fermé (distant)".

    + --------------- +
    | Longueur du tampon? (8) |
    + - + ------------- + --------------------------------- -------------- +
    | E | Dépendance de flux? (31) |
    + - + ------------- + --------------------------------- -------------- +
    | Poids? (8) |
    + - + ------------- + --------------------------------- -------------- +
    | Fragment de bloc d'en-tête (*) ...
    + ------------------------------------------------- -------------- +
    | Rembourrage (*) ...
    + ------------------------------------------------- -------------- +

                      Figure 7: Charge utile de trame HEADERS

   La charge utile de la trame HEADERS contient les champs suivants:

   Pad Length: un champ de 8 bits contenant la longueur de la trame
      remplissage en unités d'octets. Ce champ n'est présent que si le
      L'indicateur PADDED est défini.

   E: un indicateur à un seul bit indiquant que la dépendance de flux est
      exclusif (voir section 5.3). Ce champ n'est présent que si le
      L'indicateur PRIORITY est défini.

   Dépendance de flux: un identifiant de flux 31 bits pour le flux qui
      ce flux dépend de (voir Section 5.3). Ce champ est uniquement
      présent si l'indicateur PRIORITY est défini.

   Weight: Un entier 8 bits non signé représentant un poids de priorité pour
      le flux (voir Section 5.3). Ajoutez-en un à la valeur pour obtenir un
      poids entre 1 et 256. Ce champ n'est présent que si le
      L'indicateur PRIORITY est défini.

   Fragment de bloc d'en-tête: Un fragment de bloc d'en-tête (section 4.3).

   Remplissage: octets de remplissage.

   Le cadre HEADERS définit les indicateurs suivants:

   END_STREAM (0x1): lorsqu'il est défini, le bit 0 indique que le bloc d'en-tête
      (Section 4.3) est le dernier que le point final enverra pour le
      flux identifié.

      Une trame HEADERS porte l'indicateur END_STREAM qui signale la fin
      d'un ruisseau. Cependant, un cadre HEADERS avec l'indicateur END_STREAM
      set peut être suivi de trames CONTINUATION sur le même flux.
      Logiquement, les trames CONTINUATION font partie de la trame HEADERS.

   END_HEADERS (0x4): lorsqu'il est défini, le bit 2 indique que cette trame
      contient un bloc d'en-tête entier (section 4.3) et n'est pas suivi
      par n'importe quel cadre de CONTINUATION.

      Une trame HEADERS sans le jeu d'indicateurs END_HEADERS DOIT être suivie
      par une trame CONTINUATION pour le même flux. Un récepteur DOIT
      traiter la réception de tout autre type de cadre ou d'un cadre sur un
      flux différent comme erreur de connexion (section 5.4.1) de type
      ERREUR DE PROTOCOLE.

   PADDED (0x8): lorsqu'il est défini, le bit 3 indique que le champ Pad Length
      et tout remplissage qu'il décrit sont présents.

   PRIORITY (0x20): lorsqu'il est mis à 1, le bit 5 indique que le drapeau exclusif
      Les champs (E), Stream Dependency et Weight sont présents; voir
      Section 5.3.

   La charge utile d'une trame HEADERS contient un fragment de bloc d'en-tête
   (Section 4.3). Un bloc d'en-tête qui ne rentre pas dans un HEADERS
   cadre se poursuit dans un cadre CONTINUATION (Section 6.10).

   Les trames HEADERS DOIVENT être associées à un flux. Si un cadre HEADERS
   est reçu dont le champ d'identifiant de flux est 0x0, le destinataire DOIT
   répondre avec une erreur de connexion (section 5.4.1) de type
   ERREUR DE PROTOCOLE.

   Le cadre HEADERS modifie l'état de la connexion comme décrit dans
   Section 4.3.

   Le cadre HEADERS peut inclure un rembourrage. Les champs de remplissage et les indicateurs sont
   identiques à ceux définis pour les trames DATA (section 6.1). Rembourrage
   qui dépasse la taille restante pour le fragment de bloc d'en-tête DOIT être
   traité comme un PROTOCOL_ERROR.

   Les informations de priorisation dans une trame HEADERS sont logiquement équivalentes
   à un cadre PRIORITY séparé, mais l'inclusion dans HEADERS évite
   potentiel de désabonnement dans la hiérarchisation des flux lorsque de nouveaux flux sont
   établi. Champs de priorisation dans les trames HEADERS après
   d'abord sur un flux, redéfinissez la priorité du flux (Section 5.3.3).

6.3. PRIORITÉ

   La trame PRIORITY (type = 0x2) spécifie la priorité conseillée par l'expéditeur
   d'un flux (section 5.3). Il peut être envoyé dans n'importe quel état de flux,
   y compris les flux inactifs ou fermés.

    + - + ----------------------------------------------- -------------- +
    | E | Dépendance de flux (31) |
    + - + ------------- + --------------------------------- -------------- +
    | Poids (8) |
    + - + ------------- +

                     Figure 8: Charge utile de trame PRIORITAIRE

   La charge utile d'une trame PRIORITY contient les champs suivants:

   E: un indicateur à un seul bit indiquant que la dépendance de flux est
      exclusif (voir section 5.3).

   Dépendance de flux: un identifiant de flux 31 bits pour le flux qui
      ce flux dépend de (voir Section 5.3).

   Weight: Un entier 8 bits non signé représentant un poids de priorité pour
      le flux (voir Section 5.3). Ajoutez-en un à la valeur pour obtenir un
      poids entre 1 et 256.

   Le cadre PRIORITY ne définit aucun indicateur.

   La trame PRIORITY identifie toujours un flux. Si une trame PRIORITAIRE
   est reçu avec un identifiant de flux de 0x0, le destinataire DOIT
   répondre avec une erreur de connexion (section 5.4.1) de type
   ERREUR DE PROTOCOLE.

   La trame PRIORITY peut être envoyée sur un flux dans n'importe quel état, même si elle
   ne peut pas être envoyé entre des trames consécutives comprenant une seule
   bloc d'en-tête (section 4.3). Notez que cette trame pourrait arriver après
   le traitement ou l'envoi de la trame est terminé, ce qui le ferait
   n'ont aucun effet sur le flux identifié. Pour un flux qui est dans le
   état "semi-fermé (distant)" ou "fermé", cette trame ne peut affecter que
   traitement du flux identifié et de ses flux dépendants; il
   n'affecte pas la transmission des trames sur ce flux.

   La trame PRIORITY peut être envoyée pour un flux en mode "inactif" ou "fermé"
   Etat. Cela permet de redéfinir les priorités d'un groupe de personnes à charge
   flux en modifiant la priorité d'un parent inutilisé ou fermé
   courant.

   Une trame PRIORITAIRE d'une longueur autre que 5 octets DOIT être traitée comme
   une erreur de flux (paragraphe 5.4.2) de type FRAME_SIZE_ERROR.

6.4. RST_STREAM

   La trame RST_STREAM (type = 0x3) permet la terminaison immédiate d'un
   courant. RST_STREAM est envoyé pour demander l'annulation d'un flux ou à
   indiquent qu'une condition d'erreur s'est produite.

    + ------------------------------------------------- -------------- +
    | Code d'erreur (32) |
    + ------------------------------------------------- -------------- +

                    Figure 9: Charge utile de trame RST_STREAM

   La trame RST_STREAM contient un seul entier 32 bits non signé
   identifiant le code d'erreur (section 7). Le code d'erreur indique pourquoi
   le flux est en cours d'arrêt.

   La trame RST_STREAM ne définit aucun indicateur.

   La trame RST_STREAM termine complètement le flux référencé et
   le fait passer à l'état «fermé». Après avoir reçu un RST_STREAM
   sur un flux, le récepteur NE DOIT PAS envoyer de trames supplémentaires pour cela
   stream, à l'exception de PRIORITY. Cependant, après avoir envoyé le
   RST_STREAM, l'extrémité émettrice DOIT être prête à recevoir et
   traiter les trames supplémentaires envoyées sur le flux qui auraient pu être
   envoyé par le pair avant l'arrivée du RST_STREAM.

   Les trames RST_STREAM DOIVENT être associées à un flux. Si un RST_STREAM
   la trame est reçue avec un identifiant de flux de 0x0, le destinataire DOIT
   traiter cela comme une erreur de connexion (section 5.4.1) de type
   ERREUR DE PROTOCOLE.

   Les trames RST_STREAM NE DOIVENT PAS être envoyées pour un flux dans l'état "inactif".
   Si une trame RST_STREAM identifiant un flux inactif est reçue, le
   le destinataire DOIT traiter cela comme une erreur de connexion (section 5.4.1) de
   tapez PROTOCOL_ERROR.

   Une trame RST_STREAM d'une longueur autre que 4 octets DOIT être traitée
   comme une erreur de connexion (paragraphe 5.4.1) de type FRAME_SIZE_ERROR.

6.5. PARAMÈTRES

   La trame SETTINGS (type = 0x4) transmet les paramètres de configuration qui
   affectent la façon dont les points finaux communiquent, comme les préférences et les contraintes
   sur le comportement des pairs. Le cadre PARAMÈTRES est également utilisé pour acquitter la
   réception de ces paramètres. Individuellement, un paramètre SETTINGS peut
   également appelé «réglage».

   Les paramètres SETTINGS ne sont pas négociés; ils décrivent les caractéristiques
   de l'homologue émetteur, qui sont utilisés par l'homologue récepteur. Différent
   les valeurs pour le même paramètre peuvent être publiées par chaque pair. Pour
   exemple, un client peut définir une fenêtre de contrôle de flux initiale élevée,
   alors qu'un serveur peut définir une valeur inférieure pour conserver les ressources.

   Une trame SETTINGS DOIT être envoyée par les deux extrémités au début d'un
   connexion et PEUT être envoyé à tout autre moment par l'un ou l'autre des
   la durée de vie de la connexion. Les implémentations DOIVENT prendre en charge tous les
   les paramètres définis par cette spécification.

   Chaque paramètre d'un cadre SETTINGS remplace toute valeur existante pour
   ce paramètre. Les paramètres sont traités dans l'ordre dans lequel ils
   apparaît, et un récepteur d'une trame SETTINGS n'a pas besoin de maintenir
   tout état autre que la valeur actuelle de ses paramètres. Par conséquent,
   la valeur d'un paramètre SETTINGS est la dernière valeur vue par un
   destinataire.

   Les paramètres SETTINGS sont acquittés par l'homologue récepteur. À
   activez ceci, la trame SETTINGS définit le drapeau suivant:

   ACK (0x1): lorsqu'il est mis à 1, le bit 0 indique que cette trame reconnaît
      réception et application de la trame SETTINGS du pair. Quand cela
      bit est mis, la charge utile de la trame SETTINGS DOIT être vide.
      Réception d'une trame SETTINGS avec le drapeau ACK défini et une longueur
      la valeur de champ autre que 0 DOIT être traitée comme une erreur de connexion
      (Paragraphe 5.4.1) de type FRAME_SIZE_ERROR. Pour plus d'informations,
      voir Section 6.5.3 («Synchronisation des paramètres»).

   Les cadres SETTINGS s'appliquent toujours à une connexion, jamais à un seul flux.
   L'identifiant de flux pour une trame SETTINGS DOIT être zéro (0x0). Si un
   le point d'extrémité reçoit une trame SETTINGS dont le champ d'identifiant de flux est
   autre chose que 0x0, l'extrémité DOIT répondre avec une connexion
   erreur (paragraphe 5.4.1) de type PROTOCOL_ERROR.

   Le cadre SETTINGS affecte l'état de la connexion. Un mal formé ou
   La trame SETTINGS incomplète DOIT être traitée comme une erreur de connexion
   (Paragraphe 5.4.1) de type PROTOCOL_ERROR.

   Une trame SETTINGS d'une longueur autre qu'un multiple de 6 octets DOIT
   être traitée comme une erreur de connexion (section 5.4.1) de type
   FRAME_SIZE_ERROR.

6.5.1. PARAMÈTRES Format

   La charge utile d'une trame SETTINGS se compose de zéro ou plusieurs paramètres,
   chacun composé d'un identificateur de paramètre 16 bits non signé et d'un
   valeur 32 bits non signée.

    + ------------------------------- +
    | Identifiant (16) |
    + ------------------------------- + ----------------- -------------- +
    | Valeur (32) |
    + ------------------------------------------------- -------------- +

                         Figure 10: Définition du format

6.5.2. Paramètres SETTINGS définis

   Les paramètres suivants sont définis:

   SETTINGS_HEADER_TABLE_SIZE (0x1): permet à l'expéditeur d'informer le
      point de terminaison distant de la taille maximale de la compression d'en-tête
      table utilisée pour décoder les blocs d'en-tête, en octets. L'encodeur peut
      sélectionnez toute taille égale ou inférieure à cette valeur en utilisant
      signalisation spécifique au format de compression d'en-tête à l'intérieur d'un
      bloc d'en-tête (voir [COMPRESSION]). La valeur initiale est 4096
      octets.

   SETTINGS_ENABLE_PUSH (0x2): ce paramètre peut être utilisé pour désactiver
      serveur push (Section 8.2). Un point d'extrémité NE DOIT PAS envoyer de
      Trame PUSH_PROMISE si elle reçoit ce paramètre défini sur une valeur de
      0. Un point de terminaison qui a à la fois défini ce paramètre sur 0 et l'a
      acquitté DOIT traiter la réception d'une trame PUSH_PROMISE comme un
      erreur de connexion (paragraphe 5.4.1) de type PROTOCOL_ERROR.

      La valeur initiale est 1, ce qui indique que le serveur push est
      permis. Toute valeur autre que 0 ou 1 DOIT être traitée comme un
      erreur de connexion (paragraphe 5.4.1) de type PROTOCOL_ERROR.

   SETTINGS_MAX_CONCURRENT_STREAMS (0x3): indique le nombre maximum
      de flux simultanés que l'expéditeur autorisera. Cette limite est
      directionnel: il s'applique au nombre de flux que l'expéditeur
      permet au récepteur de créer. Au départ, il n'y a pas de limite à
      cette valeur. Il est recommandé que cette valeur ne soit pas inférieure à
      100, afin de ne pas limiter inutilement le parallélisme.

      Une valeur de 0 pour SETTINGS_MAX_CONCURRENT_STREAMS NE DEVRAIT PAS être
      traité comme spécial par les points de terminaison. Une valeur nulle empêche le
      création de nouveaux flux; cependant, cela peut également se produire pour tout
      limite qui est épuisée avec les flux actifs. Les serveurs DEVRAIENT uniquement
      définir une valeur zéro pour les courtes durées; si un serveur ne souhaite pas
      accepter les demandes, la fermeture de la connexion est plus appropriée.

   SETTINGS_INITIAL_WINDOW_SIZE (0x4): indique l'initiale de l'expéditeur
      taille de la fenêtre (en octets) pour le contrôle de flux au niveau du flux. le
      la valeur initiale est de 2 ^ 16-1 (65 535) octets.

      Ce paramètre affecte la taille de la fenêtre de tous les flux (voir
      Section 6.9.2).

      Les valeurs supérieures à la taille maximale de la fenêtre de contrôle de flux de 2 ^ 31-1 DOIVENT
      être traitée comme une erreur de connexion (section 5.4.1) de type
      FLOW_CONTROL_ERROR.

   SETTINGS_MAX_FRAME_SIZE (0x5): indique la taille du plus grand
      charge utile de trame que l'expéditeur est prêt à recevoir, en octets.

      La valeur initiale est de 2 ^ 14 (16 384) octets. La valeur annoncée
      par un point d'extrémité DOIT être compris entre cette valeur initiale et le maximum
      taille de trame autorisée (2 ^ 24-1 ou 16 777 215 octets), inclus.
      Les valeurs en dehors de cette plage DOIVENT être traitées comme une erreur de connexion
      (Paragraphe 5.4.1) de type PROTOCOL_ERROR.

   SETTINGS_MAX_HEADER_LIST_SIZE (0x6): ce paramètre consultatif informe un
      homologue de la taille maximale de la liste d'en-têtes que l'expéditeur est
      prêt à accepter, en octets. La valeur est basée sur le
      taille non compressée des champs d'en-tête, y compris la longueur du
      nom et valeur en octets plus une surcharge de 32 octets pour chacun
      champ d'en-tête.

      Pour toute demande donnée, une limite inférieure à ce qui est annoncé PEUT
      être appliquée. La valeur initiale de ce paramètre est illimitée.

   Un point de terminaison qui reçoit une trame SETTINGS avec un inconnu ou
   L'identifiant non pris en charge DOIT ignorer ce paramètre.

6.5.3. Synchronisation des paramètres

   La plupart des valeurs de SETTINGS bénéficient ou nécessitent une compréhension de
   lorsque l'homologue a reçu et appliqué les valeurs de paramètres modifiées.
   Afin de fournir de tels moments de synchronisation, le destinataire de
   une trame SETTINGS dans laquelle l'indicateur ACK n'est pas positionné DOIT appliquer le
   paramètres mis à jour dès que possible dès réception.

   Les valeurs du cadre PARAMÈTRES DOIVENT être traitées dans l'ordre où elles
   apparaissent, sans autre traitement de trame entre les valeurs. Non pris en charge
   les paramètres DOIVENT être ignorés. Une fois toutes les valeurs traitées, le
   le destinataire DOIT immédiatement émettre une trame SETTINGS avec l'indicateur ACK
   ensemble. À la réception d'une trame SETTINGS avec l'indicateur ACK défini, le
   l'expéditeur des paramètres modifiés peut compter sur le paramètre ayant été
   appliqué.

   Si l'expéditeur d'une trame SETTINGS ne reçoit pas d'accusé de réception
   dans un délai raisonnable, il PEUT émettre une erreur de connexion
   (Section 5.4.1) de type SETTINGS_TIMEOUT.

6.6. PUSH_PROMISE

   La trame PUSH_PROMISE (type = 0x5) est utilisée pour notifier le point de terminaison homologue
   avant les flux que l'expéditeur a l'intention de lancer. le
   La trame PUSH_PROMISE comprend l'identifiant 31 bits non signé du
   diffuser les plans de point de terminaison à créer avec un ensemble d'en-têtes qui
   fournir un contexte supplémentaire pour le flux. La section 8.2 contient un
   description détaillée de l'utilisation des trames PUSH_PROMISE.

    + --------------- +
    | Longueur du tampon? (8) |
    + - + ------------- + --------------------------------- -------------- +
    | R | ID de flux promis (31) |
    + - + ----------------------------- + ----------------- -------------- +
    | Fragment de bloc d'en-tête (*) ...
    + ------------------------------------------------- -------------- +
    | Rembourrage (*) ...
    + ------------------------------------------------- -------------- +

                  Figure 11: Format de charge utile PUSH_PROMISE

   La charge utile de la trame PUSH_PROMISE contient les champs suivants:

   Pad Length: un champ de 8 bits contenant la longueur de la trame
      remplissage en unités d'octets. Ce champ n'est présent que si le
      L'indicateur PADDED est défini.

   R: Un seul bit réservé.

   ID de flux promis: un entier 31 bits non signé qui identifie le
      flux réservé par PUSH_PROMISE. Le flux promis
      L'identifiant DOIT être un choix valide pour le prochain flux envoyé par le
      sender (voir "nouvel identifiant de flux" dans la section 5.1.1).

   Fragment de bloc d'en-tête: un fragment de bloc d'en-tête (section 4.3)
      contenant des champs d'en-tête de demande.

   Remplissage: octets de remplissage.

   Le cadre PUSH_PROMISE définit les indicateurs suivants:

   END_HEADERS (0x4): lorsqu'il est défini, le bit 2 indique que cette trame
      contient un bloc d'en-tête entier (section 4.3) et n'est pas suivi
      par n'importe quel cadre de CONTINUATION.

      Une trame PUSH_PROMISE sans le jeu d'indicateurs END_HEADERS DOIT être
      suivi d'une trame CONTINUATION pour le même flux. Un récepteur
      DOIT traiter la réception de tout autre type de cadre ou d'un cadre sur un
      flux différent comme erreur de connexion (section 5.4.1) de type
      ERREUR DE PROTOCOLE.

   PADDED (0x8): lorsqu'il est défini, le bit 3 indique que le champ Pad Length
      et tout remplissage qu'il décrit sont présents.

   Les trames PUSH_PROMISE DOIVENT être envoyées uniquement sur un flux lancé par un pair qui
   est à l'état "ouvert" ou "semi-fermé (distant)". Le flux
   l'identifiant d'une trame PUSH_PROMISE indique le flux dont il s'agit
   associé à. Si le champ d'identificateur de flux spécifie la valeur
   0x0, un destinataire DOIT répondre avec une erreur de connexion (paragraphe 5.4.1)
   de type PROTOCOL_ERROR.

   Les flux promis ne doivent pas être utilisés dans l'ordre dans lequel ils sont
   promis. Le PUSH_PROMISE réserve uniquement les identifiants de flux pour
   utilisation ultérieure.

   PUSH_PROMISE NE DOIT PAS être envoyé si le paramètre SETTINGS_ENABLE_PUSH de
   le point de terminaison homologue est défini sur 0. Un point de terminaison qui a défini ce paramètre
   et a reçu un accusé de réception DOIT traiter la réception d'un
   Trame PUSH_PROMISE comme erreur de connexion (paragraphe 5.4.1) de type
   ERREUR DE PROTOCOLE.

   Les destinataires des trames PUSH_PROMISE peuvent choisir de rejeter la promesse
   streams en renvoyant un RST_STREAM référençant le stream promis
   identifiant renvoyé à l'expéditeur du PUSH_PROMISE.

   Une trame PUSH_PROMISE modifie l'état de connexion de deux manières.
   Premièrement, l'inclusion d'un bloc d'en-tête (section 4.3) potentiellement
   modifie l'état conservé pour la compression d'en-tête. Seconde,
   PUSH_PROMISE réserve également un flux pour une utilisation ultérieure, provoquant le
   a promis au flux d'entrer dans l'état «réservé». Un expéditeur NE DOIT PAS
   envoyer un PUSH_PROMISE sur un flux sauf si ce flux est soit "ouvert"
   ou "à moitié fermé (à distance)"; l'expéditeur DOIT s'assurer que la promesse
   stream est un choix valide pour un nouvel identifiant de flux (Section 5.1.1)
   (c'est-à-dire que le flux promis DOIT être dans l'état "inactif").

   Puisque PUSH_PROMISE réserve un flux, en ignorant une trame PUSH_PROMISE
   rend l'état du flux indéterminé. Un récepteur DOIT
   traiter la réception d'un PUSH_PROMISE sur un flux qui n'est ni
   "ouvert" ou "semi-fermé (local)" comme erreur de connexion
   (Paragraphe 5.4.1) de type PROTOCOL_ERROR. Cependant, un point final qui
   a envoyé RST_STREAM sur le flux associé DOIT gérer PUSH_PROMISE
   cadres qui auraient pu être créés avant que le cadre RST_STREAM ne soit
   reçus et traités.

   Un récepteur DOIT traiter la réception d'un PUSH_PROMISE qui promet un
   identifiant de flux illégal (section 5.1.1) comme erreur de connexion
   (Paragraphe 5.4.1) de type PROTOCOL_ERROR. Notez qu'un flux illégal
   identifiant est un identifiant pour un flux qui n'est pas actuellement dans le
   "état de repos.

   La trame PUSH_PROMISE peut inclure un remplissage. Champs de remplissage et indicateurs
   sont identiques à ceux définis pour les trames DATA (paragraphe 6.1).

6.7. PING

   La trame PING (type = 0x6) est un mécanisme de mesure d'un minimum
   temps aller-retour de l'expéditeur, ainsi que de déterminer si un
   la connexion inactive est toujours fonctionnelle. Les trames PING peuvent être envoyées depuis
   n'importe quel point final.

    + ------------------------------------------------- -------------- +
    | |
    | Données opaques (64) |
    | |
    + ------------------------------------------------- -------------- +

                      Figure 12: Format de la charge utile PING

   En plus de l'en-tête de trame, les trames PING DOIVENT contenir 8 octets de
   données opaques dans la charge utile. Un expéditeur peut inclure n'importe quelle valeur
   choisit et utilise ces octets de n'importe quelle manière.

   Les destinataires d'une trame PING qui n'inclut pas d'indicateur ACK DOIVENT envoyer
   une trame PING avec l'indicateur ACK mis en réponse, avec un
   charge utile. Les réponses PING DEVRAIENT avoir une priorité plus élevée que tout
   autre cadre.

   Le cadre PING définit les indicateurs suivants:

   ACK (0x1): lorsqu'il est défini, le bit 0 indique que cette trame PING est un PING
      réponse. Un point d'extrémité DOIT définir cet indicateur dans les réponses PING. Une
      le point d'extrémité NE DOIT PAS répondre aux trames PING contenant ce drapeau.

   Les trames PING ne sont associées à aucun flux individuel. Si un PING
   la trame est reçue avec une valeur de champ d'identificateur de flux autre que
   0x0, le destinataire DOIT répondre par une erreur de connexion
   (Paragraphe 5.4.1) de type PROTOCOL_ERROR.

   La réception d'une trame PING avec une valeur de champ de longueur autre que 8 DOIT
   être traitée comme une erreur de connexion (section 5.4.1) de type
   FRAME_SIZE_ERROR.

6.8. ALLEZ-VOUS EN

   La trame GOAWAY (type = 0x7) est utilisée pour lancer l'arrêt d'un
   connexion ou pour signaler des conditions d'erreur graves. GOAWAY permet une
   endpoint pour cesser d'accepter de nouveaux flux tout en étant toujours
   finition du traitement des flux précédemment établis. Cela permet
   les actions administratives, comme la maintenance du serveur.

   Il existe une condition de concurrence inhérente entre un point de terminaison commençant par un nouveau
   flux et la télécommande envoyant une trame GOAWAY. Pour faire face à ça
   cas, le GOAWAY contient l'identifiant de flux du dernier pair
   flux lancé qui a été ou pourrait être traité lors de l'envoi
   point final dans cette connexion. Par exemple, si le serveur envoie un
   GOAWAY frame, le flux identifié est le flux le plus numéroté
   initiée par le client.

   Une fois envoyés, l'expéditeur ignorera les trames envoyées sur les flux lancés par
   le récepteur si le flux a un identifiant supérieur à celui inclus
   identifiant du dernier flux. Les récepteurs d'une trame GOAWAY NE DOIVENT PAS s'ouvrir
   flux supplémentaires sur la connexion, bien qu'une nouvelle connexion puisse
   être établi pour de nouveaux flux.

   Si le récepteur du GOAWAY a envoyé des données sur des flux avec un
   identifiant de flux que ce qui est indiqué dans la trame GOAWAY, ceux
   les flux ne sont pas ou ne seront pas traités. Le récepteur du GOAWAY
   frame peut traiter les flux comme s'ils n'avaient jamais été créés à
   tous, permettant ainsi de réessayer ultérieurement ces flux sur un nouveau
   lien.

   Les points finaux DEVRAIENT toujours envoyer une trame GOAWAY avant de fermer un
   connexion afin que l'homologue distant puisse savoir si un flux a été
   partiellement traité ou non. Par exemple, si un client HTTP envoie un
   POST en même temps qu'un serveur ferme une connexion, le client
   ne peut pas savoir si le serveur a commencé à traiter cette requête POST si le
   le serveur n'envoie pas de trame GOAWAY pour indiquer quels flux il pourrait
   ont agi.

   Un point de terminaison peut choisir de fermer une connexion sans envoyer de
   GOAWAY pour les pairs qui se comportent mal.

   Un cadre GOAWAY peut ne pas précéder immédiatement la fermeture du
   lien; un récepteur d'un GOAWAY qui n'a plus d'utilité pour le
   connexion DEVRAIT encore envoyer une trame GOAWAY avant de terminer le
   lien.

    + - + ----------------------------------------------- -------------- +
    | R | ID du dernier flux (31) |
    + - + ----------------------------------------------- -------------- +
    | Code d'erreur (32) |
    + ------------------------------------------------- -------------- +
    | Données de débogage supplémentaires (*) |
    + ------------------------------------------------- -------------- +

                     Figure 13: Format de la charge utile GOAWAY

   La trame GOAWAY ne définit aucun drapeau.

   La trame GOAWAY s'applique à la connexion, pas à un flux spécifique.
   Un point d'extrémité DOIT traiter une trame GOAWAY avec un identificateur de flux autre
   que 0x0 comme erreur de connexion (section 5.4.1) de type
   ERREUR DE PROTOCOLE.

   Le dernier identifiant de flux dans la trame GOAWAY contient le plus
   identifiant de flux numéroté pour lequel l'expéditeur de la trame GOAWAY
   peut avoir pris des mesures ou peut encore prendre des mesures. Tout
   les flux jusqu'au flux identifié inclus peuvent avoir été
   traitées d'une manière ou d'une autre. Le dernier identifiant de flux peut être défini sur 0 si
   aucun flux n'a été traité.

      Remarque: dans ce contexte, «traité» signifie que certaines données du
      flux a été transmis à une couche supérieure de logiciel qui pourrait avoir
      a pris des mesures en conséquence.

   Si une connexion se termine sans une trame GOAWAY, le dernier flux
   identifier est effectivement l'identifiant de flux le plus élevé possible.

   Sur les flux avec des identifiants de numéro inférieur ou égal qui n'étaient pas
   fermé complètement avant la fermeture de la connexion, nouvelle tentative
   les demandes, les transactions ou toute activité de protocole n'est pas possible,
   à l'exception des actions idempotentes telles que HTTP GET, PUT ou
   SUPPRIMER. Toute activité de protocole qui utilise des flux de numéro plus élevé peut
   être retenté en toute sécurité en utilisant une nouvelle connexion.

   Activité sur les flux numérotés inférieur ou égal au dernier flux
   l'identificateur peut encore se terminer avec succès. L'expéditeur d'un GOAWAY
   frame pourrait arrêter une connexion en douceur en envoyant un GOAWAY
   cadre, en maintenant la connexion dans un état «ouvert» jusqu'à ce que tout soit
   les flux de progression sont terminés.

   Une extrémité PEUT envoyer plusieurs trames GOAWAY si les circonstances changent.
   Par exemple, un point de terminaison qui envoie GOAWAY avec NO_ERROR pendant
   un arrêt progressif pourrait par la suite rencontrer une condition qui
   nécessite l'arrêt immédiat de la connexion. Le dernier flux
   l'identifiant de la dernière trame GOAWAY reçue indique quel
   les flux auraient pu être utilisés. Les points finaux NE DOIVENT PAS augmenter la
   valeur qu'ils envoient dans le dernier identifiant de flux, car les pairs pourraient
   ont déjà réessayé des demandes non traitées sur une autre connexion.

   Un client qui ne parvient pas à réessayer les demandes perd toutes les demandes
   en vol lorsque le serveur ferme la connexion. C'est surtout
   vrai pour les intermédiaires qui pourraient ne pas servir les clients utilisant
   HTTP / 2. Un serveur qui tente d'arrêter correctement un
   connexion DEVRAIT envoyer une trame GOAWAY initiale avec le dernier flux
   identifiant défini sur 2 ^ 31-1 et un code NO_ERROR. Cela signale au
   client qu'un arrêt est imminent et que le lancement
   les demandes sont interdites. Après avoir accordé du temps pour tout flux en vol
   création (au moins un aller-retour), le serveur peut en envoyer un autre
   Cadre GOAWAY avec un identifiant de dernier flux mis à jour. Cela garantit
   qu'une connexion peut être fermée proprement sans perdre de requêtes.

   Après avoir envoyé une trame GOAWAY, l'expéditeur peut ignorer les trames pour
   flux lancés par le récepteur avec des identifiants supérieurs à
   identifié dernier flux. Cependant, toutes les images qui modifient la connexion
   l'état ne peut pas être complètement ignoré. Par exemple, HEADERS,
   Les trames PUSH_PROMISE et CONTINUATION DOIVENT être traitées au minimum en
   s'assurer que l'état conservé pour la compression d'en-tête est cohérent (voir
   Section 4.3); de même, les trames DATA DOIVENT être comptées dans le
   fenêtre de contrôle de flux de connexion. Le non-traitement de ces trames peut
   faire en sorte que le contrôle de flux ou l'état de compression d'en-tête devienne
   non synchronisé.

   La trame GOAWAY contient également un code d'erreur 32 bits (section 7) qui
   contient la raison de la fermeture de la connexion.

   Les points d'extrémité PEUVENT ajouter des données opaques à la charge utile de toute trame GOAWAY.
   Les données de débogage supplémentaires sont destinées à des fins de diagnostic uniquement et
   n'a aucune valeur sémantique. Les informations de débogage peuvent contenir la sécurité-
   ou des données sensibles à la confidentialité. Enregistré ou stocké de manière permanente
   les données de débogage DOIVENT avoir des garanties adéquates pour empêcher les
   accès.

6.9. WINDOW_UPDATE

   La trame WINDOW_UPDATE (type = 0x8) est utilisée pour implémenter le contrôle de flux;
   voir la section 5.2 pour un aperçu.

   Le contrôle de flux fonctionne à deux niveaux: sur chaque flux individuel et sur
   toute la connexion.

   Les deux types de contrôle de flux sont saut par saut, c'est-à-dire uniquement entre les
   deux points de terminaison. Les intermédiaires ne transfèrent pas les trames WINDOW_UPDATE
   entre connexions dépendantes. Cependant, la limitation du transfert de données
   par n'importe quel récepteur peut provoquer indirectement la propagation du contrôle de flux
   informations vers l'expéditeur d'origine.

   Le contrôle de flux ne s'applique qu'aux trames identifiées comme étant
   soumis au contrôle de flux. Parmi les types de trame définis dans ce
   document, cela inclut uniquement les trames DATA. Cadres exemptés
   du contrôle de flux DOIT être accepté et traité, sauf si le récepteur
   ne peut pas affecter des ressources à la gestion de la trame. Un récepteur PEUT
   répondre avec une erreur de flux (section 5.4.2) ou une erreur de connexion
   (Paragraphe 5.4.1) de type FLOW_CONTROL_ERROR s'il est incapable d'accepter
   un cadre.

    + - + ----------------------------------------------- -------------- +
    | R | Incrément de taille de fenêtre (31) |
    + - + ----------------------------------------------- -------------- +

                  Figure 14: Format de la charge utile WINDOW_UPDATE

   La charge utile d'une trame WINDOW_UPDATE est un bit réservé plus un
   Entier 31 bits non signé indiquant le nombre d'octets que le
   l'expéditeur peut transmettre en plus de la fenêtre de contrôle de flux existante.
   La plage légale pour l'incrément de la fenêtre de contrôle de flux va de 1 à
   2 ^ 31-1 (2 147 483 647) octets.

   Le cadre WINDOW_UPDATE ne définit aucun indicateur.

   Le cadre WINDOW_UPDATE peut être spécifique à un flux ou à l'ensemble
   lien. Dans le premier cas, l'identifiant de flux de la trame
   indique le flux affecté; dans ce dernier, la valeur "0" indique
   que l'ensemble de la connexion est le sujet du cadre.

   Un récepteur DOIT traiter la réception d'une trame WINDOW_UPDATE avec un
   incrément de la fenêtre de contrôle de flux de 0 en tant qu'erreur de flux (Section 5.4.2)
   de type PROTOCOL_ERROR; erreurs dans la fenêtre de contrôle du flux de connexion
   DOIT être traité comme une erreur de connexion (section 5.4.1).

   WINDOW_UPDATE peut être envoyé par un pair qui a envoyé une trame portant le
   Indicateur END_STREAM. Cela signifie qu'un récepteur pourrait recevoir un
   Trame WINDOW_UPDATE sur un flux "semi-fermé (distant)" ou "fermé".
   Un récepteur NE DOIT PAS traiter cela comme une erreur (voir la section 5.1).

   Un récepteur qui reçoit une trame contrôlée par le flux DOIT toujours tenir compte
   pour sa contribution à la fenêtre de contrôle de flux de connexion,
   sauf si le récepteur traite cela comme une erreur de connexion
   (Section 5.4.1). Ceci est nécessaire même si la trame est en erreur.
   L'expéditeur compte la trame vers la fenêtre de contrôle de flux, mais si
   le récepteur ne le fait pas, la fenêtre de contrôle de flux à l'expéditeur et
   le récepteur peut devenir différent.

   Une trame WINDOW_UPDATE d'une longueur autre que 4 octets DOIT être
   traitée comme une erreur de connexion (section 5.4.1) de type
   FRAME_SIZE_ERROR.

6.9.1. La fenêtre de contrôle de flux

   Le contrôle de flux dans HTTP / 2 est implémenté à l'aide d'une fenêtre conservée par chaque
   expéditeur sur chaque flux. La fenêtre de contrôle de flux est un simple entier
   valeur qui indique combien d'octets de données l'expéditeur est autorisé
   transmettre; en tant que tel, sa taille est une mesure de la capacité tampon
   du récepteur.

   Deux fenêtres de contrôle de flux sont applicables: le contrôle de flux de flux
   et la fenêtre de contrôle du flux de connexion. L'expéditeur NE DOIT PAS
   envoyer une trame contrôlée par le flux d'une longueur qui dépasse l'espace
   disponible dans l'une des fenêtres de contrôle de flux annoncées par le
   destinataire. Cadres de longueur nulle avec l'indicateur END_STREAM défini (qui
   est, une trame DATA vide) PEUT être envoyée s'il n'y a pas d'espace disponible
   dans l'une ou l'autre des fenêtres de contrôle de flux.

   Pour les calculs de contrôle de flux, l'en-tête de trame de 9 octets n'est pas
   dénombré.

   Après l'envoi d'une trame contrôlée par le flux, l'expéditeur réduit l'espace
   disponible dans les deux fenêtres par la longueur de la trame transmise.

   Le récepteur d'une trame envoie une trame WINDOW_UPDATE au fur et à mesure qu'il consomme
   données et libère de l'espace dans les fenêtres de contrôle de flux. Séparé
   Les trames WINDOW_UPDATE sont envoyées pour le niveau de flux et de connexion
   fenêtres de contrôle de flux.

   Un expéditeur qui reçoit une trame WINDOW_UPDATE met à jour le
   fenêtre correspondante par le montant spécifié dans le cadre.

   Un expéditeur NE DOIT PAS permettre à une fenêtre de contrôle de flux de dépasser 2 ^ 31-1
   octets. Si un expéditeur reçoit un WINDOW_UPDATE qui provoque un flux-
   la fenêtre de contrôle pour dépasser ce maximum, il DOIT terminer soit le
   stream ou la connexion, selon le cas. Pour les flux, l'expéditeur
   envoie un RST_STREAM avec un code d'erreur FLOW_CONTROL_ERROR; pour le
   connexion, une trame GOAWAY avec un code d'erreur FLOW_CONTROL_ERROR
   est envoyé.

   Trames contrôlées par flux de l'expéditeur et trames WINDOW_UPDATE de
   les récepteurs sont complètement asynchrones les uns par rapport aux autres.
   Cette propriété permet à un récepteur de mettre à jour la fenêtre de manière agressive
   taille conservée par l'expéditeur pour empêcher le blocage des flux.

6.9.2. Taille initiale de la fenêtre de contrôle de flux

   Lorsqu'une connexion HTTP / 2 est établie pour la première fois, de nouveaux flux sont
   créé avec une taille de fenêtre de contrôle de flux initiale de 65 535 octets.
   La fenêtre de contrôle de flux de connexion est également de 65 535 octets. Tous les deux
   les points de terminaison peuvent ajuster la taille de la fenêtre initiale pour les nouveaux flux en
   incluant une valeur pour SETTINGS_INITIAL_WINDOW_SIZE dans les SETTINGS
   cadre qui fait partie de la préface de connexion. La connexion
   la fenêtre de contrôle de flux ne peut être modifiée qu'à l'aide de trames WINDOW_UPDATE.

   Avant de recevoir une trame SETTINGS qui définit une valeur pour
   SETTINGS_INITIAL_WINDOW_SIZE, un point de terminaison ne peut utiliser que la valeur par défaut
   taille de la fenêtre initiale lors de l'envoi de trames contrôlées par le flux. De même,
   la fenêtre de contrôle du flux de connexion est définie sur la valeur initiale par défaut
   taille de la fenêtre jusqu'à ce qu'une trame WINDOW_UPDATE soit reçue.

   En plus de modifier la fenêtre de contrôle de flux pour les flux qui sont
   pas encore actif, une trame SETTINGS peut modifier le contrôle de flux initial
   taille de la fenêtre pour les flux avec des fenêtres de contrôle de flux actives (c'est-à-dire
   flux dans l'état "ouvert" ou "semi-fermé (distant)"). Quand le
   la valeur de SETTINGS_INITIAL_WINDOW_SIZE change, un récepteur DOIT ajuster
   la taille de toutes les fenêtres de contrôle de flux de flux qu'il maintient par le
   différence entre la nouvelle valeur et l'ancienne valeur.

   Une modification de SETTINGS_INITIAL_WINDOW_SIZE peut entraîner la disponibilité
   l'espace dans une fenêtre de contrôle de flux pour devenir négatif. Un expéditeur DOIT
   suivre la fenêtre de contrôle de flux négatif et NE DOIT PAS envoyer de nouveau flux-
   trames contrôlées jusqu'à ce qu'il reçoive les trames WINDOW_UPDATE qui provoquent
   la fenêtre de contrôle de flux pour devenir positive.

   Par exemple, si le client envoie 60 Ko immédiatement à la connexion
   établissement et le serveur définit la taille de la fenêtre initiale à 16
   KB, le client recalculera la fenêtre de contrôle de flux disponible pour
   être -44 Ko à la réception de la trame SETTINGS. Le client conserve un
   fenêtre de contrôle de flux négatif jusqu'à ce que les trames WINDOW_UPDATE restaurent
   fenêtre positive, après quoi le client peut reprendre l'envoi.

   Un cadre SETTINGS ne peut pas modifier la fenêtre de contrôle de flux de connexion.

   Un point final DOIT traiter une modification de SETTINGS_INITIAL_WINDOW_SIZE qui
   fait que toute fenêtre de contrôle de flux dépasse la taille maximale en tant que
   erreur de connexion (paragraphe 5.4.1) de type FLOW_CONTROL_ERROR.

6.9.3. Réduction de la taille de la fenêtre de flux

   Un récepteur qui souhaite utiliser une fenêtre de contrôle de flux plus petite que le
   la taille actuelle peut envoyer une nouvelle trame PARAMÈTRES. Cependant, le récepteur
   DOIT être prêt à recevoir des données qui dépassent cette taille de fenêtre, car
   l'expéditeur peut envoyer des données qui dépassent la limite inférieure avant
   traitement de la trame PARAMÈTRES.

   Après l'envoi d'une trame SETTINGS qui réduit le contrôle de flux initial
   taille de la fenêtre, un récepteur PEUT continuer à traiter les flux qui dépassent
   limites de contrôle de débit. Autoriser la poursuite des flux ne permet pas
   récepteur pour réduire immédiatement l'espace qu'il réserve pour le contrôle de flux
   les fenêtres. Les progrès sur ces flux peuvent également stagner, car
   Des trames WINDOW_UPDATE sont nécessaires pour permettre à l'expéditeur de reprendre
   Envoi en cours. Le récepteur PEUT à la place envoyer un RST_STREAM avec une erreur
   code de FLOW_CONTROL_ERROR pour les flux concernés.

6.10. CONTINUATION

   La trame CONTINUATION (type = 0x9) est utilisée pour continuer une séquence de
   fragments de bloc d'en-tête (section 4.3). N'importe quel nombre de CONTINUATION
   les trames peuvent être envoyées, tant que la trame précédente est sur la même
   stream et est un cadre HEADERS, PUSH_PROMISE ou CONTINUATION sans
   le jeu d'indicateurs END_HEADERS.

    + ------------------------------------------------- -------------- +
    | Fragment de bloc d'en-tête (*) ...
    + ------------------------------------------------- -------------- +

                   Figure 15: SUITE Charge utile de la trame

   La charge utile de la trame CONTINUATION contient un fragment de bloc d'en-tête
   (Section 4.3).

   Le cadre CONTINUATION définit l'indicateur suivant:

   END_HEADERS (0x4): lorsqu'il est défini, le bit 2 indique que cette trame termine un
      bloc d'en-tête (section 4.3).

      Si le bit END_HEADERS n'est pas mis à 1, cette trame DOIT être suivie de
      un autre cadre de CONTINUATION. Un récepteur DOIT traiter la réception de
      tout autre type de cadre ou un cadre sur un flux différent en tant que
      erreur de connexion (paragraphe 5.4.1) de type PROTOCOL_ERROR.

   Le cadre CONTINUATION modifie l'état de connexion tel que défini dans
   Section 4.3.

   Les trames CONTINUATION DOIVENT être associées à un flux. Si un
   La trame CONTINUATION est reçue dont le champ d'identifiant de flux est 0x0,
   le destinataire DOIT répondre par une erreur de connexion (section 5.4.1) de
   tapez PROTOCOL_ERROR.

   Une trame CONTINUATION DOIT être précédée d'un HEADERS, PUSH_PROMISE ou
   Cadre CONTINUATION sans l'indicateur END_HEADERS défini. Un destinataire
   qui observe une violation de cette règle DOIT répondre par une connexion
   erreur (paragraphe 5.4.1) de type PROTOCOL_ERROR.

7. Codes d'erreur

   Les codes d'erreur sont des champs 32 bits utilisés dans RST_STREAM et GOAWAY
   frames pour transmettre les raisons de l'erreur de flux ou de connexion.

   Les codes d'erreur partagent un espace de code commun. Certains codes d'erreur s'appliquent uniquement
   aux flux ou à l'ensemble de la connexion et n'ont pas de définition
   sémantique dans l’autre contexte.

   Les codes d'erreur suivants sont définis:

   NO_ERROR (0x0): la condition associée n'est pas le résultat d'un
      Erreur. Par exemple, un GOAWAY peut inclure ce code pour indiquer
      arrêt progressif d'une connexion.

   PROTOCOL_ERROR (0x1): le point final a détecté un protocole non spécifique
      Erreur. Cette erreur est à utiliser lorsqu'un code d'erreur plus spécifique est
      indisponible.

   INTERNAL_ERROR (0x2): le point de terminaison a rencontré un
      erreur interne.

   FLOW_CONTROL_ERROR (0x3): le point final a détecté que son homologue
      violé le protocole de contrôle de flux.

   SETTINGS_TIMEOUT (0x4): le point de terminaison a envoyé une trame SETTINGS mais
      ne pas recevoir de réponse en temps opportun. Voir la section 6.5.3
      ("Synchronisation des paramètres").

   STREAM_CLOSED (0x5): le point final a reçu une trame après un flux
      était à moitié fermé.

   FRAME_SIZE_ERROR (0x6): l'extrémité a reçu une trame avec un
      taille invalide.

   REFUSED_STREAM (0x7): le point final a refusé le flux avant
      effectuer tout traitement d'application (voir la section 8.1.4 pour
      détails).

   CANCEL (0x8): utilisé par le point de terminaison pour indiquer que le flux n'est pas
      plus nécessaire.

   COMPRESSION_ERROR (0x9): le point de terminaison est incapable de maintenir le
      contexte de compression d'en-tête pour la connexion.

   CONNECT_ERROR (0xa): la connexion établie en réponse à un
      La demande CONNECT (Section 8.3) a été réinitialisée ou anormalement fermée.

   ENHANCE_YOUR_CALM (0xb): le point final a détecté que son homologue est
      présentant un comportement susceptible de générer une charge excessive.

   INADEQUATE_SECURITY (0xc): le transport sous-jacent a des propriétés
      qui ne satisfont pas aux exigences minimales de sécurité (voir la section 9.2).

   HTTP_1_1_REQUIRED (0xd): le point de terminaison nécessite que HTTP / 1.1 soit utilisé
      au lieu de HTTP / 2.

   Les codes d'erreur inconnus ou non pris en charge NE DOIVENT PAS déclencher de
   comportement. Ceux-ci PEUVENT être traités par une implémentation comme étant
   équivalent à INTERNAL_ERROR.

8. Échanges de messages HTTP

   HTTP / 2 se veut aussi compatible que possible avec les usages actuels
   de HTTP. Cela signifie que, du point de vue de l'application, le
   les caractéristiques du protocole sont en grande partie inchangées. Pour y parvenir, tous
   la sémantique des requêtes et des réponses est préservée, bien que la syntaxe de
   transmettre cette sémantique a changé.

   Ainsi, la spécification et les exigences de la sémantique HTTP / 1.1 et
   Contenu [RFC7231], demandes conditionnelles [RFC7232], demandes de plage
   [RFC7233], Caching [RFC7234] et Authentication [RFC7235] sont
   applicable à HTTP / 2. Parties sélectionnées de la syntaxe de message HTTP / 1.1
   et le routage [RFC7230], tels que les schémas URI HTTP et HTTPS, sont
   également applicable dans HTTP / 2, mais l'expression de ces sémantiques pour
   ce protocole est défini dans les sections ci-dessous.

8.1. Échange de requête / réponse HTTP

   Un client envoie une requête HTTP sur un nouveau flux, en utilisant un
   identifiant de flux inutilisé (Section 5.1.1). Un serveur envoie un HTTP
   réponse sur le même flux que la demande.

   Un message HTTP (requête ou réponse) se compose de:

   1. pour une réponse uniquement, zéro ou plusieurs cadres HEADERS (chacun suivi
       par zéro ou plusieurs trames CONTINUATION) contenant le message
       en-têtes de réponses HTTP informatives (1xx) (voir [RFC7230],
       Section 3.2 et [RFC7231], Section 6.2),

   2. une trame HEADERS (suivie de zéro ou plusieurs trames CONTINUATION)
       contenant les en-têtes de message (voir [RFC7230], section 3.2),

   3. zéro ou plusieurs trames DATA contenant le corps de la charge utile (voir
       [RFC7230], section 3.3), et

   4. éventuellement, une trame HEADERS, suivie de zéro ou plus
       CONTINUATION cadres contenant la partie remorque, le cas échéant (voir
       [RFC7230], section 4.1.2).

   La dernière image de la séquence porte un indicateur END_STREAM, notant que
   une image HEADERS portant l'indicateur END_STREAM peut être suivie de
   Trames de CONTINUATION qui portent toutes les parties restantes de l'en-tête
   bloquer.

   D'autres trames (de n'importe quel flux) NE DOIVENT PAS se produire entre les EN-TÊTES
   frame et tous les cadres de CONTINUATION qui pourraient suivre.

   HTTP / 2 utilise des trames DATA pour transporter les charges utiles des messages. Le "chunked"
   le codage de transfert défini dans la section 4.1 de la [RFC7230] NE DOIT PAS être
   utilisé dans HTTP / 2.

   Les champs d'en-tête de fin sont portés dans un bloc d'en-tête qui
   met fin au flux. Un tel bloc d'en-tête est une séquence commençant
   avec un cadre HEADERS, suivi de zéro ou plusieurs cadres CONTINUATION,
   où le cadre HEADERS porte un indicateur END_STREAM. Blocs d'en-tête
   après le premier qui ne termine pas le flux ne fait pas partie d'un
   Requête ou réponse HTTP.

   Un cadre HEADERS (et les cadres CONTINUATION associés) ne peuvent apparaître que
   au début ou à la fin d'un flux. Un point de terminaison qui reçoit un HEADERS
   frame sans l'indicateur END_STREAM défini après avoir reçu un dernier (non-
   informationnel) le code d'état DOIT traiter la demande correspondante ou
   réponse comme malformée (section 8.1.2.6).

   Un échange de requête / réponse HTTP consomme pleinement un seul flux. UNE
   la requête commence par la trame HEADERS qui place le flux dans un
   état "ouvert". La demande se termine par un cadre portant END_STREAM,
   ce qui fait que le flux devient "à moitié fermé (local)" pour le
   client et "semi-fermé (distant)" pour le serveur. Une réponse commence
   avec un cadre HEADERS et se termine par un cadre portant END_STREAM, qui
   place le flux dans l'état «fermé».

   Une réponse HTTP est terminée après l'envoi du serveur - ou le client
   reçoit - une trame avec l'indicateur END_STREAM défini (y compris
   CONTINUATION nécessaires pour compléter un bloc d'en-tête). Un serveur peut
   envoyer une réponse complète avant que le client envoie un
   demande si la réponse ne dépend d'aucune partie de la demande
   qui n'a pas été envoyé et reçu. Lorsque cela est vrai, un serveur PEUT
   demander au client d'interrompre la transmission d'une requête sans erreur
   en envoyant un RST_STREAM avec un code d'erreur de NO_ERROR après l'envoi
   une réponse complète (c'est-à-dire une trame avec l'indicateur END_STREAM).
   Les clients NE DOIVENT PAS rejeter les réponses après avoir reçu un tel
   RST_STREAM, bien que les clients puissent toujours ignorer les réponses à leur
   discrétion pour d’autres raisons.

8.1.1. Mise à niveau depuis HTTP / 2

   HTTP / 2 supprime la prise en charge des 101 (protocoles de commutation)
   code d'état informationnel ([RFC7231], section 6.2.2).

   La sémantique de 101 (Switching Protocols) ne s'applique pas à un
   protocole multiplexé. Les protocoles alternatifs peuvent utiliser le même
   mécanismes que HTTP / 2 utilise pour négocier leur utilisation (voir la section 3).

8.1.2. Champs d'en-tête HTTP

   Les champs d'en-tête HTTP transportent des informations sous la forme d'une série de paires clé-valeur.
   Pour obtenir la liste des en-têtes HTTP enregistrés, reportez-vous à la section «En-tête de message
   Registre de terrain "maintenu à <https://www.iana.org/assignments/
   en-têtes de message>.

   Tout comme dans HTTP / 1.x, les noms de champ d'en-tête sont des chaînes de caractères ASCII
   caractères qui sont comparés sans tenir compte de la casse. cependant,
   les noms de champ d'en-tête DOIVENT être convertis en minuscules avant leur
   encodage en HTTP / 2. Une demande ou une réponse contenant des majuscules
   les noms de champ d'en-tête DOIVENT être traités comme mal formés (paragraphe 8.1.2.6).

8.1.2.1. Champs de pseudo-en-tête

   Alors que HTTP / 1.x utilisait la ligne de début du message (voir [RFC7230],
   Section 3.1) pour transmettre l'URI cible, la méthode de la demande, et
   le code d'état de la réponse, HTTP / 2 utilise un pseudo-en-tête spécial
   les champs commençant par le caractère «:» (ASCII 0x3a) à cet effet.

   Les champs de pseudo-en-tête ne sont pas des champs d'en-tête HTTP. Les points finaux NE DOIVENT PAS
   générer des champs de pseudo-en-tête autres que ceux définis dans ce
   document.

   Les champs de pseudo-en-tête ne sont valides que dans le contexte dans lequel ils sont
   défini. Les champs de pseudo-en-tête définis pour les demandes NE DOIVENT PAS apparaître
   dans les réponses; les champs de pseudo-en-tête définis pour les réponses NE DOIVENT PAS
   apparaissent dans les demandes. Les champs de pseudo-en-tête NE DOIVENT PAS apparaître dans
   bandes annonces. Les points finaux DOIVENT traiter une demande ou une réponse qui contient
   Champs de pseudo-en-tête non définis ou non valides car mal formés
   (Section 8.1.2.6).

   Tous les champs de pseudo-en-tête DOIVENT apparaître dans le bloc d'en-tête avant
   champs d'en-tête normaux. Toute demande ou réponse contenant un
   champ pseudo-en-tête qui apparaît dans un bloc d'en-tête après un
   le champ d'en-tête DOIT être traité comme mal formé (paragraphe 8.1.2.6).

8.1.2.2. Champs d'en-tête spécifiques à la connexion

   HTTP / 2 n'utilise pas le champ d'en-tête Connection pour indiquer
   champs d'en-tête spécifiques à la connexion; dans ce protocole, connexion-
   des métadonnées spécifiques sont transmises par d'autres moyens. Un point final NE DOIT PAS
   générer un message HTTP / 2 contenant un en-tête spécifique à la connexion
   des champs; tout message contenant des champs d'en-tête spécifiques à la connexion DOIT
   être traité comme malformé (section 8.1.2.6).

   La seule exception à cela est le champ d'en-tête TE, qui PEUT être
   présent dans une requête HTTP / 2; quand c'est le cas, il NE DOIT PAS contenir de
   valeur autre que "remorques".

   Cela signifie qu'un intermédiaire transformant un message HTTP / 1.x en
   HTTP / 2 devra supprimer tous les champs d'en-tête nommés par le
   Champ d'en-tête de connexion, ainsi que le champ d'en-tête de connexion
   lui-même. Ces intermédiaires DEVRAIENT également supprimer toute autre connexion-
   champs d'en-tête spécifiques, tels que Keep-Alive, Proxy-Connection,
   Transfer-Encoding et Upgrade, même s'ils ne sont pas désignés par le
   Champ d'en-tête de connexion.

      Remarque: HTTP / 2 ne prend pas en charge la mise à niveau vers un autre
      protocole. Les méthodes d'établissement de liaison décrites dans la section 3 sont
      jugé suffisant pour négocier l’utilisation de protocoles alternatifs.

8.1.2.3. Demander des champs de pseudo-en-tête

   Les champs de pseudo-en-tête suivants sont définis pour les requêtes HTTP / 2:

   o Le champ pseudo-en-tête ": method" inclut la méthode HTTP
      ([RFC7231], section 4).

   o Le champ pseudo-en-tête ": scheme" inclut la partie schéma de
      l'URI cible ([RFC3986], section 3.1).

      ": schéma" n'est pas limité aux URI schématisés "http" et "https". UNE
      le proxy ou la passerelle peuvent traduire des requêtes pour des schémas non HTTP,
      permettant l'utilisation de HTTP pour interagir avec des services non HTTP.

   o Le champ pseudo-en-tête ": autorité" inclut l'autorité
      partie de l'URI cible ([RFC3986], section 3.2). L'autorité
      NE DOIT PAS inclure le sous-composant obsolète "userinfo" pour "http"
      ou URI schématisés "https".

      Pour garantir que la ligne de requête HTTP / 1.1 peut être reproduite
      précisément, ce champ de pseudo-en-tête DOIT être omis lorsque
      traduction d'une requête HTTP / 1.1 qui a une cible de requête dans
      origine ou forme d'astérisque (voir [RFC7230], section 5.3). Clients
      qui génèrent directement des requêtes HTTP / 2 DEVRAIENT utiliser le ": autorité"
      champ pseudo-en-tête au lieu du champ d'en-tête Host. Une
      l'intermédiaire qui convertit une requête HTTP / 2 en HTTP / 1.1 DOIT
      créer un champ d'en-tête Host s'il n'y en a pas dans une requête en
      copie de la valeur du champ pseudo-en-tête ": autorité".

   o Le champ pseudo-en-tête ": path" comprend les parties chemin et requête
      de l'URI cible (la production "chemin absolu" et éventuellement un
      '?' caractère suivi de la production "requête" (voir Sections 3.3
      et 3.4 de [RFC3986]). Une demande sous forme d'astérisque inclut le
      valeur '*' pour le champ de pseudo-en-tête ": path".

      Ce champ pseudo-en-tête NE DOIT PAS être vide pour "http" ou "https"
      URI; URI "http" ou "https" qui ne contiennent pas de composant de chemin
      DOIT inclure une valeur de «/». L'exception à cette règle est une
      OPTIONS demande un URI "http" ou "https" qui n'inclut pas
      un composant de chemin; ceux-ci DOIVENT inclure un champ de pseudo-en-tête ": path"
      avec une valeur de «*» (voir [RFC7230], Section 5.3.4).

   Toutes les demandes HTTP / 2 DOIVENT inclure exactement une valeur valide pour le
   Champs de pseudo-en-tête ": method", ": scheme" et ": path", sauf si
   une requête CONNECT (Section 8.3). Une requête HTTP qui omet
   les champs de pseudo-en-tête obligatoires sont mal formés (paragraphe 8.1.2.6).

   HTTP / 2 ne définit pas un moyen de transporter l'identifiant de version qui est
   inclus dans la ligne de requête HTTP / 1.1.

8.1.2.4. Champs de pseudo-en-tête de réponse

   Pour les réponses HTTP / 2, un seul champ pseudo-en-tête ": status" est
   défini qui porte le champ de code d'état HTTP (voir [RFC7231],
   Section 6). Ce champ pseudo-en-tête DOIT être inclus dans tout
   réponses; sinon, la réponse est mal formée (section 8.1.2.6).

   HTTP / 2 ne définit pas un moyen de transporter la version ou la phrase de raison
   qui est inclus dans une ligne d'état HTTP / 1.1.

8.1.2.5. Compression du champ d'en-tête de cookie

   Le champ d'en-tête Cookie [COOKIE] utilise un point-virgule (";") pour délimiter
   biscuits-paires (ou "miettes"). Ce champ d'en-tête ne suit pas le
   lister les règles de construction dans HTTP (voir [RFC7230], Section 3.2.2), qui
   empêche les paires de cookies d'être séparées en différentes valeurs de nom
   paires. Cela peut réduire considérablement l'efficacité de la compression car
   les paires de cookies individuelles sont mises à jour.

   Pour permettre une meilleure efficacité de compression, le champ d'en-tête Cookie
   PEUT être divisé en champs d'en-tête séparés, chacun avec un ou plusieurs
   cookies-paires. S'il y a plusieurs champs d'en-tête Cookie après
   décompression, ceux-ci DOIVENT être concaténés en une seule chaîne d'octets
   en utilisant le délimiteur à deux octets de 0x3B, 0x20 (la chaîne ASCII ";")
   avant d'être passé dans un contexte non-HTTP / 2, tel qu'un HTTP / 1.1
   connexion ou une application serveur HTTP générique.

   Par conséquent, les deux listes suivantes de champs d'en-tête Cookie sont
   sémantiquement équivalent.

     cookie: a = b; c = d; e = f

     cookie: a = b
     cookie: c = d
     cookie: e = f

8.1.2.6. Demandes et réponses mal formées

   Une demande ou une réponse malformée est une demande par ailleurs valide
   séquence de trames HTTP / 2 mais n'est pas valide en raison de la présence de
   cadres superflus, champs d'en-tête interdits, absence de
   champs d'en-tête, ou l'inclusion de noms de champs d'en-tête en majuscules.

   Une demande ou une réponse qui inclut un corps de charge utile peut inclure un
   champ d'en-tête content-length. Une demande ou une réponse est également mal formée
   si la valeur d'un champ d'en-tête de longueur de contenu n'est pas égale à la somme
   des longueurs de charge utile de la trame DATA qui forment le corps. Une réponse
   qui est défini pour n'avoir aucune charge utile, comme décrit dans la [RFC7230],
   La section 3.3.2 peut avoir un champ d'en-tête de longueur de contenu différent de zéro, même
   bien qu'aucun contenu ne soit inclus dans les trames DATA.

   Intermédiaires qui traitent les requêtes ou réponses HTTP (c.-à-d.
   intermédiaire n'agissant pas comme un tunnel) NE DOIT PAS transmettre un
   demande ou réponse. Demandes ou réponses mal formées
   détecté DOIT être traité comme une erreur de flux (section 5.4.2) de type
   ERREUR DE PROTOCOLE.

   Pour les demandes mal formées, un serveur PEUT envoyer une réponse HTTP avant
   fermer ou réinitialiser le flux. Les clients NE DOIVENT PAS accepter un
   réponse. Notez que ces exigences visent à protéger
   contre plusieurs types d'attaques courantes contre HTTP; elles sont
   délibérément strict car être permissif peut exposer
   implémentations à ces vulnérabilités.

8.1.3. Exemples

   Cette section présente les requêtes et réponses HTTP / 1.1, avec
   illustrations de requêtes et réponses HTTP / 2 équivalentes.

   Une requête HTTP GET comprend des champs d'en-tête de requête et aucune charge utile
   corps et est donc transmise comme une seule trame HEADERS, suivie
   par zéro ou plusieurs trames CONTINUATION contenant le bloc sérialisé
   des champs d'en-tête de demande. Le cadre HEADERS dans ce qui suit a
   les indicateurs END_HEADERS et END_STREAM sont définis; pas de cadres de CONTINUATION
   sont envoyés.

     GET / resource HTTP / 1.1 HEADERS
     Hôte: example.org ==> + END_STREAM
     Accepter: image / jpeg + END_HEADERS
                                          : method = GET
                                          : schéma = https
                                          : chemin = / ressource
                                          hôte = example.org
                                          accepter = image / jpeg

   De même, une réponse qui comprend uniquement des champs d'en-tête de réponse est
   transmis sous forme de trame HEADERS (encore une fois, suivie de zéro ou plus
   Trames CONTINUATION) contenant le bloc de réponse sérialisé
   champs d'en-tête.

     EN-TÊTES HTTP / 1.1 304 non modifiés
     ETag: "xyzzy" ==> + END_STREAM
     Expire le: jeu.23 janvier ... + END_HEADERS
                                          : statut = 304
                                          etag = "xyzzy"
                                          expire = jeu, 23 janv ...

   Une requête HTTP POST qui inclut les champs d'en-tête de requête et la charge utile
   les données sont transmises sous la forme d'une trame HEADERS, suivie de zéro ou plus
   Trames CONTINUATION contenant les champs d'en-tête de la demande, suivis de
   une ou plusieurs trames DATA, avec la dernière CONTINUATION (ou HEADERS)
   trame ayant le drapeau END_HEADERS défini et la trame de données finale ayant
   le jeu d'indicateurs END_STREAM:

     POST / ressource HTTP / 1.1 EN-TÊTES
     Hôte: example.org ==> - END_STREAM
     Type de contenu: image / jpeg - END_HEADERS
     Content-Length: 123: méthode = POST
                                          : chemin = / ressource
     {données binaires}: schéma = https

                                      CONTINUATION
                                        + END_HEADERS
                                          content-type = image / jpeg
                                          hôte = example.org
                                          content-length = 123

                                      LES DONNÉES
                                        + END_STREAM
                                      {données binaires}

   Notez que les données contribuant à un champ d'en-tête donné pourraient être réparties
   entre les fragments de bloc d'en-tête. L'attribution des champs d'en-tête à
   les cadres de cet exemple sont uniquement illustratifs.

   Une réponse qui comprend des champs d'en-tête et des données de charge utile est
   transmis sous forme de trame HEADERS, suivie de zéro ou plus CONTINUATION
   trames, suivies d'une ou plusieurs trames DATA, avec la dernière trame DATA
   dans la séquence où l'indicateur END_STREAM est défini:

     HTTP / 1.1 200 EN-TÊTES OK
     Type de contenu: image / jpeg ==> - END_STREAM
     Longueur du contenu: 123 + END_HEADERS
                                          : état = 200
     {données binaires} content-type = image / jpeg
                                          content-length = 123

                                      LES DONNÉES
                                        + END_STREAM
                                      {données binaires}

   Une réponse d'information utilisant un code d'état 1xx autre que 101 est
   transmis sous forme de trame HEADERS, suivie de zéro ou plus CONTINUATION
   cadres.

   Les champs d'en-tête de fin sont envoyés sous forme de bloc d'en-tête après les deux
   bloc d'en-tête de demande ou de réponse et toutes les trames DATA ont été
   expédié. Le cadre HEADERS commençant le bloc d'en-tête des remorques a le
   L'indicateur END_STREAM est défini.

   L'exemple suivant comprend à la fois un code d'état 100 (Continuer),
   qui est envoyé en réponse à une demande contenant un "100-continue"
   jeton dans le champ d'en-tête Expect et les champs d'en-tête de fin:

     HTTP / 1.1 100 Continuer EN-TÊTES
     Extension-Field: bar ==> - END_STREAM
                                        + END_HEADERS
                                          : statut = 100
                                          champ d'extension = barre

     HTTP / 1.1 200 EN-TÊTES OK
     Type de contenu: image / jpeg ==> - END_STREAM
     Encodage de transfert: fragmenté + END_HEADERS
     Bande-annonce: Foo: status = 200
                                          content-length = 123
     123 type de contenu = image / jpeg
     {données binaires} trailer = Foo
0
     Foo: bar DATA
                                        - END_STREAM
                                      {données binaires}

                                      EN-TÊTES
                                        + END_STREAM
                                        + END_HEADERS
                                          toto = bar

8.1.4. Demander des mécanismes de fiabilité dans HTTP / 2

   Dans HTTP / 1.1, un client HTTP ne peut pas réessayer un non-idempotent
   demande lorsqu'une erreur se produit car il n'y a aucun moyen de déterminer
   la nature de l'erreur. Il est possible que certains traitements du serveur
   s'est produite avant l'erreur, ce qui pourrait entraîner des
   effets si la demande a été tentée à nouveau.

   HTTP / 2 fournit deux mécanismes pour fournir une garantie à un client
   qu'une demande n'a pas été traitée:

   o La trame GOAWAY indique le numéro de flux le plus élevé qui pourrait
      ont été traités. Les demandes sur les flux avec des nombres plus élevés sont
      donc garanti pour être sûr de réessayer.

   o Le code d'erreur REFUSED_STREAM peut être inclus dans un RST_STREAM
      frame pour indiquer que le flux est fermé avant tout
      traitement ayant eu lieu. Toute demande envoyée le
      le flux de réinitialisation peut être réessayé en toute sécurité.

   Les demandes qui n'ont pas été traitées n'ont pas échoué; les clients PEUVENT
   réessayez automatiquement, même ceux avec des méthodes non idempotentes.

   Un serveur NE DOIT PAS indiquer qu'un flux n'a pas été traité
   à moins qu'il ne puisse garantir ce fait. Si les cadres qui sont sur un flux
   sont transmis à la couche d'application pour n'importe quel flux, puis
   REFUSED_STREAM NE DOIT PAS être utilisé pour ce flux, et une trame GOAWAY
   DOIT inclure un identifiant de flux supérieur ou égal à
   identifiant de flux donné.

   En plus de ces mécanismes, la trame PING fournit un moyen pour un
   client pour tester facilement une connexion. Les connexions qui restent inactives peuvent
   deviennent cassés comme certains boîtiers de médiation (par exemple, l'adresse réseau
   traducteurs ou équilibreurs de charge) supprimez silencieusement les liaisons de connexion.
   La trame PING permet à un client de tester en toute sécurité si une connexion est
   toujours actif sans envoyer de demande.

8.2. Serveur Push

   HTTP / 2 permet à un serveur d'envoyer (ou de «pousser») des réponses de manière préventive
   (avec les demandes "promises" correspondantes) à un client dans
   association avec une précédente demande initiée par le client. Cela peut être
   utile lorsque le serveur sait que le client aura besoin de ces
   réponses disponibles afin de traiter pleinement la réponse à la
   demande originale.

   Un client peut demander que le serveur push soit désactivé, bien que ce soit
   négocié pour chaque saut indépendamment. Le SETTINGS_ENABLE_PUSH
   Le paramètre peut être défini sur 0 pour indiquer que le serveur push est désactivé.

   Les demandes promises DOIVENT pouvoir être mises en cache (voir [RFC7231], section 4.2.3),
   DOIT être sûr (voir [RFC7231], Section 4.2.1), et NE DOIT PAS inclure de
   corps de la demande. Les clients qui reçoivent une demande promise qui n'est pas
   pouvant être mis en cache, dont la sécurité n'est pas connue ou qui indique que
   présence d'un corps de demande DOIT réinitialiser le flux promis avec un
   erreur de flux (Section 5.4.2) de type PROTOCOL_ERROR. Notez que cela pourrait
   entraîner la réinitialisation du flux promis si le client ne
   reconnaître une méthode nouvellement définie comme étant sûre.

   Les réponses poussées qui peuvent être mises en cache (voir [RFC7234], section 3) peuvent être
   stocké par le client, s'il implémente un cache HTTP. Poussé
   les réponses sont considérées comme validées avec succès sur le serveur d'origine
   (par exemple, si la directive de réponse de cache "no-cache" est présente
   ([RFC7234], Section 5.2.2)) tandis que le flux identifié par le
   L'ID de flux promis est toujours ouvert.

   Les réponses poussées qui ne peuvent pas être mises en cache NE DOIVENT PAS être stockées par aucun
   Cache HTTP. Ils PEUVENT être mis à disposition de l'application
   séparément.

   Le serveur DOIT inclure une valeur dans le pseudo-en-tête ": autorité"
   champ pour lequel le serveur fait autorité (voir Section 10.1). UNE
   le client DOIT traiter un PUSH_PROMISE pour lequel le serveur n'est pas
   faisant autorité en tant qu'erreur de flux (section 5.4.2) de type
   ERREUR DE PROTOCOLE.

   Un intermédiaire peut recevoir des push du serveur et choisir de ne pas
   les transmettre au client. En d'autres termes, comment utiliser
   l'information transmise appartient à cet intermédiaire. De même, le
   l'intermédiaire peut choisir de faire des pressions supplémentaires vers le client,
   sans aucune action entreprise par le serveur.

   Un client ne peut pas pousser. Ainsi, les serveurs DOIVENT traiter la réception d'un
   Trame PUSH_PROMISE comme erreur de connexion (paragraphe 5.4.1) de type
   ERREUR DE PROTOCOLE. Les clients DOIVENT rejeter toute tentative de modification du
   SETTINGS_ENABLE_PUSH sur une valeur autre que 0 en traitant le
   message comme erreur de connexion (paragraphe 5.4.1) de type PROTOCOL_ERROR.

8.2.1. Requêtes push

   Server push est sémantiquement équivalent à un serveur répondant à un
   demande; cependant, dans ce cas, cette demande est également envoyée par le
   serveur, en tant que trame PUSH_PROMISE.

   La trame PUSH_PROMISE comprend un bloc d'en-tête qui contient un
   ensemble complet de champs d'en-tête de demande auxquels le serveur attribue
   la demande. Il n'est pas possible de pousser une réponse à une demande qui
   comprend un corps de requête.

   Les réponses poussées sont toujours associées à une demande explicite de
   le client. Les trames PUSH_PROMISE envoyées par le serveur sont envoyées le
   le flux de cette demande explicite. Le cadre PUSH_PROMISE comprend également
   un identifiant de flux promis, choisi parmi les identifiants de flux
   disponible pour le serveur (voir Section 5.1.1).

   Les champs d'en-tête dans PUSH_PROMISE et toute CONTINUATION ultérieure
   les trames DOIVENT être un ensemble valide et complet de champs d'en-tête de demande
   (Section 8.1.2.3). Le serveur DOIT inclure une méthode dans le ": method"
   champ pseudo-en-tête sûr et pouvant être mis en cache. Si un client reçoit
   une PUSH_PROMISE qui n'inclut pas un ensemble complet et valide de
   champs d'en-tête ou le champ pseudo-en-tête ": method" identifie un
   méthode qui n'est pas sûre, elle DOIT répondre avec une erreur de flux
   (Section 5.4.2) de type PROTOCOL_ERROR.

   Le serveur DEVRAIT envoyer des trames PUSH_PROMISE (paragraphe 6.6) avant
   envoyer toutes les trames faisant référence aux réponses promises. Ce
   évite une course où les clients émettent des demandes avant de recevoir
   Cadres PUSH_PROMISE.

   Par exemple, si le serveur reçoit une demande de document
   contenant des liens intégrés vers plusieurs fichiers image et le serveur
   choisit de pousser ces images supplémentaires vers le client, en envoyant
   Trames PUSH_PROMISE avant les trames DATA qui contiennent l'image
   liens garantit que le client est en mesure de voir qu'une ressource sera
   poussé avant de découvrir les liens intégrés. De même, si le serveur
   pousse les réponses référencées par le bloc d'en-tête (par exemple, dans
   Lier les champs d'en-tête), envoyer un PUSH_PROMISE avant d'envoyer l'en-tête
   block garantit que les clients ne demandent pas ces ressources.

   Les trames PUSH_PROMISE NE DOIVENT PAS être envoyées par le client.

   Les trames PUSH_PROMISE peuvent être envoyées par le serveur en réponse à tout
   le flux initié par le client, mais le flux DOIT être dans l'un ou l'autre
   ou état "semi-fermé (distant)" par rapport au serveur.
   Les trames PUSH_PROMISE sont intercalées avec les trames qui composent un
   réponse, bien qu'ils ne puissent pas être entrecoupés de HEADERS et
   Trames de CONTINUATION qui comprennent un seul bloc d'en-tête.

   L'envoi d'une trame PUSH_PROMISE crée un nouveau flux et place le flux
   dans l'état "réservé (local)" pour le serveur et le "réservé
   (distant) "état du client.

8.2.2. Réponses push

   Après l'envoi de la trame PUSH_PROMISE, le serveur peut commencer à livrer
   la réponse poussée comme réponse (Section 8.1.2.4) sur un serveur-
   flux lancé qui utilise l'identificateur de flux promis. le
   le serveur utilise ce flux pour transmettre une réponse HTTP, en utilisant le même
   séquence de trames telle que définie à la section 8.1. Ce flux devient
   "semi-fermé" au client (section 5.1) après les EN-TÊTES initiaux
   la trame est envoyée.

   Une fois qu'un client reçoit une trame PUSH_PROMISE et choisit d'accepter le
   réponse poussée, le client NE DEVRAIT PAS émettre de demandes pour le
   réponse promise jusqu'à la fermeture du flux promis.

   Si le client détermine, pour une raison quelconque, qu'il ne souhaite pas
   recevoir la réponse poussée du serveur ou si le serveur prend
   trop longtemps pour commencer à envoyer la réponse promise, le client peut envoyer
   une trame RST_STREAM, en utilisant le code CANCEL ou REFUSED_STREAM
   et référencer l'identifiant du flux poussé.

   Un client peut utiliser le paramètre SETTINGS_MAX_CONCURRENT_STREAMS pour limiter
   le nombre de réponses qui peuvent être poussées simultanément par un serveur.
   La publicité d'une valeur SETTINGS_MAX_CONCURRENT_STREAMS de zéro désactive
   push du serveur en empêchant le serveur de créer les
   ruisseaux. Cela n'empêche pas un serveur d'envoyer PUSH_PROMISE
   cadres; les clients doivent réinitialiser tous les flux promis qui ne sont pas
   voulait.

   Les clients recevant une réponse poussée DOIVENT valider que soit le
   le serveur fait autorité (voir Section 10.1) ou le proxy qui a fourni
   la réponse poussée est configurée pour la demande correspondante. Pour
   exemple, un serveur qui offre un certificat pour uniquement le
   "example.com" DNS-ID ou Common Name n'est pas autorisé à envoyer un
   réponse pour "https://www.example.org/doc".

   La réponse pour un flux PUSH_PROMISE commence par une trame HEADERS,
   qui met immédiatement le flux dans le "semi-fermé (distant)"
   état pour le serveur et état "semi-fermé (local)" pour le client,
   et se termine par un cadre portant END_STREAM, qui place le flux dans
   l'état "fermé".

      Remarque: le client n'envoie jamais de trame avec l'indicateur END_STREAM pour
      un serveur push.

8.3. La méthode CONNECT

   Dans HTTP / 1.x, la pseudo-méthode CONNECT ([RFC7231], section 4.3.6) est
   utilisé pour convertir une connexion HTTP en un tunnel vers un hôte distant.
   CONNECT est principalement utilisé avec les proxys HTTP pour établir un TLS
   session avec un serveur d'origine dans le but d'interagir avec
   Ressources "https".

   Dans HTTP / 2, la méthode CONNECT est utilisée pour établir un tunnel sur un
   flux HTTP / 2 unique vers un hôte distant à des fins similaires. Le HTTP
   le mappage de champ d'en-tête fonctionne comme défini dans la section 8.1.2.3 ("Request
   Champs de pseudo-en-tête "), avec quelques différences. Plus précisément:

   o Le champ pseudo-en-tête ": method" est défini sur "CONNECT".

   o Les champs de pseudo-en-tête ": scheme" et ": path" DOIVENT être omis.

   o Le champ pseudo-en-tête ": autorité" contient l'hôte et le port à
      se connecter à (équivalent à la forme d'autorité de la cible de demande
      des demandes CONNECT (voir [RFC7230], section 5.3)).

   Une demande CONNECT non conforme à ces restrictions est
   malformé (section 8.1.2.6).

   Un proxy prenant en charge CONNECT établit une connexion TCP [TCP] vers
   le serveur identifié dans le champ pseudo-en-tête ": autorité". Une fois que
   cette connexion est établie avec succès, le proxy envoie un
   Cadre HEADERS contenant un code d'état de la série 2xx pour le client, comme
   défini dans la [RFC7231], section 4.3.6.

   Après la trame HEADERS initiale envoyée par chaque pair, toutes les
   Les trames DATA correspondent aux données envoyées sur la connexion TCP. le
   la charge utile de toute trame DATA envoyée par le client est transmise par le
   proxy vers le serveur TCP; les données reçues du serveur TCP sont
   assemblés en trames DATA par le proxy. Types de trame autres que DATA
   ou des cadres de gestion de flux (RST_STREAM, WINDOW_UPDATE et PRIORITY)
   NE DOIT PAS être envoyé sur un flux connecté et DOIT être traité comme un
   erreur de flux (section 5.4.2) si elle est reçue.

   La connexion TCP peut être fermée par l'un ou l'autre des pairs. Le drapeau END_STREAM
   sur une trame DATA est considérée comme équivalente au bit TCP FIN. UNE
   le client doit envoyer une trame DATA avec l'indicateur END_STREAM défini
   après avoir reçu une trame portant le drapeau END_STREAM. Un proxy qui
   reçoit une trame DATA avec l'indicateur END_STREAM défini envoie le
   données avec le bit FIN défini sur le dernier segment TCP. Un proxy qui
   reçoit un segment TCP avec le bit FIN défini envoie une trame DATA avec
   le jeu d'indicateurs END_STREAM. Notez que le segment TCP final ou DATA
   le cadre peut être vide.

   Une erreur de connexion TCP est signalée avec RST_STREAM. Un proxy traite
   toute erreur dans la connexion TCP, qui inclut la réception d'un TCP
   segment avec le bit RST défini, comme une erreur de flux (section 5.4.2) de
   tapez CONNECT_ERROR. En conséquence, un proxy DOIT envoyer un segment TCP
   avec le bit RST positionné s'il détecte une erreur avec le flux ou le
   Connexion HTTP / 2.

9. Exigences / considérations HTTP supplémentaires

   Cette section décrit les attributs du protocole HTTP qui améliorent
   interopérabilité, réduire l'exposition aux vulnérabilités de sécurité connues,
   ou réduire le potentiel de variation de la mise en œuvre.

9.1. Gestion des connexions

   Les connexions HTTP / 2 sont persistantes. Pour de meilleures performances, il est
   s'attend à ce que les clients ne ferment pas les connexions avant
   déterminé qu'aucune autre communication avec un serveur n'est nécessaire
   (par exemple, lorsqu'un utilisateur quitte une page Web particulière)
   ou jusqu'à ce que le serveur ferme la connexion.

   Les clients NE DEVRAIENT PAS ouvrir plus d'une connexion HTTP / 2 à un
   paire hôte et port, où l'hôte est dérivé d'un URI, un
   service alternatif [ALT-SVC], ou un proxy configuré.

   Un client peut créer des connexions supplémentaires en remplacement, soit pour
   remplacer les connexions qui sont sur le point d'épuiser le flux disponible
   espace identifiant (Section 5.1.1), pour actualiser le matériel de saisie pour
   une connexion TLS, ou pour remplacer les connexions qui ont rencontré
   erreurs (section 5.4.1).

   Un client PEUT ouvrir plusieurs connexions à la même adresse IP et TCP
   port utilisant différentes valeurs d'indication de nom de serveur [TLS-EXT] ou
   fournir différents certificats clients TLS mais DEVRAIT éviter de créer
   plusieurs connexions avec la même configuration.

   Les serveurs sont encouragés à maintenir des connexions ouvertes aussi longtemps que
   possible mais sont autorisés à mettre fin aux connexions inactives si
   nécessaire. Lorsque l'un des points de terminaison choisit de fermer la couche de transport
   Connexion TCP, le point d'extrémité de terminaison DEVRAIT d'abord envoyer un GOAWAY
   (Section 6.8) afin que les deux points finaux puissent déterminer de manière fiable
   si les trames précédemment envoyées ont été traitées et correctement
   terminer ou terminer toutes les tâches restantes nécessaires.

9.1.1. Réutilisation de la connexion

   Les connexions établies avec un serveur d'origine, soit directement, soit
   via un tunnel créé à l'aide de la méthode CONNECT (section 8.3), PEUT
   être réutilisé pour les demandes avec plusieurs droits URI différents
   Composants. Une connexion peut être réutilisée tant que le serveur d'origine
   fait autorité (section 10.1). Pour les connexions TCP sans TLS,
   cela dépend de la résolution de l'hôte vers la même adresse IP.

   Pour les ressources "https", la réutilisation des connexions dépend en outre de
   avoir un certificat valide pour l'hôte dans l'URI. le
   certificat présenté par le serveur DOIT satisfaire à toutes les vérifications que le
   le client s'exécuterait lors de la formation d'une nouvelle connexion TLS pour l'hôte
   dans l'URI.

   Un serveur d'origine peut proposer un certificat avec plusieurs
   Attributs ou noms "subjectAltName" avec des caractères génériques, dont l'un est
   valide pour l'autorité dans l'URI. Par exemple, un certificat avec
   un "subjectAltName" de "* .example.com" peut autoriser l'utilisation du
   même connexion pour les requêtes aux URI commençant par
   "https://a.example.com/" et "https://b.example.com/".

   Dans certains déploiements, la réutilisation d'une connexion pour plusieurs origines peut
   entraîner des demandes dirigées vers le mauvais serveur d'origine. Pour
   Par exemple, la terminaison TLS peut être effectuée par un boîtier de médiation qui utilise
   l'extension [TLS-EXT] d'indication de nom de serveur TLS (SNI) pour sélectionner un
   serveur d'origine. Cela signifie qu'il est possible pour les clients d'envoyer
   des informations confidentielles aux serveurs qui pourraient ne pas être
   cible de la demande, même si le serveur est autrement
   faisant autorité.

   Un serveur qui ne souhaite pas que les clients réutilisent les connexions peut indiquer
   qu'il ne fait pas autorité pour une demande en envoyant un 421
   (Demande mal dirigée) code d'état en réponse à la demande (voir
   Section 9.1.2).

   Un client configuré pour utiliser un proxy via HTTP / 2 dirige
   demandes à ce proxy via une seule connexion. C'est tout
   les demandes envoyées via un proxy réutilisent la connexion au proxy.

9.1.2. Le code d'état 421 (demande mal dirigée)

   Le code d'état 421 (demande mal dirigée) indique que la demande
   a été dirigé vers un serveur qui n'est pas en mesure de produire une réponse.
   Cela peut être envoyé par un serveur qui n'est pas configuré pour produire
   réponses pour la combinaison de régime et d'autorité qui sont
   inclus dans l'URI de la demande.

   Clients recevant une réponse 421 (demande mal dirigée) d'un serveur
   PEUT réessayer la demande - si la méthode de demande est idempotente ou
   pas - sur une connexion différente. Ceci est possible si une connexion
   est réutilisé (section 9.1.1) ou si un service alternatif est sélectionné
   [ALT-SVC].

   Ce code d'état NE DOIT PAS être généré par des mandataires.

   Une réponse 421 peut être mise en cache par défaut, c'est-à-dire sauf indication contraire
   indiqué par la définition de méthode ou les contrôles de cache explicites (voir
   Section 4.2.2 de la [RFC7234]).

9.2. Utilisation des fonctionnalités TLS

   Les implémentations de HTTP / 2 DOIVENT utiliser TLS version 1.2 [TLS12] ou supérieure
   pour HTTP / 2 sur TLS. Conseils généraux sur l’utilisation de TLS dans [TLSBCP]
   DEVRAIT être suivi, avec quelques restrictions supplémentaires
   spécifique à HTTP / 2.

   L'implémentation TLS DOIT prendre en charge l'indication de nom de serveur (SNI)
   Extension [TLS-EXT] vers TLS. Les clients HTTP / 2 DOIVENT indiquer la cible
   nom de domaine lors de la négociation de TLS.

   Les déploiements de HTTP / 2 qui négocient TLS 1.3 ou supérieur ne nécessitent que
   prendre en charge et utiliser l'extension SNI; les déploiements de TLS 1.2 sont soumis
   aux exigences des sections suivantes. Les implémentations sont
   encouragés à fournir des valeurs par défaut conformes, mais il est reconnu que
   les déploiements sont ultimement responsables de la conformité.

9.2.1. Caractéristiques TLS 1.2

   Cette section décrit les restrictions sur l'ensemble de fonctionnalités TLS 1.2 qui
   peut être utilisé avec HTTP / 2. En raison des limitations de déploiement, il se peut que
   être possible d'échouer la négociation TLS lorsque ces restrictions ne sont pas
   rencontré. Un point d'extrémité PEUT mettre fin immédiatement à une connexion HTTP / 2 qui
   ne répond pas à ces exigences TLS avec une erreur de connexion
   (Section 5.4.1) de type INADEQUATE_SECURITY.

   Un déploiement de HTTP / 2 sur TLS 1.2 DOIT désactiver la compression. TLS
   la compression peut conduire à l'exposition d'informations qui ne
   autrement être révélé [RFC3749]. La compression générique n'est pas nécessaire
   puisque HTTP / 2 fournit des fonctionnalités de compression plus conscientes de
   contexte et donc susceptible d'être plus approprié pour une utilisation
   performances, sécurité ou autres raisons.

   Un déploiement de HTTP / 2 sur TLS 1.2 DOIT désactiver la renégociation. Une
   le point d'extrémité DOIT traiter une renégociation TLS comme une erreur de connexion
   (Paragraphe 5.4.1) de type PROTOCOL_ERROR. Notez que la désactivation
   la renégociation peut rendre les connexions de longue durée inutilisables
   en raison des limites du nombre de messages de la suite de chiffrement sous-jacente
   peut chiffrer.

   Un point final PEUT utiliser la renégociation pour assurer la confidentialité
   protection des informations d'identification du client offerte dans la poignée de main, mais
   la renégociation DOIT avoir lieu avant l'envoi de la préface de connexion. UNE
   le serveur DEVRAIT demander un certificat client s'il voit une renégociation
   demande immédiatement après l'établissement d'une connexion.

   Cela empêche efficacement l'utilisation de la renégociation en réponse à une
   demande d'une ressource protégée spécifique. Une future spécification
   pourrait fournir un moyen de prendre en charge ce cas d'utilisation. Alternativement, un
   le serveur peut utiliser une erreur (section 5.4) de type HTTP_1_1_REQUIRED pour
   demander au client d'utiliser un protocole prenant en charge la renégociation.

   Les implémentations DOIVENT prendre en charge des tailles d'échange de clés éphémères d'au moins
   2048 bits pour les suites de chiffrement utilisant un champ fini éphémère Diffie-
   Hellman (DHE) [TLS12] et 224 bits pour les suites de chiffrement utilisant
   courbe elliptique éphémère Diffie-Hellman (ECDHE) [RFC4492]. Clients
   DOIT accepter des tailles DHE allant jusqu'à 4096 bits. Les critères d'évaluation PEUVENT traiter
   négociation de tailles de clé inférieures aux limites inférieures
   erreur de connexion (section 5.4.1) de type INADEQUATE_SECURITY.

9.2.2. Suites de chiffrement TLS 1.2

   Un déploiement de HTTP / 2 sur TLS 1.2 NE DEVRAIT PAS utiliser l'un des chiffrements
   suites répertoriées dans la liste noire des suites de chiffrement (Annexe A).

   Les points d'extrémité PEUVENT choisir de générer une erreur de connexion (section 5.4.1)
   de type INADEQUATE_SECURITY si l'une des suites de chiffrement du
   la liste noire est négociée. Un déploiement qui choisit d'utiliser un noir
   la suite de chiffrement répertoriée risque de déclencher une erreur de connexion à moins que
   ensemble de pairs potentiels est connu pour accepter cette suite de chiffrement.

   Les implémentations NE DOIVENT PAS générer cette erreur en réaction au
   négociation d'une suite de chiffrement qui ne figure pas sur la liste noire.
   Par conséquent, lorsque les clients proposent une suite de chiffrement qui n'est pas sur le
   liste noire, ils doivent être prêts à utiliser cette suite de chiffrement avec
   HTTP / 2.

   La liste noire comprend la suite de chiffrement créée par TLS 1.2
   obligatoire, ce qui signifie que les déploiements TLS 1.2 peuvent avoir des
   ensembles croisés de suites de chiffrement autorisées. Pour éviter ce problème
   provoquant des échecs de négociation TLS, des déploiements de HTTP / 2 utilisant TLS
   1.2 DOIT prendre en charge TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE]
   avec la courbe elliptique P-256 [FIPS186].

   Notez que les clients peuvent annoncer la prise en charge des suites de chiffrement
   sur la liste noire afin de permettre la connexion à des serveurs qui
   ne prend pas en charge HTTP / 2. Cela permet aux serveurs de sélectionner HTTP / 1.1 avec un
   suite de chiffrement figurant sur la liste noire HTTP / 2. Cependant, cela peut
   entraîner la négociation de HTTP / 2 avec une suite de chiffrement figurant sur la liste noire si
   le protocole d'application et la suite de chiffrement sont sélectionnés indépendamment.

10. Considérations relatives à la sécurité

10.1. Autorité du serveur

   HTTP / 2 s'appuie sur la définition d'autorité HTTP / 1.1 pour déterminer
   si un serveur fait autorité pour fournir une réponse donnée (voir
   [RFC7230], section 9.1). Cela repose sur la résolution de noms locaux pour
   le schéma d'URI "http" et l'identité du serveur authentifié pour le
   Schéma "https" (voir [RFC2818], section 3).

10.2. Attaques inter-protocoles

   Dans une attaque inter-protocole, un attaquant amène un client à lancer un
   transaction dans un protocole vers un serveur qui comprend un
   protocole différent. Un attaquant pourrait être en mesure de provoquer
   transaction pour apparaître comme une transaction valide dans le deuxième protocole.
   En combinaison avec les capacités du contexte Web, cela peut être
   utilisé pour interagir avec des serveurs mal protégés dans les réseaux privés.

   La conclusion d'une prise de contact TLS avec un identifiant ALPN pour HTTP / 2 peut être
   considéré comme une protection suffisante contre les attaques inter-protocoles.
   ALPN fournit une indication positive qu'un serveur est prêt à
   continuez avec HTTP / 2, qui empêche les attaques sur d'autres
   protocoles.

   Le chiffrement dans TLS rend difficile pour les attaquants de contrôler le
   données qui pourraient être utilisées dans une attaque inter-protocole sur un texte clair
   protocole.

   La version en texte clair de HTTP / 2 offre une protection minimale contre les
   attaques de protocole. La préface de connexion (section 3.5) contient un
   chaîne conçue pour confondre les serveurs HTTP / 1.1, mais pas de
   une protection est offerte pour d'autres protocoles. Un serveur qui accepte
   pour ignorer des parties d'une requête HTTP / 1.1 contenant un en-tête Upgrade
   le champ en plus de la préface de connexion client pourrait être exposé
   à une attaque inter-protocole.

10.3. Attaques d'encapsulation intermédiaire

   Le codage du champ d'en-tête HTTP / 2 permet l'expression de noms qui
   ne sont pas des noms de champ valides dans la syntaxe des messages Internet utilisée par
   HTTP / 1.1. Demandes ou réponses contenant un champ d'en-tête non valide
   les noms DOIVENT être traités comme mal formés (Section 8.1.2.6). Une
   L'intermédiaire ne peut donc pas traduire une requête ou une réponse HTTP / 2
   contenant un nom de champ non valide dans un message HTTP / 1.1.

   De même, HTTP / 2 autorise les valeurs de champ d'en-tête qui ne sont pas valides.
   Alors que la plupart des valeurs qui peuvent être encodées ne modifieront pas l'en-tête
   analyse de champ, retour chariot (CR, ASCII 0xd), saut de ligne (LF, ASCII
   0xa), et le caractère zéro (NUL, ASCII 0x0) pourrait être exploité par
   un attaquant s'ils sont traduits textuellement. Toute demande ou réponse
   qui contient un caractère non autorisé dans une valeur de champ d'en-tête DOIT
   être traité comme malformé (section 8.1.2.6). Les caractères valides sont
   défini par la règle ABNF "field-content" dans la section 3.2 de la [RFC7230].

10.4. Mise en cache des réponses poussées

   Les réponses poussées n'ont pas de demande explicite du client; les
   la demande est fournie par le serveur dans la trame PUSH_PROMISE.

   La mise en cache des réponses qui sont poussées est possible en fonction des instructions
   fourni par le serveur d'origine dans le champ d'en-tête Cache-Control.
   Cependant, cela peut entraîner des problèmes si un seul serveur héberge plus d'un
   locataire. Par exemple, un serveur peut offrir à plusieurs utilisateurs chacun un
   petite partie de son espace URI.

   Lorsque plusieurs locataires partagent de l'espace sur le même serveur, ce serveur
   DOIT s'assurer que les locataires ne sont pas en mesure de pousser les représentations de
   ressources sur lesquelles ils n’ont pas d’autorité. Défaut de faire respecter
   cela permettrait à un locataire de fournir une représentation qui serait
   servi hors du cache, remplaçant la représentation réelle que le
   le locataire faisant autorité fournit.

   Réponses poussées pour lesquelles un serveur d'origine ne fait pas autorité (voir
   Section 10.1) NE DOIT PAS être utilisé ou mis en cache.

10.5. Considérations relatives au déni de service

   Une connexion HTTP / 2 peut exiger un plus grand engagement de ressources pour
   fonctionner qu'une connexion HTTP / 1.1. L'utilisation de la compression d'en-tête
   et le contrôle de flux dépendent d'un engagement de ressources pour stocker un
   une plus grande quantité d’État. Les paramètres de ces fonctionnalités garantissent que
   les engagements de mémoire pour ces fonctionnalités sont strictement limités.

   Le nombre de trames PUSH_PROMISE n'est pas limité dans le même
   mode. Un client qui accepte le serveur push DEVRAIT limiter le nombre
   de flux, il permet d'être dans l'état "réservé (distant)". Une
   un nombre excessif de flux push du serveur peut être traité comme un flux
   erreur (section 5.4.2) de type ENHANCE_YOUR_CALM.

   La capacité de traitement ne peut pas être gardée aussi efficacement que l'état
   capacité.

   La trame SETTINGS peut être utilisée de manière abusive pour amener un pair à dépenser des
   temps de traitement. Cela peut être fait en changeant inutilement les paramètres
   paramètres, définir plusieurs paramètres non définis ou modifier
   même réglage plusieurs fois dans le même cadre. WINDOW_UPDATE ou
   Les cadres PRIORITY peuvent être abusés pour entraîner un gaspillage inutile de
   Ressources.

   Un grand nombre de cadres petits ou vides peut être abusé pour provoquer un pair
   pour passer du temps à traiter les en-têtes de trame. Notez cependant que certains
   les utilisations sont tout à fait légitimes, comme l'envoi d'une DONNÉE vide ou
   Cadre de CONTINUATION à la fin d'un flux.

   La compression d'en-tête offre également des opportunités de traitement des déchets
   Ressources; voir la section 7 de [COMPRESSION] pour plus de détails sur
   abus potentiels.

   Les limites des paramètres SETTINGS ne peuvent pas être réduites instantanément,
   ce qui laisse un point de terminaison exposé au comportement d'un pair qui pourrait
   dépasser les nouvelles limites. En particulier, immédiatement après l'établissement
   une connexion, les limites fixées par un serveur ne sont pas connues des clients et
   pourrait être dépassé sans être une violation évidente du protocole.

   Toutes ces fonctionnalités - c'est-à-dire, les changements de PARAMÈTRES, les petits cadres, l'en-tête
   compression - ont des utilisations légitimes. Ces fonctionnalités deviennent un fardeau
   seulement lorsqu'ils sont utilisés inutilement ou à outrance.

   Un point de terminaison qui ne surveille pas ce comportement s'expose à un
   risque d'attaque par déni de service. Les implémentations DEVRAIENT suivre les
   l'utilisation de ces fonctionnalités et fixer des limites à leur utilisation. Un point final PEUT
   traiter l'activité suspecte comme une erreur de connexion
   (Paragraphe 5.4.1) de type ENHANCE_YOUR_CALM.

10.5.1. Limites de la taille du bloc d'en-tête

   Un gros bloc d'en-tête (section 4.3) peut amener une implémentation à
   commettre une grande quantité d'état. Champs d'en-tête critiques pour
   le routage peut apparaître vers la fin d'un bloc d'en-tête, ce qui empêche
   diffusion en continu des champs d'en-tête vers leur destination finale. Ce
   la commande et d'autres raisons, telles que la garantie de l'exactitude du cache, signifient
   qu'un point de terminaison pourrait avoir besoin de mettre en mémoire tampon tout le bloc d'en-tête. Puisque
   il n'y a pas de limite stricte à la taille d'un bloc d'en-tête, certains points de terminaison
   pourrait être forcé de consacrer une grande quantité de mémoire disponible pour
   champs d'en-tête.

   Un point de terminaison peut utiliser SETTINGS_MAX_HEADER_LIST_SIZE pour informer ses pairs
   des limites qui pourraient s'appliquer à la taille des blocs d'en-tête. Ce
   le réglage est uniquement consultatif, donc les points d'extrémité PEUVENT choisir d'envoyer l'en-tête
   blocs qui dépassent cette limite et risquent d'avoir la demande ou la réponse
   être traité comme mal formé. Ce paramètre est spécifique à un
   connexion, donc toute demande ou réponse peut rencontrer un saut avec un
   limite inférieure inconnue. Un intermédiaire peut tenter d'éviter cela
   problème en transmettant des valeurs présentées par différents pairs, mais
   ne sont pas obligés de le faire.

   Un serveur qui reçoit un bloc d'en-tête plus grand qu'il ne le souhaite
   handle peut envoyer un état HTTP 431 (Request Header Fields Too Large)
   code [RFC6585]. Un client peut ignorer les réponses qu'il ne peut pas
   processus. Le bloc d'en-tête DOIT être traité pour assurer une cohérence
   état de la connexion, sauf si la connexion est fermée.

10.5.2. Problèmes de CONNECT

   La méthode CONNECT peut être utilisée pour créer une charge disproportionnée sur un
   proxy, car la création de flux est relativement peu coûteuse en comparaison
   à la création et à la maintenance d'une connexion TCP. Un proxy pourrait
   conserver également certaines ressources pour une connexion TCP au-delà de la fermeture
   du flux qui porte la demande CONNECT, puisque le flux sortant
   La connexion TCP reste dans l'état TIME_WAIT. Par conséquent, un proxy
   ne peut pas compter uniquement sur SETTINGS_MAX_CONCURRENT_STREAMS pour limiter
   ressources consommées par les demandes CONNECT.

10.6. Utilisation de la compression

   La compression peut permettre à un attaquant de récupérer des données secrètes lorsqu'il
   compressé dans le même contexte que les données sous le contrôle de l'attaquant.
   HTTP / 2 permet la compression des champs d'en-tête (section 4.3); les
   les préoccupations suivantes s'appliquent également à l'utilisation de contenu compressé HTTP -
   codages ([RFC7231], section 3.1.2.1).

   Il existe des attaques démontrables contre la compression qui exploitent le
   caractéristiques du Web (par exemple, [BREACH]). L'attaquant induit
   plusieurs requêtes contenant un texte brut variable, en respectant la longueur
   du texte chiffré résultant dans chacun, ce qui révèle une longueur plus courte
   quand une supposition sur le secret est correcte.

   Les implémentations communiquant sur un canal sécurisé NE DOIVENT PAS compresser
   contenu qui comprend à la fois des données confidentielles et contrôlées par les attaquants
   sauf si des dictionnaires de compression séparés sont utilisés pour chaque source de
   Les données. La compression NE DOIT PAS être utilisée si la source des données ne peut
   déterminé de manière fiable. Compression de flux générique, comme celle-là
   fourni par TLS, NE DOIT PAS être utilisé avec HTTP / 2 (voir la section 9.2).

   D'autres considérations concernant la compression des champs d'en-tête sont
   décrit dans [COMPRESSION].

10.7. Utilisation du rembourrage

   Le remplissage dans HTTP / 2 n'est pas destiné à remplacer les
   remplissage de fonction, tel que celui fourni par TLS [TLS12]. Redondant
   le rembourrage pourrait même être contre-productif. Une application correcte peut
   dépendent de la connaissance spécifique des données qui sont complétées.

   Pour atténuer les attaques qui reposent sur la compression, la désactivation ou la limitation
   la compression peut être préférable au rembourrage comme contre-mesure.

   Le remplissage peut être utilisé pour masquer la taille exacte du contenu du cadre et est
   fourni pour atténuer des attaques spécifiques dans HTTP, par exemple,
   les attaques où le contenu compressé comprend à la fois
   des données en clair et secrètes (par exemple, [BREACH]).

   L'utilisation d'un rembourrage peut entraîner moins de protection qu'il n'y paraît
   immédiatement évident. Au mieux, le rembourrage ne fait que rendre les choses plus difficiles
   pour qu'un attaquant puisse déduire des informations de longueur en augmentant le nombre
   d'images qu'un attaquant doit observer. Mal implémenté
   les schémas de rembourrage peuvent être facilement vaincus. En particulier, randomisé
   le rembourrage avec une distribution prévisible fournit très peu
   protection; de même, le remplissage des charges utiles à une taille fixe expose
   informations lorsque les tailles de charge utile franchissent la limite de taille fixe, qui
   pourrait être possible si un attaquant peut contrôler le texte en clair.

   Les intermédiaires DEVRAIENT conserver le rembourrage pour les trames DATA mais PEUVENT abandonner
   rembourrage pour les cadres HEADERS et PUSH_PROMISE. Une raison valable pour un
   L'intermédiaire pour changer la quantité de rembourrage des cadres est d'améliorer
   les protections fournies par le rembourrage.

10.8. Considérations relatives à la confidentialité

   Plusieurs caractéristiques de HTTP / 2 offrent une opportunité à un observateur
   pour corréler les actions d'un seul client ou serveur au fil du temps. Celles-ci
   inclure la valeur des paramètres, la manière dont le contrôle de flux
   les fenêtres sont gérées, la façon dont les priorités sont attribuées aux flux, les
   le moment des réactions au stimulus et la gestion de toutes les caractéristiques
   qui sont contrôlés par les paramètres.

   Dans la mesure où ceux-ci créent des différences de comportement observables, ils pourraient
   être utilisé comme base pour la prise d'empreintes digitales d'un client spécifique, tel que défini
   dans la section 1.8 de [HTML5].

   La préférence de HTTP / 2 pour l'utilisation d'une seule connexion TCP permet
   corrélation de l'activité d'un utilisateur sur un site. Réutilisation des connexions pour
   différentes origines permettent le suivi de ces origines.

   Parce que les trames PING et SETTINGS sollicitent des réponses immédiates,
   ils peuvent être utilisés par un point de terminaison pour mesurer la latence par rapport à leur homologue.
   Cela peut avoir des implications sur la confidentialité dans certains scénarios.

11. Considérations IANA

   Une chaîne pour identifier HTTP / 2 est entrée dans le champ "Application-
   Registre des ID de protocole de négociation de protocole de couche (ALPN) établi
   dans [TLS-ALPN].

   Ce document établit un registre pour les types de cadres, les paramètres et
   codes d'erreur. Ces nouveaux registres apparaissent dans le nouveau "Hypertext
   Paramètres du protocole de transfert version 2 (HTTP / 2) ».

   Ce document enregistre le champ d'en-tête HTTP2-Settings à utiliser dans
   HTTP; il enregistre également le code d'état 421 (demande mal dirigée).

   Ce document enregistre la méthode "PRI" à utiliser dans HTTP pour éviter
   collisions avec la préface de connexion (section 3.5).

11.1. Enregistrement des chaînes d'identification HTTP / 2

   Ce document crée deux enregistrements pour l'identification des
   HTTP / 2 (voir Section 3.3) dans le "Protocole de couche d'application
   Registre des ID de protocole de négociation (ALPN) établi dans [TLS-ALPN].

   La chaîne "h2" identifie HTTP / 2 lorsqu'elle est utilisée sur TLS:

   Protocole: HTTP / 2 sur TLS

   Séquence d'identification: 0x68 0x32 ("h2")

   Spécification: ce document

   La chaîne "h2c" identifie HTTP / 2 lorsqu'elle est utilisée sur TCP en clair:

   Protocole: HTTP / 2 sur TCP

   Séquence d'identification: 0x68 0x32 0x63 ("h2c")

   Spécification: ce document

11.2. Registre de type de trame

   Ce document établit un registre pour les codes de type de trame HTTP / 2.
   Le registre "HTTP / 2 Frame Type" gère un espace 8 bits. Le "HTTP / 2
   Le registre de type de trame "fonctionne sous l'un ou l'autre de" IETF Review "ou
   Politiques "IESG Approval" [RFC5226] pour les valeurs comprises entre 0x00 et 0xef,
   avec des valeurs entre 0xf0 et 0xff réservées à l'expérimentation
   Utilisation.

   Les nouvelles entrées dans ce registre nécessitent les informations suivantes:

   Type de cadre: un nom ou une étiquette pour le type de cadre.

   Code: Le code 8 bits attribué au type de trame.

   Spécification: une référence à une spécification qui comprend un
      description de la disposition du cadre, de sa sémantique et des indicateurs que le
      le type de cadre utilise, y compris toutes les parties du cadre qui sont
      conditionnellement présent en fonction de la valeur des drapeaux.

   Les entrées du tableau suivant sont enregistrées par ce document.

   + --------------- + ------ + -------------- +
   | Type de cadre | Code | Section |
   + --------------- + ------ + -------------- +
   | DATA | 0x0 | Section 6.1 |
   | HEADERS | 0x1 | Section 6.2 |
   | PRIORITÉ | 0x2 | Section 6.3 |
   | RST_STREAM | 0x3 | Section 6.4 |
   | RÉGLAGES | 0x4 | Section 6.5 |
   | PUSH_PROMISE | 0x5 | Section 6.6 |
   | PING | 0x6 | Section 6.7 |
   | GOAWAY | 0x7 | Section 6.8 |
   | WINDOW_UPDATE | 0x8 | Section 6.9 |
   | CONTINUATION | 0x9 | Section 6.10 |
   + --------------- + ------ + -------------- +

11.3. Registre des paramètres

   Ce document établit un registre pour les paramètres HTTP / 2. le
   Le registre "Paramètres HTTP / 2" gère un espace de 16 bits. Le "HTTP / 2
   Le registre "Paramètres" fonctionne selon la politique "Examen par des experts"
   [RFC5226] pour les valeurs comprises entre 0x0000 et 0xefff, avec des valeurs
   entre et 0xf000 et 0xffff étant réservés pour une utilisation expérimentale.

   Les nouvelles inscriptions sont invitées à fournir les informations suivantes:

   Nom: nom symbolique du paramètre. La spécification d'un nom de paramètre est
      optionnel.

   Code: Le code 16 bits attribué au paramètre.

   Valeur initiale: valeur initiale du paramètre.

   Spécification: une référence facultative à une spécification qui
      décrit l'utilisation du paramètre.

   Les entrées du tableau suivant sont enregistrées par ce document.

   + ------------------------ + ------ + --------------- + - -------------- +
   | Nom | Code | Valeur initiale | Spécification |
   + ------------------------ + ------ + --------------- + - -------------- +
   | HEADER_TABLE_SIZE | 0x1 | 4096 | Section 6.5.2 |
   | ENABLE_PUSH | 0x2 | 1 | Section 6.5.2 |
   | MAX_CONCURRENT_STREAMS | 0x3 | (infini) | Section 6.5.2 |
   | INITIAL_WINDOW_SIZE | 0x4 | 65535 | Section 6.5.2 |
   | MAX_FRAME_SIZE | 0x5 | 16384 | Section 6.5.2 |
   | MAX_HEADER_LIST_SIZE | 0x6 | (infini) | Section 6.5.2 |
   + ------------------------ + ------ + --------------- + - -------------- +

11.4. Registre des codes d'erreur

   Ce document établit un registre pour les codes d'erreur HTTP / 2. le
   Le registre "HTTP / 2 Error Code" gère un espace 32 bits. Le "HTTP / 2
   Le registre des codes d'erreur "fonctionne selon la politique" Examen par des experts "
   [RFC5226].

   Les enregistrements pour les codes d'erreur doivent inclure une description
   du code d'erreur. Un examinateur expert est invité à examiner les nouveaux
   enregistrements pour une éventuelle duplication avec les codes d'erreur existants.
   L'utilisation des enregistrements existants doit être encouragée, mais pas obligatoire.

   Les nouvelles inscriptions sont invitées à fournir les informations suivantes:

   Nom: nom du code d'erreur. La spécification d'un nom de code d'erreur est
      optionnel.

   Code: la valeur du code d'erreur 32 bits.

   Description: une brève description de la sémantique du code d'erreur, plus
      si aucune spécification détaillée n'est fournie.

   Spécification: une référence facultative pour une spécification qui
      définit le code d'erreur.

   Les entrées du tableau suivant sont enregistrées par ce document.

   + --------------------- + ------ + -------------------- - + --------------- +
   | Nom | Code | Description | Spécification |
   + --------------------- + ------ + -------------------- - + --------------- +
   | NO_ERROR | 0x0 | Arrêt gracieux | Section 7 |
   | PROTOCOL_ERROR | 0x1 | Erreur de protocole | Section 7 |
   | | | détecté | |
   | INTERNAL_ERROR | 0x2 | Défaut de mise en œuvre | Section 7 |
   | FLOW_CONTROL_ERROR | 0x3 | Limites de contrôle de débit | Section 7 |
   | | | dépassé | |
   | SETTINGS_TIMEOUT | 0x4 | Paramètres non | Section 7 |
   | | | reconnu | |
   | STREAM_CLOSED | 0x5 | Trame reçue pour | Section 7 |
   | | | flux fermé | |
   | FRAME_SIZE_ERROR | 0x6 | Taille du cadre incorrecte | Section 7 |
   | REFUSED_STREAM | 0x7 | Flux non traité | Section 7 |
   | ANNULER | 0x8 | Stream annulé | Section 7 |
   | COMPRESSION_ERROR | 0x9 | État de compression | Section 7 |
   | | | pas mis à jour | |
   | CONNECT_ERROR | 0xa | Erreur de connexion TCP | Section 7 |
   | | | pour la méthode CONNECT | |
   | ENHANCE_YOUR_CALM | 0xb | Capacité de traitement | Section 7 |
   | | | dépassé | |
   | INADEQUATE_SECURITY | 0xc | TLS négocié | Section 7 |
   | | | paramètres non | |
   | | | acceptable | |
   | HTTP_1_1_REQUIRED | 0xd | Utilisez HTTP / 1.1 pour le | Section 7 |
   | | | demande | |
   + --------------------- + ------ + -------------------- - + --------------- +

11.5. Enregistrement du champ d'en-tête HTTP2-Settings

   Cette section enregistre le champ d'en-tête HTTP2-Settings dans le
   Registre "Noms de champ d'en-tête de message permanent" [BCP90].

   Nom du champ d'en-tête: HTTP2-Settings

   Protocole applicable: http

   Statut: standard

   Auteur / contrôleur de changement: IETF

   Document (s) de spécification: Section 3.2.1 de ce document

   Information associée: Ce champ d'en-tête n'est utilisé que par un HTTP / 2
      client pour la négociation basée sur la mise à niveau.

11.6. Enregistrement de la méthode PRI

   Cette section enregistre la méthode "PRI" dans le "HTTP Method Registry"
   ([RFC7231], section 8.1).

   Nom de la méthode: PRI

   Sûr: Oui

   Idempotent: Oui

   Document (s) de spécification: Section 3.5 de ce document

   Information associée: Cette méthode n'est jamais utilisée par un client réel.
      Cette méthode semble être utilisée lorsqu'un serveur HTTP / 1.1 ou
      intermédiaire tente d'analyser une préface de connexion HTTP / 2.

11.7. Le code d'état HTTP 421 (demande mal dirigée)

   Ce document enregistre l'état HTTP 421 (demande mal dirigée)
   code dans le registre "HTTP Status Codes" ([RFC7231], Section 8.2).

   Code d'état: 421

   Description courte: Demande mal dirigée

   Spécification: Section 9.1.2 de ce document

11.8. Le jeton de mise à niveau h2c

   Ce document enregistre le jeton de mise à niveau "h2c" dans la "Mise à jour HTTP"
   Registre des jetons ([RFC7230], section 8.6).

   Valeur: h2c

   Description: Hypertext Transfer Protocol version 2 (HTTP / 2)

   Jetons de version attendus: aucun

   Référence: section 3.2 de ce document

12. Références

12.1. Références normatives

   [COMPRESSION] Peon, R. et H. Ruellan, "HPACK: Header Compression for
                 HTTP / 2 ", RFC 7541, DOI 10.17487 / RFC7541, mai 2015,
                 <http://www.rfc-editor.org/info/rfc7541>.

   [COOKIE] Barth, A., "Mécanisme de gestion d'état HTTP", RFC 6265,
                 DOI 10.17487 / RFC6265, avril 2011,
                 <http://www.rfc-editor.org/info/rfc6265>.

   [FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB
                 186-4, juillet 2013,
                 <http://dx.doi.org/10.6028/NIST.FIPS.186-4>.

   [RFC2119] Bradner, S., "Mots clés à utiliser dans les RFC pour indiquer
                 Niveaux d'exigence ", BCP 14, RFC 2119, DOI 10.17487 /
                 RFC2119, mars 1997,
                 <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2818] Rescorla, E., "HTTP sur TLS", RFC 2818, DOI 10.17487 /
                 RFC2818, mai 2000,
                 <http://www.rfc-editor.org/info/rfc2818>.

   [RFC3986] Berners-Lee, T., Fielding, R., et L. Masinter,
                 "Identificateur de ressource uniforme (URI): syntaxe générique",
                 STD 66, RFC 3986, DOI 10.17487 / RFC3986, janvier 2005,
                 <http://www.rfc-editor.org/info/rfc3986>.

   [RFC4648] Josefsson, S., "Les données Base16, Base32 et Base64
                 Encodings ", RFC 4648, DOI 10.17487 / RFC4648, octobre
                 2006, <http://www.rfc-editor.org/info/rfc4648>.

   [RFC5226] Narten, T. et H. Alvestrand, «Guidelines for Writing
                 une section des considérations IANA dans les RFC ", BCP 26,
                 RFC 5226, DOI 10.17487 / RFC5226, mai 2008,
                 <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5234] Crocker, D., Ed. et P. Overell, "Augmented BNF for
                 Spécifications de syntaxe: ABNF ", STD 68, RFC 5234,
                 DOI 10.17487 / RFC5234, janvier 2008,
                 <http://www.rfc-editor.org/info/rfc5234>.

   [RFC7230] Fielding, R., Ed. et J. Reschke, Ed., "Hypertext
                 Protocole de transfert (HTTP / 1.1): syntaxe des messages et
                 Routing ", RFC 7230, DOI 10.17487 / RFC7230, juin 2014,
                 <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7231] Fielding, R., Ed. et J. Reschke, Ed., "Hypertext
                 Protocole de transfert (HTTP / 1.1): sémantique et contenu ",
                 RFC 7231, DOI 10.17487 / RFC7231, juin 2014,
                 <http://www.rfc-editor.org/info/rfc7231>.

   [RFC7232] Fielding, R., Ed. et J. Reschke, Ed., "Hypertext
                 Protocole de transfert (HTTP / 1.1): demandes conditionnelles ",
                 RFC 7232, DOI 10.17487 / RFC7232, juin 2014,
                 <http://www.rfc-editor.org/info/rfc7232>.

   [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., Et J. Reschke, Ed.,
                 "Protocole de transfert hypertexte (HTTP / 1.1): plage
                 Requests ", RFC 7233, DOI 10.17487 / RFC7233, juin 2014,
                 <http://www.rfc-editor.org/info/rfc7233>.

   [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., Et J. Reschke,
                 Ed., "Hypertext Transfer Protocol (HTTP / 1.1): Caching",
                 RFC 7234, DOI 10.17487 / RFC7234, juin 2014,
                 <http://www.rfc-editor.org/info/rfc7234>.

   [RFC7235] Fielding, R., Ed. et J. Reschke, Ed., "Hypertext
                 Protocole de transfert (HTTP / 1.1): authentification ",
                 RFC 7235, DOI 10.17487 / RFC7235, juin 2014,
                 <http://www.rfc-editor.org/info/rfc7235>.

   [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
                 793, DOI 10.17487 / RFC0793, septembre 1981,
                 <http://www.rfc-editor.org/info/rfc793>.

   [TLS-ALPN] Friedl, S., Popov, A., Langley, A. et E. Stephan,
                 "Couche d'application TLS (Transport Layer Security)
                 Extension de négociation de protocole ", RFC 7301,
                 DOI 10.17487 / RFC7301, juillet 2014,
                 <http://www.rfc-editor.org/info/rfc7301>.

   [TLS-ECDHE] Rescorla, E., "TLS Elliptic Curve Cipher Suites with
                 SHA-256/384 et mode compteur AES Galois (GCM) ",
                 RFC 5289, DOI 10.17487 / RFC5289, août 2008,
                 <http://www.rfc-editor.org/info/rfc5289>.

   [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS)
                 Extensions: définitions d'extensions ", RFC 6066,
                 DOI 10.17487 / RFC6066, janvier 2011,
                 <http://www.rfc-editor.org/info/rfc6066>.

   [TLS12] Dierks, T. et E. Rescorla, "The Transport Layer
                 Protocole de sécurité (TLS) version 1.2 ", RFC 5246,
                 DOI 10.17487 / RFC5246, août 2008,
                 <http://www.rfc-editor.org/info/rfc5246>.

12.2. Références informatives

   [ALT-SVC] Nottingham, M., McManus, P. et J. Reschke, "HTTP
                 Services alternatifs ", travail en cours, draft-ietf-
                 httpbis-alt-svc-06, février 2015.

   [BCP90] Klyne, G., Nottingham, M. et J. Mogul, "Registration
                 Procédures pour les champs d'en-tête de message ", BCP 90,
                 RFC 3864, septembre 2004,
                 <http://www.rfc-editor.org/info/bcp90>.

   [BREACH] Gluck, Y., Harris, N. et A. Prado, "BREACH: Reviving
                 the CRIME Attack ", juillet 2013,
                 <http://breachattack.com/resources/
                 BREACH% 20-% 20SSL,% 20gone% 20in% 2030% 20seconds.pdf>.

   [HTML5] Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
                 Doyle Navara, E., O'Connor, E., et S. Pfeiffer,
                 "HTML5", Recommandation REC-html5-20141028 du W3C, octobre
                 2014, <http://www.w3.org/TR/2014/REC-html5-20141028/>.

   [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
                 Méthodes de compression ", RFC 3749, DOI 10.17487 / RFC3749,
                 Mai 2004, <http://www.rfc-editor.org/info/rfc3749>.

   [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., et
                 B. Moeller, "Chiffre ECC (Elliptic Curve Cryptography)
                 Suites for Transport Layer Security (TLS) ", RFC 4492,
                 DOI 10.17487 / RFC4492, mai 2006,
                 <http://www.rfc-editor.org/info/rfc4492>.

   [RFC6585] Nottingham, M. et R. Fielding, "Statut HTTP supplémentaire
                 Codes ", RFC 6585, DOI 10.17487 / RFC6585, avril 2012,
                 <http://www.rfc-editor.org/info/rfc6585>.

   [RFC7323] Borman, D., Braden, B., Jacobson, V. et R.
                 Scheffenegger, Ed., «Extensions TCP pour
                 Performance ", RFC 7323, DOI 10.17487 / RFC7323, septembre
                 2014, <http://www.rfc-editor.org/info/rfc7323>.

   [PARLER] Huang, L., Chen, E., Barth, A., Rescorla, E. et C.
                 Jackson, "Se parler pour le plaisir et le profit",
                 2011, <http://w2spconf.com/2011/papers/websocket.pdf>.

   [TLSBCP] Sheffer, Y., Holz, R. et P. Saint-Andre,
                 "Recommandations pour une utilisation sécurisée de la couche de transport
                 Sécurité (TLS) et sécurité de la couche de transport de datagrammes
                 (DTLS) ", BCP 195, RFC 7525, DOI 10.17487 / RFC7525, mai
                 2015, <http://www.rfc-editor.org/info/rfc7525>.

Annexe A. Liste noire de la suite de chiffrement TLS 1.2

   Une implémentation HTTP / 2 PEUT traiter la négociation de l'un des
   suite de suites de chiffrement avec TLS 1.2 comme erreur de connexion
   (Section 5.4.1) de type INADEQUATE_SECURITY:

   o TLS_NULL_WITH_NULL_NULL

   o TLS_RSA_WITH_NULL_MD5

   o TLS_RSA_WITH_NULL_SHA

   o TLS_RSA_EXPORT_WITH_RC4_40_MD5

   o TLS_RSA_WITH_RC4_128_MD5

   o TLS_RSA_WITH_RC4_128_SHA

   o TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

   o TLS_RSA_WITH_IDEA_CBC_SHA

   o TLS_RSA_EXPORT_WITH_DES40_CBC_SHA

   o TLS_RSA_WITH_DES_CBC_SHA

   o TLS_RSA_WITH_3DES_EDE_CBC_SHA

   o TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA

   o TLS_DH_DSS_WITH_DES_CBC_SHA

   o TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA

   o TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA

   o TLS_DH_RSA_WITH_DES_CBC_SHA

   o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA

   o TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

   o TLS_DHE_DSS_WITH_DES_CBC_SHA

   o TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

   o TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

   o TLS_DHE_RSA_WITH_DES_CBC_SHA

   o TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

   o TLS_DH_anon_EXPORT_WITH_RC4_40_MD5

   o TLS_DH_anon_WITH_RC4_128_MD5

   o TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

   o TLS_DH_anon_WITH_DES_CBC_SHA

   o TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

   o TLS_KRB5_WITH_DES_CBC_SHA

   o TLS_KRB5_WITH_3DES_EDE_CBC_SHA

   o TLS_KRB5_WITH_RC4_128_SHA

   o TLS_KRB5_WITH_IDEA_CBC_SHA

   o TLS_KRB5_WITH_DES_CBC_MD5

   o TLS_KRB5_WITH_3DES_EDE_CBC_MD5

   o TLS_KRB5_WITH_RC4_128_MD5

   o TLS_KRB5_WITH_IDEA_CBC_MD5

   o TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA

   o TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA

   o TLS_KRB5_EXPORT_WITH_RC4_40_SHA

   o TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5

   o TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5

   o TLS_KRB5_EXPORT_WITH_RC4_40_MD5

   o TLS_PSK_WITH_NULL_SHA

   o TLS_DHE_PSK_WITH_NULL_SHA

   o TLS_RSA_PSK_WITH_NULL_SHA

   o TLS_RSA_WITH_AES_128_CBC_SHA

   o TLS_DH_DSS_WITH_AES_128_CBC_SHA

   o TLS_DH_RSA_WITH_AES_128_CBC_SHA

   o TLS_DHE_DSS_WITH_AES_128_CBC_SHA

   o TLS_DHE_RSA_WITH_AES_128_CBC_SHA

   o TLS_DH_anon_WITH_AES_128_CBC_SHA

   o TLS_RSA_WITH_AES_256_CBC_SHA

   o TLS_DH_DSS_WITH_AES_256_CBC_SHA

   o TLS_DH_RSA_WITH_AES_256_CBC_SHA

   o TLS_DHE_DSS_WITH_AES_256_CBC_SHA

   o TLS_DHE_RSA_WITH_AES_256_CBC_SHA

   o TLS_DH_anon_WITH_AES_256_CBC_SHA

   o TLS_RSA_WITH_NULL_SHA256

   o TLS_RSA_WITH_AES_128_CBC_SHA256

   o TLS_RSA_WITH_AES_256_CBC_SHA256

   o TLS_DH_DSS_WITH_AES_128_CBC_SHA256

   o TLS_DH_RSA_WITH_AES_128_CBC_SHA256

   o TLS_DHE_DSS_WITH_AES_128_CBC_SHA256

   o TLS_RSA_WITH_CAMELLIA_128_CBC_SHA

   o TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA

   o TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA

   o TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA

   o TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA

   o TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA

   o TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

   o TLS_DH_DSS_WITH_AES_256_CBC_SHA256

   o TLS_DH_RSA_WITH_AES_256_CBC_SHA256

   o TLS_DHE_DSS_WITH_AES_256_CBC_SHA256

   o TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

   o TLS_DH_anon_WITH_AES_128_CBC_SHA256

   o TLS_DH_anon_WITH_AES_256_CBC_SHA256

   o TLS_RSA_WITH_CAMELLIA_256_CBC_SHA

   o TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA

   o TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA

   o TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA

   o TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA

   o TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA

   o TLS_PSK_WITH_RC4_128_SHA

   o TLS_PSK_WITH_3DES_EDE_CBC_SHA

   o TLS_PSK_WITH_AES_128_CBC_SHA

   o TLS_PSK_WITH_AES_256_CBC_SHA

   o TLS_DHE_PSK_WITH_RC4_128_SHA

   o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA

   o TLS_DHE_PSK_WITH_AES_128_CBC_SHA

   o TLS_DHE_PSK_WITH_AES_256_CBC_SHA

   o TLS_RSA_PSK_WITH_RC4_128_SHA

   o TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA

   o TLS_RSA_PSK_WITH_AES_128_CBC_SHA

   o TLS_RSA_PSK_WITH_AES_256_CBC_SHA

   o TLS_RSA_WITH_SEED_CBC_SHA

   o TLS_DH_DSS_WITH_SEED_CBC_SHA

   o TLS_DH_RSA_WITH_SEED_CBC_SHA

   o TLS_DHE_DSS_WITH_SEED_CBC_SHA

   o TLS_DHE_RSA_WITH_SEED_CBC_SHA

   o TLS_DH_anon_WITH_SEED_CBC_SHA

   o TLS_RSA_WITH_AES_128_GCM_SHA256

   o TLS_RSA_WITH_AES_256_GCM_SHA384

   o TLS_DH_RSA_WITH_AES_128_GCM_SHA256

   o TLS_DH_RSA_WITH_AES_256_GCM_SHA384

   o TLS_DH_DSS_WITH_AES_128_GCM_SHA256

   o TLS_DH_DSS_WITH_AES_256_GCM_SHA384

   o TLS_DH_anon_WITH_AES_128_GCM_SHA256

   o TLS_DH_anon_WITH_AES_256_GCM_SHA384

   o TLS_PSK_WITH_AES_128_GCM_SHA256

   o TLS_PSK_WITH_AES_256_GCM_SHA384

   o TLS_RSA_PSK_WITH_AES_128_GCM_SHA256

   o TLS_RSA_PSK_WITH_AES_256_GCM_SHA384

   o TLS_PSK_WITH_AES_128_CBC_SHA256

   o TLS_PSK_WITH_AES_256_CBC_SHA384

   o TLS_PSK_WITH_NULL_SHA256

   o TLS_PSK_WITH_NULL_SHA384

   o TLS_DHE_PSK_WITH_AES_128_CBC_SHA256

   o TLS_DHE_PSK_WITH_AES_256_CBC_SHA384

   o TLS_DHE_PSK_WITH_NULL_SHA256

   o TLS_DHE_PSK_WITH_NULL_SHA384

   o TLS_RSA_PSK_WITH_AES_128_CBC_SHA256

   o TLS_RSA_PSK_WITH_AES_256_CBC_SHA384

   o TLS_RSA_PSK_WITH_NULL_SHA256

   o TLS_RSA_PSK_WITH_NULL_SHA384

   o TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256

   o TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256

   o TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256

   o TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256

   o TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256

   o TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256

   o TLS_EMPTY_RENEGOTIATION_INFO_SCSV

   o TLS_ECDH_ECDSA_WITH_NULL_SHA

   o TLS_ECDH_ECDSA_WITH_RC4_128_SHA

   o TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA

   o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA

   o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA

   o TLS_ECDHE_ECDSA_WITH_NULL_SHA

   o TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

   o TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

   o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

   o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

   o TLS_ECDH_RSA_WITH_NULL_SHA

   o TLS_ECDH_RSA_WITH_RC4_128_SHA

   o TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA

   o TLS_ECDH_RSA_WITH_AES_128_CBC_SHA

   o TLS_ECDH_RSA_WITH_AES_256_CBC_SHA

   o TLS_ECDHE_RSA_WITH_NULL_SHA

   o TLS_ECDHE_RSA_WITH_RC4_128_SHA

   o TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

   o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

   o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

   o TLS_ECDH_anon_WITH_NULL_SHA

   o TLS_ECDH_anon_WITH_RC4_128_SHA

   o TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA

   o TLS_ECDH_anon_WITH_AES_128_CBC_SHA

   o TLS_ECDH_anon_WITH_AES_256_CBC_SHA

   o TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA

   o TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA

   o TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA

   o TLS_SRP_SHA_WITH_AES_128_CBC_SHA

   o TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA

   o TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA

   o TLS_SRP_SHA_WITH_AES_256_CBC_SHA

   o TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA

   o TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA

   o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

   o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

   o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

   o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384

   o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

   o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

   o TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256

   o TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384

   o TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256

   o TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384

   o TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256

   o TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384

   o TLS_ECDHE_PSK_WITH_RC4_128_SHA

   o TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA

   o TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

   o TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

   o TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256

   o TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384

   o TLS_ECDHE_PSK_WITH_NULL_SHA

   o TLS_ECDHE_PSK_WITH_NULL_SHA256

   o TLS_ECDHE_PSK_WITH_NULL_SHA384

   o TLS_RSA_WITH_ARIA_128_CBC_SHA256

   o TLS_RSA_WITH_ARIA_256_CBC_SHA384

   o TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256

   o TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384

   o TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256

   o TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384

   o TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256

   o TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384

   o TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256

   o TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384

   o TLS_DH_anon_WITH_ARIA_128_CBC_SHA256

   o TLS_DH_anon_WITH_ARIA_256_CBC_SHA384

   o TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256

   o TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384

   o TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256

   o TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384

   o TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256

   o TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384

   o TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256

   o TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384

   o TLS_RSA_WITH_ARIA_128_GCM_SHA256

   o TLS_RSA_WITH_ARIA_256_GCM_SHA384

   o TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256

   o TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384

   o TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256

   o TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384

   o TLS_DH_anon_WITH_ARIA_128_GCM_SHA256

   o TLS_DH_anon_WITH_ARIA_256_GCM_SHA384

   o TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256

   o TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384

   o TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256

   o TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384

   o TLS_PSK_WITH_ARIA_128_CBC_SHA256

   o TLS_PSK_WITH_ARIA_256_CBC_SHA384

   o TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256

   o TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384

   o TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256

   o TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384

   o TLS_PSK_WITH_ARIA_128_GCM_SHA256

   o TLS_PSK_WITH_ARIA_256_GCM_SHA384

   o TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256

   o TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384

   o TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256

   o TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384

   o TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384

   o TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384

   o TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384

   o TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384

   o TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256

   o TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384

   o TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256

   o TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384

   o TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256

   o TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384

   o TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256

   o TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384

   o TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256

   o TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384

   o TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256

   o TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384

   o TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256

   o TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384

   o TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256

   o TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384

   o TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384

   o TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384

   o TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384

   o TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256

   o TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384

   o TLS_RSA_WITH_AES_128_CCM

   o TLS_RSA_WITH_AES_256_CCM

   o TLS_RSA_WITH_AES_128_CCM_8

   o TLS_RSA_WITH_AES_256_CCM_8

   o TLS_PSK_WITH_AES_128_CCM

   o TLS_PSK_WITH_AES_256_CCM

   o TLS_PSK_WITH_AES_128_CCM_8

   o TLS_PSK_WITH_AES_256_CCM_8

      Remarque: cette liste a été constituée à partir de l'ensemble des TLS enregistrés
      suites de chiffrement au moment de la rédaction. Cette liste comprend ceux
      suites de chiffrement qui n'offrent pas d'échange de clé éphémère et
      ceux qui sont basés sur le type de chiffrement TLS nul, flux ou bloc
      (tel que défini dans la section 6.2.3 de [TLS12]). Chiffre supplémentaire
      des suites avec ces propriétés pourraient être définies; ce ne serait pas
      explicitement interdit.

Remerciements

   Ce document comprend une contribution substantielle des éléments suivants
   personnes:

   o Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa
      Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam
      Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay,
      Paul Amer, Fan Yang et Jonathan Leighton (contributeurs SPDY).

   o Gabriel Montenegro et Willy Tarreau (mécanisme de mise à niveau).

   o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro,
      Jitu Padhye, Roberto Peon et Rob Trace (contrôle de flux).

   o Mike Bishop (extensibilité).

   o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike
      Bishop et Hervé Ruellan (contributions éditoriales substantielles).

   o Kari Hurtta, Tatsuhiro Tsujikawa, Greg Wilkins, Poul-Henning Kamp,
      et Jonathan Thackray.

   o Alexey Melnikov, qui était rédacteur en chef de ce document en 2013.

   Une part importante de la contribution de Martin a été soutenue par
   Microsoft pendant son emploi là-bas.

   La communauté japonaise HTTP / 2 a fourni des contributions inestimables,
   y compris un certain nombre d'implémentations ainsi que de nombreuses techniques
   et contributions éditoriales.

Adresses des auteurs

   Mike Belshe
   BitGo

   Courriel: mike@belshe.com


   Roberto Peon
   Google Inc

   Courriel: fenix@google.com


   Martin Thomson (éditeur)
   Mozilla
   331 E rue ​​Evelyn
   Mountain View, Californie 94041
   États Unis

   COURRIEL: martin.thomson@gmail.com

Balisage HTML produit par rfcmarkup 1.129d, disponible sur https://tools.ietf.org/tools/rfcmarkup/