| Internet-Draft | HTTP/3 qlog event definitions | July 2024 |
| Marx, et al. | Expires 9 January 2025 | [Page] |
This document defines a qlog event schema containing concrete events for the core HTTP/3 protocol and selected extensions.¶
Note to RFC editor: Please remove this section before publication.¶
Feedback and discussion are welcome at 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.¶
Concrete examples of integrations of this schema in various programming languages can be found at https://github.com/quiclog/qlog/.¶
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 https://datatracker.ietf.org/drafts/current/.¶
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 9 January 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document defines a qlog event schema (Section 8 of [QLOG-MAIN]) containing concrete events for the core HTTP/3 protocol [HTTP/3] and selected extensions ([EXTENDED-CONNECT], [H3_PRIORITIZATION], and [H3-DATAGRAM]).¶
The event schema namespace http is defined, containing the category h3; see
Section 2. In this category multiple events derive from the qlog abstract
Event class (Section 7 of [QLOG-MAIN]), each extending the "data" field and
defining their "name" field values and semantics¶
Table 1 summarizes the name value of each event type that is defined in this specification. Some event data fields use complex datastructures. These are represented as enums or re-usable definitions, which are grouped together on the bottom of this document for clarity.¶
| Name value | Importance | Definition |
|---|---|---|
| h3:parameters_set | Base | Section 3.1 |
| h3:parameters_restored | Base | Section 3.2 |
| h3:stream_type_set | Base | Section 3.3 |
| h3:priority_updated | Base | Section 3.4 |
| h3:frame_created | Core | Section 3.5 |
| h3:frame_parsed | Core | Section 3.6 |
| h3:datagram_created | Base | Section 3.7 |
| h3:datagram_parsed | Base | Section 3.8 |
| h3:push_resolved | Extra | Section 3.9 |
When any event from this document is included in a qlog trace, the "protocol_type" qlog array field MUST contain an entry with the value "HTTP3":¶
$ProtocolType /= "HTTP3"
The events described in this document can be used with or without logging the related QUIC events defined in [QLOG-QUIC]. If used with QUIC events, the QUIC document takes precedence in terms of recommended filenames and trace separation setups.¶
If used without QUIC events, it is recommended that the implementation assign a globally unique identifier to each HTTP/3 connection. This ID can then be used as the value of the qlog "group_id" field, as well as the qlog filename or file identifier, potentially suffixed by the vantagepoint type (For example, abcd1234_server.qlog would contain the server-side trace of the connection with GUID abcd1234).¶
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 [RFC2119] [RFC8174] 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 [CDDL] and its extensions described in [QLOG-MAIN].¶
The following fields from [QLOG-MAIN] are imported and used: name, category, type, data, group_id, protocol_type, importance, RawInfo, and time-related fields.¶
As is the case for [QLOG-MAIN], the qlog schema definitions in this document are intentionally agnostic to serialization formats. The choice of format is an implementation decision.¶
This document describes how the core HTTP/3 protocol and selected extensions can
be expressed in qlog using a newly defined event schema. Per the requirements in
Section 8 of [QLOG-MAIN], this document registers the http namespace and
h3 category identifiers. The URI is urn:ietf:params:qlog:events:http#h3.¶
This section is to be removed before publishing as an RFC.¶
Only implementations of the final, published RFC can use the events belonging to
the category with the URI urn:ietf:params:qlog:events:http#h3. 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 07 of this
document is identified using the URI urn:ietf:params:qlog:events:http#h3-07.¶
The category identifier itself is not affected by this requirement.¶
HTTP/3 events extend the $ProtocolEventData extension point defined in
[QLOG-MAIN]. Additionally, they allow for direct extensibility by their use of
per-event extension points via the $$ CDDL "group socket" syntax, as also
described in [QLOG-MAIN].¶
H3EventData = H3ParametersSet /
H3ParametersRestored /
H3StreamTypeSet /
H3PriorityUpdated /
H3FrameCreated /
H3FrameParsed /
H3DatagramCreated /
H3DatagramParsed /
H3PushResolved
$ProtocolEventData /= H3EventData
HTTP events are logged when a certain condition happens at the application layer, and there isn't always a one to one mapping between HTTP and QUIC events. The exchange of data between the HTTP and QUIC layer is logged via the "stream_data_moved" and "datagram_data_moved" events in [QLOG-QUIC].¶
HTTP/3 frames are transmitted on QUIC streams, which allows them to span multiple QUIC packets. Some implementations might send a single large frame, rather than a sequence of smaller frames, in order to amortize frame header overhead. HTTP/3 frame headers are represented by the frame_created (Section 3.5) and frame_parsed (Section 3.6) events. Subsequent frame payload data transfer is indicated by stream_data_moved events. Furthermore, stream_data_moved events can appear before frame_parsed events because implementations need to read data from a stream in order to parse the frame header.¶
The parameters_set event contains HTTP/3 and QPACK-level settings, mostly
those received from the HTTP/3 SETTINGS frame. It has Base importance level; see
Section 9.2 of [QLOG-MAIN].¶
All these parameters are typically set once and never change. However, they
might be set at different times during the connection, therefore a qlog can have
multiple instances of parameters_set with different fields set.¶
The "owner" field reflects how Settings are exchanged on a connection. Sent settings have the value "local" and received settings have the value "received".¶
H3ParametersSet = {
? owner: Owner
; RFC9114
? max_field_section_size: uint64
; RFC9204
? max_table_capacity: uint64
? blocked_streams_count: uint64
; RFC9220 (SETTINGS_ENABLE_CONNECT_PROTOCOL)
? extended_connect: uint16
; RFC9297 (SETTINGS_H3_DATAGRAM)
? h3_datagram: uint16
; qlog-specific
; indicates whether this implementation waits for a SETTINGS
; frame before processing requests
? waits_for_settings: bool
* $$h3-parametersset-extension
}
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.¶
When using QUIC 0-RTT, HTTP/3 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/3 settings were restored and to which values when
utilizing 0-RTT. It has Base importance level; see Section 9.2 of [QLOG-MAIN].¶
H3ParametersRestored = {
; RFC9114
? max_field_section_size: uint64
; RFC9204
? max_table_capacity: uint64
? blocked_streams_count: uint64
; RFC9220 (SETTINGS_ENABLE_CONNECT_PROTOCOL)
? extended_connect: uint16
; RFC9297 (SETTINGS_H3_DATAGRAM)
? h3_datagram: uint16
* $$h3-parametersrestored-extension
}
The stream_type_set event conveys when a HTTP/3 stream type becomes known; see
Sections 6.1 and 6.2 of [HTTP/3]. It has Base importance level; see Section 9.2 of [QLOG-MAIN].¶
Client bidirectional streams always have a stream_type value of "request". Server bidirectional streams have no defined use, although extensions could change that.¶
Unidirectional streams in either direction begin with with a variable-length integer type. Where the type is not known, the stream_type value of "unknown" type can be used and the value captured in the stream_type_bytes field; a numerical value without variable-length integer encoding.¶
The generic $H3StreamType is defined here as a CDDL "type socket" extension
point. It can be extended to support additional HTTP/3 stream types.¶
H3StreamTypeSet = {
? owner: Owner
stream_id: uint64
stream_type: $H3StreamType
; only when stream_type === "unknown"
? stream_type_bytes: uint64
; only when stream_type === "push"
? associated_push_id: uint64
* $$h3-streamtypeset-extension
}
$H3StreamType /= "request" /
"control" /
"push" /
"reserved" /
"unknown" /
"qpack_encode" /
"qpack_decode"
Emitted when the priority of a request stream or push stream is initialized or updated through mechanisms defined in [RFC9218]. For example, the priority can be updated through signals received from client and/or server (e.g., in HTTP/3 HEADERS or PRIORITY_UPDATE frames) or it can be changed or overridden due to local policies. The event has Base importance level; see Section 9.2 of [QLOG-MAIN].¶
H3PriorityUpdated = {
; if the prioritized element is a request stream
? stream_id: uint64
; if the prioritized element is a push stream
? push_id: uint64
? old: H3Priority
new: H3Priority
* $$h3-priorityupdated-extension
}
The frame_created event is emitted when the HTTP/3 framing actually happens.
It has Core importance level; see Section 9.2 of [QLOG-MAIN].¶
This event does not necessarily coincide with HTTP/3 data getting passed to the
QUIC layer. For that, see the stream_data_moved event in [QLOG-QUIC].¶
H3FrameCreated = {
stream_id: uint64
? length: uint64
frame: $H3Frame
? raw: RawInfo
* $$h3-framecreated-extension
}
The frame_parsed event is emitted when the HTTP/3 frame is parsed. It has Core
importance level; see Section 9.2 of [QLOG-MAIN].¶
This event is not necessarily the same as when the HTTP/3 data is actually
received on the QUIC layer. For that, see the stream_data_moved event in
[QLOG-QUIC].¶
H3FrameParsed = {
stream_id: uint64
? length: uint64
frame: $H3Frame
? raw: RawInfo
* $$h3-frameparsed-extension
}
The datagram_created event is emitted when an HTTP/3 Datagram is created (see
[RFC9297]). It has Base importance level; see Section 9.2 of [QLOG-MAIN].¶
This event does not necessarily coincide with the HTTP/3 Datagram getting passed
to the QUIC layer. For that, see the datagram_data_moved event in
[QLOG-QUIC].¶
H3DatagramCreated = {
quarter_stream_id: uint64
? datagram: $H3Datagram
? raw: RawInfo
* $$h3-datagramcreated-extension
}
The datagram_parsed event is emitted when the HTTP/3 Datagram is parsed (see
[RFC9297]). It has Base importance level; see Section 9.2 of [QLOG-MAIN].¶
This event is not necessarily the same as when the HTTP/3 Datagram is actually
received on the QUIC layer. For that, see the datagram_data_moved event in
[QLOG-QUIC].¶
H3DatagramParsed = {
quarter_stream_id: uint64
? datagram: $H3Datagram
? raw: RawInfo
* $$h3-datagramparsed-extension
}
The push_resolved event is emitted when a pushed resource (Section 4.6 of [HTTP/3]) is successfully claimed (used) or, conversely, abandoned (rejected)
by the application on top of HTTP/3 (e.g., the web browser). This event provides
additional context that can is aid debugging issues related to server push. It
has Extra importance level; see Section 9.2 of [QLOG-MAIN].¶
H3PushResolved = {
? push_id: uint64
; in case this is logged from a place that does not have access
; to the push_id
? stream_id: uint64
decision: H3PushDecision
* $$h3-pushresolved-extension
}
H3PushDecision = "claimed" /
"abandoned"
The following data field definitions can be used in HTTP/3 events.¶
Owner = "local" /
"remote"
The generic $H3Frame is defined here as a CDDL "type socket" extension point.
It can be extended to support additional HTTP/3 frame types.¶
; The H3Frame is any key-value map (e.g., JSON object)
$H3Frame /= {
* text => any
}
The HTTP/3 frame types defined in this document are as follows:¶
H3BaseFrames = H3DataFrame /
H3HeadersFrame /
H3CancelPushFrame /
H3SettingsFrame /
H3PushPromiseFrame /
H3GoawayFrame /
H3MaxPushIDFrame /
H3ReservedFrame /
H3UnknownFrame
$H3Frame /= H3BaseFrames
The generic $H3Datagram is defined here as a CDDL "type socket" extension
point. It can be extended to support additional HTTP/3 datagram types. This
document intentionally does not define any specific qlog schemas for specific
HTTP/3 Datagram types.¶
; The H3Datagram is any key-value map (e.g., JSON object)
$H3Datagram /= {
* text => any
}
H3DataFrame = {
frame_type: "data"
? raw: RawInfo
}
The payload of an HTTP/3 HEADERS frame is the QPACK-encoding of an HTTP field
section; see Section 7.2.2 of [HTTP/3]. H3HeaderFrame, in contrast,
contains the HTTP field section without QPACK encoding.¶
H3HTTPField = {
? name: text
? name_bytes: hexstring
? value: text
? value_bytes: hexstring
}
H3HeadersFrame = {
frame_type: "headers"
headers: [* H3HTTPField]
}
For example, the HTTP field section¶
:path: /index.html :method: GET :authority: example.org :scheme: https¶
would be represented in a JSON serialization as:¶
headers: [
{
"name": ":path",
"value": "/"
},
{
"name": ":method",
"value": "GET"
},
{
"name": ":authority",
"value": "example.org"
},
{
"name": ":scheme",
"value": "https"
}
]
Section 4.2 of [HTTP/3] and Section 5.1 of [HTTP] 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 H3HTTPField. 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 H3HTTPField MUST include either the name or name_bytes
field and MAY include both. An H3HTTPField MAY include a value or
value_bytes field or neither.¶
H3CancelPushFrame = {
frame_type: "cancel_push"
push_id: uint64
}
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/http3-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.¶
H3SettingsFrame = {
frame_type: "settings"
settings: [* H3Setting]
}
H3Setting = {
? name: $H3SettingsName
; only when name === "unknown"
? name_bytes: uint64
value: uint64
}
$H3SettingsName /= "settings_qpack_max_table_capacity" /
"settings_max_field_section_size" /
"settings_qpack_blocked_streams" /
"settings_enable_connect_protocol" /
"settings_h3_datagram" /
"reserved" /
"unknown"
H3PushPromiseFrame = {
frame_type: "push_promise"
push_id: uint64
headers: [* H3HTTPField]
}
H3GoawayFrame = {
frame_type: "goaway"
; Either stream_id or push_id.
; This is implicit from the sender of the frame
id: uint64
}
H3MaxPushIDFrame = {
frame_type: "max_push_id"
push_id: uint64
}
The PRIORITY_UPDATE frame is defined in [RFC9218].¶
H3PriorityUpdateFrame = {
frame_type: "priority_update"
; if the prioritized element is a request stream
? stream_id: uint64
; if the prioritized element is a push stream
? push_id: uint64
priority_field_value: H3Priority
}
; The priority value in ASCII text, encoded using Structured Fields
; Example: u=5, i
H3Priority = text
H3ReservedFrame = {
frame_type: "reserved"
? length: uint64
}
The frame_type_bytes field is the numerical value without variable-length integer encoding.¶
H3UnknownFrame = {
frame_type: "unknown"
frame_type_bytes: uint64
? raw: RawInfo
}
H3ApplicationError = "http_no_error" /
"http_general_protocol_error" /
"http_internal_error" /
"http_stream_creation_error" /
"http_closed_critical_stream" /
"http_frame_unexpected" /
"http_frame_error" /
"http_excessive_load" /
"http_id_error" /
"http_settings_error" /
"http_missing_settings" /
"http_request_rejected" /
"http_request_cancelled" /
"http_request_incomplete" /
"http_early_response" /
"http_connect_error" /
"http_version_fallback"
The H3ApplicationError extends the general $ApplicationError definition in the qlog QUIC document, see [QLOG-QUIC].¶
; ensure HTTP errors are properly validated in QUIC events as well ; e.g., QUIC's ConnectionClose Frame $ApplicationError /= H3ApplicationError¶
The security and privacy considerations discussed in [QLOG-MAIN] apply to this document as well.¶
This document registers a new entry in the "qlog event category URIs" registry.¶
Much of the initial work by Robin Marx was done at the Hasselt and KU Leuven Universities.¶
Thanks to Jana Iyengar, Brian Trammell, Dmitri Tikhonov, Stephen Petrides, Jari Arkko, Marcus Ihlar, Victor Vasiliev, Mirja Kuehlewind, Jeremy Laine, Kazu Yamamoto, Christian Huitema, Hugo Landau and Jonathan Lennox for their feedback and suggestions.¶
This section is to be removed before publishing as an RFC.¶
Major changes:¶
Smaller changes:¶