3. URI bien connus
3. URI bien connus
Un URI bien connu (well-known URI) est un URI [RFC3986] dont le composant de chemin commence par les caractères /.well-known/, à condition que le schéma soit explicitement défini pour prendre en charge les URI bien connus.
Par exemple, si une application enregistre le nom example, l’URI bien connu correspondant sur http://www.example.com/ serait http://www.example.com/.well-known/example.
La présente spécification met à jour les schémas http [RFC7230] et https [RFC7230] pour prendre en charge les URI bien connus. D’autres schémas existants peuvent suivre le processus approprié pour mettre à jour leurs définitions ; par exemple [RFC8307] le fait pour les schémas ws et wss. Le registre « Uniform Resource Identifier (URI) Schemes » indique quels schémas prennent en charge les URI bien connus ; voir la section 5.2.
Les applications qui souhaitent créer de nouveaux URI bien connus MUST les enregistrer selon les procédures de la section 5.1, sous réserve des exigences suivantes.
Les noms enregistrés MUST se conformer à la production segment-nz de [RFC3986]. Ils ne peuvent donc pas contenir le caractère /.
Les noms enregistrés pour une application donnée SHOULD être précis à propos ; l’occupation de termes génériques est déconseillée. Par exemple, si l’application Example veut un emplacement bien connu pour des métadonnées, un nom enregistré approprié pourrait être example-metadata ou même example.com-metadata, et non metadata.
Un enregistrement référencera au minimum une spécification qui définit le format et le ou les types de média (media types) obtenus en déréférençant l’URI bien connu, ainsi que le ou les schémas d’URI avec lesquels l’URI bien connu peut être utilisé. Si aucun schéma n’est explicitement indiqué, http et https sont supposés.
En général, les applications utiliseront le port par défaut pour le schéma concerné ; si un port alternatif est utilisé, il MUST être explicitement précisé par l’application concernée.
Les enregistrements MAY également contenir des informations supplémentaires, telles que la syntaxe de composants de chemin, de chaînes de requête et/ou d’identifiants de fragment à ajouter à l’URI bien connu, ou des détails propres au protocole (par ex. gestion des méthodes HTTP [RFC7231]).
Notamment, cette spécification ne définit ni comment déterminer le nom d’hôte à utiliser pour trouver l’URI bien connu d’une application donnée, ni la portée des métadonnées découvertes en déréférençant l’URI bien connu ; ces deux aspects doivent être définis par l’application elle-même.
De plus, cette spécification ne définit pas de format ni de type de média pour la ressource située à /.well-known/, et les clients ne devraient pas s’attendre à ce qu’une ressource existe à cet emplacement.
Les URI bien connus sont ancrés au sommet de la hiérarchie du chemin ; par définition, ils ne sont pas « bien connus » dans d’autres parties du chemin. Par exemple, /.well-known/example est un URI bien connu, alors que /foo/.well-known/example ne l’est pas.
Voir également la section 4 pour les considérations de sécurité relatives aux emplacements bien connus.
3.1. Enregistrer des URI bien connus
Le registre « Well-Known URIs » se trouve à https://www.iana.org/assignments/well-known-uris/. Les demandes d’enregistrement peuvent être faites en suivant les instructions qui y figurent ou en envoyant un courriel à la liste [email protected].
Une demande d’enregistrement comprend au moins les informations suivantes :
URI suffix : le nom demandé pour l’URI bien connu, relatif à /.well-known/ ; par ex. example.
Change controller : pour les RFC Standards Track, indiquer « IETF ». Sinon, donner le nom de la partie responsable. D’autres détails (adresse électronique, URI de page d’accueil, etc.) peuvent être inclus.
Specification document(s) : référence au document qui spécifie le champ, de préférence avec un URI permettant d’en obtenir une copie. Une indication des sections pertinentes peut être incluse, mais n’est pas obligatoire.
Status : permanent ou provisional. Voir les indications ci-dessous.
Related information : éventuellement, des citations vers des documents supplémentaires contenant d’autres informations pertinentes.
Les exigences générales pour les valeurs enregistrées sont décrites à la section 3.
Les valeurs définies par des RFC Standards Track et d’autres standards ouverts (au sens de [RFC2026], section 7.1.1) ont le statut permanent. D’autres valeurs peuvent aussi être enregistrées comme permanentes si les experts estiment, en concertation avec la communauté, qu’elles sont utilisées. Les autres valeurs devraient être enregistrées comme provisional.
Les entrées provisoires peuvent être supprimées par les experts si, en concertation avec la communauté, ils estiment qu’elles ne sont pas utilisées. Les experts peuvent passer le statut d’une entrée provisoire à permanent ; ce faisant, ils devraient évaluer l’ampleur de l’usage de la valeur et consulter la communauté au préalable.
La mention « consulter la communauté » ci-dessus désigne les personnes responsables du ou des schémas d’URI concernés. En général, cela se fait sur la ou les listes de diffusion du groupe de travail approprié (éventuellement clos), ou sur [email protected] s’il n’existe pas de telle liste.
Des tiers (y compris le ou les experts) peuvent enregistrer des URI bien connus si les experts estiment qu’un URI bien connu non enregistré est largement déployé et qu’il ne sera probablement pas enregistré à temps autrement. De tels enregistrements restent soumis aux exigences définies, y compris la nécessité de référencer une spécification.