3. Connection Setup and Management (Configuration et gestion de la connexion)
3.1. Discovering an HTTP/3 Endpoint (Découverte d'un point de terminaison HTTP/3)
HTTP repose sur la notion de réponse autoritaire (Authoritative Response) : une réponse qui a été déterminée comme étant la réponse la plus appropriée pour cette requête, compte tenu de l'état de la ressource cible au moment de l'origine du message de réponse par (ou sous la direction de) le serveur d'origine identifié dans l'URI cible. La localisation d'un serveur autoritaire pour un URI HTTP est discutée dans la section 4.3 de [HTTP].
Le schéma "https" associe l'autorité à la possession d'un certificat que le client considère comme digne de confiance pour l'hôte identifié par le composant d'autorité (Authority Component) de l'URI. Lors de la réception d'un certificat de serveur dans la poignée de main TLS, le client doit (MUST) vérifier que le certificat est une correspondance acceptable pour le serveur d'origine (Origin Server) de l'URI en utilisant le processus décrit dans la section 4.3.4 de [HTTP]. Si le certificat ne peut pas être vérifié par rapport au serveur d'origine de l'URI, le client ne doit pas (MUST NOT) considérer le serveur comme autoritaire pour cette origine.
Un client peut (MAY) tenter d'accéder à une ressource avec un URI "https" en résolvant l'identifiant d'hôte en une adresse IP, en établissant une connexion QUIC à cette adresse sur le port indiqué (y compris la validation du certificat de serveur comme décrit ci-dessus), et en envoyant un message de requête HTTP/3 ciblant l'URI au serveur via cette connexion sécurisée. À moins qu'un autre mécanisme ne soit utilisé pour sélectionner HTTP/3, le jeton "h3" est utilisé dans l'extension de négociation de protocole de couche application (Application-Layer Protocol Negotiation, ALPN ; voir [RFC7301]) pendant la poignée de main TLS.
Les problèmes de connectivité (par exemple, le blocage d'UDP) peuvent entraîner un échec d'établissement d'une connexion QUIC ; les clients devraient (SHOULD) tenter d'utiliser des versions basées sur TCP de HTTP dans ce cas.
Les serveurs peuvent (MAY) servir HTTP/3 sur n'importe quel port UDP ; une annonce de service alternatif (Alternative Service Advertisement) inclut toujours un port explicite, et les URI contiennent soit un port explicite, soit un port par défaut associé au schéma.
3.1.1. HTTP Alternative Services (Services alternatifs HTTP)
Une origine HTTP peut annoncer la disponibilité d'un point de terminaison HTTP/3 équivalent via le champ d'en-tête de réponse HTTP Alt-Svc ou la trame HTTP/2 ALTSVC ([ALTSVC]) en utilisant le jeton ALPN "h3".
Par exemple, une origine pourrait indiquer dans une réponse HTTP que HTTP/3 était disponible sur le port UDP 50781 au même nom d'hôte en incluant le champ d'en-tête suivant :
Alt-Svc: h3=":50781"
À la réception d'un enregistrement Alt-Svc indiquant le support HTTP/3, un client peut (MAY) tenter d'établir une connexion QUIC vers l'hôte et le port indiqués ; si cette connexion réussit, le client peut envoyer des requêtes HTTP en utilisant le mappage décrit dans ce document.
3.1.2. Other Schemes (Autres schémas)
Bien que HTTP soit indépendant du protocole de transport, le schéma "http" associe l'autorité à la capacité de recevoir des connexions TCP sur le port indiqué de tout hôte identifié dans le composant d'autorité. Parce que HTTP/3 n'utilise pas TCP, HTTP/3 ne peut pas être utilisé pour un accès direct au serveur autoritaire pour une ressource identifiée par un URI "http". Cependant, des extensions de protocole telles que [ALTSVC] permettent au serveur autoritaire d'identifier d'autres services qui sont également autoritaires et qui pourraient être accessibles via HTTP/3.
Avant de faire des requêtes pour une origine dont le schéma n'est pas "https", le client doit (MUST) s'assurer que le serveur est disposé à servir ce schéma. Pour les origines dont le schéma est "http", une méthode expérimentale pour accomplir cela est décrite dans [RFC8164]. D'autres mécanismes pourraient être définis pour divers schémas à l'avenir.
3.2. Connection Establishment (Établissement de la connexion)
HTTP/3 s'appuie sur QUIC version 1 comme transport sous-jacent. L'utilisation d'autres versions de transport QUIC avec HTTP/3 peut (MAY) être définie par des spécifications futures.
QUIC version 1 utilise TLS version 1.3 ou supérieure comme protocole de poignée de main (Handshake Protocol). Les clients HTTP/3 doivent (MUST) prendre en charge un mécanisme pour indiquer l'hôte cible au serveur pendant la poignée de main TLS. Si le serveur est identifié par un nom de domaine ([DNS-TERMS]), les clients doivent (MUST) envoyer l'extension TLS d'indication du nom de serveur (Server Name Indication, SNI ; [RFC6066]) sauf si un mécanisme alternatif pour indiquer l'hôte cible est utilisé.
Les connexions QUIC sont établies comme décrit dans [QUIC-TRANSPORT]. Pendant l'établissement de la connexion, le support HTTP/3 est indiqué en sélectionnant le jeton ALPN "h3" dans la poignée de main TLS. Le support d'autres protocoles de couche application peut (MAY) être offert dans la même poignée de main.
Alors que les options de niveau connexion relatives au protocole QUIC de base sont définies dans la poignée de main cryptographique initiale, les paramètres spécifiques à HTTP/3 sont transmis dans la trame SETTINGS. Après l'établissement de la connexion QUIC, une trame SETTINGS doit (MUST) être envoyée par chaque point de terminaison en tant que trame initiale de leur flux de contrôle HTTP (HTTP Control Stream) respectif.
3.3. Connection Reuse (Réutilisation de la connexion)
Les connexions HTTP/3 sont persistantes sur plusieurs requêtes. Pour de meilleures performances, on s'attend à ce que les clients ne ferment pas les connexions jusqu'à ce qu'il soit déterminé qu'aucune communication supplémentaire 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.
Une fois qu'une connexion à un point de terminaison de serveur existe, cette connexion peut (MAY) être réutilisée pour des requêtes avec plusieurs composants d'autorité URI différents. Pour utiliser une connexion existante pour une nouvelle origine, les clients doivent (MUST) valider le certificat présenté par le serveur pour le nouveau serveur d'origine en utilisant le processus décrit dans la section 4.3.4 de [HTTP]. Cela implique que les clients devront conserver le certificat de serveur et toute information supplémentaire nécessaire pour vérifier ce certificat ; les clients qui ne le font pas seront incapables de réutiliser la connexion pour des origines supplémentaires.
Si le certificat n'est pas acceptable pour la nouvelle origine pour quelque raison que ce soit, la connexion ne doit pas (MUST NOT) être réutilisée et une nouvelle connexion devrait (SHOULD) être établie pour la nouvelle origine. Si la raison pour laquelle le certificat ne peut pas être vérifié pourrait s'appliquer à d'autres origines déjà associées à la connexion, le client devrait (SHOULD) revalider le certificat de serveur pour ces origines. Par exemple, si la validation d'un certificat échoue parce que le certificat a expiré ou été révoqué, cela pourrait être utilisé pour invalider toutes les autres origines pour lesquelles ce certificat a été utilisé pour établir l'autorité.
Les clients ne devraient pas (SHOULD NOT) ouvrir plus d'une connexion HTTP/3 vers une adresse IP et un port UDP donnés, où l'adresse IP et le port pourraient être dérivés d'un URI, d'un service alternatif sélectionné ([ALTSVC]), d'un proxy configuré, ou de la résolution de nom de l'un de ceux-ci. Un client peut (MAY) ouvrir plusieurs connexions HTTP/3 vers la même adresse IP et le même port UDP en utilisant différentes configurations de transport ou TLS mais devrait (SHOULD) éviter de créer plusieurs connexions avec la même configuration.
Les serveurs sont encouragés à maintenir les connexions HTTP/3 ouvertes aussi longtemps que possible mais sont autorisés à terminer les connexions inactives (Idle Connections) si nécessaire. Lorsque l'un ou l'autre point de terminaison choisit de fermer la connexion HTTP/3, le point de terminaison qui termine devrait (SHOULD) d'abord envoyer une trame GOAWAY (section 5.2) afin que les deux points de terminaison puissent déterminer de manière fiable si les trames précédemment envoyées ont été traitées et terminer ou achever gracieusement toutes les tâches restantes nécessaires.
Un serveur qui ne souhaite pas que les clients réutilisent les connexions HTTP/3 pour une origine particulière peut indiquer qu'il n'est pas autoritaire pour une requête en envoyant un code d'état 421 (Misdirected Request, Requête mal dirigée) en réponse à la requête ; voir section 7.4 de [HTTP].