Re: #642: Allowing PRIORITY on streams in any any state. [was: Concerns about HTTP/2 Priority]

On 2014/11/06 14:29, Martin Thomson wrote:
> On 5 November 2014 18:48, Shigeki Ohtsu <ohtsu@iij.ad.jp> wrote:
>> Can't we use just HEADERS with a priority flag and no header block as a
>> group anchor
>>   instead of using PRIORITY for an idle stream?
> I'm concerned that will result in problems for servers.   There will
> always be a header block, but it will just be empty.  If there are
> missing header fields, then the server will reject the "request".

Empty header block in HEADES with END_HEADER flags is not explicitly 
prohibited
in the current draft and permitted in the past when we have the 
reference set.

I agree that there may be a server that checks empty header set emission 
and
rejects such a request.

>> This might work since the reference sets has gone and a stream timeout is
>> not defined yet in the current spec.
>>
>> I'm worrying about the idle stream in the priority tree is out of
>> SETTINGS_MAX_CONCURRENT_STREAMS.
> There is already a need to maintain priority information that is
> independent of the concurrent stream limit and to have nodes in the
> tree that are not active.  See
> http://http2.github.io/http2-spec/#priority-gc  This just makes that a
> little bit more flexible.

This depends on the implementation design.

For me, maintaining closed streams in the tree is much easier as we can 
handle it
at the time  when the stream state is transited (half-closed->closed, 
reserved->closed).

PRIORITY for an idle stream leads no stream state transition and they 
can be increased
with no limits  and they are preserved in the tree until we trigger gc 
so I think this causes
  more complex than the case of HEADERS with priority and no header block.

Regards,

Received on Thursday, 6 November 2014 06:30:34 UTC