RE: Recursive HTTP/2 Push

Part of the problem is also lifetime.  If I may be pushed streams that chain up to a navigation long after I've finished the navigation, the server gets an almost limitless ability to push resources at me so long as there's one push still in flight that I haven't RST.  Racing RSTs and PUSH_PROMISEs also become even more tricky.

By restricting pushes to streams the client initiated, the client has a well-defined point at which it knows all the streams the server has proposed to push, and can RST any that it doesn't want.

-----Original Message-----
From: Simone Bordet [mailto:simone.bordet@gmail.com] 
Sent: Sunday, February 7, 2016 10:12 AM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Recursive HTTP/2 Push

Hi,

On Sun, Feb 7, 2016 at 4:06 PM, Daniel Stenberg <daniel@haxx.se> wrote:
> On Sun, 7 Feb 2016, Simone Bordet wrote:
>> Can someone clarify if HTTP/2 really intended to forbid recursive 
>> pushes and why ?
>
> I can't remember the exact reasoning, but it seems clear to me that we
> want(ed) servers only to push resources on streams the client has asked for.
> "Pushed responses are always associated with an explicit request from 
> the client" (from 8.2.1)
>
> But is there a particular reason to insist on sending the push promise 
> on stream_id 2 in the second push and not just make it on stream_id 3?

The reason is to respect the shape of the resource tree: recursive.png depends on recursive.css.
If the client directly asks for recursive.css, then it should get recursive.png pushed.

Sure we can make the pushed resources just one level deep, or flatten the resource tree like you suggest, but the recursive solution looked more "natural".

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

Received on Monday, 8 February 2016 18:57:59 UTC