Re: Priority inside PUSH_PROMISE frames

If server wants to push resouces in whatever sequence, it just do so and
telling priority to client is not necessary. The priority scheme is
optional and no guarantee to sequential processing. It means that client
cannot know server capability from that.

Best regatds,
Tatsuhiro Tsujikawa
 2014/06/13 4:34 "RUELLAN Herve" <Herve.Ruellan@crf.canon.fr>:

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

Received on Thursday, 12 June 2014 23:30:28 UTC