- From: Martin Nilsson <nilsson@opera.com>
- Date: Mon, 30 Jul 2012 01:58:50 +0200
- To: ietf-http-wg@w3.org
On Mon, 16 Jul 2012 16:19:36 +0200, Mike Belshe <mike@belshe.com> wrote: > Making it a client decision kills the feature entirely. We > need to either support push or not support it. But seriously, who are > these clients which will reject the pushes? You can't push random data. > You can only push in-domain data. If the browser doesn't need it, you > only hurt yourself. Seriously, why would any browser block the push? > I'll disagree with you from two different directions... First of all I think it would be useful if a client could set up a subscription on a resource or a set of resources. I guess you could associate the resources with the subscription request, but the duration would be different than from a normal request (e.g. for the duration of the connection). This is obviously outside of the scope of HTTP semantics, but it would be nice if the infrastructure was in place on a binary level (e.g. current SPDY/3 can be twisted to support it). Secondly, if I disable javascript and images, override CSS and turn on on-demand-plugins there are very few relevant resources the server can push (frame documents and favicons). The issue is for the server to determine what types of resources are relevant for the client. If the purpose is to limit bandwidth (which is likely if e.g. images are turned off), rejecting the incoming pushed content is pointless, as most resources are less than 64K and thus fully on the wire already, with default SPDY initial window. Some sort of actually working Accept-header system could be one way to go. /Martin Nilsson -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Received on Sunday, 29 July 2012 23:59:21 UTC