Each implementation below was driven through every test by the runner,
which spawns the client's own binary. The suite is the judge: it can see
what the client did on the wire, which the client cannot honestly report
about itself.
A pass rate is over conclusive results only — pass plus
fail. Inconclusive means the run never put the client in the situation the
test is about, which is a fact about the run and not about the client.
ngtcp2 + nghttp3 · C · ngtcp2/1.11.0
30 Pass0 Fail22 Inconclusive5 Not run
100% of 30 conclusive
quinn + h3 (our fork) · Rust · noq fork
38 Pass3 Fail16 Inconclusive
93% of 41 conclusive
aioquic · Python · 1.3.0
38 Pass3 Fail11 Inconclusive5 Not run
93% of 41 conclusive
Chromium QUICHE · C++ · build 1223
43 Pass5 Fail9 Inconclusive
90% of 48 conclusive
quic-go · Go · quic-go v0.61.0
42 Pass2 Fail13 Inconclusive
95% of 44 conclusive
Cloudflare quiche · Rust · 0.30.0
41 Pass3 Fail13 Inconclusive
93% of 44 conclusive
neqo (Firefox) · Rust · unknown
42 Pass4 Fail11 Inconclusive
91% of 46 conclusive
Where they disagree
28 of 57 tests
drew more than one answer. Several are discretionary — the RFC permits either
behaviour and the disagreement is not a defect in anybody. The rest are the
rows worth reading.
-
Unknown frame type in a 1-RTT packet
RFC 9000 §12.4 · correctness
-
NEW_CONNECTION_ID followed by RETIRE_CONNECTION_ID
RFC 9000 §5.1 · resilience
-
Stateless reset
RFC 9000 §10.3 · correctness
-
Packets marked ECT(0)
RFC 9000 §13.4 · correctness
-
Transport parameter carrying a value the specification forbids
RFC 9000 §7.4, §18.2 · correctness
-
Path marking packets CE, not just ECT(0)
RFC 9000 §13.4 · correctness
-
No stream credit at first, then MAX_STREAMS mid-connection
RFC 9000 §4.6 · discretionary
-
A DATA frame on the control stream
RFC 9114 §7.2.1 · correctness
-
Control stream whose first frame is not SETTINGS
RFC 9114 §6.2.1 · correctness
-
A second control stream opened by the server
RFC 9114 §6.2.1 · correctness
-
103 Early Hints before the final response
RFC 9110 §15.2, RFC 8297 · resilience
-
GOAWAY sent mid-connection
RFC 9114 §5.2 · resilience
-
MAX_PUSH_ID sent by the server
RFC 9114 §7.2.7 · correctness
-
SETTINGS frame on a request stream
RFC 9114 §7.2.4 · correctness
-
DATA frame before any HEADERS on the response stream
RFC 9114 §4.1 · correctness
-
CANCEL_PUSH for a push ID that was never promised
RFC 9114 §7.2.3 · correctness
-
PUSH_PROMISE for a push the client never allowed
RFC 9114 §7.2.5, §4.6 · correctness
-
SETTINGS_H3_DATAGRAM with a value that is neither 0 nor 1
RFC 9297 §2.1.1 · correctness
-
A second GOAWAY naming a larger identifier than the first
RFC 9114 §5.2 · correctness
-
Push stream opened for a push nobody allowed
RFC 9114 §6.2.2 · correctness
-
Field line indexing a static table entry that does not exist
RFC 9204 §3.1, §4.5.2 · correctness
-
Encoder instruction naming a static index that does not exist
RFC 9204 §3.1, §4.3.2 · correctness
-
Server negotiates only the post-quantum hybrid X25519MLKEM768
RFC 8446 §4.1.4, draft-ietf-tls-hybrid-design · interoperability
-
Server negotiates only classical X25519 against a hybrid offer
RFC 8446 §4.1.1, draft-ietf-tls-hybrid-design §5 · discretionary
-
Hybrid key share large enough to split the Initial across packets
RFC 9000 §8.1, §14.1, RFC 9001 §4.4 · resilience
-
Server selects a key exchange group the client never offered
RFC 8446 §4.1.3, §4.2.8, RFC 9001 §4.8 · correctness
-
Hybrid key share with an intact X25519 half and a corrupt ML-KEM half
draft-ietf-tls-hybrid-design §3.2, RFC 8446 §4.1.3 · correctness
-
GREASE named group a client must tolerate
RFC 8701 §4, RFC 8446 §4.2.7 · extensibility