The client completed its request and then said nothing further before the window closed. A rejection whose CONNECTION_CLOSE was lost cannot be told apart from a client that never objected: QUIC re-sends that frame only in answer to an incoming packet, so one that goes missing is simply never seen.
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.
What was measured
- Client
- quic-go — quic-go, quic-go v0.61.0
- Test
- Field line indexing a static table entry that does not exist —
h-qpack-static-index-invalid - Clause
- RFC 9204 §3.1, §4.5.2 (MUST)
- Class
- correctness — Rejected something invalid, with the code the RFC names.
- Required behaviour
- Close the connection with QPACK_DECOMPRESSION_FAILED (0x200). The static table has 99 entries, so index 200 refers to nothing, and §3.1 is explicit: "When the decoder encounters an invalid static table index in a field line representation, it MUST treat this as a connection error of type QPACK_DECOMPRESSION_FAILED." The static table needs no permission and never changes size, so unlike the dynamic-table tests this one applies to every client.
- 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 quic-go at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["h-qpack-static-index-invalid"]'