Re: Priority inside PUSH_PROMISE frames

This isn't necessary.

The HEADERS frame has an optional priority field to avoid a race condition.
PRIORITY frames cannot be sent on the stream that HEADERS is being sent on
because the HEADERS frame creates the stream. If the request contains no
body, the server may process and send the response before receiving any
subsequent PRIORITY frames on that stream.

For PUSH_PROMISE frames, the stream is opened with the PUSH_PROMISE and
processing cannot complete until a HEADERS frame containing the response
metadata is received. Servers that wish to set a non-default priority can
do so by sending a PRIORITY frame between the PUSH_PROMISE and the HEADERS.
There is no race condition.


On Thu, Jun 12, 2014 at 12:29 PM, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
wrote:

> All,
>
> Currently, when a stream is created by a PUSH_PROMISE, it has a default
> priority. It depends on its associated stream and its weight is 16.  In
> many
> case, this default priority has no impact from the client point of view and
> doesn't need to be changed.
>
> Recent work on DASH has shown interest in using HTTP/2 push for
> transmitting
> several video segments upon receiving one client request. These video
> segments
> are consecutive parts of the video and should be received sequentially by
> the
> client to allow for a streaming playback of the video. A smart server will
> push these video segments sequentially, notwithstanding the default
> priorities.
> However, the client has no way to know whether the server it is connecting
> to is smart or not. To share this knowledge, the PUSH_PROMISE frame should
> be modified
> to optionally include priority information (as is already the case for the
> HEADER frame).  The client could rely on this priority information to
> discover
> the server behaviour, and to decide whether or not sending PRIORITY frames
> to
> correct it.
>
> Other scenarios could take advantage of including priority information
> inside
> PUSH_PROMISE frames. For example, a group of images can be pushed in
> parallel
> (the default behaviour), which is useful for starting quickly a progressive
> rendering of all the images belonging to a web page. This group of images
> can
> also be pushed sequentially (with non-default priorities), which is useful
> to
> show quickly the first images in a long list of images. In this latter
> case,
> the PUSH_PROMISE frames would contain priority information, indicating to
> the
> client the intended behaviour of the server.
>
> Hervé
>