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

Re: Priority inside PUSH_PROMISE frames

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 12 Jun 2014 17:07:54 -0700
Message-ID: <CAP+FsNeMqXshxGQDM_1gry-t9Bc7_nZxsaE899u7xOSt0gNT-g@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, HTTP Working Group ‎[ietf-http-wg@w3.org]‎ <ietf-http-wg@w3.org>
The idea was that the client need not re-prioritize if the server sets a
priority that it does like, and does re-prioritize if the server sets a
priority that it doesn't like.

How otherwise would the client know how the server was prioritizing it?

-=R


On Thu, Jun 12, 2014 at 4:30 PM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
wrote:

> 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 Friday, 13 June 2014 00:08:22 UTC

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