On Mar 24, 2012, at 12:06 AM, Jack Bates <[email protected]> wrote:
> On 22/03/12 10:08 PM, James Peach wrote:
>> On 22/03/2012, at 4:19 AM, Jack Bates wrote:
>>> On 10/03/12 08:43 PM, Jack Bates wrote:
>>>> What can sites like this do to help intermediate proxies like Apache
>>>> Traffic Server make cache hits from requests for the same content from
>>>> different mirrors?
>>>>
>>>> Are there any best practices?
>>>
>>> Has there ever been any discussion or work on supporting RFC 6249 [1] or
>>> "Metalink" [2] in Apache Traffic Server?
>>
>> No I don't think so.
>>
>>> I found this [3] mention of Metalink and intermediate caching proxies
>>> ("Metalink integration with Proxy/Cache" heading)
>>
>> That sounds like a pretty useful project. There's probably a number of
>> different ways a plugin could implement this. Folks on the dev list or
>> #traffic-server would be happy to help.
>>
>>> [1] http://tools.ietf.org/html/rfc6249
>>> [2] http://metalinker.org/
>>> [3] http://sourceforge.net/apps/trac/metalinks/wiki/GsocIdeas
>
> Thank you very much James, I am replying to the dev list
>
> Perhaps a minimum viable product could:
>
> 1. If the response status code is 3XX
> 2. Scan RFC 6249 "Link: <...>; rel=duplicate" headers for URL that already
> exist in cache
> 3. If found, update "Location: ..." header with this URL and pass on response
That sounds like a promising approach.
>
> It could also check for an RFC 3230 "Digest: ..." header and, if found, check
> for content with same digest already in cache?
I think there was some conversation on IRC indicating that doing cage lookups
by hash would require a fair amount of change to the cache.
> Could this behavior be achieved with any of the existing "remap" plugins?
I don't think so, but I don't have much experience with them. It might be worth
poking around the trafficserver-plugins repository to see whether there's
anything similar ...
J
