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]>]

@mikkelfj Yes, I did edit my comment in order to clarify what I meant, while you tried to confirm what we have now. Thank you for the clarification and sorry for the confusion.

> Hence, if it treats this as a critical error, streams can never be reset. Consequently, either streams should never be reset, or a reset without a type should not be treated as critical. I.e. a stream only exists for real once a type is positively known.

Yes. To be precise, calling the symptom a critical error would mean that the sender cannot reset a stream until it knows that the peer has received the first octet. But it is often hard for the application to "know" that the peer has received the first octet. For example, the sender will in practice never know that the first octet of the control stream has been received by the peer if the values sent in the SETTINGS frame were: NUM_PLACEHOLDERS=0, QPACK_MAX_TABLE_CAPACITY=0.

OTOH, the downside of _not_ calling that a critical error means that the connection state might not advance at all, if the server creates a control stream and then resets it before the first byte is delivered to the client. In such case, a client that waits for SETTINGS frame before sending any request will stall forever. However, we might argue that such stall would also happen when the packet that carries the control stream gets always dropped on the network (for some reason), and that a sender resetting the control stream is as unlikely as that.

In the end, now I think I might prefer the second option (i.e. ignore).

-- 
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-453785366