The specification doesn't mention what to do when you receive a RESET_STREAM or STREAM_DATA_BLOCKED frame on a bidirectional stream that you are responsible for creating, but you haven't created it yet.

We should kill the connection if this happens. Otherwise, we are acknowledging frames that make changes to the state of streams. We need to stop ignoring those frames. However, the frame could be a late-arriving frame for a stream that has been discarded, so a little care is needed to distinguish between streams that haven't been created yet from streams that have been closed already.

It also looks like we ignore STREAM frames in the same way, despite the spec being clear on that point. That's at least as bad as ignoring RESET_STREAM.

We might also ignore these frames when they are sent in the wrong direction for unidirectional streams. That would be bad too.

As the specification is not clear about what error code to use, but STREAM_STATE_ERROR seems most appropriate.