摘要

  • RFC 3744 将主体表示为可能拥有多个 URL 的 Web 资源，但要求访问控制条目使用唯一的 DAV:principal-URL 规范引用主体。
  • 按人名搜索和主体集合公告可以帮助找到候选项，却不保证目录完整，也不证明身份或授予权限。

屏幕上的名字不是规则里的主体

WebDAV 让客户端能够通过 HTTP 编辑远程文档和集合。它的访问控制扩展需要表达谁可以对某项资源执行哪些操作。用户界面上显示名字看似足够，协议层却需要不同的信息：名字便于人识别，而访问控制条目（ACE）需要服务器能够判定的主体引用。

2004 年 5 月发布的 RFC 3744 把主体定义为代表人或计算代理的网络资源。同一主体可以有多个 URL，例如一个机器生成的路径和一个易读路径。客户端无法仅凭 URL 的外观判断它们是否代表同一主体。DAV:displayname 可以显示可读名称，但它不是身份键。

因此，规范规定了规范化步骤。无论客户端从主体的哪个 URL 查询受保护属性 DAV:principal-URL，服务器都返回同一个指定 URL。创建 ACE 时，客户端必须使用主体 URL；组成员集合也用成员的主体 URL 表示。这样，引用保持一致，而面向用户的别名仍可存在。

这个区别很关键：ACL 关联到资源，ACE 则把主体与被授予或拒绝的权限连接起来。如果一条 ACE 写入某个别名，另一个客户端遇到另一个 URL 时，并没有通用办法推断两者等价。RFC 3744 将这种对应关系放进由服务器维护的受保护属性，而不是让每个客户端各自猜测。

搜索能力不等于完整名册

当主体有成百上千个时，操作者需要查找工具。RFC 3744 定义了 DAV:principal-property-search，可对部分属性做子串搜索；另一个报告则用于查询哪些属性可以搜索。这比强迫用户沿固定目录层级逐级翻找更灵活，但并未承诺所有身份属性都可查询。

服务器可以限制可搜索属性。DAV:principal-collection-set 可以公布一部分主体集合，也可以不公布任何集合。因此它不是完整目录的保证。搜索结果只说明该服务器支持的发现接口找到了候选资源；未出现某人并不能证明此人不存在，两个结果也不自动证明属于同一身份。

客户端流程包含两个问题：“操作者要选择哪个资源？”以及“ACE 应该写入哪个规范 URL？”这两者都没有回答“实际发出请求的是谁”。RFC 3744 将身份认证交给 HTTP 机制。服务器在评估 ACE 时仍须验证请求者并检查 ACL。显示名称、搜索结果、规范引用、认证凭据和有效权限是控制链中的不同记录。

它规定了接口，没有定义完整身份系统

RFC 3744 没有规定如何创建和维护主体资源或群组，也没有规定资源初始 ACL 如何建立。它提供了可以接入不同用户管理库的互操作引用和搜索报告；目录完整性和生命周期治理仍由其他系统负责。

它的历史贡献是一个范围有限的约定：别名可以共存；ACE 需要规范主体 URL；发现能力取决于服务器公开的功能；认证与授权仍是分开的检查。RFC 证明的是标准设计，不是某个产品的采用情况、现实目录的完整性或某次访问事件的结果。

来源