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

Re: HTTP2 Expression of Interest : Squid

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 17 Jul 2012 22:26:18 +1200
Message-ID: <50053DCA.9050200@treenet.co.nz>
To: ietf-http-wg@w3.org
On 17/07/2012 10:04 p.m., Poul-Henning Kamp wrote:
> In message <20120717063647.GC30530@1wt.eu>, Willy Tarreau writes:
>> On Tue, Jul 17, 2012 at 06:24:10AM +0000, Poul-Henning Kamp wrote:
>>> Uhm, doesn't this lead to incredible cache-bloat ?
>>>
>>> 	index.html + {style.css, logo.png...}
>>> 	article.html?art=1 + {style.css, logo.png...}
>> You're right, [...]
> That's quite a bummer.
>
> In the scenario where the user-agent has accessed this particular
> website previously, there is a very good chance that it has already
> cached the extra resources, whereas the first time it accesses
> a website, it knows for sure that it hasn't.
>
> That indicates to me that we should put the client in charge.
>
> So why don't we simply give HTTP/2.0 a new primitive, which we
> for historical continuity can call "MGET" meaning "send me all
> you think I'll need", vs. "GET" meaning "give me just this one" ?

Or "PULL"?  as in "Pull this resource plus associated", "the client-pull 
feature".


>
> The response to MGET would be perfectly normal objects in all
> other respects (but we need to stick their URI in the reponse
> somehow.) so caching and all that works normally.
>
> That puts the client squarely in charge of enabling server-push,
> makes it trivially easy to avoid it (bots, scripts etc) and
> will give the user-agent writers a chance to compete on the
> best logic for chosing MGET vs. GET ?
>
> Heck, you could even do that in HTTP/1.1:
>
> 	MGET /index.html HTTP/1.1
> 	Host: example.com
> 	[...]
>
> 	1xx Multiple objects coming your way
> 	Mget-Object: uri=/style.css, size=23132
> 	Mget-Object: uri=/index.html size=213123
> 	Mget-Object: uri=/logo.png size=2394
>
> 	200 OK
> 	[style.css reply]
>
> 	200 OK
> 	[index.html reply]
>
> 	200 OK
> 	[logo.png reply]

Now *that* would be an HTTP/1.2 feature. Existing HTTP/1.1 caches would 
relay the 1xx and cache the first 200 under that request. Assigning the 
second 200 to the second pipelined request... and poof. There goes the 
cache integrity.

AYJ
Received on Tuesday, 17 July 2012 10:26:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 July 2012 10:27:01 GMT