Subject: draft-ruellan-http-accept-push-policy-02 comments

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Jul 2016 15:14:46 +1000

I think that this is a promising avenue of exploration for server
push.  Clients clearly don't have enough ways to influence how the
server pushes content.

I'm almost tempted to suggest that it be made experimental rather than
proposed standard.  We yet really understand how push is going to be
deployed enough to settle on a sensible set of policies.  The set of
policies in the document seem reasonable, but we won't know until they
are deployed in a range of places.

I am also unconvinced by the use of two header fields.  The
Accept-Push-Policy header field is the only one that seems to have a
real use.  Knowing what the server understands is of relatively little
use.  More so given the nebulous nature of what is pushed when you
consider cache-digest and other improvements.

>From what I can see, the most direct response to seeing that a value
isn't supported is that a client would omit the header (or values from
it) on subsequent requests.  But there is no real harm in repetition,
especially when you would probably save more bytes by leaving the
header unchanged and relying on header compression.

I think that Accept-Push-Policy needs to have a different name.  Right
now, it implies content negotiation, but it's a bit of a stretch for
me to imagine using it in a Vary header field.  If you remove the
server's use of Push-Policy, then that's a better name for the request
header field.

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 13 Jul 2016 08:41:36 +0200

> Am 13.07.2016 um 07:14 schrieb Martin Thomson <[email-masked]>:
> 

+1

I implemented this draft in httpd, although I do not know of a client using it. I agree with Martin about the header rename/removal. Furthermore, the value of "fast-load" seems not very helpful while "none", "default" and "head" are very clear and lightweight to implement on a server. I'd be especially interested to learn if clients see use cases for "head" or have any plans of using this.

-Stefan

---

From: RUELLAN Herve <[email-masked]>
Date: Wed, 13 Jul 2016 20:07:42 +0000

Currently the draft is more oriented in providing negotiation between the client and the server regarding what is pushed. Another option is to only keep the client part, going more into some kind of client hint.

It's true that going for the hint makes it easier to interact with other push-related experiments such as cache-digest or push-assets. I however think that its also possible, even if more complex to integrate cache-digest or push-assets with some push negotiation.

Hervé
________________________________________
From: Martin Thomson <[email-masked]>
Sent: Wednesday, July 13, 2016 07:14
To: HTTP Working Group
Subject: draft-ruellan-http-accept-push-policy-02 comments

---

From: RUELLAN Herve <[email-masked]>
Date: Wed, 13 Jul 2016 20:12:59 +0000

It's nice to hear that you've implemented it.

The fast-load value comes from a DASH use-case where it allows the client to ask the server to push the video initialization data while responding to a request for a MPD: this allows starting the video playback faster.
This could also be useful for client on slow networks to ask the server to push the required assets for a first display of a web page. But possibly it is too generic and could be more useful in a more specialized version.

Hervé
________________________________________
From: Stefan Eissing <[email-masked]>
Sent: Wednesday, July 13, 2016 08:41
To: Martin Thomson
Cc: HTTP Working Group
Subject: Re: draft-ruellan-http-accept-push-policy-02 comments

+1

-Stefan