]> Google LLC

bnc@google.com

Google LLC

birenroy@google.com

Applications and Real-Time HTTP Internet-Draft This document describes a mechanism to send meta information over HTTP/2 () and HTTP/3 () connections that refers to either the entire connection or a specific stream without changing the semantics of the HTTP messages. This mechanism can be used, for example, to gather information for accounting or logging purposes. Discussion Venues Discussion of this document takes place on the HTTP Working Group mailing list (ietf-http-wg@w3.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction HTTP/2 and HTTP/3 connections are capable of transporting multiple HTTP messages, which are composed of field sections and bodies. This document describes a mechanism to convey additional information about HTTP messages or the entire connection, in a way that does not change HTTP semantics, over the same connection. For instance, an endpoint may wish to convey the CPU cost or other loadbalancing information for a particular HTTP message, or perhaps certain statistics for a particular HTTP message or for the connection as a whole. Applications may wish to provide such information without affecting HTTP messages themselves. These are some non-exhaustive examples of use cases that may be well served by the METADATA frame. A proxy MAY consume METADATA frames, pass them along unmodified, modify the payloads, or emit new METADATA frames, depending on the specific needs of the application.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

METADATA frame Both HTTP/2 and HTTP/3 specifications allow the protocol to be extended, see and . This document defines a new frame type: METADATA. The payload of a sequence of METADATA frames is a metadata block, which is an encoded list of key-value pairs. Each key and value is a sequence of bytes with no restriction on the allowed values. An endpoint MAY transmit multiple metadata blocks on the same stream. METADATA frames do not change HTTP semantics.

METADATA HTTP/2 frame The type of METADATA HTTP/2 frame is 0x4d.

METADATA HTTP/2 frame

The METADATA frame defines the following flag:

END_METADATA (0x04):

When set, the END_METADATA flag indicates that this frame ends the logical metadata block.

A METADATA frame without the END_METADATA flag set MUST be followed by a another METADATA frame on the same stream. However, METADATA frames MAY be interleaved with non-METADATA frames on the same stream, or frames of any type on different streams.

METADATA frames are allowed on any stream. METADATA frames on stream 0 carry information pertaining to the whole connection. METADATA frames on any other stream are associated with the exchange carried by that stream. METADATA frames do not alter the state of a stream. METADATA frames MUST NOT be sent on a stream in the "closed" or "half closed (local)" state. An endpoint that receives METADATA for a stream in the "idle" state MAY choose to retain the payload for a period of time, under the assumption that the stream will soon transition to the "open" state. A metadata block is the concatenation of the payloads of a sequence of one or more METADATA frames, only the last of which has the END_METADATA flag set. If the transfer of the last metadata block cannot be completed due to the stream or connection being closed before a METADATA frame with the END_METADATA flag, then the incomplete metadata block SHOULD be discarded. This SHOULD NOT affect processing of previous metadata blocks on the same stream or connection. METADATA frames obey the maximum frame size set by SETTINGS_MAX_FRAME_SIZE. METADATA frames are not subject to flow control. The metadata block of an HTTP/2 METADATA frame is encoded using HPACK instructions (). An endpoint MUST NOT use any HPACK instructions that change the dynamic table.

METADATA HTTP/3 frame The type of METADATA HTTP/3 frame is 0x4d.

METADATA HTTP/3 frame

METADATA frames are allowed on any stream that uses HTTP/3 frames. METADATA frames on the control stream carry information pertaining to the whole connection. METADATA frames on a request stream or a push stream are associated with the exchange carried by that stream. The metadata block of a HTTP/3 METADATA frame is encoded using QPACK representations. An endpoint MUST NOT use any QPACK representations that reference the dynamic table. Therefore the Required Insert Count is be zero, and decoding METADATA frame payloads do not elicit instructions on the QPACK decoder stream.

Negotiating METADATA This document defines a new HTTP/2 setting identifier, SETTINGS_ENABLE_METADATA, with value 0x4d44. It also defines a new HTTP/3 setting identifier, SETTINGS_ENABLE_METADATA, with value 0x4d44. An endpoint that supports METADATA frames SHOULD advertise that by sending SETTINGS_ENABLE_METADATA with value 1 on each connection. A value of 0 indicates that the endpoint does not support METADATA frames. A value other than 0 or 1 MUST NOT be sent. The initial value is 0. For HTTP/2, SETTINGS_ENABLE_METADATA MUST NOT be sent in any SETTINGS frame other than the first one. An endpoint MAY send METADATA frames before it learns that the peer supports them. For example, a proxy might chose to forward METADATA frames, or it might chose to buffer them, before it receives a SETTINGS frame. An endpoint SHOULD NOT send METADATA frames after it learns that the peer does not support them.

Security Considerations TODO Security

IANA Considerations

HTTP/2 This document adds an entry to the "HTTP/2 Frame Type" registry originally defined in but updated to refer to with the following parameters:

Code:

0x4d

Frame Type:

METADATA

Reference:

[[this document]]

This document adds an entry to the "HTTP/2 Settings" registry originally defined in but updated to refer to with the following parameters:

Code:

0x4d44

Name:

SETTINGS_ENABLE_METADATA

Initial Value:

0

Reference:

[[this document]]

HTTP/3 This document adds an entry to the "HTTP/3 Frame Types" registry defined in with the following parameters:

Value:

0x4d

Frame Type:

METADATA

Reference:

[[this document]]

This document adds an entry to the "HTTP/3 Frame Types" registry defined in with the following parameters:

Value:

0x4d44

Settings Name:

SETTINGS_ENABLE_METADATA

Default:

0

Reference:

[[this document]]

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 latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. 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. 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2. Informative 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.

Acknowledgments The authors would like to acknowledge Dianna Hu and Ian Swett for their contributions to this document.