Add support for RST_STREAM packets #10

Merged
merged 3 commits into from Jan 1, 2012

Conversation

Projects
None yet
2 participants
Collaborator

jonasschneider commented Dec 30, 2011

No description provided.

Owner

igrigorik commented Dec 30, 2011

Can we generalize this to on_close instead? There should be multiple ways to reach this state..

Collaborator

jonasschneider commented Dec 30, 2011

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.

Collaborator

jonasschneider commented Dec 30, 2011

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.

Owner

igrigorik commented Jan 1, 2012

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?

Collaborator

jonasschneider commented Jan 1, 2012

Sounds good!

Collaborator

jonasschneider commented Jan 1, 2012

Rebased.

igrigorik merged commit 716c4f3 into igrigorik:master Jan 1, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment