- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 16 Jul 2012 08:16:02 +0200
- To: Mike Belshe <mike@belshe.com>
- Cc: Roberto Peon <grmocg@gmail.com>, Julian Reschke <julian.reschke@gmx.de>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>, tom <zs68j2ee@gmail.com>
On Sun, Jul 15, 2012 at 11:06:25PM -0700, Mike Belshe wrote: > > > Server push doesn't break the request response model. You issue a request, > > > you get a response. You can't get responses without requests. > > > > 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). You forgot the proxy between the client and the server :-) Typically the one which at my company and my customers prevents me from accessing a number of websites based on URL classification. > > > As for impact on content filtering, I think you're quite mistaken. Using > > > server push allows the content to look like content and makes it much > > > *easier* to do filtering. If we do as you proposed above (and move it to > > > websockets) then it becomes opaque data and much harder to apply common > > > filtering rules. > > > > Note that I'm not advocating the use of WS to retrieve objects, I was just > > observing that more and more contents are delivered as data to > > applications, > > so I'm not saying that I'd prefer to filter them in one form or another. > > Concerning filtering, I think that what embarrasses me a bit with server > > push is the difficulty of applying URL-based filtering. But maybe this is > > just a problems which needs to be carefully addressed so that it is not a > > problem at all. > > > > URL based filters will work great with server push, as every pushed > response has a unique URL. OK. But what if the server pretends this URL being anything else (including random) ? Well anyway this is too early to discuss this now. From a technical point of view I'm convinced about the efficiency of server push, my concerns are only about efficient deployments, so I think this will be discussed to great extents later. Let's not pollute the EOI threads with this. Cheers, Willy
Received on Monday, 16 July 2012 06:16:36 UTC