Re: Design Issue: PUSH_PROMISE and Stream Priority

[James M Snell <[e-mail]>]

A new frame is not required. We already have HEADERS+PRIORITY and
HEADERS. The PUSH_PROMISE definition states that the promise will be
followed up by a HEADERS frame, then data frames. If we allow it to be
HEADERS or HEADERS+PRIORITY then we meet the requirement.

That said, is there even a need for server pushed streams to specify a
priority? Do we want to allow servers to dictate priority to the
client? I can see a number of ways in which a naughty server could
abuse that privilege.

Another question: do pushed streams inherit the same priority as their
associated "parent" streams? That is, client initiates a stream #1 to
the server with priority 5, server responds on that stream with two
PUSH_PROMISES for server-initiated streams #2 and #4... do streams #2
and #4 inherit the same priority as stream #1. (Please say no, Please
say no)

- James

On Thu, Apr 25, 2013 at 4:48 PM, Martin Thomson
<[e-mail]> wrote:
> Good point.  The hope was that a reprioritization frame would be
> proposed (Will, Roberto, we're all still waiting).
>
> If that's enough, then adding a default (maybe 2^30) would fix this.
>
> On 25 April 2013 11:03, James M Snell <[e-mail]> wrote:
>> https://github.com/http2/http2-spec/issues/75
>>
>> The current draft (-02) says, "The endpoint establishing a new stream
>> can assign a priority for the stream."
>>
>> However, the spec does not define how a stream established using
>> PUSH_PROMISE can assign the priority for a stream, nor does the spec
>> discuss whether the notion of stream priority applies to push streams.
>>
>> The spec currently states that PUSH_PROMISE is followed later on by a
>> HEADERS frame.
>>
>> If priority applies to push streams, then we need to add that priority
>> can be assigned by allowing the use of a HEADERS+PRIORITY frame.
>> Otherwise, we need to clarify the spec text to say that push streams
>> have no priority.
>>