The ORIGIN Extension in HTTP/3
Extracted elements (9)
HTTP/2 reserves stream 0 for connection-state frames, whereas HTTP/3 uses a pair of unidirectional control streams for this purpose. The ORIGIN frame is therefore mapped to the HTTP/3 server control stream rather than stream 0.
The frame type value 0x0c is reused from HTTP/2 to maintain consistency, even though HTTP/3 maintains a separate frame type registry. The payload semantics are kept identical to minimize divergence between the two versions.
HTTP/3 does not define a Flags field in its generic frame layout. Because no flags have been defined for the ORIGIN frame, this specification defines no mechanism for communicating ORIGIN flags in HTTP/3.
Where RFC 8336 (ORIGIN for HTTP/2) specifies the ORIGIN frame is sent on stream 0, this MUST be interpreted to mean the HTTP/3 server control stream; the frame is sent from servers to clients on the server's control stream.
The ORIGIN HTTP/3 frame allows a server to indicate what origin or origins the server would like the client to consider as members of the Origin Set for the connection. Semantics are identical to the HTTP/2 ORIGIN frame defined in RFC 8336.
This document registers frame type 0x0c (ORIGIN) as a permanent entry in the IANA 'HTTP/3 Frame Types' registry defined by RFC 9114, with change controller IETF and contact HTTP WG.
This document introduces no new security considerations beyond those discussed in RFC 8336 (ORIGIN for HTTP/2) and RFC 9114 (HTTP/3). Implementors should consult those documents for applicable security guidance.
Origin-Entry encodes a length-delimited ASCII origin: Origin-Len is an unsigned 16-bit integer indicating the octet length of the ASCII-Origin field; ASCII-Origin is the ASCII serialization of the origin per RFC 6454 Section 6.2.
The ORIGIN frame type value is 0x0c (decimal 12), matching HTTP/2. The frame payload contains zero or more Origin-Entry fields, each consisting of a 16-bit Origin-Len followed by a variable-length ASCII-Origin string.