Decoded it and completed the request.
The client did what the clause requires.
Why the run landed here
lsquic rejects response trailers every time -- and its demo client occasionally exits before saying so.
Driven through the suite's own driver ten times on 2026-09-25, lsquic 4.9.4 closed the connection with H3_MESSAGE_ERROR (0x10e) on the trailing HEADERS every time, which is the failure this cell reports. In one scored run of four the server saw no close at all: lsquic's http_client calls exit(2) the moment a stream read fails (bin/http_client.c: "could not read"), and now and then the process ends before the library has sent the CONNECTION_CLOSE it was about to. From the server that looks like a client that finished and left, which a run cannot tell apart from success, so this cell can read pass in a run where the demo client won that race. The rejection is lsquic's behaviour; the silent exit is its demo client's.
Established separately from the run and recorded beside it, not in it:
the verdict above is still only what the server could see. Measured by
h3-conformance --filter h-trailers, 10 runs; lsquic src/bin/http_client.c,
2026-09-25.
What was measured
- Client
- lsquic — LiteSpeed lsquic + BoringSSL, 4.9.4 (2b30189)
- Test
- Trailing field section after the body —
h-trailers - Clause
- RFC 9114 §4.1 (MUST)
- Class
- interoperability — Correctly decoded something valid but demanding.
- Required behaviour
- Deliver the trailers to the application after the body completes.
- 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 lsquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["h-trailers"]'