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.

Received on Wednesday, 13 July 2016 05:15:16 UTC