API for awaiting for stream reset on the reader about quinn

[Ralith]

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

[Ralith]

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

[MOZGIII]

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.

[Ralith]

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.

[MOZGIII]

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.