Aussi disponible en : English · Español · Português · العربية
URI well-known
Le registre IANA complet des chemins /.well-known/, avec statut, responsable et date, accompagné d'une mesure de ce que les sites servent réellement.
Ce qu'est /.well-known/
Le RFC 8615 réserve un chemin sur chaque site web. Tout ce qui se trouve sous /.well-known/ est un endroit où un protocole peut déposer un fichier à un emplacement identique sur tous les hôtes, si bien qu'un client sait où regarder sans qu'on le lui dise. C'est ainsi qu'une autorité de certification vérifie que vous contrôlez un domaine, qu'un navigateur trouve votre page de changement de mot de passe, et qu'un téléphone relie une application à un site.
Cela en fait un espace de noms mondial partagé, découpé dans chaque domaine d'internet, et c'est pourquoi il existe un registre plutôt qu'un terrain libre. Il y a 101 chemins enregistrés. Presque toutes les listes qui circulent en comptent une douzaine et aucune date ; celle-ci les contient tous, avec les trois colonnes que le registre publie et que les copies laissent généralement tomber.
La plus intéressante de ces colonnes est celle du responsable, car seuls 36 des 101 relèvent de l'IETF. Le reste appartient à des entreprises et des consortiums précis : 54 organisations distinctes en tout. Quand vous servez un fichier sous /.well-known/, les règles de la plupart de ces chemins ont été écrites par celui qui les a demandés.
Comment se servir de cette liste
- Cherchez par chemin, par responsable ou par spécification. Le champ interroge les trois : vous pouvez donc chercher acme-challenge, ou tout ce que contrôle le W3C, ou tout ce que définit un RFC donné.
- Filtrez par statut. Permanent, provisoire, déconseillé et obsolète sont quatre choses différentes, et une liste recopiée qui les affiche comme un seul type de ligne masque la différence.
- Lisez le tableau de déploiement en dessous. Il montre la même mesure comptée de deux façons, et c'est l'écart entre les colonnes qui compte.
Une réponse 200 ne signifie pas que le fichier est là
Vérifier si un site sert un chemin well-known paraît trivial : on le demande et on regarde si l'on obtient un 200. Cette méthode est presque inutile, et la mesure présentée ici montre à quel point.
Sur 120 domaines, dont 89 ont répondu, le code de statut seul indique que host-meta est servi par 28,1 % d'entre eux. Exiger en plus un type de contenu plausible donne 0,0 %. Pas un seul de ces domaines ne sert un document host-meta : ils servent une application monopage dont la route fourre-tout répond 200 avec une coquille HTML pour n'importe quel chemin demandé, y compris des chemins que personne n'a jamais enregistrés.
La surestimation n'est pas uniforme, et c'est ce qui la rend dangereuse. Pour les chemins réellement répandus elle reste légère : assetlinks.json passe de 61,8 % à 44,9 %, et security.txt de 64,0 % à 42,7 %. Pour les autres elle est catastrophique : change-password chute de 37,1 % à 1,1 %, et mta-sts.txt comme nodeinfo font de même. Un outil qui rapporte la première colonne vous annonce qu'un site prend en charge des choses dont il n'a jamais entendu parler.
Ce qui l'a révélée n'est pas un contrôle en échec mais un motif suspect : host-meta et nodeinfo ont obtenu exactement le même score, 25 occurrences chacun. Deux protocoles sans rapport ne peuvent pas avoir la même adoption : le chiffre mesurait donc la sonde et non le web. Tout contrôle d'existence en HTTP a besoin d'un type de contenu, d'une forme de corps, ou d'un chemin témoin dont on sait qu'il est absent.
Une réserve énoncée clairement : 89 domaines constituent une démonstration, pas un recensement, et il existe des balayages bien plus vastes de ces chemins. Le résultat, c'est l'écart entre les deux colonnes ; les valeurs absolues sont illustratives.
Ce que le registre ne dit pas
Le registre consigne ce qui a été enregistré, ce qui n'est pas la même chose que ce que le web sert. L'exemple le plus net figure dans le tableau de déploiement : apple-app-site-association est servi par environ un tiers des domaines de l'échantillon, ce qui en fait le troisième chemin le plus déployé mesuré ici, et il n'apparaît pas du tout dans le registre. Google a enregistré son équivalent, assetlinks.json ; Apple n'a pas enregistré le sien. Les deux sont sur des millions de sites.
Le statut ne vaut pas davantage comme indicateur d'adoption. change-password n'est toujours que provisoire alors qu'il est implémenté par tous les grands navigateurs et tous les gestionnaires de mots de passe, tandis que quantité d'entrées permanentes ne sont servies par presque personne. Les quatre états décrivent la fermeté de la réservation d'un chemin, pas son usage.
Une entrée s'est vidée de sa substance. Cinq chemins sont déconseillés ou obsolètes, et l'un d'eux, mud, s'est vu retirer à la fois sa référence et son responsable, laissant un nom enregistré qui ne pointe vers rien. Il reste dans la liste plutôt que filtré, car un registre qui admet ne plus savoir à qui appartient quelque chose est plus instructif qu'un tableau bien rangé.
Sur l'exactitude : la page de l'IANA comporte deux tableaux, le registre et un autre listant les contacts des responsables, et racler les lignes sans les distinguer donne 146 entrées pour un registre de 101. Le générateur employé ici identifie le registre par sa ligne d'en-tête, et la suite de tests redérive du HTML source tous les chiffres de cette page plutôt que du fichier généré, avec 971 assertions et 14 contrôles négatifs.
Pourquoi est-ce gratuit ?
Ceci est un tableau dessiné dans votre navigateur. Aucun serveur ne travaille : il n'y a donc rien à facturer ni de compte à créer.
Rien n'est non plus récupéré en votre nom. Un navigateur ne peut pas demander les chemins /.well-known/ d'un autre site, aussi cette page ne prétend-elle pas vérifier votre domaine : elle vous dit ce qui existe et ce que les chiffres signifient vraiment, et les outils de développement ou la ligne de commande feront le reste.