Re[2]: HTTP2 Expression of Interest : Squid


you could maybe just do it with a multipart response.

But IMO limiting server push to only providing associated resources is 
a waste of potential.

Real-time notifications is something I find quite interesting, and that 
would only really work if requested by the client, but then at any 
stage until the connection is closed or whatever, messages could be 
sent.  May not be cachable, but that would make no sense anyway for a 
notification.

Adrien


------ Original Message ------
From: "Amos Jeffries" <squid3@treenet.co.nz>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 17/07/2012 10:26:18 p.m.
Subject: Re: HTTP2 Expression of Interest : Squid
>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:32:25 UTC