Re: Design Issue: PUSH_PROMISE and Stream Priority

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

Ok, there are a couple of issues that have been discussed in this
thread.. let me see if I can summarize the priority issue: The spec
currently states that all Streams can have a priority, but provides no
way for the Server to specify the priority of PUSH_PROMISE streams.
For this there are several possible solutions:

    A. We can simply say PUSH_PROMISE streams have no priority.
    B. We can say that PUSH_PROMISE streams inherit the priority of
their parent, client-initiated stream
    C. We can allow the server to use HEADERS+PRIORITY or a new
Reprioritization Frame to establish the priority of a pushed stream.

For Options B and C, there is an open question about whether and how
an http client would even make use of stream priority.

My recommendation at this point is to go with option A. If, at some
point down the road, someone wants to start experimenting with
prioritized push streams, then more power to them. For now, I just
don't see the justification for it.

- James


On Fri, Apr 26, 2013 at 3:43 AM, RUELLAN Herve
<[e-mail]> wrote:
>
>
>> -----Original Message-----
>> From: Martin Thomson [mailto:[e-mail]]
>> Sent: vendredi 26 avril 2013 02:17
>> To: James M Snell
>> Cc: [e-mail]
>> Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
>>
> [snip]
>>
>> > 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)
>>
>> I'm going to say yes and then make your day even worse by pointing out that
>> RST_STREAM(CANCEL) on stream #1 is expected to terminate all related
>> push streams, even if stream #1 is long gone.  (I'm assuming that one didn't
>> sink in when you read it.)  At least with priority you can copy that state over
>> when you copy over request headers (unless you want reprioritization of the
>> "parent" to also reprioritize pushes, which seems mega-crazy to me).  The
>> push cancellation thing is messy.
>
> I'm seeing the problem in a slightly different way: in the current usage of SPDY, the client initiates the stream #1 by sending the HEADERS+PRIORITY frame with the FINAL flag set to half close it. Therefore, the client is unable to send a RST_STREAM on stream #1 to terminate the related push streams.
> To take into account server push, the client will want to keep the stream #1 fully open until at least it is half closed by the server. This means that in HTTP/2.0, stream #1 will stay alive much longer.
>
> Hervé.