Re: some notes and help to think is needed + Test results of testing basics in store_url_rewrite.

On 6/10/2012 8:53 p.m., Eliezer Croitoru wrote:
> On 9/27/2012 7:55 AM, Amos Jeffries wrote:
>>
>> This is the HTTP/1.1 variant handling code. Each request URL may have
>> multiple response variants depending on the things indicated by Vary:
>> header and possibly ETag header as a unique ID for each variant. How it
>> is done in Squid is that the store contains a vary meta object as well
>> as the normal file meta object.
> Well yes but this specific check:
> http://bazaar.launchpad.net/~squid/squid/3-trunk/view/head:/src/client_side_reply.cc#L506
>
>
> is not related to the vary headers at all but a basic url match check.
>

?? sure we are looking at the same Line-506 of src/client_side_reply.cc
in trunk ??

" switch (varyEvaluateMatch(e, r)) {"

>
>>
>> The storeURL should point at the meta object, and then when loaded meta
>> object points at other bits to combine in addition to the storeURL to
>> make a new key for a second lookup which is expected to find the actual
>> file object for that variant.
> So if I understood right you mean that we need to store the storeURL
> in the metadata?

No, not quite. The vary object needs only to store the additional
details to append to the key (ie for "Vary:Accept-Encoding" it stores
the encoding header values). Not a URL.
The URL being used (original or store) is already known to the code
which looked it up ... using that URL.

> We were talking about it before and never decided if to use the
> metadata or not.
> If I understood correctly the store_url is in the ufs\aufs store
> metadata but not in others.
> I can put the storeURL in the meta data and then to make a check for
> that.

We still have not found a case for it being added.

>
>>
>> You should make these secondary keys use the storeURL instead of the
>> original URL (only when the original URL was used, some variant may be
>> looked up based on ETag or digest values alone).
>
>
>
>
>> Some other places which need it are:
>> PURGE requets handling lookups
>> ICP request lookups
>> HTCP request lookups
>
> This is after we decide whatever to do on regular cache checks behavior.

Yes the 2.7 store-URL is known not to support these well. First the
portage, then the additional bug fixes.

Amos
Received on Sat Oct 06 2012 - 12:08:58 MDT