Re[2]: HTTP2 Expression of Interest : Squid


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?

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.

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.

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> wrote:
> 
> 
> On Sun, Jul 15, 2012 at 11:06 PM, Mike Belshe <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