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
