Re: HTTP2 Expression of Interest : Squid

In an offline study, without any connection to IETF, I (we) found
server-push too costly in HTTP-SMS gateways, which includes upgrades to MMS
That is easily exploited, even with websockets, so that/this becomes one
use-case for implementation of HTTP status 402. Of course, it polls, so
that is the request, and then the server-push happens. We have shown more
elaborate actions in another WG.

While offline, there is no way to resolve the issue except to disable
polls, so maybe that should be the default for 402 from causes like the
use-case.

Tested.

On Sun, Jul 15, 2012 at 4:26 PM, Mike Belshe <mike@belshe.com> 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.
>
>
>>
>> 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
>>
>>
>>
>