摘要

  • IETF 的 EPP over HTTPS 草案第 04 版明确规定：只要请求已经进入 EPP 处理层并产生 EPP 响应，外层 HTTP 就应返回 200，无论里面的 EPP 结果是成功还是失败。
  • 如果客户端没有收到有效 EPP 响应，而命令又可能已经进入处理层，结果不是“失败”，而是“未定”。只有理解完整命令及其扩展语义的 EoH 客户端，才可能在严格条件下决定重试。
  • 注册局与注册商需要一份“命令处置回执”，把 HTTP 尝试、EPP 事务标识、顺序屏障、幂等依据、责任人和最终核对证据连成同一条可审计链。

运维屏幕上的绿色很有说服力。HTTP 200 出现后，告警恢复，成功率回升，工单也很容易被标成“完成”。这种视觉习惯在普通 Web 服务中已经足够强，进入注册业务后更容易越界：它把“外层服务返回了成功类响应”悄悄改写成“注册局已经成功执行命令”。

2026 年 9 月 3 日发布的 draft-ietf-regext-epp-https-04，恰好把这两个判断拆开。草案规定，一项 HTTP 请求只要到达 EPP 处理层，并由该层生成 EPP 响应，服务器就必须把这份响应装在 HTTP 200 里返回。里面的 EPP 结果可以是成功，也可以是失败。200 证明的是容器顺利承载了一份应用响应，不是注册对象已经按请求发生变化。

另一边也不能反推。网关超时、过载、限流或媒体类型错误首先是 HTTP 层结果。如果命令可能已经穿过边界进入 EPP 处理，而有效 EPP 响应没有回到客户端，就不能把外层失败当成应用层拒绝。草案为这种情况保留了一个非常重要、但不讨人喜欢的状态：命令结果未定。

“未定”不是含糊其辞。它是一项积极的证据结论：手里没有权威 EPP 结果，现有记录又排除不了命令已被处理的可能。若此时把未知自动翻译成失败并再次发送，基础设施就在没有 EPP 语义知识的情况下，替注册业务作出了第二次动作决定。

HTTPS 的外观不会消除 EPP 的状态

RFC 5730 把 EPP 定义为一种有状态、按序执行的 XML 客户端—服务器协议，用来配置共享中央资料库中的对象。它区分会话管理、只读查询与对象变换。创建、续期、转移、更新、删除等操作都属于可能改变共享状态的命令。规范说命令具有原子性，并且在设计上可以被实现为幂等；它没有说任意命令在任意实现、任意扩展组合下天然都可重复。

HTTPS 映射以一个空 POST 开始。只有服务器返回包含 EPP greeting 的 HTTP 200，并通过 Cookie 建立 HTTP 会话，EoH 连接才算成立。随后还要成功执行 EPP login，才进入经过认证的 EPP 会话。此后一个 POST 只携带一条 EPP 消息，一次经过 EPP 处理的响应只携带一条 EPP 响应。

使用 443 端口、负载均衡器、Web 应用防火墙和云原生部署方式，确实能减少运维摩擦。但草案把这种映射称为“隧道”并非偶然。Web 基础设施提供的是承载能力，不会因此获得注册协议的业务判断力。缓存、多路复用、认证、日志和自动重试等常见 HTTP 能力，都不能不加区别地移植进来。

无效会话标识是最直观的例子。若一条带空白或无效会话标识的命令仍然到达 EPP 处理层，草案要求服务器在 HTTP 200 内返回 EPP 2002，也就是 command use error。外层和内层都出现了“200”这个数字，却属于完全不同的代码空间。只读外层，得到的结论正好会与业务结果相反。

不能为了报表好看而消灭“未定”

很多工单系统只欢迎两个按钮：成功或失败。第三种状态会拉长关闭时间，干扰服务指标，也迫使两个机构继续对账。可是，删掉选项不会创造事实，只会把不确定性转交给下一位操作员、注册商、注册人或审计者。

一条未定命令至少要求守住三条边界。第一，在没有 EPP 成功结果或足够核对证据前，不能对外确认对象已按请求改变。第二，不能把没有收到响应说成注册局明确拒绝。第三，在旧命令处置未明时，不应放行后续命令，让一个未知分叉成多个可能的执行历史。

事后查询对象当然有用，却不总能证明因果。对象可能在第一条命令前就处于该状态；另一位有权限的客户端可能修改过它；某项操作也可能进入离线审核或待处理状态。当前状态回答“现在是什么”，处置证据回答“哪一条命令造成了什么”。两者可能重合，也可能不重合。

所以，未定状态不应只存在于瞬时错误日志里。它应成为可持续跟踪的业务案件，有明确的等待期限、核对方式和关闭权限。超时恢复了，不等于命令历史自动恢复了确定性。

幂等性属于完整命令，而不是 POST 标签

RFC 9110 没有把 POST 定义为幂等方法。客户端若要自动重试非幂等方法，至少应知道具体请求语义其实是幂等的，或者能够确定原请求从未被应用；代理不得自动重试非幂等请求。这是一条刻意保守的边界。

第 04 版草案把边界进一步落实到 EPP。EoH 客户端只有同时满足三项条件，才可以重试：故障可能是暂时的；收到的 HTTP 状态语义允许重试；客户端知道所封装的完整 EPP 命令（包括所有扩展）具有幂等的应用语义。重试必须携带同一条命令，并在原来存在 clTRID 时保留同一个值。在收到有效响应或放弃该 EPP 会话以前，客户端不得发送下一条 EPP 命令。

“包括扩展”决定了审查不能停在基础动词。一个 update、renew 或其他命令在基本映射中或许具有某种重复执行预期，但扩展可能加入条件、时间、附带效果或新的对象关系。真正需要分类的是当时发送的整份 XML、所用扩展版本以及服务端承诺，而不是命令菜单上的一个名字。

草案还把普通 HTTP 中间件排除在决定者之外。负载均衡器知道连接断在哪里，Service Mesh 知道请求走过哪些节点，通用客户端库知道超时策略；它们通常不知道 EPP 扩展的应用含义，也不拥有会话内的业务顺序。因此，运营方必须配置自己控制的中间件，使其不要自动重试 EPP POST。所谓“自动恢复”在这里不是中性功能，而是可能重复行使注册权力的机制。

clTRID 可以把记录串起来，却不自动构成去重承诺

RFC 5730 允许客户端附带 clTRID，由客户端负责在自己的标识空间内保持唯一。服务器响应则把这个值与服务器分配且唯一的 svTRID 放在一起。两者维持命令与响应的同步完整性，规范建议双方记录、保留并保护这些标识。

第 04 版要求获准重试时继续使用同一个 clTRID。这样做能把多个传输尝试归入同一个业务案件，是必要的关联证据。然而，引用的规范并没有进一步宣布：重复 clTRID 本身会强制每一种服务器实现拒绝第二次执行。某个注册局可以在双边服务合同或实现说明里提供更强的去重保证，但那项保证必须有明确范围、版本与启用证据。

关联、幂等和去重回答的是三个不同问题。关联说明哪些消息属于同一意图；幂等说明重复执行是否产生相同的预期净效果；去重说明服务器是否真的阻止再次执行。把一个追踪标识想象成同时解决后两项问题，是对证据能力的夸大。

当 svTRID 随有效响应到达时，它能把客户端记录锚定到服务器事务。若响应丢失，空缺本身也必须被保存，不能用网关请求号冒充。否则，两层标识又会被错误合并。

一次只允许一个未决命令，是因果保护

HTTP/2 和 HTTP/3 支持多路复用，同一连接上同时存在多条请求十分常见。EoH 映射却明确禁止同一 EPP 会话中有超过一个尚未完成的 HTTP 请求。即使客户端没有并发，中间件也可能制造并发；服务器必须预先定义发现 EPP pipelining 时是失败还是串行处理。

这条限制不仅牺牲了一点性能优化。它保住了可解释的因果顺序。后续更新可能依赖创建成功，转移命令可能改变谁有权提交下一项更新。如果第一条命令仍然未定，第二条命令已经前进，最终对象状态就可能由多种序列解释。到那时，核对不是在寻找一个事实，而是在多个故事中猜测。

放弃会话可以阻断序列继续扩散，却不会自动解决已经发出的命令。运营方仍需通过服务器侧事务记录、找回的有效响应、范围恰当的对象查询、人工确认或事先约定的双边流程来关闭案件。新建会话解决的是连通性，不是旧命令的处置证明。

一张跨越两层的命令处置回执

普通 HTTP 日志围绕路径、后端、状态码、延迟和重试次数组织。EPP 日志围绕命令 XML、结果码和事务标识组织。隧道架构下，单独任何一边都不够。治理对象正是把两边可靠接合的那张回执。

每一条离开客户端的 EPP 命令，都应建立一项处置记录，至少保存：

  1. 命令类别、受影响对象，以及包含所有扩展的完整 EPP 消息规范化指纹；
  2. EPP 会话标识、clTRID 与每次 HTTP 尝试的独立标识；
  3. 客户端开始交付请求的时间，以及最后一个仍能证明“尚未送达”的边界；
  4. 观察到的 HTTP 状态、真正生成该状态的组件和相关中间链路事件；
  5. 有效响应中的 EPP 结果码与 svTRID；若没有，就明确留空；
  6. 三值处置：已确认成功、已确认失败、结果未定；
  7. 判断完整命令可幂等重试的文件、版本、适用扩展和证据；
  8. 未定期间阻止后续命令进入的顺序屏障；
  9. 批准重试、放弃会话或启动核对的责任人或客户端策略；
  10. 最终关闭案件的证据、时间、可信度，以及客户端与注册局记录间仍存在的差异。

这不是要求全世界采用同一套数据库。Lu Heng 关于“最小初始规范”的思路给出了更合适的尺度：共同规则只强制保留关键区别、标识和责任链，具体存储、签名、支持工单与核对程序由本地决定。回执可以是一条签名事件，也可以是连接两套日志的受保护案件。它唯一不能做的，是为方便统计而把“尚不清楚”改写成“已经失败”。

The Policy Mirror 则要求看见配置背后的利益分配。自动重试让谁获得再次行使命令的权力？若首个请求已经生效，谁承担重复动作的成本？谁能够看到并质疑证据？如果平台用更漂亮的可用性数字换来注册商、注册人或客服更重的核对负担，那已经不是单纯的传输参数，而是一项隐藏的风险政策。

草案本身也必须按其真实状态陈述

第 04 版是 REGEXT 工作组的一份活跃 Internet-Draft，目标是 Standards Track。它还不是 RFC，也没有完成 IESG 审议，并将在 2027 年 3 月 7 日到期。工作组计划于 2026 年 9 月提交出版，只是一项里程碑，不能被报道成已经提交或批准。

实现状态章节列出了 Verisign EPP SDK 与 IIT-CNR/Registro.it 的实现情况。按照该章节引用的 RFC 7942 声明，这些信息由贡献者提供，未经 IETF 核验，不代表 IETF 背书，也不是完整产品目录。它们能证明有人报告了实践与试验，不能证明所有生产环境都正确关闭了中间件重试，或所有扩展都已完成幂等分类。

草案描述的 IANA EPP 扩展注册项同样是拟议内容。文本中的“应注册”不等于现有登记表已因草案自动新增。对协议结果要求精确时，也应对规范自身的权限状态保持同样精确。

来源

  1. IETF Internet-Draft：EPP Transport over HTTPS，第 04 版
  2. IETF Datatracker：草案状态
  3. IETF Datatracker：版本历史
  4. IETF REGEXT 工作组
  5. RFC 5730：Extensible Provisioning Protocol
  6. RFC 5731：EPP 域名对象映射
  7. RFC 5734：EPP over TCP
  8. RFC 9110：HTTP Semantics
  9. RFC 7942：Improving Awareness of Running Code
  10. IANA：Extensions for EPP
  11. Lu Heng：Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. Lu Heng：The Policy Mirror