Re: MD5 and URL validation (continue to other very old thread)

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