[2] RFC 5785 は URL の「よく知られた場所well-known locations」 の登録簿を規定しています。これは (主に) HTTP で特定の情報を得たい時にアクセスするべきであるとハードコードされる URL で、 robots.txt のような用途を想定しています。 (が、 robots.txt はこの定義における「よく知られた場所」ではありません。)

仕様書

構文

[4] URL の path 部は

/.well-known/{URL接尾辞}
のように、「.well-known」が最初の path 部品で、 2つ目の path 部品「URL 接尾辞suffix」が所望の情報を表す名前です。

[5] 「.well-known」という名前なのは衝突を避けるためですが、不恰好ですね。

[6] 2つ目の path 部品は構文的には URL segment-nz でなければなりません >>1。

[7] 3つ目以降は2つ目の「{URL 接尾辞}」部分に依存して好きに使っていいようです。 query, fragment も好きにしてよいとされています >>1。

登録

[8] 基本的には RFC 5226 の手続きに準じて、仕様書があることを条件に指定専門家への諮問を経て登録されます。 詳しくは RFC 5785 を読んでください。

[9] 新しい「よく知られた場所」を作ろうとするアプリケーションは、URL接尾辞を登録しなければなりません >>1。

[10] 「アプリケーション」の定義が若干微妙ではありますが、これにより、 「/.well-known/」ではじまる URL の一般利用は禁止されることになります。

path の一覧

[20] 主要なパスURL path
  • /.well-known/dnt/

対応 URL scheme の一覧

[3] 「よく知られた場所」の規定が適用されるのは特定の URL scheme だけです。 RFC 5785 では http: と https: に適用するとし、それらを定義する RFC を更新updateしています。 また、それ以外の URL scheme でも明示的に適用されると規定されていれば適用されることになっています。

[13] 次の URL scheme に適用されることになっています。

セキュリティー

[18] 「よく知られた場所」の中には、当該サーバーの管理権限を持つことを確認するためのもの、 当該サーバーの他の資源へのアクセスに関する設定を記述するためのものなど、 セキュリティー的に深刻な影響を持つものもあります。

[19] UGC サービスなどで第三者が任意の path の内容を書き換えられるサーバーでは、 「よく知られた場所」の扱いに十分注意を払う必要があります。

[25] サーバーは、自己の管理下に置くよう適切な処置を取るべきです >>24。

[21] ブログサービスの中には記事のパスURL pathを利用者が設定できるようにしているものもありますが、 悪意ある利用者が /.well-known/ 以下に任意の内容の記事を書けると、 困ることもあるかもしれません。

関連

[26] META-INF/, 特別なファイル名

歴史

[11] RFC 5785 は http: を規定する RFC 2616 と https: を規定する RFC 2818 を更新する形を採っています。

[12] しかしこれらの改訂である RFC 7230 は RFC 5785 を更新どころか参照すらしておらず、宙に浮いた形になっています。

[16] RFC正誤表における指摘 >>15 は、 RFC 5785 は何も更新していないのだから、 更新という形にするべきではなかったと述べています。

[22] そうはいっても、元は自由に使えることになっていたパスURL pathの名前空間に勝手に新しい意味を割り当てるわけですから、 HTTP(S) URL の仕様の一部改訂であり、IETF の手続きとしては更新が相応しかったと思いますが・・・。

メモ

[17] HTTPサーバーの実装によっては .FULL STOP から始まる path segment の URL を使えないかもしれません。

[23] Unix では .FULL STOP から始まるファイル名は隠しファイルを表しており、 設定ファイルやプライベートなファイルなどに使われています。 ファイルシステムを写像する HTTPサーバーの実装や設定は、 そうしたファイルが意図せず漏洩することを防ぐため、 .FULL STOP から始まるファイル名の時 HTTP アクセスを拒否している場合があるのです。