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.
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
- quinn — quinn + h3 (our fork), noq fork
- Test
- Encoder stream setting a dynamic table capacity above the client's limit —
h-qpack-encoder-overflow - Clause
- RFC 9204 §4.3.1, §6 (MUST)
- Class
- correctness — Rejected something invalid, with the code the RFC names.
- Required behaviour
- Close the connection with QPACK_ENCODER_STREAM_ERROR (0x201). §4.3.1 says the new capacity "MUST be lower than or equal to the limit" the decoder advertised, and that a decoder "MUST treat a new dynamic table capacity value that exceeds this limit as a connection error of type QPACK_ENCODER_STREAM_ERROR". Unlike the other two dynamic-table tests, this one runs against every client: they all advertise a capacity of zero, and any capacity at all exceeds a limit of zero.
- 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 quinn at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["h-qpack-encoder-overflow"]'