三条客户端铁律：fail-closed 不是口号是攻防清单

规范解读 · 第 7 篇 · 引证源：draft-li-rttp-iqa-addressing-00 §1 / §4.5 / §6 · 姊妹柱：rttp://（CRI 27）· iqa://（CRI 28）

每份设计文档都会在这里遇到同一个质疑：「客户端要求这么多，是不是过度设计？」合并文档的致谢一节其实已经自答：「作者感谢各位对早期修订版的意见——关注点正是客户端行为要求，这部分规范最容易被实现错。」三条铁律不是清单癖，每一条都对应一种用户可嵌入字符串的经典攻击面。

铁律一：禁止以 URI 为导航目标（§4.5.1）。原文：「客户端不得将 rttp 或 iqa URI 的任何组件用作导航目标。凡是渲染由这类 URI 派生的链接、重定向或抓取的客户端，即为开放重定向，属非合规实现。」攻击面：页面嵌入一个 rttp URI，诱导客户端把 authority 当主机去访问——寻址值变成跳转值，这就是开放重定向。规范允许的唯一定向是「客户端自己预先固定的目的地」。

铁律二：scheme 前缀检查（§4.5.2）。原文：「协议处理器必须拒绝任何 scheme 既非 rttp、iqa、也非其自身注册所用 scheme 名的输入；否则它就成了一台通用启动器，任何页面都能借它打开任意 scheme 的任意 URI。」攻击面：处理器只认「不认识的 scheme 就交给系统」——一个 web 页面就能借它拉起其他 handler。前缀检查把处理器锁死在自己的 scheme 上。

铁律三：同意，永不沉默（§4.5.3）。原文：「处理 rttp 或 iqa URI 的能力不得在无用户显式动作的情况下获得；客户端不得模拟、预选或以其他方式绕过该同意。」附带一条隐私纪律：「平台暴露已注册处理器列表之处，该列表不得暴露给网络。」攻击面：静默注册+处理器列表探测=用户指纹。同意必须是一次真实的用户点击。

三条铁律共享同一个底层立场（§1）：「非合规输入被拒绝，永不修复」——fail-closed 不是一种风格，而是一个论断：用户可嵌入的短字符串必然被投喂恶意输入，唯一安全的策略是让所有非预期输入走向显式失败。

一句话：开放重定向、通用启动器、静默指纹——三条铁律各堵一个洞；最容易被实现错的部分，我们写得最多。