I agree it's not clearly stated in the RCF that this is an error. But instead of explicitly listing which frames are not allowed, should we have a generic statement along the lines of "receiving any stream-related frame for a stream that would originate locally, but has not yet been created is considered an error"? Maybe instead of "created" something more like "indicated to the peer"? This would cover any new stream related frames created by extensions, so they don't have to restate this.
While thinking of this and looking at our implementation, generally our stack is fine, except for a possible race condition when we have a stream queued up ready to send, but happen to process a packet for it first. In the reset case, instead of sending out the stream frame, we'll ack the reset and clean up our local (receive) state. Another interesting variant of this would be if the peer sent STOP_SENDING on a local unidirectional stream before we got a chance to send out anything for it. In this case, we'd clean up all our state and ACK the packet, send a RESET_STREAM and be done with it. In all these cases, while the peer shouldn't have done it, I believe the end result is that we're still in sync. I could add another state to each stream indicating "we actually sent something" instead of just leveraging our "active stream" list logic we have today, but I'd prefer not. I don't practically expect this to happen, and even if it does, it shouldn't be fatal. -----Original Message----- From: QUIC <[email protected]> On Behalf Of Martin Thomson Sent: Wednesday, August 9, 2023 9:18 PM To: Marten Seemann <[email protected]> Cc: [email protected] Subject: Re: RESET_STREAM on a non-existent bidirectional stream On Thu, Aug 10, 2023, at 11:12, Marten Seemann wrote: > I think RFC 9000 covers this case, albeit in a less than ideal way. > > Section 20.1 defines the STREAM_STATE_ERROR: "An endpoint received a > frame for a stream that was not in a state that permitted that frame" Yeah, I don't think that's quite good enough. It's pretty good support for using STREAM_STATE_ERROR, but it's not really support for the position that an endpoint MUST terminate the connection in either case.
