The ORIGIN HTTP/2 Frame
Extracted elements (22)
ORIGIN allows clients to skip consulting DNS when determining authority for an origin in the Origin Set. This removes latency from DNS lookups and relaxes the dual DNS+certificate authority check required by HTTP/2, at the cost of a new attack surface described in Section 4.
ORIGIN does not support wildcard names (e.g., '*.example.com') in Origin-Entry. Sending ORIGIN with a wildcard certificate in use effectively disables any origins not explicitly listed, since wildcards cannot be enumerated.
ORIGIN is defined as a non-critical extension; endpoints that do not support it can safely ignore it, allowing incremental deployment without breaking existing HTTP/2 connections.
The Origin Set is unaffected by alternative services advertisements made by the server; advertising an alternative service does not affect whether a server is considered authoritative.
When ORIGIN is sent on an alternative service connection (RFC 7838), the initial Origin Set contains the actual port in use (which may differ from the intended origin's port). Servers must explicitly include the intended origin in the ORIGIN frame payload in such cases.
An intermediary MUST NOT forward ORIGIN frames, as the frame describes a property of the connection and is processed hop by hop. Clients configured to use a proxy MUST ignore any ORIGIN frames received from it.
Clients SHOULD NOT emit new requests on any connection whose Origin Set is a proper subset of another connection's Origin Set, and SHOULD close such connections once all outstanding requests are satisfied.
Each ASCII-Origin field in the frame payload MUST be parsed as an ASCII serialization of an origin per RFC 6454 Section 6.2. If parsing fails, the field MUST be ignored.
Even with ORIGIN, server authentication via a certificate passing suitable checks is still required for a connection to be authoritative for a given origin, including verifying the host matches a dNSName in the certificate subjectAltName field.
Once an Origin Set is initialized, clients MUST NOT consider a connection authoritative for an origin not present in the Origin Set, and SHOULD use the connection for all requests to origins in the Origin Set for which the connection is authoritative.
The ORIGIN frame MUST be ignored when received on a connection with the 'h2c' protocol identifier; it is only valid on connections with the 'h2' protocol identifier or when explicitly nominated by a protocol's definition.
The ORIGIN frame MUST be sent on stream 0; an ORIGIN frame received on any other stream is invalid and MUST be ignored.
Upon receipt of a 421 (Misdirected Request) response, implementing clients MUST create the ASCII serialization of the corresponding request's origin and remove it from the connection's Origin Set, if present.
When any of the first four flags (0x1, 0x2, 0x4, or 0x8) are set on an ORIGIN frame, the frame MUST be ignored by conforming clients unless the flag's semantics are understood, as these flags are reserved for backwards-incompatible changes.
The ORIGIN frame (type 0xc, decimal 12) allows a server to indicate what origins the client should consider as members of the Origin Set for the connection. It contains zero or more Origin-Entry fields and defines no flags, though future updates MAY define flags.
The Origin Set is the set of origins a given connection might be used for. By default it is uninitialized, meaning standard HTTP/2 coalescing rules from RFC 7540 Section 9.1.1 apply. It is initialized when the first ORIGIN frame is successfully processed.
When the first ORIGIN frame is successfully processed, the Origin Set is initialized with an initial origin composed of scheme 'https', the SNI hostname (lowercased) or server IP if SNI is absent, and the remote port of the connection.
This specification adds an entry to the IANA 'HTTP/2 Frame Type' registry: Frame Type ORIGIN, Code 0xc, Specification RFC 8336.
Clients opting to skip DNS consultation SHOULD employ alternative means to establish high confidence in certificate legitimacy, such as requiring Certificate Transparency log inclusion (RFC 6962) or a recent non-revoked OCSP response (RFC 6960).
Clients that blindly trust ORIGIN frame contents are vulnerable to a large number of attacks. Relaxing the DNS check means an attacker with a valid certificate can redirect traffic by convincing a user to visit another website and coalescing connections, without needing to modify DNS.
The Origin Set's size is unbounded by this specification and could be exploited by attackers to exhaust client resources. Clients should monitor state commitment and close the connection if it grows too large.
Each Origin-Entry is a length-delimited string consisting of a 16-bit unsigned integer (Origin-Len) indicating the octet length of the following ASCII-Origin field, which contains the ASCII serialization of an origin. The Origin field is OPTIONAL.