]> Akamai

mbishop@evequefou.be

Applications HTTPbis Internet-Draft 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.

Introduction Existing RFCs define extensions to HTTP/2 which remain useful in HTTP/3. describes the required updates for HTTP/2 frames to be used with HTTP/3. defines the HTTP/2 ORIGIN frame, which indicates what origins are available on a given connection. It defines a single HTTP/2 frame type.

Basic Mapping Conventions

The ORIGIN HTTP/3 Frame The ORIGIN HTTP/3 frame allows a server to indicate what origin(s) () the server would like the client to consider as members of the Origin Set () for the connection within which it occurs. 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 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. The layout and semantics of the frame payload are identical to those of the HTTP/2 frame defined in . The ORIGIN frame type is 0xc (decimal 12), as in HTTP/2.

Security Considerations This document introduces no new security considerations beyond those discussed in and .

IANA Considerations This document registers a frame type in the "HTTP/3 Frame Type" registry (). Registered HTTP/3 Frame Types

Frame Type	Value	Specification
ORIGIN	0xc

References Normative References This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. Akamai The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3. DO NOT DEPLOY THIS VERSION OF HTTP DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This version is still a work in progress. For trial deployments, please use earlier versions. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-http. This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection. Informative References This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK]