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

[MikkelFJ <[e-mail]>]

(It's now RESET_STREAM)

You can close normally (FIN), or with RESET_STREAM. In both cases there is a final size. The difference is that RESET_STREAM does not require unsent or lost data to be (re)transmitted. (I'm sure you are aware of all this).

If you get a RESET_STREAM and you do not have the stream type, there is no point in waiting for it. If you get a FIN without a type and a final size >= 1 but have not received the first byte, you can choose to wait for it. You probably should - but an implementation could make a mistake here assuming an error if an internal struct says type = type_missing. I take it you issue is intended for RESET only, but you were not clear on that.

Now, further analysis:
Assume you send a non critical stream with a type, and some other data. Then decide to RESET_STREAM in a later packet. This later packet overtakes the previous packet holding the type. Since the receiver cannot assume that the type was ever sent or will ever be received, it must act on what it knows. 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.

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