2. La trame ORIGIN HTTP/2 (The ORIGIN HTTP/2 Frame)

Ce document définit un nouveau type de trame HTTP/2 ([RFC7540], Section 4) appelé ORIGIN, qui permet à un serveur d'indiquer quelle(s) origine(s) [RFC6454] le serveur souhaite que le client considère comme membres de l'ensemble d'origines (Section 2.3) pour la connexion dans laquelle elle apparaît.

2.1. Syntaxe

Le type de trame ORIGIN est 0xc (12 en décimal) et contient zéro ou plusieurs instances du champ Origin-Entry.

+-------------------------------+-------------------------------+
|         Origin-Entry (*)                                    ...
+-------------------------------+-------------------------------+

Une Origin-Entry est une chaîne délimitée par la longueur :

+-------------------------------+-------------------------------+
|         Origin-Len (16)       | ASCII-Origin?               ...
+-------------------------------+-------------------------------+

Spécifiquement :

Origin-Len : Un entier non signé de 16 bits indiquant la longueur, en octets, du champ ASCII-Origin.

Origin : Une séquence de caractères OPTIONNELLE contenant la sérialisation ASCII d'une origine ([RFC6454], Section 6.2) pour laquelle l'expéditeur affirme que cette connexion est ou pourrait être autoritaire.

La trame ORIGIN ne définit aucun drapeau. Cependant, les futures mises à jour de cette spécification PEUVENT définir des drapeaux. Voir la Section 2.2.

2.2. Traitement des trames ORIGIN

La trame ORIGIN est une extension non critique de HTTP/2. Les points de terminaison qui ne prennent pas en charge cette trame peuvent l'ignorer en toute sécurité à la réception.

Lorsqu'elle est reçue par un client implémentant, elle est utilisée pour initialiser et manipuler l'ensemble d'origines (voir Section 2.3), modifiant ainsi la façon dont le client établit l'autorité pour les serveurs d'origine (voir Section 2.4).

La trame ORIGIN DOIT être envoyée sur le flux 0 ; une trame ORIGIN sur tout autre flux est invalide et DOIT être ignorée.

De même, la trame ORIGIN n'est valide que sur les connexions avec l'identifiant de protocole "h2" ou lorsqu'elle est spécifiquement désignée par la définition du protocole ; elle DOIT être ignorée lorsqu'elle est reçue sur une connexion avec l'identifiant de protocole "h2c".

Cette spécification ne définit aucun drapeau pour la trame ORIGIN, mais les futures mises à jour de cette spécification (par consensus de l'IETF) pourraient les utiliser pour modifier sa sémantique. Les quatre premiers drapeaux (0x1, 0x2, 0x4 et 0x8) sont réservés aux changements incompatibles avec les versions antérieures ; par conséquent, lorsque l'un d'eux est défini, la trame ORIGIN les contenant DOIT être ignorée par les clients conformes à cette spécification, à moins que la sémantique du drapeau ne soit comprise. Les drapeaux restants sont réservés aux changements compatibles avec les versions antérieures et n'affectent pas le traitement par les clients conformes à cette spécification.

La trame ORIGIN décrit une propriété de la connexion et est donc traitée saut par saut. Un intermédiaire NE DOIT PAS transférer les trames ORIGIN. Les clients configurés pour utiliser un proxy DOIVENT ignorer toutes les trames ORIGIN reçues de celui-ci.

Chaque champ ASCII-Origin dans la charge utile de la trame DOIT être analysé comme une sérialisation ASCII d'une origine ([RFC6454], Section 6.2). Si l'analyse échoue, le champ DOIT être ignoré.

Notez que la trame ORIGIN ne prend pas en charge les noms génériques (par exemple, "*.example.com") dans Origin-Entry. Par conséquent, l'envoi d'ORIGIN lorsqu'un certificat générique est utilisé désactive efficacement toutes les origines qui ne sont pas explicitement répertoriées dans la ou les trames ORIGIN (lorsque le client comprend ORIGIN).

Voir l'Annexe A pour un algorithme illustratif de traitement des trames ORIGIN.

2.3. L'ensemble d'origines

L'ensemble des origines (selon [RFC6454]) pour lequel une connexion donnée pourrait être utilisée est connu dans cette spécification sous le nom d'ensemble d'origines.

Par défaut, l'ensemble d'origines pour une connexion n'est pas initialisé. Un ensemble d'origines non initialisé signifie que les clients appliquent les règles de fusion de la Section 9.1.1 de [RFC7540].

Lorsqu'une trame ORIGIN est reçue pour la première fois et traitée avec succès par un client, l'ensemble d'origines de la connexion est défini pour contenir une origine initiale. L'origine initiale est composée de :

• Schéma : "https"
• Hôte : la valeur envoyée dans l'indication de nom de serveur (SNI) ([RFC6066], Section 3) convertie en minuscules ; si SNI n'est pas présent, l'adresse distante de la connexion (c'est-à-dire l'adresse IP du serveur)
• Port : le port distant de la connexion (c'est-à-dire le port du serveur)

Le contenu de cette trame ORIGIN (et des suivantes) permet au serveur d'ajouter progressivement de nouvelles origines à l'ensemble d'origines, comme décrit dans la Section 2.2.

L'ensemble d'origines est également affecté par le code d'état de réponse 421 (Misdirected Request), tel que défini dans [RFC7540], Section 9.1.2. À la réception d'une réponse avec ce code d'état, les clients implémentant DOIVENT créer la sérialisation ASCII de l'origine de la requête correspondante (selon [RFC6454], Section 6.2) et la supprimer de l'ensemble d'origines de la connexion, si elle est présente.

Note : Lors de l'envoi d'une trame ORIGIN à une connexion initialisée en tant que service alternatif [RFC7838], l'ensemble d'origines initial (Section 2.3) contiendra une origine avec le schéma et le nom d'hôte appropriés (puisque la RFC 7838 spécifie que le nom d'hôte de l'origine soit envoyé dans SNI). Cependant, il est possible que le port soit différent de celui de l'origine prévue, puisque l'ensemble d'origines initial est calculé en utilisant le port réel utilisé, qui peut être différent pour le service alternatif. Dans ce cas, l'origine prévue doit être envoyée explicitement dans la trame ORIGIN.

Par exemple, un client effectuant des requêtes pour "https://example.com" est dirigé vers un service alternatif à ("h2", "x.example.net", "8443"). Si ce service alternatif envoie une trame ORIGIN, l'origine initiale sera "https://example.com:8443". Le client ne pourra pas utiliser le service alternatif pour effectuer des requêtes pour "https://example.com" à moins que cette origine ne soit explicitement incluse dans la trame ORIGIN.

2.4. Autorité, Push et fusion avec ORIGIN

La Section 10.1 de [RFC7540] utilise à la fois le DNS et le certificat TLS (Transport Layer Security) présenté pour établir le(s) serveur(s) d'origine pour le(s)quel(s) une connexion est autoritaire, tout comme HTTP/1.1 le fait dans [RFC7230].

De plus, la Section 9.1.1 de [RFC7540] permet explicitement qu'une connexion soit utilisée pour plus d'un serveur d'origine, si elle est autoritaire. Cela affecte les réponses qui peuvent être considérées comme autoritaires, tant pour les réponses directes aux requêtes que pour le push serveur (voir [RFC7540], Section 8.2.2). Indirectement, cela affecte également les requêtes qui seront envoyées sur une connexion, car les clients n'enverront généralement des requêtes que sur des connexions qu'ils jugent autoritaires pour l'origine en question.

Une fois qu'un ensemble d'origines a été initialisé pour une connexion, les clients qui implémentent cette spécification l'utilisent pour aider à déterminer pour quoi la connexion est autoritaire. Plus précisément, ces clients NE DOIVENT PAS considérer qu'une connexion est autoritaire pour une origine non présente dans l'ensemble d'origines, et ils DEVRAIENT utiliser la connexion pour toutes les requêtes vers des origines dans l'ensemble d'origines pour lesquelles la connexion est autoritaire, sauf s'il existe des raisons opérationnelles d'ouvrir une nouvelle connexion.

Notez que pour qu'une connexion soit considérée comme autoritaire pour une origine donnée, le serveur doit toujours s'authentifier avec un certificat qui passe les vérifications appropriées ; voir la Section 9.1.1 de [RFC7540] pour plus d'informations. Cela inclut la vérification que l'hôte correspond à une valeur "dNSName" du champ "subjectAltName" du certificat (en utilisant les règles définies dans [RFC2818] ; voir aussi [RFC5280], Section 4.2.1.6).

De plus, les clients PEUVENT éviter de consulter le DNS pour établir l'autorité de la connexion pour de nouvelles requêtes vers des origines dans l'ensemble d'origines ; cependant, ceux qui le font font face à de nouveaux risques, comme expliqué dans la Section 4.

Parce qu'ORIGIN peut modifier l'ensemble des origines pour lesquelles une connexion est utilisée au fil du temps, il est possible qu'un client ait plus d'une connexion viable vers une origine ouverte à tout moment. Lorsque cela se produit, les clients NE DEVRAIENT PAS émettre de nouvelles requêtes sur une connexion dont l'ensemble d'origines est un sous-ensemble propre de l'ensemble d'origines d'une autre connexion, et ils DEVRAIENT la fermer une fois que toutes les requêtes en attente sont satisfaites.

L'ensemble d'origines n'est pas affecté par les annonces de services alternatifs [RFC7838] faites par le serveur. La publicité d'un service alternatif n'affecte pas si un serveur est autoritaire.