Stream operations after RESET has been sent

[vasilvv]

• Is it valid to send WT_STREAM for streams that already had a WT_RESET_STREAM sent?
• Is it valid to send WT_RESET_STREAM for a stream that already had a WT_RESET_STREAM sent?
• Is it valid to send WT_STOP_SENDING for a stream that already had a WT_STOP_SENDING sent?
• Is it valid to send WT_MAX_STREAM_DATA for a stream that already had a WT_STOP_SENDING sent?

In QUIC, I believe we answered "yes" to all of the above since the protocol is inherently unordered. As far as I can tell, this does not apply to WT over HTTP/2, since it's strictly ordered, at least for an individual peer.

[vasilvv]

Oh, forgot to add: we should decide the same for FIN, too.

[martinthomson]

It should be possible to do this, if you consider HTTP/2 uses in isolation, but are there cases where there could be a hop that is HTTP/3 and it would be easier to intermediate if the ordering could be loose?

[ekinnear]

Seems like we have two options:

• Most of these operations are inherently observable, for example if you go to forward a WT_STREAM frame and you think that the stream is already closed because you already had a WT_RESET_STREAM come through, you could see an error and drop that WT_STREAM frame.

• Allow being a direct passthrough, so HTTP/2 is just preserving the inherent reordering that happened on the HTTP/3 side.

It's a little bit annoying that we'd need someone running pure HTTP/2 to accept obviously wrong things, just in case somewhere someone had HTTP/3 in existence.

However, it also seems nice to not make the intermediary keep track of the state of streams if possible -- but you have to have a mapping already because the stream IDs don't match across HTTP/2 and HTTP/3.

[ekinnear]

Discussed in editor's meeting:

• Prohibit and error because you already have to write code that handles this case where you cannot find the mapping in your table. Preference towards it being cleaner.