W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Priority inside PUSH_PROMISE frames

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Thu, 12 Jun 2014 19:29:15 +0000
To: HTTP Working Group ý[ietf-http-wg@w3.org]ý <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E532D66E0E@ADELE.crf.canon.fr>

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

Received on Thursday, 12 June 2014 19:29:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC