Akamai

mnot@mnot.net http://www.mnot.net/

Akamai

nygren@akamai.com

General Internet-Draft This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.

HTTP/2 allows clients to coalesce different origins onto the same connection when certain conditions are met. In some cases, the server is not authoritative for a coalesced origin, so the 421 (Misdirected Request) status code was defined. Using a status code in this manner allows clients to recover from misdirected requests, but at the penalty of adding latency. To address that, this specification defines a new HTTP/2 frame type, “ORIGIN”, to allow servers to indicate what origins a connection is authoritative for.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in .

The ORIGIN HTTP/2 frame (, Section 4) indicates what origin(s) the sender considers this connection authoritative for (in the sense of , Section 10.1). The ORIGIN frame is a non-critical extension to HTTP/2. Endpoints that do not support this frame can safely ignore it. It MUST occur on stream 0; an ORIGIN frame on any other stream is invalid and MUST be ignored. When received by a client, it can be used to inform HTTP/2 connection coalescing (see , Section 9.1.1), but does not relax the requirement there that the server is authoritative. If multiple ORIGIN frames are received on the same connection, only the most recent is to be considered current. Once an ORIGIN frame has been received and processed, clients that implement this specification SHOULD NOT use that connection for a given origin if it did not appear within the current ORIGIN frame. The ORIGIN frame type is 0xb (decimal 11).

The ORIGIN frame contains the following fields, sets of which may be repeated within the frame to indicate multiple origins: Origin-Len: An unsigned, 16-bit integer indicating the length, in octets, of the Origin field. Origin: An optional sequence of characters containing the ASCII serialization of an origin (, Section 6.2) that the sender believes this connection is authoritative for. The ORIGIN frame does not define any flags. It can contain one or more Origin-Len/Origin pairs. The ORIGIN frame is processed hop-by-hop. An intermediary must not forward ORIGIN frames. Clients configured to use a proxy MUST ignore any ORIGIN frames received from it.

Clients that blindly trust the ORIGIN frame’s contents will be vulnerable to a large number of attacks; hence the reinforcement that this specification does not relax the requirement for server authority in , Section 10.1.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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] 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.