xquic — GOAWAY sent mid-connection

Inconclusive

The run did not exercise this test: the connection failed during the handshake (detected an error with protocol compliance that was not covered by more specific error codes in STREAMS_BLOCKED_BIDI: illegal frame type in handshake), so the client never reached the anomaly.

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

xquic — Alibaba xquic + BoringSSL, 2060a44

Test

GOAWAY sent mid-connection — h-goaway

Clause

RFC 9114 §5.2 (SHOULD)

Class

resilience — Recovered rather than giving up.

Required behaviour

Stop opening requests, finish those in flight, and retry idempotent ones elsewhere. The GOAWAY is written once the client's request is running and names the stream after it, so §5.2 puts that request inside the range the server promises to process: finishing it is the behaviour under test. Sent before the request instead, the correct answer would be to close and reconnect, and the test would be measuring a race rather than recovery.

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 xquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["h-goaway"]'