摘要

  • REGEXT 工作组的 RDAP 扩展草案要求：发出重定向的服务器不得盲目复制原请求参数；只有知道目标能够处理、也适合接收参数内容，才可将其写进新 URL。
  • 草案要求面向跨权威服务器发现的扩展不能依赖查询参数承载必要信息。客户端已知道权威服务器、直接向它发起搜索时，可以使用参数。

门牌换对了，问法却变了

草案第 4.1 节从一个真实的部署条件切入：依据 IANA 初始分配寻找 RIR 服务器，无法覆盖资源后来在 RIR 之间转手的情况。第一台服务器可以用 HTTP Location 把客户端送到现管 RIR。紧接着，草案同节给这次交接设下双重门槛：不能把原请求的参数照抄进 Location；只有明确知道下一站能处理、且适合接收参数内容，才允许带上。重定向解决“去哪儿问”，参数还要回答“凭什么跟过去”。

RFC 9224规定如何使用 IANA 的分配登记表定位权威 RDAP 服务。这个流程提供的是可计算的起点，草案指出跨 RIR 转移需要之后的重定向。一次查询因此可能涉及两家登记机构：第一家掌握引路决定，第二家掌握当前记录。前者不能因为后者是正确保管者，就把用户交给自己的所有参数一并移交。

RFC 7480规定服务器忽略未知查询参数。扩展草案进一步给发出重定向的一方划线：不得把收到的参数不加判断地拼进 Location URL。参数里可能有安全凭据或跟踪信息，和目标服务器毫无关系。原服务器要同时知道两件事，才能转交：目标有处理该参数的能力，目标也适合接收参数的实际内容。会读一项字段，不等于有权拿到字段里的值。

草案第 5.1 节承认参数在跨权威重定向中无法保证存活，并据此要求扩展作者：涉及权威服务器发现的功能，不能靠参数独自承载必要信息。后果很具体。原服务器按第 4.1 节留住参数，客户端仍可收到基础 RDAP 记录；若产品只统计 HTTP 成功，额外请求的结果缺席便被成功率掩盖。无条件传递参数则可能把凭据或跟踪信息交给另一家。安全的删减与功能的缩水，必须由产品如实区分。

直接查询可以走另一条路

草案允许在客户端事先知道权威服务器、直接向它请求时使用查询参数，并以搜索为例。问题出在必须先发现权威服务器、过程中可能跨机构重定向的功能。扩展作者不能把必要信息只装在一个可能在交接处被拿掉的参数里。功能的承诺要按实际查询路线设计，不能拿实验室里直连一个端点的结果充数。

还有一种看似聪明的办法：让客户端读取重定向附带的 RDAP 内容，自己重组下一次请求。草案列出代价。部分浏览器客户端无法读取重定向中的 RDAP 内容；手动处理还要面对循环、参数冲突和 URL 编码。这些工作都压到了客户端，而原本的扩展设计并没有解决跨权威边界。

IETF 文件状态页列出第 17 版，状态仍是 REGEXT 工作组活跃草案及 IESG 的“I-D Exists”。它尚未成为 RFC。第 4.1 节把参数转交的判断交给发出重定向的服务器；第 5.1 节则要求扩展作者别把核心功能建立在参数必定通过的假设上。

这份条款组合给采购和审计留下一个可以实测的问题：同一项扩展，直连现管 RIR 与经 IANA 引导、再跨 RIR 重定向，两条路径返回的额外字段是否一致？读出两条路径的 Location 和最终答复，比数一个“成功”更能说明产品究竟交付了什么。

来源