- 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>
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 19:29:45 UTC