Concurrent Streams Limits and Unidirectional Streams

[jasnell]

In the current draft (-02), we state that:

A. Any endpoint can initiate and half-close a fully unidirectional stream that does not require any action or acknowledgement from the receiving peer. Once half-closed, these remain in a constant half-closed state with the receiving peer having the option of sending frames for that stream at any time for the full duration of the session.

B. An endpoint MUST NOT exceed the maximum concurrent streams limit set by it's peer and that half-closed streams in any direction count towards this limit.

C. Unless I missed it somewhere, clients are not required to half-close PUSH_PROMISE streams.

The potential problem here is simple:

If a client sets a limit of 4 concurrent streams, and the server initiates 4 separate PUSH_PROMISE streams that the server half-closes but that are never half-closed by the client, the server not be able to initiate new push streams for the duration of the session.

[martinthomson]

On the list...

[jasnell]

See Thread: http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0380.html

[mnot]

DIscussed at SF Interim; pending proposal from Layering TF.

[martinthomson]

This should be addressed by 05df79d

Pending approval of the changes included in the layering branch, this should be ok.