The run did not exercise this test: the client did not wait for the credit. This port grants no bidirectional stream until 700ms in, and declining to wait that long is not a violation of anything — it simply leaves the limit untested.
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
- curl — ngtcp2 + nghttp3, ngtcp2/1.11.0
- Test
- No stream credit at first, then MAX_STREAMS mid-connection —
q-max-streams-credit - Clause
- RFC 9000 §4.6 (MUST NOT)
- Class
- discretionary — The RFC permits either behaviour; the report says which was chosen.
- Required behaviour
- Wait for the credit, then open the request. This port grants no bidirectional streams in its transport parameters and issues MAX_STREAMS a moment later. §4.6 is unambiguous that a client may not jump the gun — "Endpoints MUST NOT exceed the limit set by their peer" — and announcing the wait with STREAMS_BLOCKED is a SHOULD, so a client that waits quietly is equally conformant. Giving up rather than waiting is not scored as a failure: nothing obliges a one-shot client to sit on a connection it cannot use yet, and the report says which it did.
- 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 curl at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-max-streams-credit"]'