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

Re: HTTP2 Expression of Interest : Squid

From: Roberto Peon <grmocg@gmail.com>
Date: Sun, 15 Jul 2012 23:36:57 -0700
Message-ID: <CAP+FsNcV-QrveziO3y5Jp1=HoZ9RjrCqWJyVYbzVFNLaOM600A@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>, tom <zs68j2ee@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, Mike Belshe <mike@belshe.com>
That would be pretty pointless-- at that point the browser should just send
the data. The model in SPDY is push and let cancel.
Server push is just better inlining.

Let's discuss this in  a separate thread...

On Jul 15, 2012 11:34 PM, "James M Snell" <jasnell@gmail.com> wrote:

> On Sun, Jul 15, 2012 at 11:06 PM, Mike Belshe <mike@belshe.com> wrote:
>> [snip]
>>> OK but some data may end up in the client's cache without having been
>>> requested by him. I don't think it has a high technical impact, but it
>>> may rather be a legal one in some cases. In fact it's a delicate
>>> question.
>> Let's not pretend that browsers behave differently than they do.  With
>> HTTP today,  browsers download subresources - whether you use IE or Chrome
>> or Opera or Safari.  All server push does is allow the server to optionally
>> send the secondary resources without waiting for a second request from the
>> client.  Servers that think this is illegal don't have to do it.  Clients
>> that don't want it (these don't exist!) can cancel them.  Sending resources
>> the browser won't use are no-ops and won't impact anything (except make
>> your web page load slower, so don't do it).
> One possibility to throw in here would be a simple requirement that the
> server has to ask the client before it pushes... a reverse 100-Continue if
> you will... require the server to tell the client what content it is trying
> to push and give the client the opportunity to say No.... intervening
> proxies, such as a corporate firewall, would be capable of answering on the
> users behalf.
> - James
Received on Monday, 16 July 2012 06:37:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC