摘要

  • 11 月 2 日发布的 draft-ietf-rpp-core-01 新增重定向规则。这是 IETF 工作组的互联网草案，尚未成为 RFC。
  • RPP 服务器只能用 HTTP 307 或 308 和绝对 HTTPS 地址转址。客户端若跟随，必须保留请求内容及全部请求头，包括交易标识 RPP-Cltrid。
  • 目标若换了源，客户端原则上不能转发 Authorization 与 RPP-Authorization；已确认是原源别名，或另有适用于新源的凭据，才有例外。

路可以改，授权不能搭便车

注册局迁移服务地址，听起来像一张运维变更单。注册商发出的却可能是创建、修改或转移域名的操作。把这类请求导向另一台机器，既要保证操作本身没有变样，也要决定新机器有没有资格拿到注册商的凭据。RPP 核心草案这次把两个决定拆开写了。

11 月 2 日的修订要求服务器只用 307 或 308 重定向，并在 Location 写入绝对 HTTPS URL。这两个状态码保留原请求方法。客户端可以选择跟随；跟随时，请求体和请求头都必须保持一致，RPP-Cltrid 也不能丢。交易绕了路，仍须是同一笔交易。301、302 等其他重定向，即使由中间设备产生，也按协议错误处理。

更关键的是凭据。新地址如果属于另一个源，客户端不能自动把两个授权头一并送去。草案只给出两种通道：客户端知道目标是原源的别名；或者它持有对新源有效的凭据，并改用那套凭据。转址消息只能指路，不能自己证明收件人有权持钥匙。

这版还要求客户端在发出任何请求前校验 TLS 证书链，并核对证书与 URL 主机名是否相符。校验失败，请求不得发出。发现一个服务地址、确认应答机器的身份、决定交出哪套授权信息，是三张不同的凭条。混成一张，服务迁移就会变成凭据外流的捷径。

RPP 仍是工作组草案；官方文件没有给出实际部署或事故数据。眼下可确认的变化是协议边界：注册局可以提出新入口，注册商客户端仍要独立守住凭据和服务器身份。

原始资料