What's the difference between waiting for a reset and reading? Can you link the spec for the WebTransport API you're referring to?

Based on this: https://w3c.github.io/webtransport/

There is a WebTransport object. It can create streams, which are represented via

• WebTransportSendStream that extends WritableStream, and
• WebTransportReceiveStream that extends ReadableStream

There are no relevant methods in the subclasses, so we can focus on the base classes: WritableStream and ReadableStream.

ReadableStream allows getting a ReadableStreamReader, which is either a ReadableStreamDefaultReader or ReadableStreamBYOBReader - but both include ReadableStreamGenericReader .

The ReadableStreamGenericReader has a readonly attribute Promise<undefined> closed; - which in turns allows awaiting for the stream to close without actually reading it (as I understand it). Upon getting an RESET, the promise returned by closed would reject with a WebTransportError, which would contain the error code.

This is what I find missing in the quinn API.

Maybe I am misinterpreting my findings in the Web API, but then I need some tips on the topic of implementing this - but it seems like the Web API for WebTransport does have an API that can't be (simply) built on top of quinn.

I find the web spec difficult to read (lots of circular definitions that don't actually specify anything useful), but the general idea you describe seems to make sense, and I don't oppose having such an API, even though its use may be niche. Our existing SendStream::stopped is similar.

Yep, SendStream::stopped covers it for the send streams, it is only the reading streams that don't have a matching counter part for that.

web spec difficult

Yeah, it is. I am not specializing on dealing with w3c stuff, had to dig through this just for the cross platform WebTransport, and it was veery tricky to spot this API even existing.

Let me know if #1873 suits your requirements. Particular points of interest are &mut self and the non-idempotent behavior.