W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

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

From: Mike Belshe <mike@belshe.com>
Date: Mon, 30 Jul 2012 21:39:08 -0700
Message-ID: <CABaLYCshbR6OZPSaDe_GQ=fSRxM3soBrP+1MZsHv4XjH7zQ=Hg@mail.gmail.com>
To: Martin Nilsson <nilsson@opera.com>
Cc: ietf-http-wg@w3.org
On Sun, Jul 29, 2012 at 4:58 PM, Martin Nilsson <nilsson@opera.com> wrote:

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

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

mike


>
>
> /Martin Nilsson
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>
>
Received on Tuesday, 31 July 2012 04:39:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 31 July 2012 04:39:43 GMT