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

On Sun, Jul 29, 2012 at 4:58 PM, Martin Nilsson <> wrote:

> On Mon, 16 Jul 2012 16:19:36 +0200, Mike Belshe <> 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).

I agree this could be useful :-)  But this isn't what SPDY's push does
right now, and that is what I was commenting on.

> 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.

Fair enough, you've presented an argument for who doesn't want push.  But
this is a tiny tiny fraction of people.  I would not sacrifice billions of
internet users that do want images and JS for the needs of a very small
few.  The very small few won't be broken by using push - they'll still get
their pages just fine and can RST the streams they don't want.

I think we should build "fast by default".


> /Martin Nilsson
> --
> Using Opera's revolutionary email client:

Received on Tuesday, 31 July 2012 04:39:37 UTC