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.
The client does not do this, and said so itself — by what it advertised, or by refusing outright. A definite answer about the client, not a failure and not a gap.
What was measured
- Client
- msquic — .NET HttpClient + msquic, 2.7.0 (7e6525d)
- Test
- Field section that blocks until the encoder stream catches up —
h-qpack-blocked-stream - Clause
- RFC 9204 §2.1.2, §2.2.1 (MUST)
- Class
- interoperability — Correctly decoded something valid but demanding.
- Required behaviour
- Hold the field section, apply the insertions when they arrive on the encoder stream, and complete the request. §2.2.1 makes a section whose Required Insert Count exceeds the decoder's Insert Count a blocked stream — something to be waited on, not an error. Only run when the client advertised both a table capacity and at least one blocked stream; §2.1.2 forbids the encoder from blocking more streams than the decoder promised to support, so a client that permits none cannot be tested on this.
- Measured
- 2026-10-27
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-blocked-stream"]'