Stream ID issue for HTTP/2

[vjpai]

Some issues that we need to support related to the HTTP/2 stream ID

1. Check that the incoming stream ID follows the expected invariant of always increasing by 2 or more
2. Send a go away on a transport if the stream is reaching too close to the limit (2^32)
3. Write a test to confirm that the above 2 things actually happen

[vjpai]

More details on this issue, quoted from HTTP/2 draft 17 ( https://tools.ietf.org/html/draft-ietf-httpbis-http2-17 )

1. "Streams are identified with an unsigned 31-bit integer. Streams
   initiated by a client MUST use odd-numbered stream identifiers; those
   initiated by the server MUST use even-numbered stream identifiers. "
2. "HTTP/1.1 requests that are upgraded to HTTP/2 (see Section 3.2) are
   responded to with a stream identifier of one (0x1). After the
   upgrade completes, stream 0x1 is "half closed (local)" to the client.
   Therefore, stream 0x1 cannot be selected as a new stream identifier
   by a client that upgrades from HTTP/1.1."
3. "The identifier of a newly established stream MUST be numerically
   greater than all streams that the initiating endpoint has opened or
   reserved. "
4. "An endpoint that receives an unexpected stream identifier MUST respond with a
   connection error (Section 5.4.1) of type PROTOCOL_ERROR."
5. "A peer can limit the number of concurrently active streams using the
   SETTINGS_MAX_CONCURRENT_STREAMS parameter (see Section 6.5.2) within
   a SETTINGS frame. The maximum concurrent streams setting is specific
   to each endpoint and applies only to the peer that receives the
   setting. That is, clients specify the maximum number of concurrent
   streams the server can initiate, and servers specify the maximum
   number of concurrent streams the client can initiate."

[ctiller]

The issue is mostly fixed, but further test cases are necessary.

Moving to GA as this is when I expect most of this work will be done.

[ctiller]

Re-assigning to Carl: rich tests in this space should come from our HTTP/2 interop suite.

[ctiller]

There's definitely sufficient test coverage for C here. It'd be nice to get something into HTTP/2 interop at some point.

[dgquintas]

are we there yet?

[ctiller]

good question