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

Re: HTTP2 Expression of Interest : Squid

From: Willy Tarreau <w@1wt.eu>
Date: Tue, 17 Jul 2012 08:36:47 +0200
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Mike Belshe <mike@belshe.com>, 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: <20120717063647.GC30530@1wt.eu>
On Tue, Jul 17, 2012 at 06:24:10AM +0000, Poul-Henning Kamp wrote:
> In message <20120717055619.GA30530@1wt.eu>, Willy Tarreau writes:
> >On Mon, Jul 16, 2012 at 08:31:28AM -0400, Patrick McManus wrote:
> 
> >> I hesitate to comment, because I've only got a partial push
> >> implementation for firefox (and that's on hold right now just due to
> >> other priorities) - but the approach I've taken helps I think. Pushed
> >> resources are kept in a partitioned cache that is scoped to just the 1
> >> "associated-to" resource that triggered the push. When the associated-to
> >> resource goes away so does the pushed cache (and is never persisted to
> >> disk). Documents are promoted out of this micro cache into the real
> >> profile-wide cache when a request is made for them as a sub-resource of
> >> the associated-to resource and they "hit" in the micro cache.
> >
> >It seems to make sense indeed and it's probably the easiest way to
> >implement it.
> 
> Uhm, doesn't this lead to incredible cache-bloat ?
> 
> 	index.html + {style.css, logo.png...}
> 	article.html?art=1 + {style.css, logo.png...}
> 	article.html?art=2 + {style.css, logo.png...}
> 	article.html?art=3 + {style.css, logo.png...}
> 	...
> 
> Or did I misunderstand something ?

You're right, I remember we discussed this point with Robert in Paris.
I think that there should be a way for the client to tell the server
either that it already has some objects (though that's not easy). One
point was that the client can abort the retrieval in one round trip,
so in the end, the worst that may happen is that the download link is
filled with data you already have during one RTT, which means you
download up to the BDP extra data. It can be a concern with overloaded
uplinks though.

I tried to think about ways to avoid this using some date headers in
requests but there is no way you can tell you're up to date with just
this. The referrer might help the server guess you don't need some
shared objects though.

Regards,
Willy
Received on Tuesday, 17 July 2012 06:37:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 July 2012 06:37:29 GMT