On 11/22/2012 4:58 AM, Amos Jeffries wrote:
On 22.11.2012 08:06, Eliezer Croitoru wrote:
Last time long ago There was a talk about URL storing the original
request URL at the swap_file Meta data.
Now it strikes me again while testing something.
the code of:
<SNIP>
Disabling this check will make my life easy with store_url making it
from "not" to "works".
So I have couple options how to "fix" the issue:
1. disable this check.
2. disable this check for only store_url_rewritten requests.
3. adding the store_url meta object into the cache file and use it to
identify the expected url.
4. add on\off switch to disable this check.
5. others?
<SNIP>
What do you think?
I think the usual method of calculations for hash collisions are a
little biased towards an even distribution of bytes. Whereas real-world
URL space is a lot tighter - with a far greater similarity between any
two similar-length URLs than in normal text of same length.
I'm not certain what effect this has on the hash or how best to
compensate though.
Have you seen real world scenario of collision?
No.
I'm kind of having the opinion that we should try (2) if that non-UFS
are also skipping it anyway.
OK, This was my first aim.
My problem was that in the stage of the check I dont know what variables
are available to me.
Since the request is not.. and I dont want to change the function\method
for the check.
I was thinking maybe to use a flag in the middle so it will be available
later for the check as part of the StoreEntry.
I need to find a stage which I can flag or copy the storeURL.
Maybe the cacheHit method fine for that since it still has the request
in hand but I didnt checked if there is another earlier stage.
Eliezer
--
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
