W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: HTTP2 Expression of Interest : Squid

From: Mike Belshe <mike@belshe.com>
Date: Sun, 15 Jul 2012 16:26:13 -0700
Message-ID: <CABaLYCuO9qokPH9XpFeg7ZdiN1EVH=hMyTTf+f3VfHZ_z60e6g@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
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 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.


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

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.

Mike



>
> > It is all cost/benefit tradeoffs, all the way down. :)
>
> Exactly :-)
>
> Cheers,
> Willy
>
>
>
Received on Sunday, 15 July 2012 23:26:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 15 July 2012 23:26:47 GMT