- From: Mike Belshe <mike@belshe.com>
- Date: Sun, 15 Jul 2012 16:26:13 -0700
- 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>
- Message-ID: <CABaLYCuO9qokPH9XpFeg7ZdiN1EVH=hMyTTf+f3VfHZ_z60e6g@mail.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 UTC