3. Starting HTTP/2 (Démarrage d'HTTP/2)
Les implémentations qui génèrent des requêtes HTTP doivent découvrir si un serveur prend en charge HTTP/2.
HTTP/2 utilise les schémas URI "http" et "https" définis dans la section 4.2 de [HTTP], avec les mêmes numéros de port par défaut que HTTP/1.1 [HTTP/1.1]. Ces URI n'incluent aucune indication sur les versions HTTP qu'un serveur en amont (Upstream Server, le pair immédiat avec lequel le client souhaite établir une connexion) prend en charge.
Les moyens par lesquels le support d'HTTP/2 est déterminé sont différents pour les URI "http" et "https". La découverte pour les URI "https" est décrite dans la section 3.2. Le support d'HTTP/2 pour les URI "http" ne peut être découvert que par des moyens hors bande (Out-of-Band Means) et nécessite une connaissance préalable (Prior Knowledge) du support comme décrit dans la section 3.3.
3.1. HTTP/2 Version Identification (Identification de version HTTP/2)
Le protocole défini dans ce document a deux identifiants. La création d'une connexion basée sur l'un ou l'autre implique l'utilisation du transport, du tramage et de la sémantique des messages décrits dans ce document.
-
La chaîne "h2" identifie le protocole où HTTP/2 utilise la sécurité de la couche de transport (Transport Layer Security, TLS) ; voir la section 9.2. Cet identifiant est utilisé dans le champ d'extension de négociation de protocole de couche application TLS (Application-Layer Protocol Negotiation, ALPN) [TLS-ALPN] et dans tout endroit où HTTP/2 sur TLS est identifié.
La chaîne "h2" est sérialisée en un identifiant de protocole ALPN comme la séquence de deux octets : 0x68, 0x32.
-
La chaîne "h2c" était précédemment utilisée comme jeton pour le champ d'en-tête Upgrade du mécanisme de mise à niveau HTTP (section 7.8 de [HTTP]). Cette utilisation n'a jamais été largement déployée et est dépréciée par ce document. Il en va de même pour le champ d'en-tête HTTP2-Settings, qui était utilisé avec la mise à niveau vers "h2c".
3.2. Starting HTTP/2 for "https" URIs (Démarrage d'HTTP/2 pour les URI "https")
Un client qui fait une requête à un URI "https" utilise TLS [TLS13] avec l'extension ALPN [TLS-ALPN].
HTTP/2 sur TLS utilise l'identifiant de protocole "h2". L'identifiant de protocole "h2c" ne doit pas (MUST NOT) être envoyé par un client ou sélectionné par un serveur ; l'identifiant de protocole "h2c" décrit un protocole qui n'utilise pas TLS.
Une fois la négociation TLS terminée, le client et le serveur doivent tous deux (MUST) envoyer une préface de connexion (Connection Preface, section 3.4).
3.3. Starting HTTP/2 with Prior Knowledge (Démarrage d'HTTP/2 avec connaissance préalable)
Un client peut apprendre qu'un serveur particulier prend en charge HTTP/2 par d'autres moyens. Par exemple, un client pourrait être configuré avec la connaissance qu'un serveur prend en charge HTTP/2.
Un client qui sait qu'un serveur prend en charge HTTP/2 peut établir une connexion TCP et envoyer la préface de connexion (section 3.4) suivie de trames HTTP/2. Les serveurs peuvent identifier ces connexions par la présence de la préface de connexion. Cela n'affecte que l'établissement de connexions HTTP/2 sur TCP en texte clair ; les connexions HTTP/2 sur TLS doivent (MUST) utiliser la négociation de protocole dans TLS [TLS-ALPN].
De même, le serveur doit (MUST) envoyer une préface de connexion (section 3.4).
Sans informations supplémentaires, le support préalable d'HTTP/2 n'est pas un signal fort qu'un serveur donné prendra en charge HTTP/2 pour les connexions futures. Par exemple, il est possible que les configurations de serveur changent, que les configurations diffèrent entre les instances dans les serveurs en cluster, ou que les conditions réseau changent.
3.4. HTTP/2 Connection Preface (Préface de connexion HTTP/2)
Dans HTTP/2, chaque point de terminaison est tenu d'envoyer une préface de connexion (Connection Preface) comme confirmation finale du protocole utilisé et pour établir les paramètres initiaux de la connexion HTTP/2. Le client et le serveur envoient chacun une préface de connexion différente.
La préface de connexion client commence par une séquence de 24 octets, qui en notation hexadécimale est :
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
C'est-à-dire que la préface de connexion commence par la chaîne "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n". Cette séquence doit (MUST) être suivie d'une trame SETTINGS (section 6.5), qui peut (MAY) être vide. Le client envoie la préface de connexion client comme les premiers octets de données d'application d'une connexion.
Note : La préface de connexion client est sélectionnée de sorte qu'une grande proportion de serveurs et d'intermédiaires HTTP/1.1 ou HTTP/1.0 ne tentent pas de traiter d'autres trames. Notez que cela ne résout pas les préoccupations soulevées dans [TALKING].
La préface de connexion serveur consiste en une trame SETTINGS potentiellement vide (section 6.5) qui doit (MUST) être la première trame que le serveur envoie dans la connexion HTTP/2.
Les trames SETTINGS reçues d'un pair dans le cadre de la préface de connexion doivent (MUST) être acquittées (voir section 6.5.3) après l'envoi de la préface de connexion.
Pour éviter une latence inutile, les clients sont autorisés à envoyer des trames supplémentaires au serveur immédiatement après l'envoi de la préface de connexion client, sans attendre de recevoir la préface de connexion serveur. Il est important de noter, cependant, que la trame SETTINGS de la préface de connexion serveur peut inclure des paramètres qui modifient nécessairement la façon dont un client est censé communiquer avec le serveur. Lors de la réception de la trame SETTINGS, le client est censé honorer tous les paramètres établis. Dans certaines configurations, il est possible pour le serveur de transmettre SETTINGS avant que le client n'envoie des trames supplémentaires, offrant ainsi une opportunité d'éviter ce problème.
Les clients et les serveurs doivent (MUST) traiter une préface de connexion invalide comme une erreur de connexion (section 5.4.1) de type PROTOCOL_ERROR. Une trame GOAWAY (section 6.8) peut (MAY) être omise dans ce cas, car une préface invalide indique que le pair n'utilise pas HTTP/2.