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

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.

>
> 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?
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.

>
> 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.

>
> Cache Digest is a little more tricky. Ignore it for now. The remote
> proxy will never be guaranteed to do the right lookups even if you add
> both original and store URL to the digest.

-- 
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il