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"
One could argue that this covers the case where RESET_STREAM or STREAM_DATA_BLOCKED is received on a bidirectional stream that you were supposed to open, since the stream was not in one of the states that permitted sending this frame. Section 3.1 explicitly says that receiving a RESET_STREAM frame only creates peer-initiated streams: "The receiving part of a stream initiated by a peer (types 1 and 3 for a client, or 0 and 2 for a server) is created when the first STREAM, STREAM_DATA_BLOCKED, or RESET_STREAM frame is received for that stream." On Wed, 9 Aug 2023 at 20:58, Martin Thomson <[email protected]> wrote: > Damien Neil on slack asked about what to do when you receive a > RESET_STREAM (or STREAM_DATA_BLOCKED) frame on a bidirectional stream that > you were supposed to open, when you haven't created that stream (yet). > > It turns out that we forbid endpoints from sending STREAM frames in this > case: https://quicwg.org/base-drafts/rfc9000.html#section-19.8-3 but we > don't say anything about RESET_STREAM or STREAM_DATA_BLOCKED. We couldn't > find any text for these, which seems like a serious oversight. > > There is a clear case for killing the connection if this happens. Aside > from the fact that this is what we decided for STREAM, it's pretty > obviously bad. An endpoint might not be willing to commit to tracking any > state for RESET_STREAM, but acknowledges that frame. That might imply to > its peer that it has remembered that the return path for that stream is > dead. If the stream is ever created, the return path is in an > indeterminate state. Though STREAM_DATA_BLOCKED is arguably safe to ignore, > I see no value in allowing that sort of thing to slide. > > We have not defined error handling for this, but STREAM_STATE_ERROR seems > like a sensible response. > > I suspect that some implementations already reject these. Ours didn't > (and we have a few other interesting holes, it would seem). > > I'm floating this here for visibility, but I think that this warrants an > erratum. It's a bit bigger than a typical erratum, but that's the best > process we have right now. > > Cheers, > Martin > >
