- From: Patrick McManus <pmcmanus@mozilla.com>
- Date: Mon, 16 Jul 2012 09:50:09 -0400
- To: Roberto Peon <grmocg@gmail.com>
- Cc: James M Snell <jasnell@gmail.com>, 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>
On Sun, 2012-07-15 at 23:36 -0700, Roberto Peon wrote: > 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. > fwiw .. The middle ground is use of flow control to limit the amount of data that can be pushed.. that way small pushes that are rtt bound still get performance benefits and bigger pushes have a limited amount of bandwidth they can consume before being validated by a url filter. (and of course from a browser pov the leading bytes of a response are more interesting than the trailing bytes, so even this partial push before the window-update rtt after going through the filter is quite valuable). I intend to experiment with that approach. > Let's discuss this in a separate thread... > > -=R > > On Jul 15, 2012 11:34 PM, "James M Snell" <jasnell@gmail.com> wrote: > > > > 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 13:50:46 UTC