Si vous voulez définir un Well-Known URI

 (mnot.net)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Quand le client connaît déjà le site et doit découvrir efficacement des informations concernant l’ensemble du site, un Well-Known URI est la solution la plus adaptée
  • Comme avec robots.txt, placer une politique à un emplacement central peut réduire les vérifications répétées, mais cela peut aussi servir à ouvrir une interaction à l’échelle du site, comme change-password
  • Si un protocole capable de transmettre une URL réelle utilise un Well-Known URI, le service et le site se retrouvent liés en 1:1, ce qui rigidifie le déploiement et le routage
  • Lorsqu’on l’applique à un mécanisme de découverte ou à des métadonnées de contenu, il faut d’abord examiner la structure opérationnelle : nom d’hôte de départ, emplacement de recherche, redirections, sites à plusieurs éditeurs
  • Pour migrer depuis un chemin fixe existant à la racine, un plan de transition est nécessaire, et préciser explicitement les schémas au-delà de http et https augmente les chances de réussite de l’enregistrement

Les cas où un Well-Known URI est approprié

  • Mark Nottingham, l’un des auteurs de la spécification Well-Known URI et Designated Expert du registre, partage des critères pratiques pour savoir quand utiliser un Well-Known URI
  • Tous ces critères ne sont pas des conditions d’enregistrement ; ils relèvent davantage des bonnes pratiques
  • Un emplacement Well-Known convient lorsque le client connaît déjà le site et doit y découvrir quelque chose ou interagir avec lui à l’échelle du site entier
    • Ici, le site désigne techniquement une origin, c’est-à-dire le triplet (scheme, host, port)
  • robots.txt existait avant la RFC, mais c’est l’une des principales raisons pour lesquelles l’espace Well-Known a été réservé
    • Les crawlers doivent connaître la politique d’accès d’un site
    • Placer cette politique à un emplacement central évite d’avoir à vérifier les en-têtes et le contenu de chaque réponse
  • Un emplacement Well-Known ne doit pas nécessairement contenir uniquement une politique
    • Si c’est un mécanisme par lequel le client connaît déjà le site et doit apprendre quelque chose ou interagir avec lui à l’échelle du site, cela peut être un bon candidat
    • L’emplacement Well-Known change-password permet à un client de modifier le mot de passe du site

Quand cela devient le mauvais outil

  • Certaines conceptions définissent un emplacement Well-Known non pas à cause d’un vrai problème, mais parce que cela donne l’impression qu’il faut faire ainsi
  • Le simple fait d’avoir une entrée dans l’espace d’enregistrement ne garantit ni la légitimité ni l’adoption
    • Un emplacement Well-Known résout un problème précis : « le client connaît le site et a besoin de quelque chose à l’échelle du site »
    • Si le protocole ne rencontre pas ce problème, l’enregistrement peut en créer de nouveaux et ne pas mener à l’adoption espérée
  • Certaines propositions utilisent en pratique un emplacement Well-Known comme raccourcisseur d’URL
    • Le protocole ne transmet pas l’URL complète, seulement le site concerné
    • L’emplacement Well-Known complète le reste du chemin
  • Ce modèle fige le service et le site dans une relation 1:1
    • Si le déploiement a besoin de plusieurs services, il faut créer d’autres sites
    • Il faut aussi un mécanisme séparé pour envoyer les utilisateurs vers le bon site
  • Si le protocole ne peut réellement transmettre qu’un nom d’hôte, l’usage d’un emplacement Well-Known peut se justifier
  • Si une URL réelle peut être utilisée, il vaut mieux éviter un emplacement Well-Known ; le choisir pour des raisons de commodité ou d’apparence plus officielle rigidifie inutilement le déploiement

Les pièges des mécanismes de découverte

  • De nombreux protocoles veulent utiliser un emplacement Well-Known comme mécanisme de découverte, en partant du principe que « l’utilisateur connaît déjà le site »
  • En pratique, la portée de l’interaction courante de l’utilisateur et l’endroit où la découverte a lieu peuvent ne pas coïncider
    • Si le client commence sur login.example.com, il faut se demander si l’emplacement Well-Known doit être recherché sur ce site ou sur example.com
    • Il faut aussi décider s’il faut suivre une redirection de l’un vers l’autre
    • Il peut aussi être difficile de savoir sur quel site l’éditeur doit fournir l’emplacement Well-Known pour garantir l’interopérabilité
  • Ce problème est particulièrement important lorsque le protocole ne traite pas réellement du site web lui-même et utilise HTTP à d’autres fins
  • On peut vouloir spécifier que l’emplacement Well-Known d’un nom de domaine enregistrable soit placé à l’apex, mais cela peut être difficile à exploiter dans certains environnements
  • Pour cette catégorie de protocoles, il faut réfléchir à la fois à ce qui est découvert et à l’endroit où l’utilisateur commence
    • Il faut déterminer comment trouver de manière fiable le bon nom d’hôte, sans faire trop d’hypothèses sur l’architecture du Web

Les compromis pour les métadonnées de contenu

  • Certains protocoles veulent utiliser un emplacement Well-Known pour apprendre des informations sur le contenu d’un site
  • /robots.txt fonctionne de cette manière, mais ce modèle ne s’adapte pas facilement à toutes les métadonnées de contenu
  • Beaucoup de sites représentent plusieurs éditeurs
    • L’ancienne convention /~username/ en est un exemple
  • Placer des métadonnées de contenu à un emplacement central pose deux problèmes
    • Le mécanisme concerné peut devenir, dans les faits, inutilisable pour chaque utilisateur individuel
    • L’administrateur peut devoir mettre en place une infrastructure complexe pour prendre en charge et superviser le contrôle des utilisateurs
  • Ces déploiements mettent en évidence un compromis entre commodité et granularité
    • Il peut devenir nécessaire de créer en parallèle un mécanisme de métadonnées dans les en-têtes de réponse HTTP ou dans le contenu lui-même
    • Il faut aussi harmoniser différentes façons d’attacher les métadonnées
  • Cela ne signifie pas qu’un emplacement Well-Known ne peut pas être utilisé pour les métadonnées de contenu, mais cela peut demander bien plus de travail qu’on ne l’imagine
  • Les protocoles qui utilisent un emplacement Well-Known pour des métadonnées de ressource doivent tenir compte de la diversité des structures de site sur le Web

Points à considérer pour l’enregistrement et la transition

  • Certaines propositions définissent déjà un emplacement fixe à la racine
    • C’est le cas lorsqu’on découvre Well-Known après coup, comme pour /robots.txt
  • Dans ce cas, un plan de transition est nécessaire pour les déploiements existants
    • Les auteurs de propositions ont tendance à se concentrer excessivement sur la base de déploiement actuelle
    • Avec un bon plan de transition sur une période raisonnable, il est possible de gérer le passage à un emplacement Well-Known
  • Beaucoup de propositions supposent implicitement des URL http et https
  • Comme les emplacements Well-Known s’appliquent aussi à d’autres schémas d’URL, il faut énumérer explicitement les schémas concernés
  • Un emplacement Well-Known doit être enregistré
    • Ce lien contient des recommandations sur le moment où enregistrer et sur la manière de choisir un nom
    • Contrairement aux conseils précédents, ces consignes d’enregistrement ont un impact réel sur les chances de réussite de l’enregistrement

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis Hacker News

  • J’aimerais qu’on adopte ce genre d’approche au lieu de continuer à créer de nouveaux standards dans l’espace de noms racine. Ça me fait penser à llms.txt
    Il serait temps d’arrêter d’encombrer la racine du domaine
    https://llmstxt.org/

    • LLMs.txt n’a pas été adopté par les grands acteurs de l’IA, donc cela ne semble déjà pas avoir beaucoup de sens en soi

  • Je ne suis pas d’accord. Cet article n’aide pas vraiment de toute façon. Il est presque vide et donne surtout l’impression d’énoncer des évidences
    Sans exemples débouchant sur de vraies recommandations, l’expertise que l’auteur met en avant n’est pas très utile

    • L’auteur a déjà essayé de supprimer dans NodeJS la prise en charge du HTTP 418 "I'm a teapot", ce qui a provoqué un retour de bâton et conduit Python à l’ajouter au contraire
      https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol#Save_418_movement
    • C’est un peu trop harsh. L’auteur a probablement reçu des questions de personnes voulant réellement enregistrer un chemin well-known, et certaines n’avaient peut-être pas pris en compte une structure de site avec des chemins du type ~user
      Cet article pourrait les amener à choisir une meilleure solution. Et s’ils restent convaincus qu’il leur faut une URL well-known, il fournit aussi le lien vers la procédure d’enregistrement
    • L’idée principale de l’article, c’est que si vous devez ajouter quelque chose comme robots.txt, il ne faut pas simplement le poser arbitrairement : il faut indiquer où cela se trouve

  • Pourquoi être aussi spécifique ? Au lieu de password-reset, pourquoi ne pas avoir un arbre de liens plus générique ?
    Même la vérification de domaine Discord pourrait fonctionner avec une liste dynamique sous domain-verifications, mais cela semble être une perte de temps. Pour mon usage, je définirais probablement ma propre spécification en dehors de well-known

    • Si vous créez votre propre spécification, personne d’autre ne l’utilisera
      Le point de terminaison well-known password-reset sert à permettre aux gestionnaires de mots de passe d’afficher un bouton "Change password..." dans l’UI et de pointer directement vers la page de changement de mot de passe indiquée dans ce fichier well-known
    • discord domain verification est plus simple tel quel, parce que l’enregistrement TXT est déjà lui-même une liste dynamique d’éléments
      Autrement dit, il est bien plus simple de parcourir la liste et de comparer le début de chaque valeur avec la chaîne recherchée pour trouver discord domain verification
      Par exemple, les enregistrements TXT de ycombinator.com contiennent ensemble des valeurs comme openai-domain-verification=..., anthropic-domain-verification-..., google-site-verification=..., apple-domain-verification=..., dropbox-domain-verification=..., rippling-domain-verification=...
    • discord domain verification est un problème côté Discord. Ce n’est pas dans le registre IANA : https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
      Pour la partie sur l’idée de faire de password-reset un arbre de liens plus générique, une réponse plus détaillée a été donnée dans un fil frère : https://news.ycombinator.com/item?id=48596286

  • Que ce soit via .well-known, des enregistrements DNS ou DNS over HTTP, je pense qu’il est important de permettre une découverte autonome fondée sur une confiance ancrée dans le domaine
    Cloudflare semble déjà avoir ajouté pas mal d’observabilité produit dans cet espace, et je suis aussi en train d’enquêter là-dessus : https://instagrate-me.sudoscience.dev/
    À mesure que les usages agentiques augmentent, le nombre de services qui auront besoin de ce genre de chose, ainsi que la quantité nécessaire par organisation, va probablement croître. auth.md semble être un autre exemple récent utilisant .well-known

  • « Ce site Web a besoin d’un navigateur plus moderne pour fonctionner en toute sécurité. Veuillez mettre à niveau votre navigateur. »
    Alternative : cela fonctionne aussi sans SNI
    https://web.archive.org/web/20260619061625if_/https://mnot.net/blog/2026/well_known_uris

    • Le SNI, ce n’est pas une bonne chose ? Je me demande dans quelles situations cela pose problème
    • Si votre position consiste à surveiller ou censurer les utilisateurs du Web, le SNI n’est pas une bonne chose
      Donc c’est une très bonne chose

  • Le registre change-password est-il réellement utilisé ? Je ne sais même pas si des bots s’en servent
    Sur mes sites, je n’ai jamais vu de bots consulter l’URL .well-known/change-password. C’est peut-être correct comme emplacement pour des paramètres publics, mais pas vraiment comme mécanisme de découverte

    • Certains gestionnaires de mots de passe, comme celui de Chrome, affichent un bouton "change password" dans l’UI lorsqu’un mot de passe a fuité
      Cette fonctionnalité repose sur .well-known/change-password

  • .well-known avait commencé proprement, mais c’est discrètement devenu le tiroir à bazar de la racine du Web. security.txt, ACME, app-site-association, et la liste continue de s’allonger

    • Je ne vois pas ce que tu veux dire. Cela a précisément été conçu comme un tiroir à bazar dès le départ
    • Un tiroir à bazar vaut mieux qu’un bazar éparpillé
    • N’est-ce pas justement le but ? Au lieu de laisser traîner le bazar sur le plan de travail de la cuisine, on le range dans un tiroir étiqueté bazar

  • Le fait qu’un domaine puisse avoir plusieurs entrées well-known semble souvent être négligé

  • Le titre parle d’URI, mais l’article ne traite en réalité que des URL, qui ne sont qu’un type d’URI

  • Mais au fond, à quel point ces URI sont-ils vraiment well-known ? :-\

    • J’ai passé 10 minutes à fouiller l’article, la RFC, Wikipedia et Google pour trouver des exemples de .well-known, sans en trouver un seul
      J’en avais déjà lu un autrefois en travaillant sur GitHub OIDC, et à l’époque je l’avais trouvé plutôt utile
      Je ne comprends pas pourquoi la documentation technique consacre autant de mots à expliquer un concept en profondeur tout en ne donnant absolument aucun exemple. Ce n’est pas la première fois que je vois ça
    • Ils sont rassemblés ici dans le registre : https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
    • Il y a une liste intéressante sur Wikipedia : https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-known_URIs
    • D’accord. Je m’attendais à voir quelques bons exemples, mais il n’y en avait pas. Le seul que je connaisse est le point de terminaison de découverte OIDC
    • Cela semble encore moins connu que les répertoires XDG parmi les développeurs de logiciels pour Linux
      Sérieusement, le nom est contradictoire. /index.html est littéralement une URL bien connue, que la plupart des développeurs Web connaissent. Mais créer tout un tas d’URL dotées d’une signification prédéfinie et leur coller l’étiquette “well-known” ne les rend pas réellement célèbres