1. はじめに

1. はじめに

一部の Web アプリケーションは, リクエストを行う前にオリジン (origin) [RFC6454] に関する情報 (「サイト全体メタデータ (site-wide metadata)」と呼ばれることもある) を発見する必要がある. 例えば Robots Exclusion Protocol (http://www.robotstxt.org) は, 自動化されたプロセスがリソースへのアクセス許可を得る方法を規定する. 同様に Platform for Privacy Preferences (P3P) [P3P] は, ユーザエージェント (user agent) がオリジンサーバとやり取りする前にプライバシーポリシーを発見する方法を示す.

リソース単位のメタデータにアクセスする方法はいくつかある (例: HTTP ヘッダフィールド, Web Distributed Authoring and Versioning (WebDAV) [RFC4918] の PROPFIND) が, それに伴う認識上のオーバーヘッド (クライアントが感じる遅延やデプロイの難しさのいずれか, または両方) により, これらのシナリオではしばしば使われない.

同時に, HTTP を Web 以外のプロトコルの下層として使うことが一般化している. そのようなプロトコルでは, 所定のホスト上の 1 つ以上のリソースを見つける手段が必要になることがある.

その場合の解の 1 つは, オリジン全体に関連するデータやサービスのために「well-known location (よく知られた場所)」を指定し, 容易に見つけられるようにすることである. しかしこの方式は, 他の同様に指定された「well-known location」との衝突や, オリジンが作成した (または作成したい) リソースとの衝突のリスクがある. さらに, well-known location を定義することは, オリジンが自身の URI 空間をコントロールする権利を奪う [RFC7320].

これらの用途に対処するため, 本メモは HTTP, HTTPS, WebSocket (WS), Secure WebSocket (WSS) の URI に, これらの「well-known location」用のパス接頭辞 /.well-known/ を予約する. 将来, この種のメタデータ用リソースを定義する必要がある仕様は, 登録することで衝突を避け, オリジンの URI 空間への影響を最小化できる.

Well-known URI は他の URI スキームでも使えるが, 当該スキームの定義で明示的に許可されている場合に限る.