- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 17 Jul 2012 10:04:46 +0000
- To: Willy Tarreau <w@1wt.eu>
- 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>
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" ?
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]
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Tuesday, 17 July 2012 10:05:15 UTC