8. Expressing HTTP Semantics in HTTP/2 (Expression de la Sémantique HTTP dans HTTP/2)

HTTP/2 vise à être aussi compatible que possible avec les utilisations actuelles de HTTP. Cela signifie que, du point de vue de l'application, les fonctionnalités du protocole restent largement inchangées. Pour y parvenir, toutes les sémantiques de requête et de réponse sont préservées grâce aux mécanismes de HTTP/1.1 [HTTP], bien que la syntaxe de transmission de ces sémantiques ait changé.

Ainsi, la spécification et les exigences de HTTP [HTTP], la sémantique et la syntaxe, ainsi que les extensions telles que [COOKIES], s'appliquent à HTTP/2. Les restrictions et exigences supplémentaires décrites dans cette section se limitent à celles nécessaires pour une mise en œuvre réussie de HTTP/2, qui concernent le format de transmission HTTP ou qui, en l'absence de définition supplémentaire dans HTTP/2, entraîneraient une ambiguïté.

8.1. HTTP Message Framing (Tramage des Messages HTTP)

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

1. pour une réponse uniquement, zéro ou plusieurs trames HEADERS (chacune suivie de zéro ou plusieurs trames CONTINUATION) contenant les en-têtes de message des réponses HTTP informationnelles (1xx) (voir Section 15 de [HTTP]), et/ou

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

3. zéro ou plusieurs trames DATA contenant le contenu du message (voir Section 6.4 de [HTTP]), et

4. éventuellement, une trame HEADERS (suivie de zéro ou plusieurs trames CONTINUATION) contenant la section de champ trailer-part (voir Section 6.5 de [HTTP]).

La dernière trame de la séquence porte un drapeau END_STREAM, en notant qu'une trame HEADERS portant le drapeau END_STREAM peut être suivie de trames CONTINUATION qui transportent toute portion restante du bloc d'en-tête. D'autres trames (de n'importe quel flux) NE DOIVENT PAS se produire entre la trame HEADERS et les trames CONTINUATION qui pourraient suivre.

HTTP/2 utilise des trames DATA pour transporter le contenu du message. Le codage de transfert [CHUNKED] (défini dans la Section 7.1 de [HTTP]) NE DOIT PAS être utilisé avec HTTP/2.

Les champs de trailer sont transportés dans une section de champ ; voir Section 8.2. Il n'y a pas de nom de section de champ défini pour les champs de trailer car tous les champs de trailer sont encodés dans la même section de champ dans HTTP/2. Il n'y a pas d'ordre défini entre les lignes de champ ; voir Section 8.2.1. Enfin, les champs de trailer n'incluent pas de champs pseudo-header (voir Section 8.3).

Une requête ou réponse HTTP est mal formée si elle est l'une des suivantes :

• Elle contient une ligne de champ avec un nom de champ invalide (voir Section 5.1 de [HTTP]), une ligne de champ avec une valeur de ligne de champ invalide (voir Section 5.5 de [HTTP]), ou un champ pseudo-header qui n'est pas autorisé à apparaître dans ce contexte (voir Section 8.3),

• Elle omet un champ pseudo-header requis pour ce type de message (voir Section 8.3),

• Elle contient des caractères majuscules dans les noms de ligne de champ, ou

• Elle contient une valeur de champ Content-Length invalide.

La gestion des erreurs pour les flux est décrite dans Section 8.1.1.

En plus des parties obligatoires d'un message, les informations PRIORITY peuvent être présentes dans les trames HEADERS. Voir Section 5.3 pour plus d'informations.

La réception d'une trame HEADERS contenant un bloc de champ invalide entraîne une erreur de flux (voir Section 5.4.2).

8.1.1. Malformed Messages (Messages Mal Formés)

Un message mal formé est un message qui est une séquence de trames par ailleurs valide mais est invalide en raison de la présence de champs interdits, de l'absence de champs requis ou de valeurs de champ invalides. Un pair qui détecte une requête ou réponse mal formée DOIT répondre par une erreur de flux (voir Section 5.4.2). Pour les requêtes mal formées, un serveur PEUT envoyer une réponse HTTP avant de fermer ou réinitialiser le flux. Les clients NE DOIVENT PAS accepter une réponse mal formée. Notez que ces exigences visent à protéger contre plusieurs types d'attaques courantes ; elles sont délibérément strictes car être permissif peut exposer les implémentations à ces vulnérabilités.

8.2. HTTP Fields (Champs HTTP)

Les noms et valeurs de champs HTTP sont des séquences d'octets et sont utilisés avec le même encodage que celui utilisé dans HTTP/1.x (voir Section 5.1 de [HTTP]). Cependant, les noms de champs DOIVENT être convertis en minuscules avant leur encodage dans HTTP/2. Une requête ou réponse contenant des caractères de nom de champ en majuscules DOIT être traitée comme mal formée (Section 8.1.1).

HTTP/2 n'utilise pas le champ d'en-tête Connection (voir Section 7.6.1 de [HTTP]) pour indiquer les champs spécifiques à la connexion ; dans ce protocole, les métadonnées spécifiques à la connexion sont transmises par d'autres moyens. Un point de terminaison NE DOIT PAS générer de message HTTP/2 contenant des champs spécifiques à la connexion ; tout message contenant des champs spécifiques à la connexion DOIT être traité comme mal formé (Section 8.1.1).

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

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

| Note : HTTP/2 ne prend délibérément pas en charge la mise à niveau vers un autre | protocole. Les méthodes de négociation décrites dans Section 3 | sont considérées comme suffisantes pour négocier l'utilisation de protocoles alternatifs.

8.2.1. Field Validity (Validité des Champs)

Les noms de champs sont validés selon les règles de la Section 5.1 de [HTTP], mais convertis en minuscules avant la représentation dans HTTP/2.

Une section de champ compressée à l'aide de [COMPRESSION] peut contenir des espaces blancs tels que définis par la production "optional whitespace" (OWS) ; les espaces blancs ne font pas partie du champ ; ils DOIVENT être supprimés lors de la décompression ou avant de transmettre le message à un contexte non-HTTP/2, tel qu'une connexion HTTP/1.1, ou une application serveur HTTP générique.

Les valeurs des champs pseudo-header sont spécifiées dans Section 8.3.

8.2.2. Connection-Specific Header Fields (Champs d'En-tête Spécifiques à la Connexion)

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

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

8.2.3. Compressing the Cookie Header Field (Compression du Champ d'En-tête Cookie)

Le champ d'en-tête Cookie [COOKIES] utilise un point-virgule (";") pour délimiter les paires de cookies (ou "crumbs"). Ce champ d'en-tête ne suit pas les règles de liste (voir Section 5.3 de [HTTP]) de séparation par virgule, ce qui peut empêcher les paires de cookies d'être compressées efficacement. Étant donné que le champ d'en-tête Cookie peut souvent contenir une quantité relativement importante de données, cela peut dégrader significativement l'efficacité de la compression.

Pour permettre une meilleure compression, le champ d'en-tête Cookie PEUT être divisé en champs d'en-tête séparés, chacun avec une ou plusieurs paires de cookies. 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 de deux octets 0x3B, 0x20 (la chaîne ASCII "; ") avant d'être transmis dans un contexte non-HTTP/2, tel qu'une connexion HTTP/1.1, 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 équivalentes.

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

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

8.3. HTTP Control Data (Données de Contrôle HTTP)

HTTP/2 utilise des champs pseudo-header spéciaux commençant par le caractère ':' (ASCII 0x3a) pour transmettre des informations sur la requête ou la réponse qui, dans HTTP/1.x, étaient transportées dans la ligne de début du message. Les champs pseudo-header ne sont pas des champs HTTP. Les points de terminaison NE DOIVENT PAS générer de champs pseudo-header autres que ceux définis dans ce document.

Les champs pseudo-header ne sont valides que dans la section de champ d'une trame HEADERS et PUSH_PROMISE. Cependant, une section de champ transportant des champs de trailer NE DOIT PAS contenir de champs pseudo-header ; une section de champ trailer-part contenant des champs pseudo-header DOIT être traitée comme mal formée (Section 8.1.1).

Les champs pseudo-header commencent par un caractère ':' (ASCII 0x3a). Leurs noms sont des noms de champs qui ne consistent qu'en ce préfixe ; les deux-points ne font pas partie du nom du champ. Les deux-points ne font pas partie de l'ensemble de tokens utilisé pour les noms de champs (voir Section 5.1 de [HTTP]).

Tous les champs pseudo-header DOIVENT apparaître avant tous les champs réguliers. Toute requête ou réponse qui contient un champ pseudo-header qui apparaît après un champ régulier DOIT être traitée comme mal formée (Section 8.1.1).

Les champs pseudo-header suivants sont définis :

8.3.1. Request Pseudo-Header Fields (Champs Pseudo-Header de Requête)

Les champs pseudo-header suivants sont définis pour les requêtes HTTP/2 :

• Le champ pseudo-header :method contient la méthode HTTP (Section 9 de [HTTP]).

• Le champ pseudo-header :scheme contient la partie schéma de l'URI cible (Section 3.1 de [URI]).

  Le :scheme n'est pas limité aux URI schématisés "http" et "https". Un proxy ou une passerelle peut traduire des requêtes pour des schémas non-HTTP, permettant l'utilisation de HTTP pour interagir avec des services non-HTTP.

  Voir Section 8.5 pour la méthode CONNECT, qui omet le champ pseudo-header :scheme.

• Le champ pseudo-header :authority contient la partie autorité de l'URI cible (Section 3.2 de [URI]). L'autorité NE DOIT PAS inclure le sous-composant userinfo obsolète pour les URI schématisés "http" ou "https".

  Pour garantir que la ligne de requête HTTP/1.1 peut être reproduite avec précision, ce champ pseudo-header DOIT être omis lors de la traduction d'une requête HTTP/1.1 qui a une cible de requête sous forme d'origine ou d'astérisque (voir Section 3.2 de [HTTP]). Les clients qui génèrent directement des requêtes HTTP/2 DOIVENT utiliser le champ pseudo-header :authority au lieu du champ Host. Un intermédiaire qui convertit une requête HTTP/2 en HTTP/1.1 DOIT créer un champ Host s'il n'est pas présent dans une requête en copiant la valeur du champ pseudo-header :authority.

  Un serveur DEVRAIT traiter une requête comme mal formée si elle contient à la fois le champ pseudo-header :authority et le champ Host, si les valeurs des champs ne sont pas identiques.

• Le champ pseudo-header :path contient les parties chemin et requête de l'URI cible (la production absolute-path et éventuellement un caractère '?' suivi de la production query (voir Sections 3.3 et 3.4 de [URI])). Une requête sous forme d'astérisque inclut la valeur '*' pour le champ pseudo-header :path.

  Ce champ pseudo-header NE DOIT PAS être vide pour les URI "http" ou "https" ; les URI "http" ou "https" qui ne contiennent pas de composant de chemin DOIVENT inclure une valeur de '/', sauf si la requête est faite sous forme d'astérisque, auquel cas elle DOIT contenir une valeur de '*'.

  Voir Section 8.5 pour la méthode CONNECT, qui omet le champ pseudo-header :path.

Toutes les requêtes HTTP/2 DOIVENT inclure exactement une valeur valide pour les champs pseudo-header :method et :scheme, sauf s'il s'agit d'une requête CONNECT (Section 8.5).

Si le champ pseudo-header :scheme identifie un schéma qui utilise une autorité (voir Section 3.2 de [URI]), alors une requête HTTP/2 qui ne contient pas la cible de requête DOIT inclure soit le champ :authority soit le champ Host. Si ces champs sont absents, le serveur recevant la requête DEVRAIT répondre avec un code d'état 400 (Bad Request) (voir Section 15.5.1 de [HTTP]).

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

8.3.2. Response Pseudo-Header Fields (Champs Pseudo-Header de Réponse)

Pour les réponses HTTP/2, un seul champ pseudo-header :status est défini qui transporte le champ de code d'état HTTP (voir Section 15 de [HTTP]). Ce champ pseudo-header DOIT être inclus dans toutes les réponses ; sinon, la réponse est mal formée (Section 8.1.1).

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

8.4. Server Push (Push Serveur)

HTTP/2 permet à un serveur d'envoyer (ou de "pousser") de manière préemptive des réponses à un client en association avec une requête précédente initiée par le client. Cela peut être utile lorsque le serveur sait que le client aura besoin de ces réponses disponibles pour traiter complètement la réponse à la requête d'origine.

Une réponse poussée est toujours associée à une requête explicite du client. Le serveur envoie une trame PUSH_PROMISE sur le flux de cette requête. La trame PUSH_PROMISE inclut une section de champ qui contient un ensemble complet de champs de requête que le serveur attribue à la requête.

Il n'y a pas de limite au nombre de réponses qui peuvent être poussées par un serveur, en dehors des identifiants de flux disponibles sur une seule connexion. Cependant, un client peut limiter le nombre de flux poussés simultanément en modifiant le paramètre SETTINGS_MAX_CONCURRENT_STREAMS. Définir cette valeur à zéro désactive le push serveur en empêchant le serveur de créer les flux nécessaires. Cela n'empêche pas un serveur d'envoyer des trames PUSH_PROMISE ; les clients doivent réinitialiser tous les flux promis non désirés.

8.4.1. Push Requests (Requêtes Push)

Le push serveur est sémantiquement équivalent à un serveur répondant à une requête ; cependant, dans ce cas, cette requête est également envoyée par le serveur, sous forme de trame PUSH_PROMISE.

La trame PUSH_PROMISE inclut une section de champ qui contient un ensemble complet de champs de requête que le serveur attribue à la requête. Il n'est pas possible de pousser une réponse à une requête qui inclut un corps de requête, sauf dans le cas où la connexion HTTP/2 a été initiée sur TLS (voir [TLS13]).

Les requêtes poussées DOIVENT être mises en cache (voir Section 9.2.3 de [HTTP]), DOIVENT être sûres (voir Section 9.2.1 de [HTTP]), et NE DOIVENT PAS inclure de contenu de requête. Les clients qui reçoivent une requête poussée qui n'est pas mise en cache, n'est pas sûre ou qui inclut du contenu de requête DOIVENT réinitialiser le flux promis avec une erreur de flux (Section 5.4.2) de type PROTOCOL_ERROR.

Les champs de requête poussée et les champs pseudo-header de requête DOIVENT être autoritaires (voir Section 10.1). Le serveur DOIT inclure une valeur dans le champ pseudo-header :authority pour laquelle le serveur est autoritaire (voir Section 10.1). Un client DOIT traiter une requête poussée qui n'est pas autoritaire comme une erreur de flux (Section 5.4.2) de type PROTOCOL_ERROR.

Un client peut signaler qu'il ne souhaite pas recevoir une réponse poussée en envoyant un RST_STREAM au serveur, référençant l'identifiant de flux promis.

Un serveur DEVRAIT uniquement pousser des réponses qu'il croit que le client utilisera ou dont il bénéficiera autrement. Le serveur DEVRAIT considérer le contenu de requête possible, tous les champs de cache dans la requête, la méthode de la requête et tout contenu connu pour être géré par le client (basé, par exemple, sur les Cookies reçus sur des requêtes antérieures) lors de la décision de ce qu'il faut pousser.

8.4.2. Push Responses (Réponses Push)

Après avoir envoyé une trame PUSH_PROMISE qui référence le flux promis, le serveur peut commencer à livrer la réponse poussée sur un flux utilisant l'identifiant de flux promis. Le serveur transmet les champs de réponse initiaux en utilisant une trame HEADERS, en utilisant l'identifiant de flux promis. Ce flux entre dans l'état "half-closed (remote)" (Section 5.1). Le serveur DEVRAIT envoyer la réponse qui initie le push avant d'envoyer la trame PUSH_PROMISE pour éviter une condition de concurrence.

Une fois qu'un client reçoit une trame PUSH_PROMISE et choisit d'accepter la réponse poussée, le client NE DEVRAIT PAS émettre de requêtes pour la réponse promise jusqu'à ce que le flux promis soit fermé.

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 de temps pour commencer à envoyer la réponse promise, le client peut envoyer une trame RST_STREAM, en utilisant soit le code CANCEL soit REFUSED_STREAM et en référençant l'identifiant de 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. Annoncer une valeur SETTINGS_MAX_CONCURRENT_STREAMS de zéro désactive le push serveur en empêchant le serveur de créer les flux nécessaires. Cela n'interdit pas à un serveur d'envoyer des trames PUSH_PROMISE ; les clients doivent réinitialiser tous les flux promis qui ne sont pas désirés.

8.5. The CONNECT Method (La Méthode CONNECT)

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

Dans HTTP/2, la méthode CONNECT est utilisée pour établir un tunnel sur un hôte distant à des fins similaires.

Une requête CONNECT DOIT utiliser les champs pseudo-header suivants :

• Le champ pseudo-header :method est défini sur "CONNECT".
• Le champ pseudo-header :authority contient l'hôte et le port à connecter (équivalent à la forme d'autorité de la cible de requête d'une requête CONNECT ; voir Section 3.2 de [HTTP]).

Les champs pseudo-header :scheme et :path DOIVENT être omis.

Une requête CONNECT NE DOIT PAS contenir de champ d'en-tête Content-Length ou Transfer-Encoding. Toute requête CONNECT contenant ces champs est mal formée (Section 8.1.1).

Un flux qui transporte une requête CONNECT n'est pas utilisé pour transmettre des requêtes ou réponses HTTP. Toute réponse CONNECT réussie est utilisée pour notifier le client que le flux est devenu un tunnel. Ce flux n'est pas fermé en recevant une trame DATA avec le drapeau END_STREAM. Le flux de requête CONNECT n'est pas fermé en recevant une trame DATA portant le drapeau END_STREAM.

Un proxy supprime tous les champs d'en-tête connus pour être spécifiques à la connexion (tels que ceux définis dans la Section 7.6.1 de [HTTP]), puis permet aux champs d'en-tête de requête restants de passer inchangés sur la connexion au serveur.

Toute réponse 2xx (Successful) reçue après une requête CONNECT indique que le proxy a établi une connexion à l'hôte et au port demandés et a basculé vers le tunneling du flux correspondant.

Pour toute autre réponse réussie, aucun tunnel n'est créé.

Après qu'un tunnel réussi est établi, le serveur DOIT envoyer une seule trame DATA (avec le drapeau END_STREAM défini) sur le flux de tunnel pour fermer immédiatement le tunnel. Le client DEVRAIT fermer à moitié son flux à l'un ou l'autre des points de terminaison après la fermeture du tunnel, puis fermer son flux après avoir reçu le drapeau END_STREAM du pair.

Une erreur de connexion TCP est signalée par l'un ou l'autre des points de terminaison en utilisant une trame RST_STREAM avec un code d'erreur. Un proxy traite tout code d'erreur qu'il reçoit comme indication d'une erreur de flux (Section 5.4.2) qu'il n'a pas pu compléter avec succès la requête CONNECT. En conséquence, si un proxy détecte une erreur avec la connexion TCP qu'il représente pour un flux de requête CONNECT, il envoie un signal au client de la même manière.

8.6. The Upgrade Header Field (Le Champ d'En-tête Upgrade)

HTTP/2 ne prend pas en charge le code d'état informationnel 101 (Switching Protocols) (Section 15.2.2 de [HTTP]).

La sémantique du champ d'en-tête Upgrade est spécifique au protocole vers lequel on effectue la mise à niveau. Le champ Upgrade dans une connexion directe (Section 9.1.1) ne s'applique qu'au prochain saut. Par conséquent, le champ Upgrade n'est pas applicable à HTTP/2.

Une implémentation qui souhaite effectuer une mise à niveau vers un protocole différent sur une connexion HTTP/2 DEVRAIT utiliser [ALT-SVC].

8.7. Request Reliability (Fiabilité des Requêtes)

En général, un client HTTP ne peut pas réessayer une requête non-idempotente lorsqu'une erreur se produit car il n'y a aucun moyen de déterminer la nature de l'erreur. Il est possible qu'un traitement serveur se soit produit avant l'erreur, ce qui pourrait entraîner des effets indésirables si la requête était réessayée.

Lorsqu'un serveur rejette un flux de requête sans effectuer de traitement d'application, la requête peut être considérée comme sûre à réessayer sur une connexion différente. Un serveur peut indiquer cela en utilisant le code d'erreur REFUSED_STREAM (Section 7) sur une trame RST_STREAM.

Un serveur NE DOIT PAS utiliser le code d'erreur REFUSED_STREAM après avoir effectué un traitement d'application. C'est parce que l'utilisation de REFUSED_STREAM indique que le serveur n'a effectué aucun traitement sur la requête, la rendant sûre à réessayer. Un code d'erreur différent DOIT être utilisé pour les requêtes qui ont été traitées par le serveur de quelque manière que ce soit.

Les clients peuvent réessayer les requêtes qui ont été refusées en utilisant REFUSED_STREAM, même si la requête n'est pas idempotente. Cependant, si le client choisit de réessayer une telle requête, il DOIT supposer que le serveur pourrait avoir traité la requête avant de la refuser. Si le client a réessayé une requête qui n'était pas idempotente, il DEVRAIT inclure un indicateur dans les requêtes suivantes afin que le serveur puisse détecter une requête réessayée.

Une requête PUSH_PROMISE qui contient du contenu non-cacheable n'est pas réessayable. Les requêtes poussées qui sont non-cacheables ou pas sûres ne sont pas autorisées, comme décrit dans Section 8.4.1.

8.8. Examples (Exemples)

Cette section montre des requêtes et réponses HTTP/1.1, avec des illustrations de requêtes et réponses HTTP/2 équivalentes. Une requête et réponse HTTP/2 utilisent la section d'en-tête compressée, qui n'est pas affichée au-dessus de la couche de trame HTTP/2.

8.8.1. Simple Request (Requête Simple)

Une requête GET HTTP/1.1 inclut des champs de requête, une méthode et une cible de requête.

GET /resource HTTP/1.1
Host: example.org
Accept: image/jpeg

La même requête est représentée en utilisant des champs pseudo-header et envoyée comme section de champ dans des trames HEADERS dans HTTP/2 :

:method = GET
:scheme = https
:path = /resource
:authority = example.org
accept = image/jpeg

8.8.2. Simple Response (Réponse Simple)

Une réponse HTTP/1.1 simple inclut un code d'état, des champs de réponse et du contenu de réponse :

HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 123

{binary data}

Dans HTTP/2, le code d'état est représenté en utilisant un champ pseudo-header :

:status = 200
content-type = image/jpeg
content-length = 123

{binary data}

8.8.3. Complex Request (Requête Complexe)

Une requête POST HTTP/1.1 avec des champs optionnels :

POST /resource HTTP/1.1
Host: example.org
Content-Type: image/jpeg
Content-Length: 123

{binary data}

La même requête HTTP/2 :

:method = POST
:scheme = https
:path = /resource
:authority = example.org
content-type = image/jpeg
content-length = 123

{binary data}

8.8.4. Response with Body (Réponse avec Corps)

Une réponse HTTP/1.1, incluant des champs et un corps de réponse :

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 552

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <h1>Example</h1>
    <p>This is an example page.</p>
  </body>
</html>

Dans HTTP/2, en utilisant une section de champ et des trames DATA :

:status = 200
content-type = text/html; charset=utf-8
content-length = 552

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <h1>Example</h1>
    <p>This is an example page.</p>
  </body>
</html>

8.8.5. Informational Responses (Réponses Informationnelles)

HTTP/2 prend en charge les réponses informationnelles (1xx) envoyées en utilisant des trames HEADERS, comme défini dans la Section 15 de [HTTP].

Par exemple, une réponse 100 (Continue) peut être envoyée avant une réponse finale :

:status = 100

:status = 200
content-type = image/jpeg
content-length = 123

{binary data}

---

Chapitre 8 terminé !

References

• [HTTP] RFC 9110
• [COOKIES] RFC 6265
• [COMPRESSION] RFC 7541
• [URI] RFC 3986
• [TLS13] RFC 8446
• [ALT-SVC] RFC 7838