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 分布式创作与版本控制 (WebDAV, Web Distributed Authoring and Versioning) [RFC4918] 中的 PROPFIND), 但与之相关的感知开销 (无论是客户端感知到的延迟还是部署难度) 常常阻碍其在这些场景中的使用.

与此同时, 将 HTTP 用作非 Web 协议底层载体已更为常见. 有时, 此类协议需要一种在给定主机上定位一个或多个资源的方式.

此时, 一种解决方案是为与整个源相关的数据或服务指定一个「知名位置 (well-known location)」, 以便易于发现. 然而, 这种做法也有缺点: 可能与其他此类指定的「知名位置」以及源已创建 (或希望创建) 的资源发生冲突. 此外, 定义知名位置会侵占源对其自身 URI 空间的控制 [RFC7320].

为应对上述用途, 本备忘录在 HTTP, HTTPS, WebSocket (WS) 与安全 WebSocket (WSS) URI 中为这些「知名位置」保留路径前缀 /.well-known/. 将来需要为此类元数据定义资源的规范可通过注册其用法来避免冲突, 并尽量减少对源 URI 空间的影响.

知名 URI 也可与其他 URI 方案一起使用, 但仅当这些方案的定义明确允许时.