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 run did not establish what this client does here — either it was never put in the situation, or its answer admits more than one reading. Not a failure, and never counted as one.
What was measured
- Client
- msquic — .NET HttpClient + msquic, 2.7.0
- Test
- Encoder instruction naming a static index that does not exist —
h-qpack-encoder-bad-name-index - Clause
- RFC 9204 §3.1, §4.3.2 (MUST)
- Class
- correctness — Rejected something invalid, with the code the RFC names.
- Required behaviour
- Close the connection with QPACK_ENCODER_STREAM_ERROR (0x201). The same bad index means different things depending on where it arrives, and §3.1 says both: on a field line it is QPACK_DECOMPRESSION_FAILED, and "if this index is received on the encoder stream, this MUST be treated as a connection error of type QPACK_ENCODER_STREAM_ERROR". Paired deliberately with the field-line version on the neighbouring port: a client that answers both with the same code has collapsed a distinction the specification draws twice in one paragraph.
- 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 msquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["h-qpack-encoder-bad-name-index"]'
What this suite is · The full grid · All clients · All tests · Findings