Beware: Idle states

[olix0r]

I noticed the following:

The first use of a new stream identifier implicitly closes all streams in the "idle" state that might have been initiated by that peer with a lower-valued stream identifier. For example, if a client sends a HEADERS frame on stream 7 without ever sending a frame on stream 5, then stream 5 transitions to the "closed" state when the first frame for stream 7 is sent or received.

We need to be careful that we don't initialize streams in the idle state such that they may be moved into reserved/open out of order. We should probably only ever initialize streams directly to a Reserved or Open (or HalfOpenRemote) state.

[carllerche]

This issue can be closed once there is a test ensuring this behavior is followed. I am pretty sure this behavior is already implemented.

[olix0r]

To expand on my comment above: we need the client's send side (i.e. prioritize.rs) to ensure that headers are sent in stream-id-order.

[carllerche]

In fact, h2 probably should have an assert that stream id of initial headers frame is greater than all previously sent stream ids

[hawkw]

@carllerche for the assertion you mentioned, is it reasonable to use send.next_stream_id to track previously sent stream ids?

[carllerche]

@hawkw I think so...

[hawkw]

@carllerche okay, adding the assertion breaks a number of tests - it looks like it's mostly tests where a stream ID overflows, but since the assertion has to handle stream ID overflows, the panic happens in a different place. Is it reasonable for me to modify those tests?

[carllerche]

@hawkw Are you good here? I believe you followed up w/ @seanmonstar?

[hawkw]

@carllerche yeah, I talked it over with Sean and I've now opened a PR #160 to get this merged.