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

[RUELLAN Herve <[e-mail]>]

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 <[e-mail]>
Sent: Wednesday, July 13, 2016 07:14
To: HTTP Working Group
Subject: draft-ruellan-http-accept-push-policy-02 comments

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.