Well-Known URIを定義したいなら

 (mnot.net)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • クライアントがすでにサイトを知っていて、サイト全体の情報を効率よく見つける必要があるときは、Well-Known URI が最も適している
  • robots.txt のように中央の場所にポリシーを置けば繰り返し確認する手間を減らせるが、change-password のようにサイト全体の相互作用を開く用途にも使える
  • 実際のURLを渡せるプロトコルが Well-Known URI を使うと、サービスとサイトが1対1で結び付けられ、デプロイとルーティングが硬直化する
  • 発見メカニズムやコンテンツメタデータに適用するときは、開始ホスト名、検索場所、リダイレクト、複数発行者サイトのような 運用構造 を先に検討する必要がある
  • 既存のルート固定パスから移行するには移行計画が必要で、http・https 以外のスキームまで明記したほうが登録成功の可能性が高まる

Well-Known URIが適している場面

  • Well-Known URI specification の著者の一人であり、registry の Designated Expert でもある Mark Nottingham が、Well-Known URI をいつ使うのがよいかという実務上の基準を共有している
  • この基準はすべてが登録要件というわけではなく、ベストプラクティス に近い
  • Well-Known の場所は、クライアントがすでにサイトを知っていて、そのサイト全体について何かを発見したり相互作用したりする必要がある場合に適している
    • ここでいうサイトは、技術的には (scheme, host, port) タプルである origin を意味する
  • robots.txt は RFC より前から存在していたが、Well-Known 空間を予約する主な理由の一つだった
    • クローラーはサイトのアクセス方針を知る必要がある
    • 中央の場所にポリシーを置けば、すべての応答ごとにヘッダーやコンテンツを確認しなくてよくなる
  • Well-Known の場所が必ずしもポリシーだけを含む必要はない
    • クライアントがサイトをすでに知っていて、サイト全体について学習したり相互作用したりするためのメカニズムであれば候補になりうる
    • change-password の Well-Known の場所は、クライアントがサイトのパスワードを変更できるようにする

誤った道具になる場合

  • 一部の設計は、実際の問題があるからではなく、そうすべきに見えるから Well-Known の場所を指定している
  • 登録空間に項目ができたからといって、正当性や採用率が付いてくるわけではない
    • Well-Known の場所は、「クライアントがサイトを知っていて、サイト全体に必要なものがある」という特定の問題を解決する
    • プロトコルにそのような問題がないなら、登録は新たな問題を作るだけで、期待した採用にもつながらない
  • 提案の中には、Well-Known の場所を事実上 URL短縮器 のように使うものがある
    • プロトコルでは完全なURLを渡さず、関連するサイトだけを渡す
    • Well-Known の場所が残りのパスを埋める
  • このパターンはサービスとサイトを 1対1の関係 に固定する
    • デプロイに複数のサービスが必要なら、別のサイトを作らなければならない
    • ユーザーを適切なサイトに送る別の方法も必要になる
  • プロトコルが本当にホスト名しか渡せないなら、Well-Known の場所を使うのは妥当かもしれない
  • 実際のURLを使えるなら、あえて Well-Known の場所を使わないほうがよく、利便性や公式らしさのために選ぶとデプロイが不必要に硬直化する

発見メカニズムで生じる落とし穴

  • 多くのプロトコルは、「ユーザーがすでにサイトを知っている」という前提で Well-Known の場所を 発見メカニズム に使おうとする
  • 実際には、ユーザーの現在の相互作用範囲と、発見が行われる場所がずれることがある
    • クライアントが login.example.com から始めた場合、Well-Known の場所をそのサイトで探すべきか、example.com で探すべきかという問題が生じる
    • 一方から他方へのリダイレクトをたどるべきかどうかも決めなければならない
    • 発行者が相互運用性を確保するために、どのサイトに Well-Known の場所を提供すべきかも不明確になりうる
  • この問題は、プロトコルが実際のWebサイト自体を扱うのではなく、HTTP を別の目的に使う場合にとくに重要になる
  • 登録可能なドメイン名の Well-Known の場所を apex に置くよう指定したくなるかもしれないが、一部の環境では運用上難しいことがある
  • この種のプロトコルでは、何を発見するのかと、ユーザーがどこから始めるのかを合わせて考える必要がある
    • Webアーキテクチャについて過剰に仮定せず、正しいホスト名を安定して見つける方法を決めなければならない

コンテンツメタデータに使うときのトレードオフ

  • 一部のプロトコルは、サイトのコンテンツを把握するために Well-Known の場所を使おうとする
  • /robots.txt はこの方式で動作するが、このパターンがあらゆるコンテンツメタデータに簡単に当てはまるわけではない
  • 多くのサイトは複数の発行者を代表している
    • 例として、過去の /~username/ という慣習がある
  • 中央の場所にコンテンツメタデータを置くと、二つの問題が生じる
    • そのメカニズムが個々のユーザーにとって事実上使えなくなる可能性がある
    • 管理者が、ユーザーの制御を支援し監督するための複雑なインフラを作らなければならない可能性がある
  • このようなデプロイは、利便性と粒度 の間のトレードオフを浮き彫りにする
    • HTTP 応答ヘッダーやコンテンツ自体に並列するメタデータメカニズムを作る必要が出てくるかもしれない
    • 異なるメタデータ付与方法同士の整理も必要になる
  • コンテンツメタデータに Well-Known の場所が使えないわけではないが、想像以上に多くの作業が必要になることがある
  • リソースメタデータに Well-Known の場所を使うプロトコルは、Web の多様なサイト構造を考慮しなければならない

登録と移行時の考慮点

  • すでにルートの固定位置を定義している提案もある
    • /robots.txt のように、後から Well-Known の場所を知った場合がそれに当たる
  • このような場合には、既存デプロイのための 移行計画 が必要になる
    • 提案者は現在のデプロイ基盤に過度に注目しがちな傾向がある
    • 妥当な期間にわたる適切な移行計画があれば、Well-Known の場所への移行を管理できる
  • 多くの提案は http と https の URL を暗黙に前提としている
  • Well-Known の場所は他の URL スキームにも適用されるため、関連するスキームを 明示的に列挙 する必要がある
  • Well-Known の場所は 登録 しなければならない
    • そのリンクには、いつ登録すべきかと、名前をどう選ぶかについての指針がある
    • この登録指針は、前述の助言とは異なり、実際の登録成功可能性に影響する

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsのコメント

  • ルート名前空間に新しい標準を作り続けるのではなく、こういう方式に従ってほしい。たとえば llms.txt を思い出す
    ドメインルートをこれ以上汚すのはやめてほしい
    https://llmstxt.org/

    • LLMs.txt は主要なAI企業に採用されていないので、それ自体あまり意味がないようにも見える

  • 同意しない。この記事はどうせあまり役に立たない。内容がほとんどなく、当たり前のことしか言っていない感じだ
    実際の勧告につながる例がないなら、著者が打ち出している専門性も大して役に立たない

    • 著者は以前 NodeJS で HTTP 418 "I'm a teapot" のサポートを削除しようとし、その結果反発が起きて、Python がむしろサポートを追加した前歴がある
      https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol#Save_418_movement
    • 厳しすぎる。著者は実際に well-known パスを登録したい人たちから質問を受けていた可能性が高く、その中には ~user パスのようなサイト構造を考慮できていない人もいたかもしれない
      この記事によって、そういう人たちがよりよい解決策を使うようになるかもしれない。それでも well-known URL が必要だと確信するなら、登録手続きへのリンクも提供している
    • 記事の要点は、robots.txt のようなものを追加する必要があるなら、ただ適当に置くのではなく、どこにあるのかを知らせるべきだ という点にある

  • なぜこんなに具体的なのかわからない。password-reset の代わりに、もっと汎用的な リンクツリー を置けばいいのではないか？
    Discord のドメイン検証も domain-verifications の下に動的リストを置く方式でよさそうなのに、時間の無駄に見える。自分の用途なら well-known の外に独自仕様を定義すると思う

    • 独自仕様を作っても他の人は使わない
      password-reset well-known エンドポイントは、パスワードマネージャーが UI に "Change password..." ボタンを表示し、その well-known ファイルに書かれたパスワード変更ページへ直接リンクするために使われる
    • discord domain verification は TXT レコード自体がすでに動的な項目一覧なので、別の構造にするより単純だ
      リストを走査しながら各値の先頭部分を検索文字列と比較して discord domain verification を探すほうがはるかに簡単だということ
      たとえば ycombinator.com の TXT レコードには、openai-domain-verification=..., anthropic-domain-verification-..., google-site-verification=..., apple-domain-verification=..., dropbox-domain-verification=..., rippling-domain-verification=... のような値が一緒に入っている
    • discord domain verification は Discord 側の問題だ。IANA レジストリにはない: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
      password-reset をもっと汎用的なリンクツリーにしようという点については、兄弟スレッドでさらに詳しく返答してある: https://news.ycombinator.com/item?id=48596286

  • .well-known、DNS レコード、DNS over HTTP のどの方式であっても、ドメインに固定された信頼 を土台に自律的に発見可能にすることは重要だと思う
    Cloudflare はすでにこの領域の可観測性を製品にかなり追加しているようで、自分も調べているところだ: https://instagrate-me.sudoscience.dev/
    エージェント的な活用が増えるほど、こうしたものを必要とするサービス数も、組織ごとに必要な量もどちらも増えていきそうだ。auth.md も .well-known を使う最近の例に見える

  • 「このウェブサイトを安全に利用するには、よりモダンなブラウザが必要です。ブラウザをアップグレードしてください。」
    代替案としては SNI なしでも可能
    https://web.archive.org/web/20260619061625if_/https://mnot.net/blog/2026/well_known_uris

    • SNI は良いものではないのか？ どんな状況で問題になるのか気になる
    • ウェブ利用者を 監視したり検閲したり する立場なら、SNI は都合が悪い
      だからとても良い

  • change-password レジストリは実際に使われているのか？ ボットですら使っているのかわからない
    自分のサイト群では、ボットが .well-known/change-password URL を確認しているのを見たことがない。公開設定を置く場所としてはよいが、発見手段 としては違う気がする

    • Chrome など一部のパスワードマネージャーは、パスワードが漏えいしたときに UI に "change password" ボタンを表示する
      この機能は .well-known/change-password に基づいている

  • .well-known は最初はきれいに始まったが、静かにウェブルートの がらくた引き出し になってしまった。security.txt、ACME、app-site-association など、増え続けている

    • 何を言いたいのかわからない。そもそもがらくた引き出しとして設計されたものだ
    • 散らばったがらくたより がらくた引き出し のほうがましだ
    • それが目的では？ がらくたをキッチンカウンターの上に散らかす代わりに、「がらくた」とラベルの付いた引き出しに入れておくということだ

  • 1つのドメインに well-known 項目が 複数あり得ること は、しばしば見落とされている気がする

  • タイトルは URI となっているが、記事は URI の一種である URL しか扱っていない

  • でも、その URI って実際どれほど well-known なんだ？ :-\

    • 記事、RFC、Wikipedia、Google を10分ほど漁って .well-known の例を探そうとしたが、1つも見つからなかった
      GitHub OIDC の作業をしていたときに以前1つ読んだことがあり、そのときはかなり役に立った
      技術文書はどうしてあれほど多くの言葉で概念を深く説明するのに、例を1つも出さないのかわからない。こういうケースは初めてではない
    • ここにレジストリとしてまとまっている: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
    • Wikipedia に興味深い一覧がある: https://en.wikipedia.org/wiki/Well-known_URI#List_of_well-known_URIs
    • 同感。いくつか良い例が出てくることを期待していたが見当たらなかった。自分が知っている唯一の例は OIDC discovery endpoint だ
    • Linux 向けソフトウェア開発者の間での XDG ディレクトリ よりもさらに知られていない気がする
      真面目な話、名前が自己矛盾している。/index.html は文字通りよく知られた URL で、大半のウェブ開発者が知っている。だが、あらかじめ定義された意味を持つ URL を大量に作って「well-known」というラベルを貼ったからといって、実際に有名になるわけではない