[squid-dev] The next step towards: StoreID and metalink.

[Eliezer Croitoru]

Well I cannot say ignore now but yes I started a draft and stopped and 
then next time I Look at the keyboard it is in the squid list while I 
wanted to delete it.

Eliezer

On 21/09/2015 22:42, Eliezer Croitoru wrote:
> I would not push to add the functionality to squid\ECAP.
> To tell the truth about metalinks, They are not that popular.
> I can write a statistics gathering ECAP module which can tell us how
> much traffic has metalinks but it's to early for this.
> The servers just not using it, they use ETAGs mainly.
>
> I can see two cases which will work with some content hashing:
> - metalinks(not that popular)
> - If Modified Digest header(also not popular)
>
> For the metalinks headers there is 100% requirement to be able to run
> lookups on the cache DB with arbitrary request and\or StoreID.
> For the Digest If Modified case it's another story.
>
> In the past I had an idea to store all urls with a calculated HASH in a
> DB and then doing all sort of things with it.
> For the case of If Modified Digest case it could help to determine
> whether the current request in the cache(filtered by latest tested date
> in the DB) matches the tested hash.
>
> There is also the option to do something like:
> store multiple urls per hash and then use a full request rewrite to
> force a fetch of another url(which could be the StoreID url).
> The issue with that is that as a requirment
>
>
>
> On 21/09/2015 21:19, Alex Rousskov wrote:
>> On 09/19/2015 05:28 PM, Eliezer Croitoru wrote:
>>
>>> There are things which can help an ECAP module to decide how to do
>>> things when handling metalinks related affairs.
>>> For example, a cache object lookup from within an ECAP module.
>>> So basically the logic of the ECAP module is 100% blind to the cache
>>> internals.
>>
>> FWIW, there have been requests to expose host cache state to eCAP
>> adapters. It can be easily done (via Cache-Lookup metadata) for the
>> current request [in pre-cache REQMOD]. Doing so will even be compatible
>> with ICAP services.
>>
>> Unfortunately, but most real use cases I know about actually need a true
>> "cache lookup using an arbitrary request and/or StoreID" functionality
>> and not just a "is the current request likely to be served from cache?"
>> answer. Supporting arbitrary lookups would require expanding eCAP API. I
>> would support such expansion, especially if we have several different
>> specific use cases the back the new API design up.
>>
>> Alex.
>>
>