Re: HTTP2 Expression of Interest : Squid

Hi Willy,

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

> Hi Mike,
>
> On Sun, Jul 15, 2012 at 04:26:13PM -0700, Mike Belshe wrote:
> > On Sun, Jul 15, 2012 at 10:27 AM, Willy Tarreau <w@1wt.eu> wrote:
> >
> > > Hi Roberto,
> > >
> > > On Sun, Jul 15, 2012 at 10:05:31AM -0700, Roberto Peon wrote:
> > > > Note that, if ever one will wish to implement server push or anything
> > > > similar, there are ordering requirements that must be placed on at
> least
> > > > the content delivery of the requested resource and its associated
> > > metadata.
> > >
> > > Doug's EOI made me think again about server push. You may remember, we
> > > discussed the subject for countless hours when we met, with the problem
> > > basically being that when a client fetches a page, it also wants the
> > > objects in that page. Doug seems to need server push for instant
> delivery
> > > to the client of fresh new contents, which is different. And if we look
> > > at how the web is currently changing, we have more and more application
> > > code running on the browser (sometimes a smartphone) which parses
> contents
> > > delivered by the server. I suspect that once we have MUX in WebSocket,
> this
> > > new model will become even more prevalent.
> > >
> >
> > Websockets is at the wrong layer and does not do content delivery - e.g.
> a
> > websocket response will never ever land you in the client's cache.
>
> Indeed, this is a good point. I was mostly thinking about dynamic contents
> in fact.
>
> > > All this to say that maybe in the near future, the real need for server
> > > push will be for raw data processed by the application and not that
> much
> > > about page objects. I may be wrong, but this is probably something to
> > > think about, since in the end it will tell us whether we have to break
> > > the request/response model or not, which has a huge impact on content
> > > filtering BTW.
> > >
> >
> > 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).



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

Mike



>
> Regards,
> Willy
>
>