Subject: Re: Recursive HTTP/2 Push

From: Patrick McManus <[email-masked]>
Date: Mon, 8 Feb 2016 14:37:16 -0500

On Sun, Feb 7, 2016 at 1:12 PM, Simone Bordet <[email-masked]>
wrote:

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

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. I think we need a bullpen for issues like this for
the next revision. You could certainly overload it with an extension if you
think it is important enough.

The spec is clear the server must not send. In general that doesn't create
a requirement on the peer to throw a protocol_error when receiving.

I'll consider changing to refuse this.

---

From: Glen Knowles <[email-masked]>
Date: Tue, 9 Feb 2016 02:08:03 -0800

> a requirement on the peer to throw a protocol_error when receiving.

In this case the spec does have an explicit requirement (section 5.1) that
a client in the "reserved (remote)" state throw a p_e.

"Receiving any type of frame other than HEADERS, RS_STREAM, or PRIORITY on
a stream in this state MUST be treated as a connection error (Section
5.4.1) of type PROTOCOL_ERROR."

---

From: Simone Bordet <[email-masked]>
Date: Tue, 9 Feb 2016 11:14:46 +0100

Hi,

thanks for the feedback so far !

On Mon, Feb 8, 2016 at 8:37 PM, Patrick McManus <[email-masked]> wrote:
> 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

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 9 Feb 2016 11:29:43 +0100 (CET)

On Tue, 9 Feb 2016, Simone Bordet wrote:

> I think we'll go for B) in Jetty, unless there are objections stating that 
> this is not intended behavior.

Push doesn't imply anything about the resources having to be in a resource 
tree or anything like that. It is just objects the server can offer to the 
client before the client asks for it themselves.

If clients are likely to want both these files after having asked for 
"recursive.html", then I'd say (B) makes the most sense and (A) seems a bit 
limited. But ultimately, that's up to the server to decide.

-- 

  / daniel.haxx.se

---

From: Alcides Viamontes E <[email-masked]>
Date: Tue, 9 Feb 2016 11:38:20 +0100

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

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 9 Feb 2016 12:19:07 +0000

On Tue, Feb 9, Alcides Viamontes E wrote:

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

From what I have read of the servers that support server push and configurable prioritisation, the priority of connection usage is often based using the resource type. For example see mod_http2's H2PushPriority Directive[1] or h2O[2].

I would anticipate that a client would be well within its rights to reprioritise a pushed stream, especially if the server is not browser sniffing and just using a default (inefficient) priority. Examples would be bumping resources on the critical path, or vice-versa. However, I'm not sure how responsive the server would be to this, having already allocated its resources upfront.

[1] https://httpd.apache.org/docs/trunk/mod/mod_http2.html#h2pushpriority
[2] https://h2o.examp1e.net/configure/http2_directives.html

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------