摘要

  • draft-ietf-regext-epp-https-04 日期为 2026 年 9 月 3 日，是 REGEXT 工作组仍在推进的 Internet-Draft；它不是 RFC、IESG 批准或生产部署证明。
  • 请求只要进入 EPP 处理层并生成 EPP 响应，外层 HTTP 就返回 200 (OK)，无论内层命令成功还是失败。HTTP 状态与 EPP 结果必须分别记账。
  • 若处理可能已经发生却没有收到有效 EPP 响应，命令结果属于不确定。中间层不得自动重试；只有理解完整命令及扩展语义的 EoH 客户端，才能在确认幂等、保留交易标识与顺序后决定是否重发。

负载均衡器说成功，注册局说拒绝。这两个结论可以同时成立。

前者只证明 HTTP 请求完成了一个可描述的旅程；后者才说明注册对象命令的处理结果。如果运营系统把两个信号压成一个“成功率”，它既可能把明确拒绝涂成绿色，也可能把注册局已经落账的变更误判成尚未发生。

9 月 3 日更新的 draft-ietf-regext-epp-https-04 正是在划清这条线。EPP 是客户端与共享注册库之间的有状态 XML 协议。RFC 5730 要求保持命令顺序、会话状态与协调响应。新草案没有把 EPP 改造成 REST；它用 HTTPS POST 承载原有对话，让运营者复用 Web 防火墙、负载均衡和七层监控。

200 只说明外层到达了处理点

EoH 连接从一个空 POST 开始，服务器地址由注册局在协议外提供。有效的建立响应包含 EPP greeting、application/epp+xml、Cache-Control: no-store、nosniff 和会话 cookie。随后，成功的 EPP <login> 才建立经过认证的 EPP 会话。

登录后，一个 POST 只能携带一条 EPP 命令，一个 HTTP 响应携带一条 EPP 响应。草案规定，只要请求已进入 EPP 处理层并产生响应，HTTP 就必须返回 200；EPP 响应可以是成功，也可以是失败。

HTTP 4xx 或 5xx 描述另一类事实：HTTP 格式错误、不支持的媒体类型、报文过大、限流、过载或网关故障，使请求没有得到权威 EPP 结果。它们并不能自动证明命令从未触及处理层。

会话标识错误是最直观的例子。若缺失或无效 cookie 的请求已经进入 EPP 层，服务器在 HTTP 200 里面返回 EPP 2002“命令使用错误”。只数 HTTP 200 的面板会把一条清楚的拒绝当作成功。

因此，审计至少需要三项关联数据：HTTP 状态、EPP 结果码与客户端交易标识。第一项说明网络与网关发生了什么，第二项说明注册局应用作出什么决定，第三项让恢复动作仍能指向原来的业务意图。

响应丢了，不等于命令回滚

更棘手的是超时。客户端发送一条对象变更命令，网关完成转发，注册局已经处理，返回包却在代理、连接或后端切换时丢失。客户端没有拿到 EPP 成功，也没有拿到 EPP 失败。草案不给这种局面虚构答案，而是称其结果“不确定”。

此时自动重试可能把一次事故变成第二次操作。HTTP 并未把 POST 定义为幂等。EPP 命令被设计为“可以做成幂等”，但具体是否安全，取决于完整命令以及所有扩展。通用代理只看见 POST 和超时，它不知道里面是可重复查询、已经落账的变更，还是重复执行会产生不同效果的扩展。

修订版 04 因此把重试权留给 EoH 客户端。只有当故障可能是暂时的、HTTP 状态语义允许重试、客户端确认完整 EPP 命令具有幂等性时，才可以重发。重试必须使用相同命令，并在存在时沿用同一个客户端交易标识。在拿到有效响应或放弃会话之前，后续命令不能越过它。运营者控制的 HTTP 中间层必须关闭自动重试。

这些要求是在保护因果顺序。换一个交易标识，会让同一业务意图看起来像第二条命令；让下一条命令抢跑，会迫使系统在未知前置状态上继续变更；让网关决定重试，则把权限从理解 EPP 的组件交给只看见传输故障的组件。

HTTP 可以多路复用，EPP 命令不能并行

HTTP/2 与 HTTP/3 支持 multiplexing，但这份映射明确禁止同一 EPP 会话同时存在两条未完成请求。中间层仍可能制造并发，所以服务器必须事先定义：拒绝，还是按序串行处理。

会话状态同样不能被前端可用性遮住。Cookie 代表逻辑上的 EPP 连接，即使消息走过不同 HTTP 连接。多实例系统可以使用粘性会话，把同一标识导向同一后端；也可以把状态放进共享存储。前者简单，却会在实例失效时丢失活动会话，除非状态已复制。后者支持故障切换，却把共享存储变成新的安全与可用性边界。

同一 EoH 连接的请求必须顺序处理，状态更新必须原子化，存储、HTTP 会话与 EPP 会话的生命周期还要对齐。否则，443 端口和健康检查都可能正常，而它们声称承载的注册对话已经断裂。

草案列出 Verisign SDK 的开发实现，覆盖 HTTP/1.1 与 HTTP/2；也列出 Registro.it 自 2009 年运行的一种略有不同的安排。文档同时声明，这些资料由贡献者提供，未经 IETF 验证，也不构成背书。它们说明有人做过运行代码，不足以证明采用率、合规性或性能。

Heng Lu 关于现实层分离的纪律，在这里非常具体：HTTP 交付、EPP 决定、注册库状态、DNS 发布、解析器观测与最终用户结果，是一条链上的不同证据。运行代码优先进一步指出，恢复权应属于能理解完整命令、冻结后续顺序、保留交易标识并查询权威状态的组件。

把 EPP 放进 HTTPS，可以现代化传输。它不会把两本账自动合成一个真相。

来源