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

2016-09-20 10:56 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>:
> On 20 September 2016 at 11:34, Kazuho Oku <kazuhooku@gmail.com> 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
>> MAX_CONCURRENT_STREAMS.
>
> That's not going to work, since the stream limit is unidirectional,
> whereas priority applies to both.

Thank you for the correction. I agree.

If a server is going to push streams, the number of prioritization
states that needs to be tracked becomes the maximum number of
concurrent streams opened by the client _plus_ the maximum opened by
the server needs to be tracked.

Anyways, tracking such large amount of states is inefficient, and I
think we should better fix the issue together with the race pointed
out by Tom.

-- 
Kazuho Oku

Received on Tuesday, 20 September 2016 02:59:52 UTC