Re: HTTP2 Expression of Interest : Squid

On Sun, Jul 15, 2012 at 11:16 PM, Willy Tarreau <w@1wt.eu> wrote:

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

No, I didn't forget this :-)  The proxy has full visibility to the server
push urls and can filter them too.  Also, server push requires that clients
and servers abide by the same-origin policy.  So you can't push resources
from random domains.



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


This is possible with or without server push - proxies can do this today.
 This is why we need to make sure proxies can't tamper content.



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

ok

mike


>
> Cheers,
> Willy
>
>