Re: Design Issue: PUSH_PROMISE and Stream Priority

On 25 April 2013 17:03, James M Snell <jasnell@gmail.com> wrote:
> 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.

Having the server tell you priority is fairly pointless.  The client
would need something.  Apparently, the new frame was considered better
than having an otherwise empty HEADERS+PRIORITY.

> 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.

Received on Friday, 26 April 2013 00:17:31 UTC