Re: Recursive HTTP/2 Push

As far as I understand B) is perfectly legal. A) is a bit
counter-productive, since it only allows for alternating generations of
pushed resources. We do B at ShimmerCat.  Notice that for PUSH to be
effective the PUSH promises should be delivered as early as possible.
However, a flattened resource tree will include resources that the browser
doesn't need until much later, so it is worth understanding which resources
are those and prioritize frames accordingly.

A related question  is how and if browsers do issue PRIORITY frames on
pushed streams? Is there anything on the RFC about that? I can not find
anything pro- or against....

On Tue, Feb 9, 2016 at 11:14 AM, Simone Bordet <simone.bordet@gmail.com>
wrote:

> Hi,
>
> thanks for the feedback so far !
>
> On Mon, Feb 8, 2016 at 8:37 PM, Patrick McManus <pmcmanus@mozilla.com>
> wrote:
> > I guess I would say that the spec is pretty clear when it says peer
> > initiated - it means to forbid this. OTOH I think you make a good
> argument
> > about the resource tree.
>
> If servers can only push on peer-initiated streams, there are two cases:
>
> A) the client requests for recursive.html, gets recursive.css pushed,
> but it always have to explicitly request recursive.png.
>
> B) the server flattens the resource tree, so that the client requests
> recursive.html, and gets recursive.css and recursive.png pushed.
>
> I think we'll go for B) in Jetty, unless there are objections stating
> that this is not intended behavior.
>
> Thanks !
>
> --
> Simone Bordet
> http://bordet.blogspot.com
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz
>
>