md5 as memcached_key
Merlin
merlin at mahalo.com
Tue Jan 27 07:01:45 MSK 2009
I agree that since this is not a cryptographic application, the fact that
md5 has some collisions is less relevent, maybe even irrelevent unless you
have a very large set of URIs you need to pull from memcached uniquely.
Due to the way nginx configuration and modules work, I am not sure that it
is viable to have $md5(SOMETHING) return md5. A more likely (and probably
relatively easy to implement) solution might be something like this:
location /testing {
set_md5 $memcached_key $request_uri;
memcached_pass localhost:11211;
}
Perhaps I'll take a shot at it later on in the week :).
On Mon, Jan 26, 2009 at 3:25 PM, Sergio Bruder <bruder at haxent.com.br> wrote:
>
> Em 26/01/2009, às 20:47, Geoff Geoff escreveu:
>
>
> Dave Cheney wrote:
>>
>>> md5 is not guaranteed to be unique, that is to say, two seperate
>>> inputs can generate the same hash, so you would need to use extra
>>> logic in your application if you wanted to guard against this remote
>>> possibility. I'm guessing the problem you are trying to solve is the
>>> memcache key has a limitation that is shorter than the possible
>>> request_uri ?
>>>
>>> Cheers
>>>
>>> Dave
>>>
>>
>> Thanks Dave,
>>
>> The problem is that memcached will not allow certain characters in the
>> key name - so I thought it might be simpler to just store the md5 of the
>> actual request_uri.
>>
>> Thanks,
>> Geoff
>>
>
> There are the theoretical chance of colision, yes, but you probably can use
> it anyway without a practical chance of colision.
>
>
> Sergio Devojno Bruder
> bruder at haxent.com.br
> Haxent Consultoria
> http://haxent.com.br/
> 41 3362-1460
> 41 9933-8764
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090126/93bc98e7/attachment.html>
More information about the nginx
mailing list