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
