Re: Re[2]: HTTP2 Expression of Interest : Squid

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