2. Concepts de services alternatifs
Cette spécification définit un nouveau concept dans HTTP, le "Service Alternatif" (Alternative Service). Lorsqu'une origine [RFC6454] possède des ressources accessibles via une combinaison différente de protocole/hôte/port, on dit qu'elle dispose d'un service alternatif disponible.
Un service alternatif peut être utilisé pour interagir avec les ressources sur un serveur d'origine à un emplacement distinct sur le réseau, en utilisant éventuellement une configuration de protocole différente. Les services alternatifs sont considérés comme faisant autorité pour les ressources d'une origine, au sens de la [RFC7230], Section 9.1.
Par exemple, une origine :
("http", "www.example.com", "80")
pourrait déclarer que ses ressources sont également accessibles au service alternatif :
("h2", "new.example.com", "81")
Par nature, les services alternatifs sont explicitement à la granularité d'une origine ; ils ne peuvent pas être appliqués sélectivement aux ressources au sein d'une origine.
Les services alternatifs ne remplacent ni ne modifient l'origine d'une ressource donnée ; en général, ils ne sont pas visibles par le logiciel "au-dessus" du mécanisme d'accès. Le service alternatif est essentiellement une information de routage alternative qui peut également être utilisée pour atteindre l'origine de la même manière que les enregistrements DNS CNAME ou SRV définissent des informations de routage au niveau de la résolution de nom. Chaque origine correspond à un ensemble de ces routes -- la route par défaut est dérivée de l'origine elle-même et les autres routes sont introduites sur la base des informations de service alternatif.
De plus, il est important de noter que le premier membre d'un tuple de service alternatif est différent du composant "schéma" d'une origine ; il est plus spécifique, identifiant non seulement la version majeure du protocole utilisé, mais potentiellement aussi les options de communication pour ce protocole.
Cela signifie que les clients utilisant un service alternatif peuvent modifier l'hôte, le port et le protocole qu'ils utilisent pour récupérer des ressources, mais ces modifications NE DOIVENT PAS être propagées à l'application utilisant HTTP ; de ce point de vue, l'URI accédé et toutes les informations qui en découlent (schéma, hôte et port) sont les mêmes qu'auparavant.
Il est important de noter que cela inclut son contexte de sécurité ; en particulier, lorsque TLS [RFC5246] est utilisé pour l'authentification, le service alternatif devra présenter un certificat pour le nom d'hôte de l'origine, et non celui de l'alternative. De même, le champ d'en-tête Host ([RFC7230], Section 5.4) est toujours dérivé de l'origine, et non du service alternatif (tout comme ce serait le cas si un CNAME était utilisé).
Les modifications PEUVENT, cependant, être rendues visibles dans les outils de débogage, les consoles, etc.
Formellement, un service alternatif est identifié par la combinaison de :
- Un nom de protocole ALPN (Application Layer Protocol Negotiation), selon [RFC7301]
- Un hôte, selon [RFC3986], Section 3.2.2
- Un port, selon [RFC3986], Section 3.2.3
Le nom de protocole ALPN est utilisé pour identifier le protocole d'application ou la suite de protocoles utilisés par le service alternatif. Notez que pour les besoins de cette spécification, un nom de protocole ALPN inclut implicitement TLS dans la suite de protocoles qu'il identifie, sauf spécification contraire dans sa définition. En particulier, le nom ALPN "http/1.1", enregistré par la Section 6 de [RFC7301], identifie HTTP/1.1 sur TLS.
De plus, chaque service alternatif DOIT avoir une durée de fraîcheur, exprimée en secondes (voir Section 2.2).
Il existe de nombreuses façons pour un client de découvrir le(s) service(s) alternatif(s) associé(s) à une origine. Ce document décrit deux de ces mécanismes : le champ d'en-tête HTTP "Alt-Svc" (Section 3) et le type de trame HTTP/2 "ALTSVC" (Section 4).
Le reste de cette section décrit les exigences communes aux services alternatifs, quelle que soit la manière dont ils sont découverts.
2.1. Authentification de l'hôte
Les clients DOIVENT avoir des assurances raisonnables que le service alternatif est sous le contrôle de et valide pour l'ensemble de l'origine. Cela atténue l'attaque décrite dans la Section 9.2.
Aux fins de ce document, des "assurances raisonnables" peuvent être établies par l'utilisation d'un protocole basé sur TLS avec les vérifications de certificat définies dans [RFC2818]. Les clients PEUVENT imposer des critères supplémentaires pour établir des assurances raisonnables.
Par exemple, si l'hôte de l'origine est "www.example.com" et qu'une alternative est proposée sur "other.example.com" avec le protocole "h2", et que le certificat proposé est valide pour "www.example.com", le client peut utiliser l'alternative. Cependant, si l'un ou l'autre est proposé avec le protocole "h2c", le client ne peut pas l'utiliser, car il n'y a aucun mécanisme (au moment de la publication de cette spécification) dans ce protocole pour établir la relation entre l'origine et l'alternative.
2.2. Mise en cache des services alternatifs
Les mécanismes de découverte des services alternatifs leur associent également une durée de fraîcheur ; par exemple, le champ d'en-tête Alt-Svc utilise le paramètre "ma".
Les clients peuvent choisir d'utiliser un service alternatif au lieu de l'origine à tout moment lorsqu'il est considéré comme frais ; voir la Section 2.4 pour des recommandations spécifiques.
Les clients ayant des connexions existantes à un service alternatif n'ont pas besoin d'arrêter de l'utiliser lorsque sa durée de fraîcheur expire ; le mécanisme de mise en cache est destiné à limiter la durée pendant laquelle un service alternatif peut être utilisé pour établir de nouvelles connexions, et non à limiter l'utilisation des connexions existantes.
Les services alternatifs font entièrement autorité pour l'origine en question, y compris la capacité d'effacer ou de mettre à jour les entrées de service alternatif mises en cache, d'étendre les durées de fraîcheur, et toute autre autorité que le serveur d'origine aurait.
Lorsque des services alternatifs sont utilisés pour envoyer un client vers le serveur le plus optimal, un changement dans la configuration du réseau peut rendre les valeurs mises en cache sous-optimales. Par conséquent, les clients DEVRAIENT supprimer du cache tous les services alternatifs qui n'ont pas le drapeau "persist" avec la valeur "1" lorsqu'ils détectent un tel changement, lorsque des informations sur l'état du réseau sont disponibles.
2.3. Exigence de l'indication du nom du serveur (SNI)
Un client NE DOIT PAS utiliser un service alternatif basé sur TLS à moins que le client ne prenne en charge l'indication du nom du serveur TLS (SNI). Cela permet d'économiser les adresses IP sur l'hôte du service alternatif.
Notez que les informations SNI fournies dans TLS par le client seront celles de l'origine, et non celles de l'alternative (tout comme la valeur du champ d'en-tête HTTP Host).
2.4. Utilisation des services alternatifs
Par nature, les services alternatifs sont OPTIONNELS : les clients n'ont pas besoin de les utiliser. Cependant, il est avantageux pour les clients de se comporter de manière prévisible lorsque des services alternatifs sont utilisés par les serveurs, pour faciliter des objectifs tels que l'équilibrage de charge.
Par conséquent, si un client prenant en charge cette spécification prend connaissance d'un service alternatif, le client DEVRAIT utiliser ce service alternatif pour toutes les demandes vers l'origine associée dès qu'il est disponible, à condition que les informations du service alternatif soient fraîches (Section 2.2) et que les propriétés de sécurité du protocole du service alternatif soient souhaitables, par rapport à la connexion existante. Un service alternatif viable est alors traité à tous égards comme l'origine ; cela inclut la capacité d'annoncer des services alternatifs.
Si un client prend connaissance de plusieurs services alternatifs, il choisit le plus approprié selon ses propres critères, en gardant à l'esprit les propriétés de sécurité. Par exemple, une origine peut annoncer plusieurs services alternatifs pour informer les clients de la prise en charge de plusieurs versions de HTTP.
Un client configuré pour utiliser un proxy pour une demande donnée NE DEVRAIT PAS se connecter directement à un service alternatif pour cette demande, mais plutôt la router via ce proxy.
Lorsqu'un client utilise un service alternatif pour une demande, il peut l'indiquer au serveur à l'aide du champ d'en-tête Alt-Used (Section 5).
Le client n'a pas besoin de bloquer les demandes sur une connexion existante ; elle peut être utilisée jusqu'à ce que la connexion alternative soit établie. Cependant, si les propriétés de sécurité de la connexion existante sont faibles (par exemple, HTTP/1.1 en texte clair), il peut être judicieux de bloquer jusqu'à ce que la nouvelle connexion soit entièrement disponible afin d'éviter toute fuite d'informations.
De plus, si la connexion au service alternatif échoue ou ne répond pas, le client PEUT se rabattre sur l'utilisation de l'origine ou d'un autre service alternatif. Notez cependant que cela pourrait être la base d'une attaque par rétrogradation, perdant ainsi toutes les propriétés de sécurité améliorées du service alternatif. Si la connexion au service alternatif ne négocie pas le protocole attendu (par exemple, ALPN ne parvient pas à négocier h2, ou une demande de mise à niveau vers h2c n'est pas acceptée), la connexion au service alternatif DOIT être considérée comme ayant échoué.