本文是关于HTTP/3中ORIGIN扩展的网络规范文档译文，尚未完成翻译，欢迎指正。

HTTP/2的ORIGIN帧同样适用于HTTP/3，但需要重新注册。本文描述了HTTP/3的ORIGIN帧。

本文是互联网标准追踪文档。

本文产自互联网工程任务组（IETF），已接受公开审查，并由互联网工程指导委员会（IESG）批准出版。更多互联网标准相关信息详见RFC 7841第2章。

关于本文当前状态、勘误及反馈方式等相关信息请移步https://www.rfc-editor.org/info/rfc9412。

版权所有（c）2023 IETF信托及确认为文档作者的个人。保留所有权利。

本文遵守BCP 78及在本文发布之日起生效的IETF信托涉及IETF文档的法律条文（https://trustee.ietf.org/license-info）。请仔细阅读相关条文，因为其描述了你对本文所有的权利及限制。从本文中摘录的代码组件必须包含信托法律条文第4.e章的简版BSD License文件，并且不附带任何该文件所描述的保证。

已有RFC定义了HTTP/2（HTTP/2）的扩展，这些扩展在HTTP/3中仍然有用。HTTP/3的附录A.2描述了将HTTP/2帧用于HTTP/3时所需的更新。

ORIGIN定义了HTTP/2的ORIGIN帧，用于指示某个连接上有哪些源站可用。它定义了一种单一的HTTP/2帧类型。

本文中的关键字“必须（MUST）”、“必须不（MUST NOT）”、“需要（REQUIRED）”、“强烈要求（SHALL）”、“强烈要求不（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“不推荐（NOT RECOMMENDED）”、“可以（MAY）”，以及“可选（OPTIONAL）”应理解为BCP 14 《RFC2119》《RFC8174》所描述的，当且仅当它们像本段一样以斜体加粗方式出现的时候。

本文中的帧图示使用QUIC-TRANSPORT的第1.3章所定义的格式来说明字段的顺序和大小。

ORIGIN HTTP/3帧允许服务器向客户端指示一个或多个源站（origin）RFC6454，服务器希望客户端将这些源站视为该连接发生时所处源站集合（Origin Set，ORIGIN的第2.3章）的成员。

该帧负载的语义与ORIGIN中定义的HTTP/2帧的语义完全相同。HTTP/2将流0预留给与连接状态相关的帧，而HTTP/3为此目的定义了一对单向流，称为“控制流（control streams）”。

当ORIGIN指出ORIGIN帧在流0上发送时，应将其理解为HTTP/3的控制流：即ORIGIN帧由服务器在服务器的控制流上发送给客户端。

HTTP/3在通用帧布局中未定义Flags字段。由于尚未为ORIGIN帧定义任何标志位，本规范不在HTTP/3中定义传递此类标志位的机制。

ORIGIN帧的布局与HTTP/2中使用的布局几乎相同；为清晰起见，此处重新陈述相关信息。ORIGIN帧类型为0x0c（十进制12），与HTTP/2中一致。负载包含零个或多个Origin-Entry字段的实例。

图1展示了ORIGIN帧的布局。

HTTP/3 Origin-Entry {
  Origin-Len (16),
  ASCII-Origin (..),
}

HTTP/3 ORIGIN Frame {
  Type (i) = 0x0c,
  Length (i),
  Origin-Entry (..) ...,
}

一个Origin-Entry是一个以长度分隔的字符串。具体而言，它包含两个字段：

Origin-Len：

一个无符号的16位整数，指示ASCII-Origin字段的长度，以八位字节为单位。

ASCII-Origin：

一个可选的字符序列，包含发送方声称此连接对其具有或可能具有权威性的源站的ASCII序列化形式（RFC6454的第6.2章）。

除ORIGIN和HTTP/3中已讨论的内容外，本文未引入新的安全性考量。

本文在HTTP/3定义的“HTTP/3 Frame Types”注册表中注册一种帧类型，该注册表位于<https://www.iana.org/assignments/http3-parameters/>。

值：

0x0c

帧类型：

ORIGIN

状态：

permanent（永久）

参考：

第2章

日期：

2023-03-14

变更控制者：

IETF

联系方式：

HTTP工作组 ietf-http-wg@w3.org

Mike Bishop

Akamai

Email: mbishop@evequefou.be