Re: Re[2]: HTTP2 Expression of Interest : Squid

On Mon, Jul 16, 2012 at 4:42 AM, Adrien de Croy <adrien@qbik.com> wrote:

>
> Hi Mike
>
> there must be some sort of context associated between the client and the
> server for the push, otherwise what is the server pushing at?
>

Correct; in the spdy protocol this is the associated stream id.  Further,
the scope and lifetime of the associated stream id is carefully crafted so
that they are finite - you can't keep pushing additional associated
resources after you've finished the primary resource.


> This context would be established first by some request?  E.g.
>
>
Shouldn't the client request server push, and transmit a context that the
> server can use to associate the many responses.
>
>

Yes, it does.  When I fetch http://www.microsoft.com/ I'm setting up the
context, and www.microsoft.com may optionally decide to associate
'style.css' into that context.



> That then also allows an intermediary to track what is going on (e.g.
> demux on a shared connection), and allows the client to decide whether
> server push happens or not.
>

I strongly advise against client-side push enabling.  We've seen that movie
before, such as when the client decides whether or not the server can
compress or when the client decides whether or not the server can use
pipelining.  Making it a client decision kills the feature entirely.  We
need to either support push or not support it.  But seriously, who are
these clients which will reject the pushes?  You can't push random data.
 You can only push in-domain data.  If the browser doesn't need it, you
only hurt yourself.  Seriously, why would any browser block the push?

Mike



> Adrien
>
> ------ Original Message ------
> From: "Mike Belshe" <mike@belshe.com>
> To: "James M Snell" <jasnell@gmail.com>
> Cc: "Willy Tarreau" <w@1wt.eu>;"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>
> Sent: 16/07/2012 6:35:35 p.m.
> Subject: Re: HTTP2 Expression of Interest : Squid
>
>
>
> On Sun, Jul 15, 2012 at 11:33 PM, James M Snell < <jasnell@gmail.com>
> jasnell@gmail.com> wrote:
>
>>
>>
>> On Sun, Jul 15, 2012 at 11:06 PM, Mike Belshe < <mike@belshe.com>
>> mike@belshe.com> wrote:
>>
>>>   [snip]
>>>> 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).
>>>
>>>
>> One possibility to throw in here would be a simple requirement that the
>> server has to ask the client before it pushes... a reverse 100-Continue if
>> you will... require the server to tell the client what content it is trying
>> to push and give the client the opportunity to say No.... intervening
>> proxies, such as a corporate firewall, would be capable of answering on the
>> users behalf.
>>
>
> If you have a proxy, the proxy receives the pushes (not the client), so
> the proxy can do whatever it would do in the non push case.
>
> mike
>
>
>>
>> - James
>>
>
>