]>

lucas@lucaspardue.com

Web and Internet Transport HTTP obsolete and sucks This document defines a qlog event schema containing concrete events for the core HTTP/2 protocol and selected extensions. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the HTTP Working Group mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction This document defines a qlog event schema () containing concrete events for the core HTTP/2 protocol and selected extensions (, , and ). The event namespace with identifier http2 is defined; see . In this namespace multiple events derive from the qlog abstract Event class (), each extending the "data" field and defining their "name" field values and semantics. summarizes the name value of each event type that is defined in this specification. Some event data fields use complex data types. These are represented as enums or re-usable definitions, which are grouped together on the bottom of this document for clarity. HTTP/2 Events

Name value	Importance	Definition
http2:parameters_set	Core
http2:parameters_restored	Core
http2:frame_created	Core
http2:frame_parsed	Core

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. The event and data structure definitions in ths document are expressed in the Concise Data Definition Language and its extensions described in . The following fields from are imported and used: name, namespace, type, data, group_id, RawInfo, and time-related fields. Events are defined with an importance level as described in . As is the case for , the qlog schema definitions in this document are intentionally agnostic to serialization formats. The choice of format is an implementation decision.

Event Schema Definition This document describes how HTTP/2 is expressed in qlog with an event schema. Per the requirements in , this document registers the http2 namespace. The event schema URI is urn:ietf:params:qlog:events:http2.

Draft Event Schema Identification Only implementations of the final, published RFC can use the events belonging to the event schema with the URI urn:ietf:params:qlog:events:http2. Until such an RFC exists, implementations MUST NOT identify themselves using this URI. Implementations of draft versions of the event schema MUST append the string "-" and the corresponding draft number to the URI. For example, draft 99 of this document is identified using the URI urn:ietf:params:qlog:events:http2-99. The namespace identifier itself is not affected by this requirement.

HTTP/2 Events HTTP/2 events extend the $ProtocolEventData extension point defined in . Additionally, they allow for direct extensibility by their use of per-event extension points via the $$ CDDL "group socket" syntax, as also described in .

HTTP2EventData definition and ProtocolEventData extension

parameters_set The parameters_set event contains HTTP/2 settings, mostly those received from the SETTINGS frame. It has Core importance level. Parameters are typically set once but they can be set at different times during the connection, therefore a qlog can have multiple instances of parameters_set with different fields set. The "initiator" field reflects how Settings are exchanged on a connection. Sent settings have the value "local" and received settings have the value "received".

HTTP2ParametersSet definition

The parameters_set event can contain any number of unspecified fields. This allows for representation of reserved settings (aka GREASE) or ad-hoc support for extension settings that do not have a related qlog schema definition.

parameters_restored When using TLS 0-RTT, HTTP/2 clients are expected to remember and reuse the server's SETTINGs from the previous connection. The parameters_restored event is used to indicate which HTTP/2 settings were restored and to which values when utilizing 0-RTT. It has Core importance level.

HTTP2ParametersRestored definition

frame_created The frame_created event is emitted when the HTTP/2 framing actually happens. It has Core importance level.

HTTP2FrameCreated definition

frame_parsed The frame_parsed event is emitted when the HTTP/2 frame is parsed. It has Core importance level.

HTTP2FrameParsed definition

HTTP/2 Data Type Definitions The following data type definitions can be used in HTTP/2 events.

Initiator

Initiator definition

HTTP2Frame The generic $HTTP2Frame is defined here as a CDDL "type socket" extension point. It can be extended to support additional HTTP/2 frame types.

HTTP2Frame type socket definition any } ]]>

The HTTP/2 frame types defined in this document are as follows:

HTTP2Frames definition

HTTP2DataFrame

HTTP2DataFrame definition

HTTP2HeadersFrame The payload of an HTTP/2 HEADERS frame is the HPACK-encoding of an HTTP field section; see . HTTP2HeadersFrame, in contrast, contains the HTTP field section without encoding.

HTTP2HTTPField definition

HTTP2HeadersFrame definition

For example, the HTTP field section would be represented in a JSON serialization as:

HTTP2HeadersFrame example

and define rules for the characters used in HTTP field sections names and values. Characters outside the range are invalid and result in the message being treated as malformed. It can however be useful to also log these invalid HTTP fields. Characters in the allowed range can be safely logged by the text type used in the name and value fields of HTTP2HTTPField. Characters outside the range are unsafe for the text type and need to be logged using the name_bytes and value_bytes field. An instance of HTTP2HTTPField MUST include either the name or name_bytes field and MAY include both. An HTTP2HTTPField MAY include a value or value_bytes field or neither.

HTTP2PriorityFrame

HTTP2PriorityFrame definition

HTTP2RstStreamFrame

HTTPRstStreamFrame definition

HTTP2SettingsFrame The settings field can contain zero or more entries. Each setting has a name field, which corresponds to Setting Name as defined (or as would be defined if registered) in the "HTTP/3 Settings" registry maintained at https://www.iana.org/assignments/HTTP2-parameters. An endpoint that receives unknown settings is not able to log a specific name. Instead, the name value of "unknown" can be used and the value captured in the name_bytes field; a numerical value without variable-length integer encoding.

HTTP2SettingsFrame definition

HTTP2PushPromiseFrame

HTTP2PushPromiseFrame definition

HTTP2PingFrame

HTTP2PingFrame definition

HTTP2GoAwayFrame

HTTP2GoawayFrame definition

HTTP2WindowUpdateFrame

HTTP2WindowUpdateFrame definition

HTTP2ContinuationFrame

HTTP2ContinuationFrame definition

HTTP2UnknownFrame The frame_type_bytes field is the numerical value without variable-length integer encoding.

HTTP2UnknownFrame definition

HTTP2AltSvcFrame The ALTSVC frame is defined in .

HTTP2AltSvcFrame definition

HTTP2OriginFrame The ORIGIN frame is defined in .

HTTP2OriginFrame definition

HTTP2PriorityUpdateFrame The PRIORITY_UPDATE frame is defined in .

HTTP2PriorityUpdateFrame definition

Security Considerations The security and privacy considerations discussed in apply to this document as well.

IANA Considerations This document will have IANA actions if adopted.

References Normative References Akamai Meta Cloudflare qlog provides extensible structured logging for network protocols, allowing for easy sharing of data that benefits common debug and analysis methods and tooling. This document describes key concepts of qlog: formats, files, traces, events, and extension points. This definition includes the high-level log file schemas, and generic event schemas. Requirements and guidelines for creating protocol- specific event schemas are also presented. All schemas are defined independent of serialization format, allowing logs to be represented in various ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. 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. This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection. This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses. These share a common format structure that is designed to provide future extensibility. 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 document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Informative References This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.

Acknowledgments TODO acknowledge.