Re: HTTP/2: Race between PUSH_PROMISE and exclusive PRIORITY

On 20 September 2016 at 11:34, Kazuho Oku <> wrote:
> Therefore, a cautious server implementation would try to retain the
> prioritization states of most-recently-used streams up to
> MAX_CONCURRENT_STREAMS. By doing so, one can get rid of the risk to
> receive a PRIORITY stream relative to the state of a closed stream,
> since a client would never try to open more streams at once than

That's not going to work, since the stream limit is unidirectional,
whereas priority applies to both.  Keeping 2xMAX_CONCURRENT_STREAMS
would be closer to what you want (but again, not perfect).

Received on Tuesday, 20 September 2016 01:57:12 UTC