Summary

  • An ORIGIN frame lets an HTTP/2 server describe origins that an implementing client may associate with one connection.
  • Origin-Set membership remains conditional on a certificate that passes suitable checks for the named origin; the frame cannot create cryptographic authority.
  • Frame validity is connection-specific and hop by hop, while malformed entries, proxy-delivered frames and frames on the wrong stream or protocol are ignored.
  • A defensible coalescing claim joins the valid frame, exact origin, certificate decision, client choice, request result and any 421 Misdirected Request removal.

Imagine a shared edge sending an ORIGIN frame that names a second HTTPS service. A rollout dashboard sees the origin in a packet trace and retires the service’s dedicated connection test. The certificate on the shared connection does not contain the second service name. That client therefore refuses to reuse the connection and opens another one. In a separate stale-reuse test, another client instance sends the request on the old connection and receives 421 Misdirected Request. The frame was real; the authority claim was not.

This is a hypothetical trace, not a reported operator incident. The mistake is to collapse three different facts—server assertion, client authority decision and request outcome—into one green indicator.

The frame changes a connection-scoped set

RFC 8336 defines ORIGIN as an HTTP/2 extension that initializes or modifies an implementing client’s Origin Set. An entry is the ASCII serialization of one origin. It is not a wildcard, a redirect or a new identity for the resource.

The context matters. The frame belongs on stream 0, is valid on h2 or a protocol that explicitly adopts it, and is ignored on h2c. It is non-critical, so an endpoint that does not implement it may ignore it. Intermediaries must not forward it, and clients configured to use a proxy must ignore frames received from that proxy. A capture without connection, protocol, stream and sender provenance cannot show that a client processed the frame.

Malformed Origin-Entry values are ignored. Because wildcard names are unsupported, every intended origin must appear explicitly. A wildcard certificate and an Origin Set are therefore different lists with different rules.

Membership is not authority

Once initialized, the Origin Set constrains coalescing: an implementing client must not consider the connection authoritative for an origin absent from the set. Presence, however, is only one condition. RFC 8336 says the server still has to authenticate with a certificate that passes suitable checks, including matching the origin host against the certificate’s subjectAltName.

RFC 9110 likewise ties HTTPS authority to a successfully established secured connection and a certificate trusted for the identified origin. An ORIGIN entry cannot mint that trust, extend a certificate’s names or waive client policy. It can narrow or inform connection reuse; it cannot replace the cryptographic predicate.

This also separates R065 from the preceding Alt-Svc analysis. RFC 8336 states that alternative-service advertisements do not change the Origin Set or determine authority. Alt-Svc nominates another service path. ORIGIN describes origins associated with a connection. Both still rely on independent security and request evidence.

Authority can change during the connection

The Origin Set is mutable. Subsequent valid frames can add entries. A 421 Misdirected Request causes an implementing client to remove the request’s origin from the set. The server’s earlier assertion is therefore not a permanent authorization for the connection’s lifetime.

Clients may sometimes avoid consulting DNS for origins in the set, but RFC 8336 identifies additional security risk and recommends high confidence in certificate legitimacy through other means. That is a policy choice, not proof that every client skipped DNS or reached the same decision.

Close a coalescing change with a connection-authority receipt. Record connection identity, negotiated protocol, stream, frame bytes, sender, parse result and ordered Origin Set. For each origin, attach certificate chain, trust result, exact SAN match, DNS or alternative confidence evidence, client reuse decision, request result and any 421 removal. State the client population and observation window. The receipt proves only the joined chain it contains.

Sources