4. Identifiants dans HTTP

Les Uniform Resource Identifiers (URIs) [URI] sont utilisés dans tout HTTP comme moyen d'identifier les ressources (Section 3.1).

4.1. Références URI

Les références URI sont utilisées pour cibler les requêtes, indiquer les redirections et définir les relations.

Les définitions de "URI-reference", "absolute-URI", "relative-part", "authority", "port", "host", "path-abempty", "segment" et "query" sont adoptées de la syntaxe générique URI. Une règle "absolute-path" est définie pour les éléments de protocole qui peuvent contenir un composant de chemin non vide. (Cette règle diffère légèrement de la règle path-abempty de RFC 3986, qui autorise un chemin vide, et de la règle path-absolute, qui n'autorise pas les chemins commençant par "//".) Une règle "partial-URI" est définie pour les éléments de protocole qui peuvent contenir un URI relatif mais pas un composant de fragment.

URI-reference = <URI-reference, see [URI], Section 4.1>
absolute-URI  = <absolute-URI, see [URI], Section 4.3>
relative-part = <relative-part, see [URI], Section 4.2>
authority     = <authority, see [URI], Section 3.2>
uri-host      = <host, see [URI], Section 3.2.2>
port          = <port, see [URI], Section 3.2.3>
path-abempty  = <path-abempty, see [URI], Section 3.3>
segment       = <segment, see [URI], Section 3.3>
query         = <query, see [URI], Section 3.4>

absolute-path = 1*( "/" segment )
partial-URI   = relative-part [ "?" query ]

Chaque élément de protocole dans HTTP qui autorise une référence URI indiquera dans sa production ABNF si l'élément autorise toute forme de référence (URI-reference), uniquement un URI sous forme absolue (absolute-URI), uniquement les composants de chemin et de requête optionnels (partial-URI), ou une combinaison des éléments ci-dessus. Sauf indication contraire, les références URI sont analysées par rapport à l'URI cible (Section 7.1).

Il est RECOMMANDÉ que tous les expéditeurs et destinataires prennent en charge, au minimum, des URI d'une longueur de 8000 octets dans les éléments de protocole. Notez que cela implique que certaines structures et représentations sur le fil (par exemple, la ligne de requête dans HTTP/1.1) seront nécessairement plus grandes dans certains cas.

4.2. Schémas URI liés à HTTP

L'IANA maintient le registre des schémas URI [BCP35] à https://www.iana.org/assignments/uri-schemes/. Bien que les requêtes puissent cibler n'importe quel schéma URI, les schémas suivants sont inhérents aux serveurs HTTP:

Schéma URI	Description	Section
http	Protocole de Transfert Hypertexte	4.2.1
https	Protocole de Transfert Hypertexte Sécurisé	4.2.2

Tableau 2

Notez que la présence d'un URI "http" ou "https" n'implique pas qu'il y ait toujours un serveur HTTP à l'origine identifiée écoutant les connexions. N'importe qui peut créer un URI, qu'un serveur existe ou non et que ce serveur mappe actuellement cet identifiant à une ressource ou non. La nature déléguée des noms enregistrés et des adresses IP crée un espace de noms fédéré qu'un serveur HTTP soit présent ou non.

4.2.1. Schéma URI http

Le schéma URI "http" est par la présente défini pour créer des identifiants dans l'espace de noms hiérarchique régi par un serveur d'origine HTTP potentiel écoutant les connexions TCP ([TCP]) sur un port donné.

http-URI = "http" "://" authority path-abempty [ "?" query ]

Le serveur d'origine pour un URI "http" est identifié par le composant authority, qui inclut un identifiant d'hôte ([URI], Section 3.2.2) et un numéro de port optionnel ([URI], Section 3.2.3). Si le sous-composant de port est vide ou non donné, le port TCP 80 (le port réservé pour les services WWW) est le port par défaut. L'origine détermine qui a le droit de répondre de manière autoritaire aux requêtes qui ciblent la ressource identifiée, comme défini dans la Section 4.3.2.

Un expéditeur NE DOIT PAS (MUST NOT) générer un URI "http" avec un identifiant d'hôte vide. Un destinataire qui traite une telle référence URI DOIT la rejeter comme invalide.

Le composant de chemin hiérarchique et le composant de requête optionnel identifient la ressource cible dans l'espace de noms de ce serveur d'origine.

4.2.2. Schéma URI https

Le schéma URI "https" est par la présente défini pour créer des identifiants dans l'espace de noms hiérarchique régi par un serveur d'origine potentiel écoutant les connexions TCP sur un port donné et capable d'établir une connexion TLS ([TLS13]) qui a été sécurisée pour la communication HTTP. Dans ce contexte, "sécurisé" signifie spécifiquement que le serveur a été authentifié comme agissant au nom de l'autorité identifiée et que toute communication HTTP avec ce serveur dispose d'une protection de confidentialité et d'intégrité acceptable à la fois pour le client et le serveur.

https-URI = "https" "://" authority path-abempty [ "?" query ]

Le serveur d'origine pour un URI "https" est identifié par le composant authority, qui inclut un identifiant d'hôte ([URI], Section 3.2.2) et un numéro de port optionnel ([URI], Section 3.2.3). Si le sous-composant de port est vide ou non donné, le port TCP 443 (le port réservé pour HTTP sur TLS) est le port par défaut. L'origine détermine qui a le droit de répondre de manière autoritaire aux requêtes qui ciblent la ressource identifiée, comme défini dans la Section 4.3.3.

Un expéditeur NE DOIT PAS (MUST NOT) générer un URI "https" avec un identifiant d'hôte vide. Un destinataire qui traite une telle référence URI DOIT la rejeter comme invalide.

Le composant de chemin hiérarchique et le composant de requête optionnel identifient la ressource cible dans l'espace de noms de ce serveur d'origine.

Un client DOIT s'assurer que ses requêtes HTTP pour une ressource "https" sont sécurisées, avant d'être communiquées, et qu'il n'accepte que des réponses sécurisées à ces requêtes. Notez que la définition des mécanismes cryptographiques acceptables pour le client et le serveur est généralement négociée et peut changer au fil du temps.

Les ressources rendues disponibles via le schéma "https" n'ont pas d'identité partagée avec le schéma "http". Ce sont des origines distinctes avec des espaces de noms séparés. Cependant, les extensions de HTTP qui sont définies comme s'appliquant à toutes les origines avec le même hôte, telles que le protocole Cookie [COOKIE], permettent aux informations définies par un service d'impacter la communication avec d'autres services au sein d'un groupe correspondant de domaines d'hôtes. Ces extensions doivent être conçues avec beaucoup de soin pour éviter que les informations obtenues d'une connexion sécurisée ne soient échangées par inadvertance dans un contexte non sécurisé.

4.2.3. Normalisation et comparaison http(s)

Les URI avec un schéma "http" ou "https" sont normalisés et comparés selon les méthodes définies dans la Section 6 de [URI], en utilisant les valeurs par défaut décrites ci-dessus pour chaque schéma.

HTTP ne requiert pas l'utilisation d'une méthode spécifique pour déterminer l'équivalence. Par exemple, une clé de cache pourrait être comparée comme une simple chaîne, après normalisation basée sur la syntaxe, ou après normalisation basée sur le schéma.

La normalisation basée sur le schéma (Section 6.2.3 de [URI]) des URI "http" et "https" implique les règles supplémentaires suivantes:

• Si le port est égal au port par défaut pour un schéma, la forme normale consiste à omettre le sous-composant de port.

• Lorsqu'il n'est pas utilisé comme cible d'une requête OPTIONS, un composant de chemin vide est équivalent à un chemin absolu de "/", donc la forme normale consiste à fournir un chemin de "/" à la place.

• Le schéma et l'hôte sont insensibles à la casse et normalement fournis en minuscules; tous les autres composants sont comparés de manière sensible à la casse.

• Les caractères autres que ceux de l'ensemble "reserved" sont équivalents à leurs octets encodés en pourcentage: la forme normale consiste à ne pas les encoder (voir Sections 2.1 et 2.2 de [URI]).

Par exemple, les trois URI suivants sont équivalents:

http://example.com:80/~smith/home.html
http://EXAMPLE.com/%7Esmith/home.html
http://EXAMPLE.com:/%7esmith/home.html

Deux URI HTTP qui sont équivalents après normalisation (en utilisant n'importe quelle méthode) peuvent être supposés identifier la même ressource, et tout composant HTTP PEUT effectuer une normalisation. Par conséquent, des ressources distinctes NE DEVRAIENT PAS (SHOULD NOT) être identifiées par des URI HTTP qui sont équivalents après normalisation (en utilisant n'importe quelle méthode définie dans la Section 6.2 de [URI]).

4.2.4. Dépréciation du userinfo dans les URI http(s)

La syntaxe générique URI pour l'autorité inclut également un sous-composant userinfo ([URI], Section 3.2.1) pour inclure des informations d'authentification utilisateur dans l'URI. Dans ce sous-composant, l'utilisation du format "user:password" est dépréciée.

Certaines implémentations utilisent le composant userinfo pour la configuration interne des informations d'authentification, comme dans les options d'invocation de commande, les fichiers de configuration ou les listes de signets, même si une telle utilisation pourrait exposer un identifiant utilisateur ou un mot de passe.

Un expéditeur NE DOIT PAS (MUST NOT) générer le sous-composant userinfo (et son délimiteur "@") lorsqu'une référence URI "http" ou "https" est générée dans un message comme URI cible ou valeur de champ.

Avant d'utiliser une référence URI "http" ou "https" reçue d'une source non fiable, un destinataire DEVRAIT (SHOULD) analyser le userinfo et traiter sa présence comme une erreur; il est probablement utilisé pour obscurcir l'autorité dans le but d'attaques de phishing.

4.2.5. Références http(s) avec identifiants de fragment

Les identifiants de fragment permettent l'identification indirecte d'une ressource secondaire, indépendamment du schéma URI, comme défini dans la Section 3.5 de [URI]. Certains éléments de protocole qui font référence à un URI permettent l'inclusion d'un fragment, tandis que d'autres ne le permettent pas. Ils sont distingués par l'utilisation de la règle ABNF pour les éléments où le fragment est autorisé; sinon, une règle spécifique qui exclut les fragments est utilisée.

Note: Le composant identifiant de fragment ne fait pas partie de la définition du schéma pour un schéma URI (voir Section 4.3 de [URI]), donc n'apparaît pas dans les définitions ABNF pour les schémas URI "http" et "https" ci-dessus.

4.3. Accès Autoritaire

L'accès autoritaire fait référence au déréférencement d'un identifiant donné, dans le but d'accéder à la ressource identifiée, d'une manière que le client considère comme autoritaire (contrôlée par le propriétaire de la ressource). Le processus pour déterminer si l'accès est accordé est défini par le schéma URI et utilise souvent des données dans les composants URI, telles que le composant authority lorsque la syntaxe générique est utilisée. Cependant, l'accès autoritaire n'est pas limité au mécanisme identifié.

La Section 4.3.1 définit le concept d'origine comme aide à de telles utilisations, et les sous-sections suivantes expliquent comment établir qu'un pair a l'autorité de représenter une origine.

Voir la Section 17.1 pour les considérations de sécurité liées à l'établissement de l'autorité.

4.3.1. Origine URI

L'"origine" (origin) pour un URI donné est le triplet de schéma, hôte et port après normalisation du schéma et de l'hôte en minuscules et normalisation du port pour supprimer tous les zéros de tête. Si le port est élidé de l'URI, le port par défaut pour ce schéma est utilisé. Par exemple, l'URI

https://Example.Com/happy.js

aurait l'origine

{ "https", "example.com", "443" }

ce qui peut également être décrit comme le préfixe URI normalisé avec le port toujours présent:

https://example.com:443

Chaque origine définit son propre espace de noms et contrôle la manière dont les identifiants dans cet espace de noms sont mappés aux ressources. À son tour, la manière dont l'origine répond aux requêtes valides, de manière cohérente au fil du temps, détermine la sémantique que les utilisateurs associeront à un URI, et l'utilité de cette sémantique est ce qui transforme finalement ces mécanismes en une ressource que les utilisateurs référenceront et accéderont à l'avenir.

Deux origines sont distinctes si elles diffèrent en schéma, hôte ou port. Même lorsqu'il peut être vérifié que la même entité contrôle deux origines distinctes, les deux espaces de noms sous ces origines sont distincts sauf s'ils sont explicitement aliasés par un serveur autoritaire pour cette origine.

L'origine est également utilisée dans HTML et les protocoles Web associés, au-delà de la portée de ce document, comme décrit dans [RFC6454].

4.3.2. Origines http

Bien que HTTP soit indépendant du protocole de transport, le schéma "http" (Section 4.2.1) est spécifique à l'association de l'autorité avec quiconque contrôle le serveur d'origine écoutant les connexions TCP sur le port indiqué de l'hôte identifié dans le composant authority. C'est un sens très faible d'autorité car il dépend à la fois des mécanismes de résolution de noms spécifiques au client et de communications qui pourraient ne pas être sécurisées contre un attaquant sur le chemin. Néanmoins, c'est un minimum suffisant pour lier les identifiants "http" à un serveur d'origine pour une résolution cohérente dans un environnement de confiance.

Si l'identifiant d'hôte est fourni comme une adresse IP, le serveur d'origine est l'écouteur (s'il y en a un) sur le port TCP indiqué à cette adresse IP. Si l'hôte est un nom enregistré, le nom enregistré est un identifiant indirect à utiliser avec un service de résolution de noms, tel que DNS, pour trouver une adresse pour un serveur d'origine approprié.

Lorsqu'un URI "http" est utilisé dans un contexte qui nécessite l'accès à la ressource indiquée, un client PEUT tenter l'accès en résolvant l'identifiant d'hôte en une adresse IP, en établissant une connexion TCP à cette adresse sur le port indiqué, et en envoyant sur cette connexion un message de requête HTTP contenant une cible de requête qui correspond à l'URI cible du client (Section 7.1).

Si le serveur répond à une telle requête avec un message de réponse HTTP non provisoire, comme décrit dans la Section 15, alors cette réponse est considérée comme une réponse autoritaire à la requête du client.

Notez, cependant, que ce qui précède n'est pas le seul moyen d'obtenir une réponse autoritaire, et n'implique pas qu'une réponse autoritaire soit toujours nécessaire (voir [CACHING]). Par exemple, le champ d'en-tête Alt-Svc [ALTSVC] permet à un serveur d'origine d'identifier d'autres services qui sont également autoritaires pour cette origine. L'accès aux ressources identifiées "http" pourrait également être fourni par des protocoles en dehors de la portée de ce document.

4.3.3. Origines https

Le schéma "https" (Section 4.2.2) associe l'autorité en fonction de la capacité d'un serveur à utiliser une clé privée correspondant à un certificat que le client considère comme digne de confiance pour le serveur d'origine identifié. Un client s'appuiera généralement sur une chaîne de confiance, transmise depuis une ancre de confiance préarrangée ou configurée, afin de considérer un certificat comme digne de confiance (Section 4.3.4).

Dans HTTP/1.1 et les versions antérieures, un client n'attribuerait l'autorité à un serveur que lors de la communication via une connexion établie et sécurisée avec succès qui est spécifiquement établie avec l'hôte de l'origine de l'URI. L'établissement de la connexion et la vérification du certificat étaient utilisés comme preuve d'autorité.

Dans HTTP/2 et HTTP/3, un client attribuera l'autorité à un serveur lors de la communication via une connexion établie et sécurisée avec succès si l'hôte de l'origine de l'URI correspond à l'un des hôtes présents dans le certificat du serveur et que le client croit qu'il pourrait ouvrir une connexion à cet hôte pour cet URI. En effet, le client effectuera une requête DNS pour vérifier que l'hôte de l'origine contient la même adresse IP de serveur que la connexion qui a été établie. Un serveur d'origine peut supprimer cette restriction en envoyant une trame ORIGIN équivalente [RFC8336].

Les valeurs d'hôte et de port de la cible de la requête sont transmises sur chaque requête HTTP, identifiant l'origine et la distinguant des autres espaces de noms qui pourraient être contrôlés par le même serveur (Section 7.2). Il est de la responsabilité de l'origine de s'assurer que tous les services fournis avec le contrôle de la clé privée de son certificat sont également responsables de la gestion de l'espace de noms "https" correspondant ou au moins prêts à rejeter les requêtes qui semblent mal dirigées (Section 7.4).

Un serveur d'origine peut ne pas vouloir traiter les requêtes pour certains URI cibles même lorsqu'il est autoritaire pour eux. Par exemple, lorsqu'un hôte exécute des services distincts sur différents ports (par exemple, 443 contre 8000), la vérification de l'URI cible sur le serveur d'origine est nécessaire (même après que la connexion ait été sécurisée) car un attaquant réseau pourrait faire en sorte que les connexions pour un port soient reçues sur un autre port. Le non-vérification de l'URI cible pourrait permettre à un tel attaquant de remplacer la réponse à un URI cible (par exemple, "https://example.com/foo") par une réponse apparemment autoritaire d'un autre port (par exemple, "https://example.com:8000/foo").

Notez que le schéma "https" ne s'appuie pas sur TCP et le numéro de port connecté pour associer l'autorité, car les deux sont en dehors de la communication sécurisée et ne peuvent donc pas être considérés comme définitifs. Par conséquent, la communication HTTP peut avoir lieu sur n'importe quel canal sécurisé, comme défini dans la Section 4.2.2, y compris les protocoles qui n'utilisent pas TCP.

Lorsqu'un URI "https" est utilisé dans un contexte qui nécessite l'accès à la ressource indiquée, un client PEUT tenter l'accès en résolvant l'identifiant d'hôte en une adresse IP, en établissant une connexion TCP à cette adresse sur le port indiqué, en sécurisant la connexion de bout en bout en initiant avec succès TLS sur TCP avec protection de confidentialité et d'intégrité, et en envoyant sur cette connexion un message de requête HTTP contenant une cible de requête qui correspond à l'URI cible du client (Section 7.1).

Si le serveur répond à une telle requête avec un message de réponse HTTP non provisoire, comme décrit dans la Section 15, alors cette réponse est considérée comme une réponse autoritaire à la requête du client.

Notez, cependant, que ce qui précède n'est pas le seul moyen d'obtenir une réponse autoritaire, et n'implique pas qu'une réponse autoritaire soit toujours nécessaire (voir [CACHING]).

4.3.4. Vérification du certificat https

Pour établir une connexion sécurisée pour déréférencer un URI, un client DOIT vérifier que l'identité du service est une correspondance acceptable pour le serveur d'origine de l'URI. La vérification du certificat est utilisée pour empêcher l'usurpation de serveur par un attaquant sur le chemin ou par un attaquant qui contrôle la résolution de noms. Ce processus nécessite que le client soit configuré avec un ensemble d'ancres de confiance.

Typiquement, un client DOIT utiliser le processus de validation défini dans la Section 6 de [RFC6125] pour vérifier l'identité du service. Le client DOIT construire une identité de référence à partir de l'hôte du service: si l'hôte est une adresse IP littérale (Section 4.3.5), alors l'identité de référence est un IP-ID, sinon l'hôte est un nom et l'identité de référence est un DNS-ID.

Un client NE DOIT PAS (MUST NOT) utiliser une identité de référence de type CN-ID. Comme noté dans la Section 6.2.1 de [RFC6125], une identité de référence de type CN-ID pourrait être utilisée par des clients plus anciens.

Un client pourrait être spécialement configuré pour accepter des formes alternatives de vérification de l'identité du serveur. Par exemple, un client pourrait se connecter à un serveur dont l'adresse et le nom d'hôte sont dynamiques, s'attendant à ce que le service présente un certificat spécifique (ou un correspondant à une identité de référence définie extérieurement), plutôt qu'un correspondant à l'origine de l'URI cible.

Dans des cas spéciaux, il pourrait être approprié pour un client d'ignorer simplement l'identité du serveur, mais il doit être compris que cela laisse une connexion ouverte à une attaque active.

Si le certificat n'est pas valide pour l'origine de l'URI cible, un agent utilisateur DOIT soit obtenir la confirmation de l'utilisateur (voir Section 3.5) avant de continuer, soit terminer la connexion avec une erreur de mauvais certificat. Les clients automatisés DOIVENT enregistrer l'erreur dans un journal d'audit approprié, s'il est disponible, et DEVRAIENT (SHOULD) terminer la connexion avec une erreur de mauvais certificat. Les clients automatisés PEUVENT (MAY) fournir un paramètre de configuration qui désactive cette vérification mais DOIVENT fournir un paramètre qui l'active.

4.3.5. Identité de référence IP-ID

Un serveur identifié par un littéral d'adresse IP dans le champ "host" d'un URI "https" a une identité de référence de type IP-ID. Une adresse IP version 4 utilise la règle ABNF "IPv4address", et une adresse IP version 6 utilise la production "IP-literal" avec l'option "IPv6address"; voir Section 3.2.2 de [URI]. L'identité de référence pour un IP-ID contient les octets décodés de l'adresse IP.

Une adresse IP version 4 est de 4 octets, et une adresse IP version 6 est de 16 octets. L'utilisation d'un IP-ID n'est pas définie pour toute autre version IP. Un choix iPAddress dans l'extension subjectAltName d'un certificat n'inclut pas explicitement une version IP, s'appuyant plutôt sur la longueur de l'adresse pour distinguer les versions; voir Section 4.2.1.6 de [RFC5280].

Une identité de référence de type IP-ID correspond si l'adresse est identique à une valeur iPAddress de l'extension subjectAltName du certificat.