- From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
- Date: Wed, 13 Jul 2016 20:07:42 +0000
- To: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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 <martin.thomson@gmail.com> 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.
Received on Wednesday, 13 July 2016 20:08:18 UTC