摘要

  • RFC 1959 用一个可携带 URL 表示 LDAP 的服务器位置、区别名、返回属性、搜索范围与过滤器；字段省略时触发的是构造查询所用的默认值，并不是对目录状态的观察。
  • 主机可以省略，凭据则根本没有表达位置。因而，同一 URL 可以在不同服务器、会话、访问策略与时间条件下得到不同结果。
  • URL 规定怎样提出一次查询，却不能证明选中了哪台服务器、允许返回哪些属性、结果是否完整结束，或依赖方随后采取了什么行动。

三个斜杠之后，仍有人要选择服务器

1996 年的价值不在于 URL 发明了目录搜索，而在于它让搜索可以进入互联网客户端已经会传递的地址形式。一个文档、页面或程序不必再用一段说明文字交代目录操作；它可以交付一个结构化字符串，由客户端还原成 LDAP 查询。

当时 LDAP 仍被描述为 X.500 目录的轻量前端。RFC 1959 又特意说明，这种 URL 格式也足以面向不以 X.500 为后端的独立 LDAP 服务器。格式因而连接了两种世界：外层是可以复制和传递的互联网 URL，内层仍是有自身命名、协议与访问规则的目录系统。

语法依次放入 ldap://、可选的主机与端口、斜杠后的区别名，以及问号分隔的属性、范围和过滤器。每一段都承担不同责任。主机指向服务器；区别名确定查询起点；属性列表说明客户端想取回哪些字段；范围区分基对象、下一层与整棵子树；过滤器决定哪些条目满足条件。

这也划清了与既有 RFC 1558 长文的边界。RFC 1558 关注可读过滤器如何仍是一棵可执行谓词；RFC 1959 则把过滤器放进更外层的查询封套，并与服务器、起点、属性和范围一起携带。过滤器不能替代其余字段，其余字段也不会改变过滤器内部语法。

省略并不是没有决定

RFC 1959 给若干空位安排了明确含义。未写端口时使用 TCP 389；未写属性时，应请求返回条目的全部属性；未写范围时采用基对象查询；未写过滤器时采用 (objectClass=*)。

这些是查询构造默认值，不是从目录里观察到的事实。属性位置为空，并不报告每个属性都存在；默认存在过滤器并不证明条目真实、最新或对当前访问者开放；基对象范围也不证明那个对象存在。默认值完成了提问方式，服务器仍须执行和判断。

RFC 1959 的密歇根大学子树示例用两个相邻问号把空位保留下来：ldap:///o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)。属性位置故意为空，后面的 sub 和过滤器仍各居其位。这不是遗漏，而是把返回属性交给默认规则。

可选语法因此不是没有责任的真空。它要么把决定交给写明的默认值，要么把决定留给客户端或运行环境。只保存非空字符串的审计记录，会遗漏由“没有写”触发的实际选择。

RFC 1959 还叠加了两种表示。区别名先遵循目录字符串规则；已验证勘误 528 把语法中误写的 RFC 1485 更正为 RFC 1779。空格等 URL 不允许的字符再按 RFC 1738 做百分号编码，过滤器也把自身语法放在 URL 编码之内。

百分号编码让字符串可携带，却不会让区别名自动成为唯一标准形式，也不会让过滤器自动安全，更不会给解码后的值增加权威。客户端必须先恢复内层文本，再按内层语法解析。穿过 URL 边界的字节，与后来选中的目录条目，是两份不同证据。

未写主机，不等于服务器已经确定

ldap:///o=University%20of%20Michigan,c=US 中的三个斜杠非常重要。它没有给出主机。RFC 1959 说，如果条目位于 X.500 名字空间，可以联系任何提供 X.500 后端访问的 LDAP 服务器来解析。

这是一种可移植性，也是一道明确边界。URL 自身没有记录客户端最终选择哪台服务器、那台服务器是否可达、它提供哪一份目录视图，以及查询发生在何时。“任何”不是“所有”，更不是“全球权威”；它只是 1996 年那套 X.500 前提下被允许的解析路径。

一年后取代 RFC 1959 的 RFC 2255 把这部分讲得更清楚：主机缺省时，客户端需要预先知道合适的服务器；它可以新建或复用连接，可以依自身策略选择安全与认证方式，还可以设置 URL 没有写出的大小限制、时间限制和别名解引用等 SearchRequest 字段。

这些后来的说明帮助我们看清早期边界，却不能倒推成 RFC 1959 已经携带了那些字段。1996 年的字符串没有服务器选择算法、连接历史、超时、结果数量上限、别名策略或传输保护记录。历史写作必须同时保留早期格式的能力与它没有声称的能力。

引用里没有随身携带凭据

RFC 1959 的安全考虑只有几行，却给出了一条硬边界：格式没有地方指定解析 URL 时使用的凭据，因此预计查询在无认证状态下进行；其安全影响与普通 LDAP 查询相同。

无认证查询不等于必然越权。目录完全可以有意向匿名访问者公开资料。它也不等于访问者有权得到请求中写出的全部内容。会话所处的访问控制与管理规则，决定当前客户端能看到什么。

因此，“属性省略时应返回全部属性”必须按层理解。在 URL 层，这意味着客户端提出宽范围的默认属性请求；它不能迫使服务器交出被策略隐藏的值。后来的 LDAP 协议明确说明，匹配条目与返回属性仍受访问控制约束，返回条目甚至可以不含任何属性值。

同一个字符串交给两个客户端，也不能证明两者拥有相同身份。一个匿名会话可能得到公开属性，一个获准认证的会话可能得到受限视图，另一个会话则可能收到错误。差异不必来自 URL 矛盾，而可能来自服务器、会话、策略或执行时间不同。

RFC 2255 后来加入扩展机制并讨论认证策略；RFC 4516 又在缺乏已知实现的背景下移除了旧的 bindname 扩展，同时继续强调自动处理 LDAP URL 的安全风险。这段演变证明运行策略必须被单独处理，并不证明 RFC 1959 曾暗中携带凭据。

查询配方不会冻结结果

LDAP 搜索的结果不是一个天然完整的静态对象。现行 RFC 4511 把结果描述为零个或多个条目与引用，最后再由 SearchResultDone 表示成功或错误。RFC 1959 没有把这段消息序列压进 URL，也没有把 URL 变成目录快照。

当 URL 被引用为证据时，它最多可以说明预期的起点、范围、过滤器与返回属性。它不能说明另一时间的服务器仍在评估同一份数据，不能说明大小或时间限制没有截断工作，不能说明引用都被跟随，也不能说明最终成功结果已经到达。

即便收到一个条目，也还不是完整结论。它证明某台服务器在某个结果序列位置向某个客户端发出了这些内容；它并不单独证明完整性、唯一性、新鲜度或超出该服务器语境的权威。依赖程序仍要决定一个结果是否足够、空结果是否有意义、引用是否继续，以及之后的行动是否安全。

RFC 1959 没有替依赖方作这些决定。浏览器可以展示联系资料，配置工具可以预填字段，目录客户端可以发起下一次搜索。每一步都引入新的策略与后果，不能由 URL 字符串自动继承正当性。

后继标准没有取消这道边界

RFC 4516 为 LDAPv3 重新定义 LDAP URL，补充更清楚的百分号编码与扩展机制，并明确指出 LDAP SearchRequest 的全部参数并不能都由这种格式表达。LDAP URL 还可以承载引用知识，但它仍须由客户端在安全策略中解释和执行。

Heng Lu 的“最小初始规范”提供了理解这段历史的尺度：RFC 1959 之所以有用，正因为共同表面足够小，能够被携带。危险在于后来把便利误读为它从未定义的能力，例如服务器发现、身份、权限、完整性和应用意图。

“Running-Code Primacy”则要求每一层留下自身证据。规范证明一种格式被写下；捕获的字符串证明一种表示存在；客户端记录证明默认值如何解析；连接记录证明选中了哪台服务器和什么安全上下文；LDAP 消息证明返回序列；应用日志才证明后续行动。任何前一层都不应冒充后一层。

RFC 1959 让查询能够旅行。它没有让查询成为权威。

来源与边界

RFC 身份、状态和历史由 IETF Datatracker 与 RFC Editor 信息页 记录。原文见 RFC 1959 HTML 和 纯文本，已验证勘误 528 更正 DN 引用。协议、过滤器与 URL 语法背景分别来自 RFC 1777、RFC 1558 与 RFC 1738。后续解析与结果边界见 RFC 2255、RFC 4511 和 RFC 4516。

分析框架来自 Heng Lu 的 Running-Code Primacy、最小初始规范 与 现实层。这些文章用于区分表示、执行与权威，不是某个 LDAP 部署的事实证据。

这些来源能够证明规范及其明示边界；它们不能证明当前部署比例、产品一致性、真实目录内容、实际访问策略、泄露事件或某个依赖系统作出的决定。