48Pass
6Fail
5Unsupported
89%of 54 conclusive
Stack: quic-go ·
Language: Go ·
Version: quic-go v0.61.0 (h1:9So2anK4Tp22)
· Measured 2026-10-27
Badge for a README:
https://pqcrypta.com/conformance/badge/quic-go.svg
Known causes behind this client's cells
The run reports what the server saw and stops there. Where a separate experiment has since established why a cell landed where it did, it is recorded here rather than folded into the verdict — a cause found afterwards is not something the run observed, and a suite that quietly upgrades one into the other stops being reproducible.
quic-go usually reads a server's MAX_PUSH_ID and carries on; now and then it rejects it correctly.
Driven directly against this endpoint on 2026-09-25, quic-go v0.61.0 closed with H3_FRAME_UNEXPECTED (0x105) in one run of eight. In the other seven it consumed the frame -- it extended flow-control credit on the control stream, so the bytes were read -- then completed the request about a second later than usual and closed cleanly. Which one happens depends on scheduling inside the client, so this cell can differ between runs of the same build; the verdict published is the behaviour seen in most runs. A conformant client rejects this frame every time: MAX_PUSH_ID is a client-to-server frame (RFC 9114 §7.2.7).
Measured by goquic-get driven directly, 8 runs, 2026-09-25.
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.
| Class | Passing means | Pass | Fail | Inconclusive |
|---|---|---|---|---|
| correctness | Rejected something invalid, with the code the RFC names. | 18 | 5 | 0 |
| discretionary | The RFC permits either behaviour; the report says which was chosen. | 12 | 0 | 0 |
| extensibility | Ignored something unknown and carried on. | 5 | 0 | 0 |
| interoperability | Correctly decoded something valid but demanding. | 6 | 0 | 0 |
| resilience | Recovered rather than giving up. | 7 | 1 | 0 |
Every result
| Test | Clause | Verdict | What happened |
|---|---|---|---|
| Version Negotiation offering a reserved version alongside v1 | RFC 9000 §6 | Pass | Responded correctly: sent Version Negotiation for 2 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 | Pass | Recovered: rotated connection IDs and retired 33 of them. |
| Stateless reset | RFC 9000 §10.3 | Pass | Responded correctly: was sent a Stateless Reset and went quiet — nothing further arrived in the 3 seconds that followed, which is the draining period §10.3.1 requires (0 datagram(s) were already in flight when the reset went out and are not counted against 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 | Pass | Responded correctly: echoed ECN counts back in its ACKs: 18 ECT(0), 0 ECT(1), 0 ECN-CE. |
| 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 (0 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 | Fail | Stalled instead of recovering. |
| 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. The client process had already exited 3008ms in, before this test's reaction point at 3043ms, so the silence after that is not evidence either way. |
| Transport parameter carrying a value the specification forbids | RFC 9000 §7.4, §18.2 | Fail | rejected the out-of-range parameter with INTERNAL_ERROR, where RFC 9000 §7.4 requires TRANSPORT_PARAMETER_ERROR. The violation was detected; the code reported is wrong. |
| 425 (Too Early) in answer to a request sent as early data | RFC 8470 §5.2 | Pass | Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant. |
| Path marking packets CE, not just ECT(0) | RFC 9000 §13.4 | Pass | Responded correctly: reported the congestion back: 19 ECN-CE among 0 ECT(0) and 0 ECT(1), after 21 datagram(s) were marked. |
| 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. The client process had already exited 3056ms in, before this test's reaction point at never observed, so the silence after that is not evidence either way. |
| 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. The client process had already exited 3077ms in, before this test's reaction point at never observed, so the silence after that is not evidence either way. |
| SETTINGS containing the same identifier twice | RFC 9114 §7.2.4 | Pass | Rejected with error 0x106. 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 | Unsupported | 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 | Pass | Recovered and completed the follow-up request. |
| GOAWAY sent mid-connection | RFC 9114 §5.2 | Pass | Recovered and completed the follow-up request. The client process had already exited 3056ms in, before this test's reaction point at never observed, so the silence after that is not evidence either way. |
| 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 | Fail | Rejected, but with error 0x105 where the specification requires 0x108. The violation was detected; the code reported is wrong. |
| Field section that blocks until the encoder stream catches up | RFC 9204 §2.1.2, §2.2.1 | Unsupported | 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. The client process had already exited 3064ms in, before this test's reaction point at never observed, so the silence after that is not evidence either way. |
| SETTINGS_ENABLE_CONNECT_PROTOCOL with a value outside 0 and 1 | RFC 9220 §3, RFC 8441 §3 | Pass | Rejected with error 0x106. 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 | Accepted a protocol violation and carried on. The anomaly was in the response the client read and delivered, so it was seen; this should have been rejected. |
| SETTINGS_H3_DATAGRAM with a value that is neither 0 nor 1 | RFC 9297 §2.1.1 | Fail | Rejected, but with error 0x106 where the specification requires 0x109. The violation was detected; the code reported is wrong. |
| Encoder stream setting a dynamic table capacity above the client's limit | RFC 9204 §4.3.1, §6 | Unsupported | does not read the QPACK encoder stream, so the invalid instruction on it never reached its decoder. This endpoint filled the flow-control window the client granted on that stream and no credit came back while the client stayed connected -- a client that had consumed the stream would have had to grant more. |
| A second GOAWAY naming a larger identifier than the first | RFC 9114 §5.2 | Pass | Rejected with the required error code 0x108. |
| Push stream opened for a push nobody allowed | RFC 9114 §6.2.2 | Pass | Rejected with the required error code 0x108. |
| Field line indexing a static table entry that does not exist | RFC 9204 §3.1, §4.5.2 | Fail | rejected the field section with QPACK_DECOMPRESSION_FAILED, but as a stream error: it stopped the request stream and kept the connection open. The code is right and the scope is not -- RFC 9204 makes every decompression failure a connection error. |
| 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 | Unsupported | does not read the QPACK encoder stream, so the invalid instruction on it never reached its decoder. This endpoint filled the flow-control window the client granted on that stream and no credit came back while the client stayed connected -- a client that had consumed the stream would have had to grant more. |
| Server negotiates only the post-quantum hybrid X25519MLKEM768 | RFC 8446 §4.1.4, draft-ietf-tls-hybrid-design | Pass | Decoded it and completed the request. |
| 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 | Pass | Recovered and completed the follow-up request. |
| Server selects a key exchange group the client never offered | RFC 8446 §4.1.3, §4.2.8, RFC 9001 §4.8 | Pass | Responded correctly: aborted with illegal_parameter (alert 47) over a key_share naming a group it never offered, which is exactly what RFC 8446 §4.1.3 requires. |
| 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 | Pass | Responded correctly: did not complete the handshake (timed out). The shared secret is both halves through the key schedule, so a corrupt ML-KEM half must break it -- and this client did not fall back to the intact X25519 half. |
| 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 | Pass | Responded correctly: aborted with illegal_parameter (alert 47) over a server share of the wrong length for X25519MLKEM768, which is the check §3.1.2 asks the client to make and the code it names. |
| Post-quantum certificate chain, compressed per RFC 8879 | RFC 8879 §4, RFC 8446 §4.4.2 | Unsupported | The client's signature_algorithms named nothing that can verify an ML-DSA-87 chain, so this endpoint refused before sending one. Post-quantum certificates are not reachable for this client at all. |
| GREASE named group a client must tolerate | RFC 8701 §4, RFC 8446 §4.2.7 | Pass | Ignored the unrecognised element and completed the follow-up request. |