PQ Crypta Logo

aioquic — HTTP/3 Conformance Results

aioquic, 1.3.0. How it answers when the server deliberately breaks the protocol.

PQ CRYPTA PLATFORM

🏠 Main

🧪 Interactive Apps

📰 News

🛡️ PQ Crypta Proxy

👤 Account

⟨ QUANTUM ERROR PORTAL ⟩

Navigate the Error Dimensions

38Pass
3Fail
11Inconclusive
93%of 41 conclusive

Stack: aioquic · Language: Python · Version: 1.3.0 · Measured 2026-09-17

Badge for a README: https://pqcrypta.com/conformance/badge/aioquic.svg aioquic conformance badge

By class

Rolled up by what the clause requires rather than into one number. A client that ignores unknown extensions correctly but never emits the right error codes has a specific, nameable problem, and an average is exactly what hides it.

ClassPassing meansPassFailInconclusive
correctness Rejected something invalid, with the code the RFC names. 14 2 6
discretionary The RFC permits either behaviour; the report says which was chosen. 11 0 1
extensibility Ignored something unknown and carried on. 4 0 0
interoperability Correctly decoded something valid but demanding. 5 0 2
resilience Recovered rather than giving up. 4 1 2

Every result

TestClauseVerdictWhat happened
Version Negotiation offering a reserved version alongside v1 RFC 9000 §6 Pass Responded correctly: sent Version Negotiation for 1 datagram(s); the client did not persist with an unsupported version.
Retry packet for source-address validation RFC 9000 §8.1.2 Pass Responded correctly: echoed the Retry token and completed the handshake.
Reserved transport parameter (31·N+27) RFC 9000 §18.1 Pass Ignored the unrecognised element and carried on: completed a handshake carrying a reserved transport parameter.
Unknown frame type in a 1-RTT packet RFC 9000 §12.4 Pass Responded correctly: closed with FRAME_ENCODING_ERROR, which is the code §12.4 requires for a frame of unknown type.
NEW_CONNECTION_ID followed by RETIRE_CONNECTION_ID RFC 9000 §5.1 Inconclusive The run did not exercise this test: the connection was too short-lived to require a rotation.
Stateless reset RFC 9000 §10.3 Fail kept sending after the Stateless Reset: 85 more datagram(s) arrived in the following 3 seconds. RFC 9000 §10.3.1 requires a client that recognises the token to enter the draining period and send nothing further, so this connection is wedged against an endpoint that has forgotten it.
Deliberately tight MAX_DATA and MAX_STREAM_DATA RFC 9000 §4 Pass Handled it: respected the window without sending a BLOCKED frame, which §4.1 permits.
ACK Frequency extension offered draft-ietf-quic-ack-frequency Pass Handled it: ignored the extension, which the specification permits.
Packets marked ECT(0) RFC 9000 §13.4 Inconclusive The run did not exercise this test: ECN validation failed: packets sent marked ECT(0) came back acknowledged without ECN counts, so the marking was disabled. Whether the peer declined to report or the path rewrote the codepoint cannot be told apart from this end.
Path MTU black hole above a threshold RFC 9000 §14, RFC 8899 Pass Recovered: detected the black hole 1 time(s) and settled on a 1293-byte path MTU (59 datagram(s) swallowed).
Server-initiated PATH_CHALLENGE RFC 9000 §8.2 Pass Responded correctly: answered with 1 PATH_RESPONSE.
0-RTT rejected after the client sends early data RFC 9001 §4.6.2 Inconclusive The run did not exercise this test: the client sent no early data, so nothing was rejected. 0-RTT needs a session ticket from an earlier connection to this same port, and a client that connects once has none.
A second path offered mid-connection draft-ietf-quic-multipath Pass Handled it: declined the multipath offer and stayed on one path, which is conformant.
Spontaneous 1-RTT key update RFC 9001 §6.2 Pass Decoded it and completed the request.
Stream limits set to the minimum a request needs RFC 9000 §4.6 Pass Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant.
One datagram in twelve dropped once the path is established RFC 9000 §2.2, §13.3 Pass Recovered and completed the follow-up request.
Datagrams arriving from a second server address RFC 9000 §9.6 Pass Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant.
Transport parameter carrying a value the specification forbids RFC 9000 §7.4, §18.2 Pass Responded correctly: closed with TRANSPORT_PARAMETER_ERROR, which is the code §7.4 requires for a parameter carrying an invalid value (ack_delay_exponent = 21, where §18.2 permits at most 20).
425 (Too Early) in answer to a request sent as early data RFC 8470 §5.2 Inconclusive The run did not exercise this test: the client sent no early data, so it was never answered 425. 0-RTT needs a session ticket from an earlier connection to this same port, and a client that connects once has none.
Path marking packets CE, not just ECT(0) RFC 9000 §13.4 Inconclusive The run did not exercise this test: no ECN counts came back at all. §13.4.1 requires reporting only where the ECN field is accessible, and a path that stripped the codepoint cannot be told apart from a client that does not report.
A second key update after the first is acknowledged RFC 9001 §6.1, §6.5 Pass Decoded it and completed the request.
No stream credit at first, then MAX_STREAMS mid-connection RFC 9000 §4.6 Pass Handled it: announced the block with 1 STREAMS_BLOCKED rather than opening a stream it had no credit for, which is what §4.6 recommends.
Reserved SETTINGS identifier (0x1f·N+0x21) RFC 9114 §7.2.4.1 Pass Ignored the unrecognised element and completed the follow-up request.
Reserved frame type on the response stream RFC 9114 §7.2.8 Pass Ignored the unrecognised element and completed the follow-up request.
Unidirectional stream with a reserved stream type RFC 9114 §6.2.3 Pass Ignored the unrecognised element and completed the follow-up request.
SETTINGS containing the same identifier twice RFC 9114 §7.2.4 Pass Rejected with error 0x109. The specification permits this but does not require it; a client that ignored it would also be conformant.
A DATA frame on the control stream RFC 9114 §7.2.1 Pass Rejected with the required error code 0x105.
Control stream whose first frame is not SETTINGS RFC 9114 §6.2.1 Pass Rejected with the required error code 0x10a.
A second control stream opened by the server RFC 9114 §6.2.1 Pass Rejected with the required error code 0x103.
Field lines referencing dynamic table insertions RFC 9204 §4.3.3, §4.5.2 Inconclusive The run did not exercise this test: the client advertised SETTINGS_QPACK_MAX_TABLE_CAPACITY of 0 and SETTINGS_QPACK_BLOCKED_STREAMS of 0, which forbid the server's encoder from using the dynamic table at all.
Huffman-coded field lines with maximal padding RFC 9204 §4.1.2, RFC 7541 §5.2 Pass Decoded it and completed the request.
Field section larger than the client's advertised maximum RFC 9114 §4.2.2 Pass Decoded it and completed the request.
Trailing field section after the body RFC 9114 §4.1 Pass Decoded it and completed the request.
103 Early Hints before the final response RFC 9110 §15.2, RFC 8297 Fail Gave up with error 0x10e instead of recovering.
GOAWAY sent mid-connection RFC 9114 §5.2 Pass Recovered and completed the follow-up request.
MAX_PUSH_ID sent by the server RFC 9114 §7.2.7 Pass Rejected with the required error code 0x105.
SETTINGS frame on a request stream RFC 9114 §7.2.4 Pass Rejected with the required error code 0x105.
DATA frame before any HEADERS on the response stream RFC 9114 §4.1 Pass Rejected with the required error code 0x105.
CANCEL_PUSH for a push ID that was never promised RFC 9114 §7.2.3 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.
Field section that blocks until the encoder stream catches up RFC 9204 §2.1.2, §2.2.1 Inconclusive The run did not exercise this test: the client advertised SETTINGS_QPACK_MAX_TABLE_CAPACITY of 0 and SETTINGS_QPACK_BLOCKED_STREAMS of 0, which forbid the server's encoder from using the dynamic table at all.
Response stream reset mid-body with H3_REQUEST_CANCELLED RFC 9114 §8, §4.1 Pass Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant.
PRIORITY_UPDATE sent by the server RFC 9218 §7.2 Pass Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant.
SETTINGS_ENABLE_CONNECT_PROTOCOL with a value outside 0 and 1 RFC 9220 §3, RFC 8441 §3 Pass Rejected with error 0x109. The specification permits this but does not require it; a client that ignored it would also be conformant.
PUSH_PROMISE for a push the client never allowed RFC 9114 §7.2.5, §4.6 Fail Rejected, but with error 0x105 where the specification requires 0x108. The violation was detected; the code reported is wrong.
SETTINGS_H3_DATAGRAM with a value that is neither 0 nor 1 RFC 9297 §2.1.1 Pass Rejected with the required error code 0x109.
Encoder stream setting a dynamic table capacity above the client's limit RFC 9204 §4.3.1, §6 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.
A second GOAWAY naming a larger identifier than the first RFC 9114 §5.2 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.
Push stream opened for a push nobody allowed RFC 9114 §6.2.2 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.
Field line indexing a static table entry that does not exist RFC 9204 §3.1, §4.5.2 Pass Rejected with the required error code 0x200.
Datagrams delivered out of order RFC 9000 §2.2 Pass Recovered and completed the follow-up request.
Encoder instruction naming a static index that does not exist RFC 9204 §3.1, §4.3.2 Pass Rejected with the required error code 0x201.
Server negotiates only the post-quantum hybrid X25519MLKEM768 RFC 8446 §4.1.4, draft-ietf-tls-hybrid-design Not run Not attempted.
Server negotiates only classical X25519 against a hybrid offer RFC 8446 §4.1.1, draft-ietf-tls-hybrid-design §5 Pass Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant.
Hybrid key share large enough to split the Initial across packets RFC 9000 §8.1, §14.1, RFC 9001 §4.4 Not run Not attempted.
Server selects a key exchange group the client never offered RFC 8446 §4.1.3, §4.2.8, RFC 9001 §4.8 Not run Not attempted.
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 Not run Not attempted.
GREASE named group a client must tolerate RFC 8701 §4, RFC 8446 §4.2.7 Not run Not attempted.

What this suite is · The full grid · All clients · All tests · Findings