W3C home > Mailing lists > Public > public-bpwg-ct@w3.org > May 2008

Re: CT Proxies and Forward Caches

From: Jo Rabin <jrabin@mtld.mobi>
Date: Thu, 22 May 2008 11:16:17 +0100
Message-ID: <483547F1.8060107@mtld.mobi>
To: Francois Daoust <fd@w3.org>
CC: Umesh Sirsiwal <usirsiwal@movik.net>, "Sullivan, Bryan" <BS3131@att.com>, public-bpwg-ct@w3.org

Aside from the redirect cost that Francois mentions, I am not sure that 
having separate URIs to allow caching of the "high" "medium" and "low" 
cases is the whole answer, since the response may still vary within 
those groups depending on work-arounds to the quirks of any particular 
device within the grouping.

As Francois points out, this relates to the "long-running" ISSUE-222, 
and it's down to me to try to make sure that it doesn't run much longer :-(

Jo

On 21/05/2008 09:34, Francois Daoust wrote:
> 
> Indeed, the use of a "Vary: User-Agent" header generates much more 
> entries than a more typical use of Vary such as "Vary: Accept-Language", 
> and is thus not a really cache-friendly directive.
> 
> The solution Bryan suggested to create representation-specific URIs for 
> each UA group, coupled with a redirect response from a canonical 
> representation is much better from a cache perspective but it has a 
> cost: that of a round-trip between the server and the client to serve 
> the redirect response to the representation-specific URI. This solution 
> is recommended by the W3C Technical Architecture Group in a finding "On 
> Linking Alternative Representations To Enable Discovery And Publishing" 
> [1].
> 
> We only mention the use of the "Vary" header in current version of the 
> Content Transformation Guidelines document, but we have a long-running 
> discussion (internally named ISSUE-222) on the above mentioned TAG 
> finding. We may include that possibility in the document as well.
> 
> [1] http://www.w3.org/2001/tag/doc/alternatives-discovery.html#id2261672
> 
> 
> Sullivan, Bryan wrote:
>> Hi Umesh,
>> As you mention, meta-group assignment (e.g. good/better/best) is a 
>> deployment-specific function, i.e. one Content Provider (CP) may 
>> choose a different set of groups and UA assignment as compared to 
>> another. Without the direct involvement of the CT proxy in group 
>> selection, the only way I see to reduce the cached representations is 
>> for the CP to provide a distinct URI to UA's in a group (e.g. a URI 
>> parameter or unique path), so the various UA's naturally get served 
>> one of a fewer variations of the page from the cache.
>>  
>> "direct involvement of the CT proxy in group selection" implies some 
>> kind of metadata exchange between CP and CT proxy, through which 
>> group-related pages can be indicated, and maybe a tighter integration 
>> of the CT proxy and cache. Both appear (to me) to be less desirable to 
>> standardize, and at least more complex to consider.
>>  
>> Best regards,
>> Bryan Sullivan | AT&T
>> ------------------------------------------------------------------------
>> *From:* public-bpwg-ct-request@w3.org 
>> [mailto:public-bpwg-ct-request@w3.org] *On Behalf Of *Umesh Sirsiwal
>> *Sent:* Monday, May 19, 2008 8:12 AM
>> *To:* public-bpwg-ct@w3.org
>> *Subject:* CT Proxies and Forward Caches
>>
>> Several content transformation proxies and the Internet in general 
>> includes forward caches. Current definition of HTTP includes 
>> indication of transformation using Vary header. In most cases the 
>> Content Transformation proxies and servers vary their responses based 
>> on User-Agent header. The number of User-Agent string in is very high 
>> and caches cannot possibly store these mean copies of the response. 
>> Most servers are likely to classify the devices in certain meta-groups 
>> for the purpose of content transformation. However, this meta-group is 
>> expected to be server specific. In absence of formal method, the 
>> caches will be left to guess the meta-group. What will be the method 
>> to solve this?
>>
>>  
>>
> 
Received on Thursday, 22 May 2008 10:17:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 May 2008 10:17:47 GMT