lsquic — SETTINGS_H3_DATAGRAM with a value that is neither 0 nor 1

Inconclusive

The client completed its request and closed without objecting, but the anomaly was written to the control stream — a unidirectional stream nothing obliges it to read on any schedule. A one-shot request can finish before that stream is picked up, so this is equally consistent with accepting the violation and with never having seen it, and neither can be told from here.

The run did not establish what this client does here — either it was never put in the situation, or its answer admits more than one reading. Not a failure, and never counted as one.

What was measured

Client

lsquic — LiteSpeed lsquic + BoringSSL, 4.9.4

Test

SETTINGS_H3_DATAGRAM with a value that is neither 0 nor 1 — h-datagram-setting-invalid

Clause

RFC 9297 §2.1.1 (MUST)

Class

correctness — Rejected something invalid, with the code the RFC names.

Required behaviour

Close the connection with H3_SETTINGS_ERROR. Unusually for a setting, RFC 9297 pins down the invalid-value case rather than leaving it open: the value "MUST be either 0 or 1", and if one "is received with a value that is neither 0 nor 1, the receiver MUST terminate the connection with error H3_SETTINGS_ERROR". This is the setting that gates HTTP Datagrams and so WebTransport, which means a client that implements either has real parsing behind it rather than an ignored identifier.

Measured

2026-09-18

Reproduce it

The suite is the judge, so the reproduction is to point the same client at the same test and let the server report what it saw.

SESSION=$(curl -sX POST https://conformance.pqcrypta.com/session | jq -r .id)
# then drive lsquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["h-datagram-setting-invalid"]'