[2] RFC 5785 は URL の「よく知られた場所」 の登録簿を規定しています。これは (主に) HTTP で特定の情報を得たい時にアクセスするべきであるとハードコードされる URL で、 robots.txt のような用途を想定しています。 (が、 robots.txt はこの定義における「よく知られた場所」ではありません。)
/.well-known/{URL接尾辞}のように、「.well-known」が最初の path 部品で、
2つ目の path 部品「URL 接尾辞」が所望の情報を表す名前です。[6] 2つ目の path 部品は構文的には URL segment-nz でなければなりません
>>1。
[7] 3つ目以降は2つ目の「{URL 接尾辞}」部分に依存して好きに使っていいようです。 query, fragment も好きにしてよいとされています >>1。
[8] 基本的には RFC 5226 の手続きに準じて、仕様書があることを条件に指定専門家への諮問を経て登録されます。 詳しくは RFC 5785 を読んでください。
[3] 「よく知られた場所」の規定が適用されるのは特定の URL scheme だけです。
RFC 5785 では http: と https:
に適用するとし、それらを定義する RFC を更新しています。
また、それ以外の URL scheme でも明示的に適用されると規定されていれば適用されることになっています。
[13] 次の URL scheme に適用されることになっています。
[18] 「よく知られた場所」の中には、当該サーバーの管理権限を持つことを確認するためのもの、 当該サーバーの他の資源へのアクセスに関する設定を記述するためのものなど、 セキュリティー的に深刻な影響を持つものもあります。
[19] UGC サービスなどで第三者が任意の path の内容を書き換えられるサーバーでは、 「よく知られた場所」の扱いに十分注意を払う必要があります。
[11] RFC 5785 は http: を規定する RFC 2616
と https: を規定する RFC 2818 を更新する形を採っています。
[12] しかしこれらの改訂である RFC 7230 は RFC 5785 を更新どころか参照すらしておらず、宙に浮いた形になっています。
[16] RFC正誤表における指摘 >>15 は、 RFC 5785 は何も更新していないのだから、 更新という形にするべきではなかったと述べています。
[22] そうはいっても、元は自由に使えることになっていたパスの名前空間に勝手に新しい意味を割り当てるわけですから、 HTTP(S) URL の仕様の一部改訂であり、IETF の手続きとしては更新が相応しかったと思いますが・・・。
[17] HTTPサーバーの実装によっては . から始まる path segment
の URL を使えないかもしれません。
[23] Unix では . から始まるファイル名は隠しファイルを表しており、
設定ファイルやプライベートなファイルなどに使われています。
ファイルシステムを写像する HTTPサーバーの実装や設定は、
そうしたファイルが意図せず漏洩することを防ぐため、
. から始まるファイル名の時 HTTP アクセスを拒否している場合があるのです。
.well-known」という名前なのは衝突を避けるためですが、不恰好ですね。