Wenn Sie eine Well-Known-URI definieren möchten

 (mnot.net)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn der Client die Website bereits kennt und Informationen über die gesamte Website effizient finden muss, ist eine Well-Known-URI am besten geeignet
  • Eine Richtlinie an einem zentralen Ort wie robots.txt kann wiederholte Prüfungen reduzieren, kann aber auch dazu dienen, websiteweite Interaktionen wie change-password zu ermöglichen
  • Wenn ein Protokoll, das tatsächliche URLs übergeben kann, eine Well-Known-URI verwendet, werden Dienst und Website in einer 1:1-Beziehung verknüpft, wodurch Deployment und Routing unflexibel werden
  • Bei der Anwendung auf Discovery-Mechanismen oder Inhaltsmetadaten sollten zunächst Betriebsstrukturen wie Start-Hostname, Suchort, Redirects und Websites mit mehreren Herausgebern geprüft werden
  • Für den Wechsel von einem bestehenden fest verdrahteten Root-Pfad ist ein Migrationsplan nötig; außerdem steigen die Erfolgschancen einer Registrierung, wenn neben http und https auch andere Schemes ausdrücklich genannt werden

Wann eine Well-Known-URI gut passt

  • Mark Nottingham, Mitautor der Well-Known URI specification und Designated Expert des registry, teilt praktische Kriterien dafür, wann sich Well-Known-URIs eignen
  • Diese Kriterien sind nicht allesamt Registrierungsanforderungen, sondern eher Good Practices
  • Ein Well-Known-Ort ist geeignet, wenn der Client die Website bereits kennt und für diese gesamte Website etwas entdecken oder mit ihr interagieren muss
    • Mit Website ist hier technisch der Origin gemeint, also das Tupel (scheme, host, port)
  • robots.txt existierte schon vor dem RFC, war aber einer der Hauptgründe dafür, den Well-Known-Bereich zu reservieren
    • Crawler müssen die Zugriffsrichtlinien einer Website kennen
    • Wenn die Richtlinie an einem zentralen Ort liegt, müssen nicht bei jeder Antwort Header und Inhalte geprüft werden
  • Ein Well-Known-Ort muss nicht ausschließlich Richtlinien enthalten
    • Wenn es sich um einen Mechanismus handelt, bei dem der Client die Website bereits kennt und etwas über die gesamte Website lernen oder mit ihr interagieren muss, kommt er infrage
    • Der Well-Known-Ort change-password ermöglicht es dem Client, das Passwort der Website zu ändern

Wann es das falsche Werkzeug ist

  • Manche Entwürfe definieren einen Well-Known-Ort nicht wegen eines realen Problems, sondern weil es so aussieht, als sollte man das tun
  • Ein Eintrag im Registry-Bereich bringt nicht automatisch Legitimität oder Akzeptanz mit sich
    • Ein Well-Known-Ort löst das konkrete Problem „Der Client kennt die Website und braucht etwas für die gesamte Website“
    • Wenn ein Protokoll dieses Problem nicht hat, kann eine Registrierung neue Probleme schaffen und trotzdem nicht zur erhofften Akzeptanz führen
  • Manche Vorschläge verwenden einen Well-Known-Ort faktisch als URL-Kürzel
    • Das Protokoll übergibt nicht die vollständige URL, sondern nur die zugehörige Website
    • Der Well-Known-Ort ergänzt den restlichen Pfad
  • Dieses Muster fixiert Dienst und Website in einer 1:1-Beziehung
    • Wenn ein Deployment mehrere Dienste braucht, muss eine weitere Website erstellt werden
    • Außerdem wird ein zusätzlicher Mechanismus nötig, um Benutzer an die passende Website zu leiten
  • Wenn ein Protokoll wirklich nur Hostnamen übergeben kann, kann der Einsatz eines Well-Known-Orts gerechtfertigt sein
  • Wenn tatsächliche URLs verwendet werden können, ist es meist besser, keinen Well-Known-Ort zu verwenden; ihn aus Bequemlichkeit oder wegen des formellen Eindrucks zu wählen, macht Deployments unnötig starr

Fallstricke bei Discovery-Mechanismen

  • Viele Protokolle wollen einen Well-Known-Ort als Discovery-Mechanismus verwenden, unter der Annahme, dass „der Benutzer die Website bereits kennt“
  • In der Praxis können jedoch der aktuelle Interaktionskontext des Benutzers und der Ort der Discovery auseinanderfallen
    • Wenn der Client bei login.example.com startet, stellt sich die Frage, ob der Well-Known-Ort dort oder bei example.com gesucht werden soll
    • Es muss auch festgelegt werden, ob Redirects von der einen zur anderen Seite verfolgt werden sollen
    • Ebenso kann unklar sein, auf welcher Website ein Herausgeber den Well-Known-Ort bereitstellen muss, um Interoperabilität zu gewährleisten
  • Dieses Problem ist besonders wichtig, wenn das Protokoll nicht die eigentliche Website behandelt, sondern HTTP für andere Zwecke nutzt
  • Man möchte vielleicht festlegen, dass der Well-Known-Ort eines registrierbaren Domainnamens am Apex liegt, doch in manchen Umgebungen kann das betrieblich schwierig sein
  • Protokolle dieser Kategorie müssen gemeinsam betrachten, was entdeckt wird und wo der Benutzer startet
    • Es muss eine Methode festgelegt werden, um den richtigen Hostnamen zuverlässig zu finden, ohne zu viele Annahmen über die Web-Architektur zu machen

Abwägungen beim Einsatz für Inhaltsmetadaten

  • Manche Protokolle wollen einen Well-Known-Ort verwenden, um etwas über die Inhalte einer Website zu lernen
  • /robots.txt funktioniert auf diese Weise, aber dieses Muster passt nicht ohne Weiteres auf alle Arten von Inhaltsmetadaten
  • Viele Websites repräsentieren mehrere Herausgeber
    • Ein Beispiel ist die frühere Konvention /~username/
  • Wenn Inhaltsmetadaten an einem zentralen Ort abgelegt werden, entstehen zwei Probleme
    • Der Mechanismus kann für einzelne Benutzer faktisch unbenutzbar werden
    • Administratoren müssen womöglich eine komplexe Infrastruktur aufbauen, um Benutzerkontrolle und Aufsicht zu unterstützen
  • Solche Deployments machen den Zielkonflikt zwischen Bequemlichkeit und Granularität sichtbar
    • Es kann nötig werden, einen parallelen Metadatenmechanismus in HTTP-Response-Headern oder im Inhalt selbst zu schaffen
    • Außerdem muss geklärt werden, wie verschiedene Arten der Metadatenzuordnung zusammenwirken
  • Das bedeutet nicht, dass man für Inhaltsmetadaten keinen Well-Known-Ort verwenden kann, aber der Aufwand kann deutlich höher sein als erwartet
  • Protokolle, die einen Well-Known-Ort für Ressourcenmetadaten verwenden, müssen die vielfältigen Site-Strukturen des Webs berücksichtigen

Was bei Registrierung und Migration zu beachten ist

  • Es gibt auch Vorschläge, die bereits einen festen Ort im Root definieren
    • Das ist etwa dann der Fall, wenn man wie bei /robots.txt erst später von Well-Known-Orten erfährt
  • In solchen Fällen wird ein Migrationsplan für bestehende Deployments benötigt
    • Vorschlagende konzentrieren sich oft zu stark auf die aktuelle Deployment-Basis
    • Mit einem guten Übergangsplan über einen angemessenen Zeitraum lässt sich die Migration zu einem Well-Known-Ort steuern
  • Viele Vorschläge setzen stillschweigend http- und https-URLs voraus
  • Well-Known-Orte gelten aber auch für andere URL-Schemes, daher sollten die relevanten Schemes ausdrücklich aufgelistet werden
  • Well-Known-Orte müssen registriert werden
    • Der Link enthält Hinweise dazu, wann eine Registrierung sinnvoll ist und wie ein Name gewählt werden sollte
    • Anders als die vorherigen Ratschläge beeinflussen diese Registrierungsrichtlinien tatsächlich die Erfolgschancen einer Registrierung

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Ich wünschte, man würde diesem Ansatz folgen, statt immer neue Standards im Root-Namespace anzulegen. Dabei fällt mir zum Beispiel llms.txt ein
    Es wäre schön, wenn man endlich aufhören würde, die Domain-Root zu vermüllen
    https://llmstxt.org/

    • LLMs.txt wurde von den großen AI-Anbietern nicht übernommen, daher wirkt es für sich genommen auch nicht besonders sinnvoll

  • Stimme nicht zu. Dieser Artikel hilft ohnehin kaum weiter. Er enthält fast nichts und sagt nur Offensichtliches
    Wenn es keine Beispiele gibt, die zu tatsächlichen Empfehlungen führen, ist auch die vom Autor beanspruchte Expertise nicht besonders nützlich

    • Der Autor hatte früher versucht, die Unterstützung für HTTP 418 "I'm a teapot" aus NodeJS zu entfernen, woraufhin es Gegenwind gab und Python die Unterstützung im Gegenteil sogar hinzugefügt hat
      https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol#Save_418_movement
    • Das ist zu harsh. Der Autor hat wahrscheinlich Fragen von Leuten bekommen, die tatsächlich einen well-known-Pfad registrieren wollten, und einige davon haben womöglich keine Site-Strukturen wie den ~user-Pfad bedacht
      Dieser Artikel könnte solche Leute dazu bringen, eine bessere Lösung zu wählen. Und wenn sie trotzdem sicher sind, dass sie eine well-known-URL brauchen, liefert er auch einen Link zum Registrierungsverfahren
    • Der Kern des Artikels ist, dass man etwas wie robots.txt nicht einfach willkürlich irgendwo ablegen sollte, wenn man es hinzufügen muss, sondern angeben sollte, wo es sich befindet

  • Warum ist das so spezifisch? Warum nicht statt password-reset einen allgemeineren Link-Baum anlegen?
    Auch die Domain-Verifizierung von Discord könnte doch einfach unter domain-verifications eine dynamische Liste führen; das wirkt wie Zeitverschwendung. Für meinen Anwendungsfall würde ich wohl außerhalb von well-known eine eigene Spezifikation definieren

    • Wenn du deine eigene Spezifikation machst, nutzt sie niemand sonst
      Der password-reset-well-known-Endpunkt wird dafür verwendet, dass Passwortmanager in der UI einen "Change password..."-Button anzeigen und direkt auf die in dieser well-known-Datei angegebene Passwortänderungsseite verlinken
    • discord domain verification ist schon deshalb einfacher, weil der TXT-Record selbst bereits eine dynamische Liste von Einträgen ist
      Es ist viel einfacher, durch die Liste zu iterieren und den Anfang jedes Werts mit dem Suchstring zu vergleichen, um discord domain verification zu finden
      Zum Beispiel enthalten die TXT-Records von ycombinator.com gemeinsam Werte wie openai-domain-verification=..., anthropic-domain-verification-..., google-site-verification=..., apple-domain-verification=..., dropbox-domain-verification=..., rippling-domain-verification=...
    • discord domain verification ist ein Problem auf Seiten von Discord. Im IANA-Register steht es nicht: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
      Auf den Punkt, password-reset in einen allgemeineren Link-Baum zu verwandeln, wird im Schwesterthread ausführlicher geantwortet: https://news.ycombinator.com/item?id=48596286

  • Ob nun .well-known, DNS-Records oder DNS over HTTP: Ich halte es für wichtig, Dinge auf Basis von an die Domain gebundenem Vertrauen autonom auffindbar zu machen
    Cloudflare scheint in seinem Produkt bereits ziemlich viel Beobachtbarkeit in diesem Bereich ergänzt zu haben, und ich schaue mir das ebenfalls an: https://instagrate-me.sudoscience.dev/
    Je mehr agentische Anwendungen zunehmen, desto mehr Dienste werden so etwas brauchen, und auch die benötigte Menge pro Organisation dürfte steigen. auth.md scheint ebenfalls ein aktuelles Beispiel zu sein, das .well-known verwendet

  • „Diese Website benötigt einen moderneren Browser, um sicher zu funktionieren. Bitte aktualisieren Sie Ihren Browser.“
    Als Alternative ist es auch ohne SNI möglich
    https://web.archive.org/web/20260619061625if_/https://mnot.net/blog/2026/well_known_uris

    • Ist SNI nicht etwas Gutes? Ich frage mich, in welchen Situationen das problematisch ist
    • Wenn man Webnutzer überwachen oder zensieren will, ist SNI nicht gut
      Also ist es sehr gut

  • Wird das change-password-Register tatsächlich genutzt? Ich weiß nicht einmal, ob Bots es verwenden
    Auf meinen Sites habe ich noch nie gesehen, dass Bots die URL .well-known/change-password prüfen. Als Ort für öffentliche Einstellungen ist es okay, aber als Entdeckungsmechanismus scheint es mir nicht geeignet

    • Einige Passwortmanager wie Chrome zeigen in der UI einen "change password"-Button an, wenn ein Passwort kompromittiert wurde
      Diese Funktion basiert auf .well-known/change-password

  • .well-known hat sauber angefangen, ist aber still und leise zur Krimskrams-Schublade der Web-Root geworden. security.txt, ACME, app-site-association und immer mehr kommen dazu

    • Ich verstehe nicht, was du meinst. Es wurde von Anfang an als Krimskrams-Schublade entworfen
    • Eine Krimskrams-Schublade ist besser als verstreuter Krimskrams
    • Ist das nicht genau der Zweck? Statt den Krimskrams über die Küchentheke zu verteilen, legt man ihn in eine Schublade mit der Aufschrift Krimskrams

  • Dass es mehrere well-known-Einträge pro Domain geben kann, wird anscheinend oft übersehen

  • Im Titel steht URI, aber der Artikel behandelt nur URLs, also nur eine Art von URI

  • Aber wie well-known sind diese URIs eigentlich wirklich? :-\

    • Ich habe 10 Minuten lang in dem Artikel, dem RFC, Wikipedia und bei Google nach Beispielen für .well-known gesucht und kein einziges gefunden
      Ich hatte früher beim Arbeiten mit GitHub OIDC einmal eines gesehen, und damals war es ziemlich nützlich
      Ich verstehe nicht, warum technische Dokumentation ein Konzept mit so vielen Worten in die Tiefe erklärt und dann nicht ein einziges Beispiel liefert. Das ist nicht das erste Mal, dass ich so etwas sehe
    • Hier sind sie im Register gesammelt: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
    • Auf Wikipedia gibt es eine interessante Liste: https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-known_URIs
    • Stimme zu. Ich hatte ein paar gute Beispiele erwartet, aber keine gesehen. Das einzige, das ich kenne, ist der OIDC-Discovery-Endpunkt
    • Es scheint sogar weniger bekannt zu sein als die XDG-Verzeichnisse unter Entwicklern von Software für Linux-Zielsysteme
      Ernsthaft gesagt ist der Name widersprüchlich. /index.html ist buchstäblich eine wohlbekannte URL, und die meisten Webentwickler kennen sie. Aber viele URLs mit vordefinierter Bedeutung anzulegen und ihnen das Etikett „well-known“ zu geben, macht sie dadurch nicht tatsächlich bekannt