Re: [quicwg/base-drafts] What should the receiver do when the peer closes a unidirectional stream before providing the stream type? (#2331)

[Kazuho Oku <[e-mail]>]

@LPardue I agree that nobody would try to do that in practice (although in a very rare case that might happen due to some other reason; e.g. low memory). Anyways, there are million ways to block the protocol from proceeding, and I do not think it's necessary to detect this particular condition.

In contrast, allowing the sender of an extended unidirectional stream to reset the stream might have practical benefit. For example, a sender can speculatively create a unidirectional stream then reset it when the received SETTINGS indicate that the peer does not support the necessary feature. Using reset makes sense especially when the sender has sent certain amount of bytes on the stream; avoiding retransmission (if possible) is beneficial.

That's why I now think the second option (ignore early close) is preferable.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2331#issuecomment-453789586