No description provided.
Can we generalize this to on_close instead? There should be multiple ways to reach this state..
Sure! How about passing 0 as status_code on a normal finish?
This works per the spec, as 0 is not a valid status code for RST_STREAM.
I just realized: how should the parser know that the stream was closed normally? It does not know whether the client using the parser has already half-closed the stream.
Or should the callback be called on an incoming half-close, i.e. after on_message_complete?
This, on the other hand, would be inconsistent, since RST_STREAM implies a full close already.
Well, the parser as of today does not contain any knowledge of the underlying state of the connection - instead it's a simple loop that parses packets, which could be delivered in completely random order. As such, I don't think we should worry about the half-closed states.
On on_message_complete vs on_close vs on_stream_reset: except the RST packet, are there any other cases where we might need to trigger this? Perhaps keeping the reset callback is the best way.. on_reset, since stream is implicit?
add support for RST_STREAM
nevermind the ping.
rename callback to on_reset