标准

Well-known URI 为软件发现某个源站的信息提供约定位置。保留的 /.well-known/ 前缀，减少了不同协议各自设计路径时发生名称冲突的机会；注册后缀则指向定义它的具体规范。这个前缀是一种命名机制，不是自动实现，更不是内容可信的保证。服务器仍需正确路由所支持的端点，客户端也必须按照该端点自己的契约解释响应。 按具体后缀的规范实现 RFC 8615 为支持的 URI 方案保留这一命名空间，不要求每个网站发布所有已注册资源，也没有给所有后缀定义统一响应格式。确定媒体类型、认证、跳转处理、缓存或传输条件之前，应查看 IANA 注册及其引用规范。路径看起来熟悉，不能替代协议规则；不同自动化客户端也不会因为共用前缀，就自然采用相同的读取和验证方式。 对于通过网站发布漏洞联系信息，RFC 9116 规定 security.txt 位于 /.well-known/security.txt，并要求通过 HTTPS 获取。旧位置 /security.txt 可以重定向到标准位置。文档使用 UTF-8 纯文本和规定字段，包括至少一个 Contact 以及唯一的 Expires 字段。Contact 提供报告渠道，不代表邮箱一定有人值守，更不能证明某份报告已经被接收或处理。 文档中的 Expires 字段用时间戳限制信息的新鲜度，它与 HTTP 响应中的 Expires 头不是同一个东西。传输层返回二百，不会让已经过期的联系信息重新变得有效。地址和政策需要持续维护，并在内容过时之前更新。使用 Canonical、Policy 等可选字段时，也应遵守各自规则，不能把文档里任意一个网址都当成已经验证的可信声明。 坏掉的样子 宽泛的应用回退路由可能对任何未知地址都返回首页或登录页，并统一使用二百状态。浅层健康检查认为路径可达，真正的协议客户端却得不到可用文档。因此要保留准确路由，同时检查媒体类型与内容。意外跳转到另一个源站，还可能改变信任上下文，而不只是移动一个文件。仅检查最终状态成功，可能遗漏这些协议层面的错误。 命名空间本身不会认证内容。HTTPS 校验帮助建立到目标主机的连接，文档验证及协议要求的其他检查，才进一步判断内容是否可用。存在安全联系信息，不等于授权外部人员扫描或攻击服务。部署也不能因为一个标准资源计划公开，就不加区分地暴露整个目录。应围绕实际支持的资源配置路由和权限，而不是把前缀当成自动开放所有内容的规则。 ...