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