HTTP/3 Client Implementations Measured

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. The client does not do this, and said so itself — by what it advertised, or by refusing outright. A definite answer about the client, not a failure and not a gap. The suite could not establish what this client does here. That is a shortcoming of the run rather than anything about the client, and every one of these is on our list to remove.

Ordered by how much of the catalogue each client actually answered, not by pass rate. A rate on its own ranks a client that reached half the tests and passed them above one that reached nearly all and passed most — which is an artifact of how thin the driving wrapper is, not a fact about the implementation. Coverage is the harder number, so it sorts first.

Self-test, excluded from the comparison

quinn runs on the same stack the suite itself is built on. Its results are a useful check that the harness still works and are not evidence about anybody else's implementation, so they are published in full and left out of every comparative figure on this site — the ranking above, the disagreement counts, and any statement of the form “N of the clients”. The only real fix for a suite judging its own stack is a second, independent implementation, and there is not one.

Where they disagree

22 of 59 tests drew both a pass and a fail from independent clients on a clause that permits only one answer. That is the number worth reading: on each of these rows, somebody is wrong.

A further 0 split on discretionary tests, where the RFC allows either behaviour. Clients differing there is the specification working as written, so those are listed but are not disagreements about correctness. Counted together — as they were until 2026-09-19 — the interesting number hides inside the dull one. Verdicts of unsupported and inconclusive are excluded from both: neither is an answer to the clause.

• 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
• 0-RTT rejected after the client sends early data RFC 9001 §4.6.2 · resilience
• Transport parameter carrying a value the specification forbids RFC 9000 §7.4, §18.2 · correctness
• 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
• 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
• Encoder stream setting a dynamic table capacity above the client's limit RFC 9204 §4.3.1, §6 · 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 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 whose length does not match the group named with it draft-kwiatkowski-tls-ecdhe-mlkem §3.1.2, RFC 8446 §6.2, RFC 9001 §4.8 · correctness