2. Datagrammes HTTP (HTTP Datagrams)

Les datagrammes HTTP (HTTP Datagrams) sont une convention pour transporter des datagrammes bidirectionnels et potentiellement non fiables à l'intérieur d'une connexion HTTP avec multiplexage lorsque cela est possible. Tous les datagrammes HTTP sont associés à une requête HTTP.

Lorsque les datagrammes HTTP sont transportés sur une connexion HTTP/3, la trame QUIC DATAGRAM peut être utilisée pour fournir le démultiplexage et la livraison non fiable ; voir la section 2.1. La négociation de l'utilisation des trames QUIC DATAGRAM pour les datagrammes HTTP est réalisée via l'échange de paramètres HTTP/3 ; voir la section 2.1.1.

Lors de l'exécution sur HTTP/2, le démultiplexage est fourni par la couche de tramage HTTP/2, mais la livraison non fiable n'est pas disponible. Les datagrammes HTTP sont négociés et transportés en utilisant le protocole Capsule ; voir la section 3.5.

Lors de l'exécution sur HTTP/1.x, les requêtes sont strictement sérialisées dans la connexion ; par conséquent, le démultiplexage n'est pas disponible. La livraison non fiable n'est également pas disponible. Les datagrammes HTTP sont négociés et transportés en utilisant le protocole Capsule ; voir la section 3.5.

Les datagrammes HTTP doivent (MUST) uniquement être envoyés avec une association à une requête HTTP qui les prend explicitement en charge. Par exemple, les méthodes HTTP existantes GET et POST ne définissent pas de sémantique pour les datagrammes HTTP associés ; par conséquent, les datagrammes HTTP associés aux flux de requêtes GET ou POST ne peuvent pas être envoyés.

Si un datagramme HTTP est reçu et qu'il est associé à une requête qui n'a pas de sémantique connue pour les datagrammes HTTP, le récepteur doit (MUST) terminer la requête. Si HTTP/3 est utilisé, le flux de requête doit (MUST) être interrompu avec H3_DATAGRAM_ERROR (0x33). Les extensions HTTP peuvent (MAY) remplacer ces exigences en définissant un mécanisme de négociation et une sémantique pour les datagrammes HTTP.

2.1. Datagrammes HTTP/3 (HTTP/3 Datagrams)

Lorsqu'il est utilisé avec HTTP/3, le champ Datagram Data des trames QUIC DATAGRAM utilise le format suivant :

HTTP/3 Datagram {
  Quarter Stream ID (i),
  HTTP Datagram Payload (..),
}

Figure 1 : Format du datagramme HTTP/3

Quarter Stream ID : Un entier de longueur variable qui contient la valeur du flux bidirectionnel initié par le client auquel ce datagramme est associé, divisée par quatre (la division par quatre découle du fait que les requêtes HTTP sont envoyées sur des flux bidirectionnels initiés par le client, qui ont des ID de flux divisibles par quatre). La plus grande valeur légale d'ID de flux QUIC est 2^62-1, donc la plus grande valeur légale du champ Quarter Stream ID est 2^60-1. La réception d'un datagramme HTTP/3 qui inclut une valeur plus grande doit (MUST) être traitée comme une erreur de connexion HTTP/3 de type H3_DATAGRAM_ERROR (0x33).

HTTP Datagram Payload : La charge utile du datagramme, dont la sémantique est définie par l'extension qui utilise les datagrammes HTTP. Notez que ce champ peut être vide.

La réception d'une trame QUIC DATAGRAM dont la charge utile est trop courte pour permettre l'analyse du champ Quarter Stream ID doit (MUST) être traitée comme une erreur de connexion HTTP/3 de type H3_DATAGRAM_ERROR (0x33).

Les datagrammes HTTP/3 ne doivent pas (MUST NOT) être envoyés à moins que le côté envoi du flux correspondant ne soit ouvert. Si un datagramme est reçu après que le côté réception du flux correspondant est fermé, les datagrammes reçus doivent (MUST) être abandonnés silencieusement.

Si un datagramme HTTP/3 est reçu et que son champ Quarter Stream ID correspond à un flux qui n'a pas encore été créé, le récepteur doit (SHALL) soit abandonner ce datagramme silencieusement, soit le mettre temporairement en mémoire tampon (de l'ordre d'un aller-retour) en attendant la création du flux correspondant.

Si un datagramme HTTP/3 est reçu et que son champ Quarter Stream ID correspond à un flux qui ne peut pas être créé en raison des limites de flux bidirectionnels initiés par le client, il devrait (SHOULD) être traité comme une erreur de connexion HTTP/3 de type H3_ID_ERROR. La génération d'une erreur n'est pas obligatoire car la limite de flux QUIC peut être inconnue de la couche HTTP/3.

La priorisation des datagrammes HTTP/3 n'est pas définie dans ce document. Les extensions futures peuvent (MAY) définir comment prioriser les datagrammes et peuvent (MAY) définir une signalisation pour permettre la communication des préférences de priorisation.

2.1.1. Le paramètre HTTP/3 SETTINGS_H3_DATAGRAM

Un point de terminaison peut indiquer à son pair qu'il est prêt à recevoir des datagrammes HTTP/3 en envoyant le paramètre SETTINGS_H3_DATAGRAM (0x33) avec une valeur de 1.

La valeur du paramètre SETTINGS_H3_DATAGRAM doit (MUST) être soit 0 soit 1. Une valeur de 0 indique que l'implémentation n'est pas disposée à recevoir des datagrammes HTTP. Si le paramètre SETTINGS_H3_DATAGRAM est reçu avec une valeur qui n'est ni 0 ni 1, le récepteur doit (MUST) terminer la connexion avec l'erreur H3_SETTINGS_ERROR.

Les trames QUIC DATAGRAM ne doivent pas (MUST NOT) être envoyées tant que le paramètre SETTINGS_H3_DATAGRAM n'a pas été à la fois envoyé et reçu avec une valeur de 1.

Lorsque les clients utilisent 0-RTT, ils peuvent (MAY) stocker la valeur du paramètre SETTINGS_H3_DATAGRAM du serveur. Cela permet au client d'envoyer des trames QUIC DATAGRAM dans des paquets 0-RTT. Lorsque les serveurs décident d'accepter les données 0-RTT, ils doivent (MUST) envoyer un paramètre SETTINGS_H3_DATAGRAM supérieur ou égal à la valeur qu'ils ont envoyée au client dans la connexion où ils leur ont envoyé le message NewSessionTicket. Si un client stocke la valeur du paramètre SETTINGS_H3_DATAGRAM avec son état 0-RTT, il doit (MUST) valider que la nouvelle valeur du paramètre SETTINGS_H3_DATAGRAM envoyée par le serveur lors de la poignée de main est supérieure ou égale à la valeur stockée ; sinon, le client doit (MUST) terminer la connexion avec l'erreur H3_SETTINGS_ERROR. Dans tous les cas, la valeur maximale autorisée du paramètre SETTINGS_H3_DATAGRAM est 1.

Il est recommandé (RECOMMENDED) que les implémentations qui prennent en charge la réception de datagrammes HTTP/3 envoient toujours le paramètre SETTINGS_H3_DATAGRAM avec une valeur de 1, même si l'application n'a pas l'intention d'utiliser les datagrammes HTTP/3. Cela aide à éviter de « se démarquer » ; voir la section 4.

2.2. Datagrammes HTTP utilisant les Capsules (HTTP Datagrams Using Capsules)

Lorsque les datagrammes HTTP/3 ne sont pas disponibles ou ne sont pas souhaitables, les datagrammes HTTP peuvent être envoyés en utilisant le protocole Capsule ; voir la section 3.5.

---