Abort after close

[martinthomson]

In #137, @ricea points out that there is a capability of QUIC that streams can't natively support. That is, it is possible to abort the send side of a stream after closing it. This is useful in cases where the contents of the stream are time-sensitive, such that retransmitting lost packets isn't worthwhile. This is one of the ways in which QUIC can emulate some of the "partial reliability" functions of SCTP/WebRTC data channels.

However, if the WHATWG streams API can't support this, that means supporting an abortWriting function that operates very much like writer.abort() with this one extra quirk. That is horrible. My preference would be to have WHATWG recognize that close is non-atomic and that aborting a closed stream is legitimate, but if that doesn't work out, then I would argue for not retaining the capability.

[ricea]

The current semantics of WHATWG streams have been shipping for a long time and we can't change them without breaking existing websites. WebTransport is the only use case I've encountered where abort after close is meaningful.

In simple cases you can achieve similar functionality by waiting for the final write() on the stream to complete and then calling abort(), but if someone absolutely needs to send a STREAM_FINAL before the RESET_STREAM then abortWriting() would be the only way to accomplish that.

As a result, I have a mild preference for retaining abortWriting().

[vasilvv]

For reference, when we were originally designing the API, we wanted to include a feature that allows you to set a TTL on streams (that is to say, a time after which the stream is automatically reset) as we envisioned that this would be commonly used in livestreaming/real-time cases. We decided against that, because doing this is currently as easy as:

setTimeout(() => { stream.abortWriting(); }, 1000 /* TTL in ms */);

[jan-ivar]

As a result, I have a mild preference for retaining abortWriting().

@ricea the WG was wondering what the reason for the mild preference is? Is it so that JS doesn't have to hold a reference to the writer?

[ricea]

@ricea the WG was wondering what the reason for the mild preference is? Is it so that JS doesn't have to hold a reference to the writer?

No, it's purely so that you can reset a closed stream. It is my understanding that this is necessary to implement unreliable streams without needing to add an in-band end marker at the application layer. I am assuming this is useful for sending small unreliable messages without needing to worry about the datagram size limit.

[wilaw]

Moving discussion to #260