PQ Crypta Logo

quiche — No stream credit at first, then MAX_STREAMS mid-connection

The client did what the clause requires.

PQ CRYPTA PLATFORM

🏠 Main

🧪 Interactive Apps

📰 News

🛡️ PQ Crypta Proxy

👤 Account

⟨ QUANTUM ERROR PORTAL ⟩

Navigate the Error Dimensions

Jump to an anomaly59

Every one of these is a page: what the server emits, the clause it is judged against, and how each client answered. The full list carries the verdict tallies too.

Pass

Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant.

The client did what the clause requires.

What was measured

Client
quiche — Cloudflare quiche, 0.30.0
Test
No stream credit at first, then MAX_STREAMS mid-connectionq-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 quiche at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-max-streams-credit"]'