1. Introduction
Les extensions HTTP (telles que définies dans la section 16 de [HTTP]) doivent parfois accéder aux fonctionnalités du protocole de transport sous-jacent, telles que la livraison non fiable (offerte par [QUIC-DGRAM]), pour activer des fonctionnalités souhaitables. Par exemple, cela pourrait permettre l'introduction d'une version non fiable de la méthode CONNECT et l'ajout de la livraison non fiable aux WebSockets [WEBSOCKET].
Dans la section 2, ce document décrit les datagrammes HTTP (HTTP Datagrams), une convention pour transporter des datagrammes bidirectionnels et potentiellement non fiables à l'intérieur d'une connexion HTTP, avec multiplexage lorsque cela est possible. Bien que les datagrammes HTTP soient associés à des requêtes HTTP, ils ne font pas partie du contenu du message. Au lieu de cela, ils sont destinés à être utilisés par les extensions HTTP (telles que la méthode CONNECT) et sont compatibles avec toutes les versions de HTTP.
Lorsque HTTP s'exécute sur un protocole de transport qui prend en charge la livraison non fiable (par exemple lorsque l'extension QUIC DATAGRAM [QUIC-DGRAM] est disponible pour HTTP/3 [HTTP/3]), les datagrammes HTTP peuvent utiliser cette capacité.
Dans la section 3, ce document décrit le protocole Capsule HTTP (HTTP Capsule Protocol), qui permet le transport de datagrammes HTTP en utilisant une livraison fiable. Cela répond aux cas HTTP/3 où l'utilisation de la trame QUIC DATAGRAM n'est pas disponible ou n'est pas souhaitable, ou lorsque le protocole de transport ne fournit qu'une livraison fiable, comme avec HTTP/1.1 [HTTP/1.1] ou HTTP/2 [HTTP/2] sur TCP [TCP].
1.1. Conventions et définitions (Conventions and Definitions)
Les mots-clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « NOT RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans le BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.
Ce document utilise la terminologie de [QUIC].
Lorsque ce document définit des types de protocole, le format de définition utilise la notation de la section 1.3 de [QUIC]. Lorsque les champs des types sont des entiers, ils sont encodés en utilisant l'encodage d'entier de longueur variable de la section 16 de [QUIC]. Les valeurs entières n'ont pas besoin d'être encodées sur le nombre minimum d'octets nécessaires.
Dans ce document, le terme « intermédiaire » (intermediary) fait référence à un intermédiaire HTTP tel que défini dans la section 3.7 de [HTTP].