Internet-Draft ORIGIN in HTTP/3 November 2022
Bishop Expires 2 June 2023 [Page]
Intended Status:
Standards Track
M. Bishop

The ORIGIN Extension in HTTP/3


The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but needs to be separately registered. This document describes the ORIGIN frame for HTTP/3.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 2 June 2023.

1. Introduction

Existing RFCs define extensions to HTTP/2 [HTTP2] which remain useful in HTTP/3. Appendix A.2.3 of [HTTP3] describes the required updates for HTTP/2 frames to be used with HTTP/3.

[ORIGIN] defines the HTTP/2 ORIGIN frame, which indicates what origins are available on a given connection. It defines a single HTTP/2 frame type.

2. The ORIGIN HTTP/3 Frame

The ORIGIN HTTP/3 frame allows a server to indicate what origin(s) ([RFC6454]) the server would like the client to consider as members of the Origin Set (Section 2.3 of [ORIGIN]) for the connection within which it occurs.

The semantics of the frame payload are identical to those of the HTTP/2 frame defined in [ORIGIN]. Where HTTP/2 reserves Stream 0 for frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose. Where [ORIGIN] indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream. The ORIGIN frame is sent from servers to clients on the server's control stream.

HTTP/3 does not define a Flags field in the generic frame layout. As no flags have been defined for the ORIGIN frame, this specification does not define a mechanism for communicating such flags in HTTP/3.

2.1. Frame Layout

The ORIGIN frame has a nearly identical layout to that used in HTTP/2, restated here for clarity. The ORIGIN frame type is 0xc (decimal 12) as in HTTP/2. The payload contains zero or more instances of the Origin-Entry field.

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

  Type (i) = 0x0c,
  Length (i),
  Origin-Entry (..) ...,
Figure 1: ORIGIN Frame Layout

An Origin-Entry is a length-delimited string. Specifically, it contains two fields:


An unsigned, 16-bit integer indicating the length, in octets, of the ASCII-Origin field.


An OPTIONAL sequence of characters containing the ASCII serialization of an origin ([RFC6454], Section 6.2) that the sender asserts this connection is or could be authoritative for.

3. Security Considerations

This document introduces no new security considerations beyond those discussed in [ORIGIN] and [HTTP3].

4. IANA Considerations

This document registers a frame type in the "HTTP/3 Frame Type" registry ([HTTP3]).

Table 1: Registered HTTP/3 Frame Types
Frame Type Value Specification
ORIGIN 0xc Section 2

5. References

5.1. Normative References

Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, , <>.
Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, , <>.
Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", RFC 8336, DOI 10.17487/RFC8336, , <>.

5.2. Informative References

Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, , <>.

Author's Address

Mike Bishop