Aller au contenu principal

6. Frame Definitions (Définitions des Trames)

Cette spécification définit un certain nombre de types de trames, chacun identifié par un code de type unique de 8 bits. Chaque type de trame remplit un objectif distinct dans l'établissement et la gestion de la connexion dans son ensemble ou des flux individuels.

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

6.1. DATA​

Les trames DATA (type=0x00) transmettent des séquences d'octets arbitraires de longueur variable associées à un flux. Une ou plusieurs trames DATA sont utilisées, par exemple, pour transporter le contenu des messages de requête ou de réponse HTTP.

Les trames DATA peuvent également contenir un rembourrage (padding). Le rembourrage peut être ajouté aux trames DATA pour obscurcir la taille des messages. Le rembourrage est une fonctionnalité de sécurité ; voir la section 10.7.

DATA Frame {
  Length (24),
  Type (8) = 0x00,

  Unused Flags (4),
  PADDED Flag (1),
  Unused Flags (2),
  END_STREAM Flag (1),

  Reserved (1),
  Stream Identifier (31),

  [Pad Length (8)],
  Data (..),
  Padding (..2040),
}

Figure 3 : Format de la Trame DATA

Les champs Length, Type, Unused Flag(s), Reserved et Stream Identifier sont décrits dans la section 4. La trame DATA contient les champs supplémentaires suivants :

Pad Length (Longueur de rembourrage) : Un champ de 8 bits contenant la longueur du rembourrage de la trame en unités d'octets. Ce champ est conditionnel et n'est présent que si le drapeau PADDED est défini.

Data (Données) : Données d'application. La quantité de données est le reste de la charge utile de la trame après soustraction de la longueur des autres champs présents.

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

La trame DATA définit les drapeaux suivants :

PADDED (0x08) : Lorsqu'il est défini, le drapeau PADDED indique que le champ Pad Length et tout rembourrage qu'il décrit sont présents.

END_STREAM (0x01) : Lorsqu'il est défini, le drapeau END_STREAM indique que cette trame est la dernière que le point de terminaison enverra pour le flux identifié. La définition de ce drapeau fait entrer le flux dans l'un des états « half-closed » ou l'état « closed » (section 5.1).

| Note : Un point de terminaison qui apprend la fermeture du flux après avoir envoyé | toutes les données peut fermer un flux en envoyant une trame STREAM avec un champ | Data de longueur nulle et le drapeau END_STREAM défini. Cela n'est possible que si | le point de terminaison n'envoie pas de trailers, car le drapeau END_STREAM apparaît | sur une trame HEADERS dans ce cas ; voir la section 8.1.

Les trames DATA DOIVENT être associées à un flux. Si une trame DATA est reçue dont le champ Stream Identifier est 0x00, le destinataire DOIT répondre par une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

Les trames DATA sont soumises au contrôle de flux et ne peuvent être envoyées que lorsqu'un flux est dans l'état « open » ou « half-closed (remote) ». L'intégralité de la charge utile de la trame DATA est incluse dans le contrôle de flux, y compris les champs Pad Length et Padding s'ils sont présents. Si une trame DATA est reçue dont le flux n'est pas dans l'état « open » ou « half-closed (local) », le destinataire DOIT répondre par une erreur de flux (section 5.4.2) de type STREAM_CLOSED.

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

| Note : Une trame peut être augmentée d'un octet en incluant un champ Pad Length | avec une valeur de zéro.

6.2. HEADERS​

La trame HEADERS (type=0x01) est utilisée pour ouvrir un flux (section 5.1) et transporte en outre un fragment de bloc de champs. Malgré le nom, une trame HEADERS peut transporter une section d'en-tête ou une section de trailer. Les trames HEADERS peuvent être envoyées sur un flux dans l'état « idle », « reserved (local) », « open » ou « half-closed (remote) ».

HEADERS Frame {
  Length (24),
  Type (8) = 0x01,

  Unused Flags (2),
  PRIORITY Flag (1),
  Unused Flag (1),
  PADDED Flag (1),
  END_HEADERS Flag (1),
  Unused Flag (1),
  END_STREAM Flag (1),

  Reserved (1),
  Stream Identifier (31),

  [Pad Length (8)],
  [Exclusive (1)],
  [Stream Dependency (31)],
  [Weight (8)],
  Field Block Fragment (..),
  Padding (..2040),
}

Figure 4 : Format de la Trame HEADERS

Les champs Length, Type, Unused Flag(s), Reserved et Stream Identifier sont décrits dans la section 4. La charge utile de la trame HEADERS contient les champs supplémentaires suivants :

Pad Length (Longueur de rembourrage) : Un champ de 8 bits contenant la longueur du rembourrage de la trame en unités d'octets. Ce champ n'est présent que si le drapeau PADDED est défini.

Exclusive (Exclusif) : Un drapeau d'un seul bit. Ce champ n'est présent que si le drapeau PRIORITY est défini. Les signaux de priorité dans les trames HEADERS sont obsolètes ; voir la section 5.3.2.

Stream Dependency (Dépendance de flux) : Un identifiant de flux de 31 bits. Ce champ n'est présent que si le drapeau PRIORITY est défini.

Weight (Poids) : Un entier non signé de 8 bits. Ce champ n'est présent que si le drapeau PRIORITY est défini.

Field Block Fragment (Fragment de bloc de champs) : Un fragment de bloc de champs (section 4.3).

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

La trame HEADERS définit les drapeaux suivants :

PRIORITY (0x20) : Lorsqu'il est défini, le drapeau PRIORITY indique que les champs Exclusive, Stream Dependency et Weight sont présents.

PADDED (0x08) : Lorsqu'il est défini, le drapeau PADDED indique que le champ Pad Length et tout rembourrage qu'il décrit sont présents.

END_HEADERS (0x04) : Lorsqu'il est défini, le drapeau END_HEADERS indique que cette trame contient un bloc de champs entier (section 4.3) et n'est pas suivie de trames CONTINUATION.

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

END_STREAM (0x01) : Lorsqu'il est défini, le drapeau END_STREAM indique que le bloc de champs (section 4.3) est le dernier que le point de terminaison enverra pour le flux identifié.

Une trame HEADERS avec le drapeau END_STREAM défini signale la fin d'un flux. Cependant, une trame HEADERS avec le drapeau END_STREAM défini peut être suivie de trames CONTINUATION sur le même flux. Logiquement, les trames CONTINUATION font partie de la trame HEADERS.

La charge utile de la trame HEADERS contient un fragment de bloc de champs (section 4.3). Un bloc de champs qui ne rentre pas dans une trame HEADERS se poursuit dans une trame CONTINUATION (section 6.10).

Les trames HEADERS DOIVENT être associées à un flux. Si une trame HEADERS est reçue dont le champ Stream Identifier est 0x00, le destinataire DOIT répondre par une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

La trame HEADERS modifie l'état de la connexion comme décrit dans la section 4.3.

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

| Note : Une trame peut être augmentée d'un octet en incluant un champ Pad Length | avec une valeur de zéro.

6.3. PRIORITY​

La trame PRIORITY (type=0x02) est obsolète ; voir la section 5.3.2. Une trame PRIORITY peut être envoyée dans n'importe quel état de flux, y compris les flux idle ou closed.

PRIORITY Frame {
  Length (24) = 0x05,
  Type (8) = 0x02,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Exclusive (1),
  Stream Dependency (31),
  Weight (8),
}

Figure 5 : Format de la Trame PRIORITY

Les champs Length, Type, Unused Flag(s), Reserved et Stream Identifier sont décrits dans la section 4. La charge utile de la trame PRIORITY contient les champs supplémentaires suivants :

Exclusive (Exclusif) : Un drapeau d'un seul bit.

Stream Dependency (Dépendance de flux) : Un identifiant de flux de 31 bits.

Weight (Poids) : Un entier non signé de 8 bits.

La trame PRIORITY ne définit aucun drapeau.

La trame PRIORITY identifie toujours un flux. Si une trame PRIORITY est reçue avec un identifiant de flux de 0x00, le destinataire DOIT répondre par une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

L'envoi ou la réception d'une trame PRIORITY n'affecte pas l'état d'un flux (section 5.1). La trame PRIORITY peut être envoyée sur un flux dans n'importe quel état, y compris « idle » ou « closed ». Une trame PRIORITY ne peut pas être envoyée entre des trames consécutives qui composent un seul bloc de champs (section 4.3).

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

6.4. RST_STREAM​

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

RST_STREAM Frame {
  Length (24) = 0x04,
  Type (8) = 0x03,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Error Code (32),
}

Figure 6 : Format de la Trame RST_STREAM

Les champs Length, Type, Unused Flag(s), Reserved et Stream Identifier sont décrits dans la section 4. De plus, la trame RST_STREAM contient un seul entier non signé de 32 bits identifiant le code d'erreur (section 7). Le code d'erreur indique pourquoi le flux est terminé.

La trame RST_STREAM ne définit aucun drapeau.

La trame RST_STREAM termine complètement le flux référencé et le fait entrer dans l'état « closed ». Après avoir reçu un RST_STREAM sur un flux, le récepteur NE DOIT PAS envoyer de trames supplémentaires pour ce flux, à l'exception de PRIORITY. Cependant, après avoir envoyé le RST_STREAM, le point de terminaison émetteur DOIT être prêt à recevoir et traiter les trames supplémentaires envoyées sur le flux qui auraient pu être envoyées par le pair avant l'arrivée du RST_STREAM.

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

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

Une trame RST_STREAM 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.5. SETTINGS​

La trame SETTINGS (type=0x04) transmet des paramètres de configuration qui affectent la façon dont les points de terminaison communiquent, tels que les préférences et les contraintes sur le comportement du pair. La trame SETTINGS est également utilisée pour accuser réception de ces paramètres. Individuellement, un paramètre de configuration d'une trame SETTINGS est appelé un « paramètre ».

Les paramètres ne sont pas négociés ; ils décrivent les caractéristiques du pair émetteur, qui sont utilisées par le pair récepteur. Différentes valeurs pour le même paramètre peuvent être annoncées par chaque pair. Par 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 économiser les ressources.

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

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

Les trames SETTINGS sont accusées réception par le pair récepteur. Pour permettre cela, la trame SETTINGS définit le drapeau ACK :

ACK (0x01) : Lorsqu'il est défini, le drapeau ACK indique que cette trame accuse réception de la réception et de l'application de la trame SETTINGS du pair. Lorsque ce bit est défini, la charge utile de la trame SETTINGS DOIT être vide. La réception d'une trame SETTINGS avec le drapeau ACK défini et une valeur de champ de longueur autre que 0 DOIT être traitée comme une erreur de connexion (section 5.4.1) de type FRAME_SIZE_ERROR. Pour plus d'informations, voir la section 6.5.3 (« Synchronisation des paramètres »).

Les trames SETTINGS s'appliquent toujours à une connexion, jamais à un seul flux. L'identifiant de flux pour une trame SETTINGS DOIT être zéro (0x00). Si un point de terminaison reçoit une trame SETTINGS dont le champ Stream Identifier est autre que 0x00, le point de terminaison DOIT répondre par une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

La trame SETTINGS affecte l'état de la connexion. Une trame SETTINGS mal formée ou incomplète DOIT être traitée comme une erreur de connexion (section 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. SETTINGS Format (Format SETTINGS)​

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

SETTINGS Frame {
  Length (24),
  Type (8) = 0x04,

  Unused Flags (7),
  ACK Flag (1),

  Reserved (1),
  Stream Identifier (31) = 0,

  Setting (48) ...,
}

Setting {
  Identifier (16),
  Value (32),
}

Figure 7 : Format de la Trame SETTINGS

Les champs Length, Type, Unused Flag(s), Reserved et Stream Identifier sont décrits dans la section 4. La charge utile d'une trame SETTINGS contient un nombre quelconque de champs Setting, chacun constitué de :

Identifier (Identifiant) : Un identifiant de paramètre de 16 bits ; voir la section 6.5.2.

Value (Valeur) : Une valeur de 32 bits pour le paramètre.

6.5.2. Defined Settings (Paramètres Définis)​

Les paramètres suivants sont définis :

SETTINGS_HEADER_TABLE_SIZE (0x01) : Ce paramètre permet à l'émetteur d'informer le point de terminaison distant de la taille maximale de la table de compression utilisée pour décoder les blocs de champs, en unités d'octets. L'encodeur peut sélectionner toute taille égale ou inférieure à cette valeur en utilisant une signalisation spécifique au format de compression à l'intérieur d'un bloc de champs (voir [COMPRESSION]). La valeur initiale est de 4 096 octets.

SETTINGS_ENABLE_PUSH (0x02) : Ce paramètre peut être utilisé pour activer ou désactiver le push serveur. Un serveur NE DOIT PAS envoyer une trame PUSH_PROMISE s'il reçoit ce paramètre défini sur une valeur de 0 ; voir la section 8.4. Un client qui a défini ce paramètre sur 0 et l'a fait accuser réception DOIT traiter la réception d'une trame PUSH_PROMISE comme une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

La valeur initiale de SETTINGS_ENABLE_PUSH est 1. Pour un client, cette valeur indique qu'il est disposé à recevoir des trames PUSH_PROMISE. Pour un serveur, cette valeur initiale n'a aucun effet et est équivalente à la valeur 0. Toute valeur autre que 0 ou 1 DOIT être traitée comme une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

Un serveur NE DOIT PAS définir explicitement cette valeur sur 1. Un serveur PEUT choisir d'omettre ce paramètre lorsqu'il envoie une trame SETTINGS, mais si un serveur inclut une valeur, elle DOIT être 0. Un client DOIT traiter la réception d'une trame SETTINGS avec SETTINGS_ENABLE_PUSH défini sur 1 comme une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

SETTINGS_MAX_CONCURRENT_STREAMS (0x03) : Ce paramètre indique le nombre maximum de flux simultanés que l'émetteur autorisera. Cette limite est directionnelle : elle s'applique au nombre de flux que l'émetteur permet au récepteur de créer. Initialement, 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ée comme spéciale par les points de terminaison. Une valeur nulle empêche la création de nouveaux flux ; cependant, cela peut également se produire pour toute limite épuisée avec des flux actifs. Les serveurs DEVRAIENT uniquement définir une valeur nulle pendant de courtes durées ; si un serveur ne souhaite pas accepter de demandes, fermer la connexion est plus approprié.

SETTINGS_INITIAL_WINDOW_SIZE (0x04) : Ce paramètre indique la taille de fenêtre initiale de l'émetteur (en unités d'octets) pour le contrôle de flux au niveau du flux. La valeur initiale est 2^16-1 (65 535) octets.

Ce paramètre affecte la taille de fenêtre de tous les flux (voir la 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ées comme une erreur de connexion (section 5.4.1) de type FLOW_CONTROL_ERROR.

SETTINGS_MAX_FRAME_SIZE (0x05) : Ce paramètre indique la taille de la plus grande charge utile de trame que l'émetteur est disposé à recevoir, en unités d'octets.

La valeur initiale est 2^14 (16 384) octets. La valeur annoncée par un point de terminaison DOIT être comprise entre cette valeur initiale et la taille maximale de trame autorisée (2^24-1 ou 16 777 215 octets), inclusivement. Les valeurs en dehors de cette plage DOIVENT être traitées comme une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

SETTINGS_MAX_HEADER_LIST_SIZE (0x06) : Ce paramètre consultatif informe un pair de la taille maximale de la section de champs que l'émetteur est prêt à accepter, en unités d'octets. La valeur est basée sur la taille non compressée des lignes de champs, y compris la longueur du nom et de la valeur en unités d'octets plus une surcharge de 32 octets pour chaque ligne de champ.

Pour toute demande donnée, une limite inférieure à celle annoncée 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 identifiant inconnu ou non pris en charge DOIT ignorer ce paramètre.

6.5.3. Settings Synchronization (Synchronisation des Paramètres)​

La plupart des valeurs dans SETTINGS bénéficient ou nécessitent une compréhension du moment où le pair a reçu et appliqué les valeurs de paramètres modifiées. Afin de fournir de tels points de synchronisation, le destinataire d'une trame SETTINGS dans laquelle le drapeau ACK n'est pas défini DOIT appliquer les paramètres mis à jour dès que possible à la réception. Les trames SETTINGS sont accusées réception dans l'ordre dans lequel elles sont reçues.

Les valeurs dans la trame SETTINGS DOIVENT être traitées dans l'ordre dans lequel elles apparaissent, sans aucun autre traitement de trame entre les valeurs. Les paramètres non pris en charge DOIVENT être ignorés. Une fois que toutes les valeurs ont été traitées, le destinataire DOIT immédiatement émettre une trame SETTINGS avec le drapeau ACK défini. Lors de la réception d'une trame SETTINGS avec le drapeau ACK défini, l'émetteur des paramètres modifiés peut compter sur le fait que les valeurs de la plus ancienne trame SETTINGS non accusée ont été appliquées.

Si l'émetteur 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. En définissant un délai d'expiration, il faut tenir compte des délais de traitement au niveau du pair ; un délai d'expiration uniquement basé sur le temps d'aller-retour entre les points de terminaison pourrait entraîner des erreurs parasites.

6.6. PUSH_PROMISE​

La trame PUSH_PROMISE (type=0x05) est utilisée pour notifier le point de terminaison pair à l'avance des flux que l'émetteur a l'intention d'initier. La trame PUSH_PROMISE inclut l'identifiant non signé de 31 bits du flux que le point de terminaison prévoit de créer ainsi qu'une section de champs qui fournit un contexte supplémentaire pour le flux. La section 8.4 contient une description complète de l'utilisation des trames PUSH_PROMISE.

PUSH_PROMISE Frame {
  Length (24),
  Type (8) = 0x05,

  Unused Flags (4),
  PADDED Flag (1),
  END_HEADERS Flag (1),
  Unused Flags (2),

  Reserved (1),
  Stream Identifier (31),

  [Pad Length (8)],
  Reserved (1),
  Promised Stream ID (31),
  Field Block Fragment (..),
  Padding (..2040),
}

Figure 8 : Format de la Trame PUSH_PROMISE

Les champs Length, Type, Unused Flag(s), Reserved et Stream Identifier sont décrits dans la section 4. La charge utile de la trame PUSH_PROMISE contient les champs supplémentaires suivants :

Pad Length (Longueur de rembourrage) : Un champ de 8 bits contenant la longueur du rembourrage de la trame en unités d'octets. Ce champ n'est présent que si le drapeau PADDED est défini.

Promised Stream ID (ID de flux promis) : Un entier non signé de 31 bits qui identifie le flux réservé par le PUSH_PROMISE. L'identifiant de flux promis DOIT être un choix valide pour le prochain flux envoyé par l'émetteur (voir « nouvel identifiant de flux » dans la section 5.1.1).

Field Block Fragment (Fragment de bloc de champs) : Un fragment de bloc de champs (section 4.3) contenant les données de contrôle de la requête et une section d'en-tête.

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

La trame PUSH_PROMISE définit les drapeaux suivants :

PADDED (0x08) : Lorsqu'il est défini, le drapeau PADDED indique que le champ Pad Length et tout rembourrage qu'il décrit sont présents.

END_HEADERS (0x04) : Lorsqu'il est défini, le drapeau END_HEADERS indique que cette trame contient un bloc de champs entier (section 4.3) et n'est pas suivie de trames CONTINUATION.

Une trame PUSH_PROMISE sans le drapeau END_HEADERS défini DOIT être suivie d'une trame CONTINUATION pour le même flux. Un récepteur DOIT traiter la réception de tout autre type de trame ou d'une trame sur un flux différent comme une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

Les trames PUSH_PROMISE DOIVENT uniquement être envoyées sur un flux initié par le pair qui est soit dans l'état « open » soit « half-closed (remote) ». L'identifiant de flux d'une trame PUSH_PROMISE indique le flux auquel elle est associée. Si le champ Stream Identifier spécifie la valeur 0x00, un destinataire DOIT répondre par une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

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

PUSH_PROMISE NE DOIT PAS être envoyé si le paramètre SETTINGS_ENABLE_PUSH du point de terminaison pair 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'une trame PUSH_PROMISE comme une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

Les destinataires de trames PUSH_PROMISE peuvent choisir de rejeter les flux promis en renvoyant un RST_STREAM référençant l'identifiant de flux promis à l'émetteur du PUSH_PROMISE.

Une trame PUSH_PROMISE modifie l'état de la connexion de deux manières. Premièrement, l'inclusion d'un bloc de champs (section 4.3) modifie potentiellement l'état maintenu pour la compression de la section de champs. Deuxièmement, PUSH_PROMISE réserve également un flux pour une utilisation ultérieure, faisant entrer le flux promis dans l'état « reserved (local) » ou « reserved (remote) ». Un émetteur NE DOIT PAS envoyer un PUSH_PROMISE sur un flux à moins que ce flux ne soit soit « open » soit « half-closed (remote) » ; l'émetteur DOIT s'assurer que le flux promis 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 « idle »).

Étant donné que PUSH_PROMISE réserve un flux, ignorer une trame PUSH_PROMISE fait que l'état du flux devient indéterminé. Un récepteur DOIT traiter la réception d'un PUSH_PROMISE sur un flux qui n'est ni « open » ni « half-closed (local) » comme une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR. Cependant, un point de terminaison qui a envoyé RST_STREAM sur le flux associé DOIT gérer les trames PUSH_PROMISE qui auraient pu être créées avant que la trame RST_STREAM ne soit reçue et traitée.

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 une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR. Notez qu'un identifiant de flux illégal est un identifiant pour un flux qui n'est pas actuellement dans l'état « idle ».

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

| Note : Une trame peut être augmentée d'un octet en incluant un champ Pad Length | avec une valeur de zéro.

6.7. PING​

La trame PING (type=0x06) est un mécanisme pour mesurer un temps d'aller-retour minimal depuis l'émetteur, ainsi que pour déterminer si une connexion inactive est toujours fonctionnelle. Les trames PING peuvent être envoyées depuis n'importe quel point de terminaison.

PING Frame {
  Length (24) = 0x08,
  Type (8) = 0x06,

  Unused Flags (7),
  ACK Flag (1),

  Reserved (1),
  Stream Identifier (31) = 0,

  Opaque Data (64),
}

Figure 9 : Format de la Trame PING

Les champs Length, Type, Unused Flag(s), Reserved et Stream Identifier sont décrits dans la section 4.

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

Les récepteurs d'une trame PING qui n'inclut pas de drapeau ACK DOIVENT envoyer une trame PING avec le drapeau ACK défini en réponse, avec une charge utile de trame identique. Les réponses PING DEVRAIENT recevoir une priorité plus élevée que toute autre trame.

La trame PING définit le drapeau suivant :

ACK (0x01) : Lorsqu'il est défini, le drapeau ACK indique que cette trame PING est une réponse PING. Un point de terminaison DOIT définir ce drapeau dans les réponses PING. Un point de terminaison NE DOIT PAS répondre aux trames PING contenant ce drapeau.

Les trames PING ne sont pas associées à un flux individuel. Si une trame PING est reçue avec une valeur de champ Stream Identifier autre que 0x00, le destinataire DOIT répondre par une erreur de connexion (section 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. GOAWAY​

La trame GOAWAY (type=0x07) est utilisée pour initier l'arrêt d'une connexion ou pour signaler des conditions d'erreur graves. GOAWAY permet à un point de terminaison d'arrêter gracieusement d'accepter de nouveaux flux tout en continuant à traiter les flux précédemment établis. Cela permet des actions administratives, comme la maintenance du serveur.

Il existe une condition de concurrence inhérente entre un point de terminaison démarrant de nouveaux flux et le pair distant envoyant une trame GOAWAY. Pour gérer ce cas, le GOAWAY contient l'identifiant de flux du dernier flux initié par le pair qui a été ou pourrait être traité sur le point de terminaison émetteur dans cette connexion. Par exemple, si le serveur envoie une trame GOAWAY, le flux identifié est le flux de numéro le plus élevé initié par le client.

Une fois que le GOAWAY est envoyé, l'émetteur ignorera les trames envoyées sur les flux initiés par le récepteur si le flux a un identifiant supérieur au dernier identifiant de flux inclus. Les récepteurs d'une trame GOAWAY NE DOIVENT PAS ouvrir de flux supplémentaires sur la connexion, bien qu'une nouvelle connexion puisse être établie pour de nouveaux flux.

Si le récepteur du GOAWAY a envoyé des données sur des flux avec un identifiant de flux plus élevé que ce qui est indiqué dans la trame GOAWAY, ces flux ne seront pas ou ne seront pas traités. Le récepteur de la trame GOAWAY peut traiter les flux comme s'ils n'avaient jamais été créés, permettant ainsi à ces flux d'être réessayés ultérieurement sur une nouvelle connexion.

Les points de terminaison DEVRAIENT toujours envoyer une trame GOAWAY avant de fermer une connexion afin que le pair 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 serveur n'envoie pas de trame GOAWAY pour indiquer quels flux il aurait pu traiter.

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

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

GOAWAY Frame {
  Length (24),
  Type (8) = 0x07,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31) = 0,

  Reserved (1),
  Last-Stream-ID (31),
  Error Code (32),
  Additional Debug Data (..),
}

Figure 10 : Format de la Trame GOAWAY

Les champs Length, Type, Unused Flag(s), Reserved et Stream Identifier sont décrits dans la section 4.

La trame GOAWAY ne définit aucun drapeau.

La trame GOAWAY s'applique à la connexion, pas à un flux spécifique. Un point de terminaison DOIT traiter une trame GOAWAY avec un identifiant de flux autre que 0x00 comme une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

Le dernier identifiant de flux dans la trame GOAWAY contient l'identifiant de flux de numéro le plus élevé pour lequel l'émetteur de la trame GOAWAY aurait pu prendre une action ou pourrait encore prendre une action. Tous les flux jusqu'à et y compris le flux identifié auraient pu être traités 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é.

| Note : Dans ce contexte, « traité » signifie que certaines données du flux ont été | transmises à une couche supérieure du logiciel qui aurait pu prendre une action en | conséquence.

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

Sur les flux avec des identifiants de numéro inférieur ou égal qui n'ont pas été fermés complètement avant que la connexion ne soit fermée, retenter les demandes, les transactions ou toute activité de protocole n'est pas possible, sauf pour les actions idempotentes comme HTTP GET, PUT ou DELETE. Toute activité de protocole qui utilise des flux de numéro supérieur peut être réessayée en toute sécurité en utilisant une nouvelle connexion.

L'activité sur les flux numérotés inférieurs ou égaux au dernier identifiant de flux peut toujours se terminer avec succès. L'émetteur d'une trame GOAWAY peut gracieusement arrêter une connexion en envoyant une trame GOAWAY, en maintenant la connexion dans un état « open » jusqu'à ce que tous les flux en cours se terminent.

Un point de terminaison 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 gracieux pourrait par la suite rencontrer une condition nécessitant une terminaison immédiate de la connexion. Le dernier identifiant de flux de la dernière trame GOAWAY reçue indique quels flux auraient pu être traités. Les points de terminaison NE DOIVENT PAS augmenter la valeur qu'ils envoient dans le dernier identifiant de flux, car les pairs auraient peut-être déjà réessayé les demandes non traitées sur une autre connexion.

Un client qui ne peut pas réessayer les demandes perd toutes les demandes en cours lorsque le serveur ferme la connexion. Cela est particulièrement vrai pour les intermédiaires qui pourraient ne pas servir les clients en utilisant HTTP/2. Un serveur qui tente d'arrêter gracieusement une connexion DEVRAIT envoyer une trame GOAWAY initiale avec le dernier identifiant de flux défini sur 2^31-1 et un code NO_ERROR. Cela signale au client qu'un arrêt est imminent et que l'initiation de demandes supplémentaires est interdite. Après avoir laissé le temps pour toute création de flux en cours (au moins un temps d'aller-retour), le serveur PEUT envoyer une autre trame GOAWAY avec un dernier identifiant de flux mis à jour. Cela garantit qu'une connexion peut être arrêtée proprement sans perdre de demandes.

Après avoir envoyé une trame GOAWAY, l'émetteur peut supprimer les trames pour les flux initiés par le récepteur avec des identifiants supérieurs au dernier flux identifié. Cependant, toutes les trames qui modifient l'état de la connexion ne peuvent pas être complètement ignorées. Par exemple, les trames HEADERS, PUSH_PROMISE et CONTINUATION DOIVENT être traitées au minimum pour garantir que l'état maintenu pour la compression de la section de champs est cohérent (voir la section 4.3) ; de même, les trames DATA DOIVENT être comptées dans la fenêtre de contrôle de flux de la connexion. L'échec du traitement de ces trames peut entraîner la désynchronisation du contrôle de flux ou de l'état de compression de la section de champs.

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

Les points de terminaison PEUVENT ajouter des données opaques à la charge utile de toute trame GOAWAY. Des données de débogage supplémentaires sont destinées uniquement à des fins de diagnostic et ne portent aucune valeur sémantique. Les données de débogage pourraient contenir des données sensibles à la sécurité ou à la confidentialité. Les données de débogage enregistrées ou stockées de manière persistante DOIVENT avoir des protections adéquates pour empêcher l'accès non autorisé.

6.9. WINDOW_UPDATE​

La trame WINDOW_UPDATE (type=0x08) 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 l'ensemble de 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 transmettent pas les trames WINDOW_UPDATE entre les connexions dépendantes. Cependant, la limitation du transfert de données par n'importe quel récepteur peut indirectement provoquer la propagation des informations de contrôle de flux vers l'émetteur d'origine.

Le contrôle de flux ne s'applique qu'aux trames identifiées comme étant soumises au contrôle de flux. Parmi les types de trames définis dans ce document, cela inclut uniquement les trames DATA. Les trames qui sont exemptées du contrôle de flux DOIVENT être acceptées et traitées, à moins que le récepteur ne soit incapable d'allouer des ressources pour gérer la trame. Un récepteur PEUT répondre par une erreur de flux (section 5.4.2) ou une erreur de connexion (section 5.4.1) de type FLOW_CONTROL_ERROR s'il est incapable d'accepter une trame.

WINDOW_UPDATE Frame {
  Length (24) = 0x04,
  Type (8) = 0x08,

  Unused Flags (8),

  Reserved (1),
  Stream Identifier (31),

  Reserved (1),
  Window Size Increment (31),
}

Figure 11 : Format de la Trame WINDOW_UPDATE

Les champs Length, Type, Unused Flag(s), Reserved et Stream Identifier sont décrits dans la section 4. La charge utile d'une trame WINDOW_UPDATE est un bit réservé plus un entier non signé de 31 bits indiquant le nombre d'octets que l'émetteur 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 est de 1 à 2^31-1 (2 147 483 647) octets.

La trame WINDOW_UPDATE ne définit aucun drapeau.

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

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

WINDOW_UPDATE peut être envoyé par un pair qui a envoyé une trame avec le drapeau END_STREAM défini. Cela signifie qu'un récepteur pourrait recevoir une trame WINDOW_UPDATE sur un flux dans un état « half-closed (remote) » ou « closed ». 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 de sa contribution à la fenêtre de contrôle de flux de la connexion, à moins que le récepteur ne traite cela comme une erreur de connexion (section 5.4.1). Cela est nécessaire même si la trame est en erreur. L'émetteur compte la trame dans 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 au niveau de l'émetteur et du récepteur peut devenir différente.

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. The Flow-Control Window (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 émetteur sur chaque flux. La fenêtre de contrôle de flux est une simple valeur entière qui indique combien d'octets de données l'émetteur est autorisé à transmettre ; en tant que telle, sa taille est une mesure de la capacité de mise en mémoire tampon du récepteur.

Deux fenêtres de contrôle de flux sont applicables : la fenêtre de contrôle de flux du flux et la fenêtre de contrôle de flux de la connexion. L'émetteur NE DOIT PAS envoyer une trame contrôlée par le flux d'une longueur qui dépasse l'espace disponible dans l'une ou l'autre des fenêtres de contrôle de flux annoncées par le récepteur. Les trames de longueur nulle avec le drapeau END_STREAM défini (c'est-à-dire une trame DATA vide) PEUVENT être envoyées s'il n'y a pas d'espace disponible dans l'une ou l'autre fenêtre 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 compté.

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

Le récepteur d'une trame envoie une trame WINDOW_UPDATE lorsqu'il consomme des données et libère de l'espace dans les fenêtres de contrôle de flux. Des trames WINDOW_UPDATE séparées sont envoyées pour les fenêtres de contrôle de flux au niveau du flux et de la connexion. Les récepteurs sont invités à mettre en place des mécanismes pour éviter d'envoyer des trames WINDOW_UPDATE avec des incréments très petits ; voir la section 4.2.3.3 de [RFC1122].

Un émetteur qui reçoit une trame WINDOW_UPDATE met à jour la fenêtre correspondante du montant spécifié dans la trame.

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

Les trames contrôlées par le flux de l'émetteur et les trames WINDOW_UPDATE du récepteur sont complètement asynchrones l'une par rapport à l'autre. Cette propriété permet à un récepteur de mettre à jour agressivement la taille de la fenêtre conservée par l'émetteur pour empêcher les flux de caler.

6.9.2. Initial Flow-Control Window Size (Taille Initiale de la Fenêtre de Contrôle de Flux)​

Lorsqu'une connexion HTTP/2 est établie pour la première fois, les nouveaux flux sont créés 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 la connexion est également de 65 535 octets. Les deux points de terminaison peuvent ajuster la taille de fenêtre initiale pour les nouveaux flux en incluant une valeur pour SETTINGS_INITIAL_WINDOW_SIZE dans la trame SETTINGS. La fenêtre de contrôle de flux de la connexion 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 taille de fenêtre initiale par défaut lors de l'envoi de trames contrôlées par le flux. De même, la fenêtre de contrôle de flux de la connexion est définie en fonction de la taille de fenêtre initiale par défaut 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 ne sont pas encore actifs, une trame SETTINGS peut modifier la taille de fenêtre de contrôle de flux initiale pour les flux avec des fenêtres de contrôle de flux actives (c'est-à-dire les flux dans l'état « open » ou « half-closed (remote) »). Lorsque 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 la différence entre la nouvelle valeur et l'ancienne valeur.

Un changement de SETTINGS_INITIAL_WINDOW_SIZE peut faire en sorte que l'espace disponible dans une fenêtre de contrôle de flux devienne négatif. Un émetteur DOIT suivre la fenêtre de contrôle de flux négative et NE DOIT PAS envoyer de nouvelles trames contrôlées par le flux tant qu'il ne reçoit pas de trames WINDOW_UPDATE qui rendent la fenêtre de contrôle de flux positive.

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

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

Un point de terminaison DOIT traiter un changement de SETTINGS_INITIAL_WINDOW_SIZE qui fait dépasser la taille maximale à n'importe quelle fenêtre de contrôle de flux comme une erreur de connexion (section 5.4.1) de type FLOW_CONTROL_ERROR.

6.9.3. Reducing the Stream Window Size (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 la taille actuelle peut envoyer une nouvelle trame SETTINGS. Cependant, le récepteur DOIT être prêt à recevoir des données qui dépassent cette taille de fenêtre, car l'émetteur pourrait envoyer des données qui dépassent la limite inférieure avant de traiter la trame SETTINGS.

Après avoir envoyé une trame SETTINGS qui réduit la taille de fenêtre de contrôle de flux initiale, un récepteur PEUT continuer à traiter les flux qui dépassent les limites de contrôle de flux. Permettre aux flux de continuer n'autorise pas le récepteur à réduire immédiatement l'espace qu'il réserve pour les fenêtres de contrôle de flux. La progression sur ces flux peut également caler, car des trames WINDOW_UPDATE sont nécessaires pour permettre à l'émetteur de reprendre l'envoi. Le récepteur PEUT plutôt envoyer un RST_STREAM avec un code d'erreur de FLOW_CONTROL_ERROR pour les flux affectés.

6.10. CONTINUATION​

La trame CONTINUATION (type=0x09) est utilisée pour continuer une séquence de fragments de bloc de champs (section 4.3). N'importe quel nombre de trames CONTINUATION peut être envoyé, tant que la trame précédente est sur le même flux et est une trame HEADERS, PUSH_PROMISE ou CONTINUATION sans le drapeau END_HEADERS défini.

CONTINUATION Frame {
  Length (24),
  Type (8) = 0x09,

  Unused Flags (5),
  END_HEADERS Flag (1),
  Unused Flags (2),

  Reserved (1),
  Stream Identifier (31),

  Field Block Fragment (..),
}

Figure 12 : Format de la Trame CONTINUATION

Les champs Length, Type, Unused Flag(s), Reserved et Stream Identifier sont décrits dans la section 4. La charge utile de la trame CONTINUATION contient un fragment de bloc de champs (section 4.3).

La trame CONTINUATION définit le drapeau suivant :

END_HEADERS (0x04) : Lorsqu'il est défini, le drapeau END_HEADERS indique que cette trame termine un bloc de champs (section 4.3).

Si le drapeau END_HEADERS n'est pas défini, cette trame DOIT être suivie d'une autre trame CONTINUATION. Un récepteur DOIT traiter la réception de tout autre type de trame ou d'une trame sur un flux différent comme une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

La trame CONTINUATION modifie l'état de la connexion comme défini dans la section 4.3.

Les trames CONTINUATION DOIVENT être associées à un flux. Si une trame CONTINUATION est reçue avec un champ Stream Identifier de 0x00, le destinataire DOIT répondre par une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR.

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

Chapitre 6 terminé !

Dernière mise à jour le