Re: MD5 hash query

Robert Collins wrote:

> ----- Original Message -----
> From: "Joe Cooper" <joe@swelltech.com>
> To: "Robert Collins" <robert.collins@itdomain.com.au>
> Cc: <squid-dev@squid-cache.org>
> Sent: Friday, December 28, 2001 10:37 PM
> Subject: Re: MD5 hash query
>
>
>
>>I see...I'm definitely missing the Method->enum conversion. So will
>>
> try
>
>>that. Should that be octal or does it matter? METHOD_GET is shown as
>>001 in enums.h, but I thought an enum as defined there would put it
>>simply at 1. I'll just try it. ;-)
>>
>>I was looking at storeKeyPublic...you're looking at storeKeyPrivate.
>>Should I be looking at Private? If so, it looks like Squid can also
>>
>
> Whoops! Whatever one gets committed to disk, which I have never tracked
> through :}.

I think it's Public in the instances that I'm wanting to track (cachable
content that can later be served as a hit). Maybe Henrik|Adrian|Duane
knows off-hand if my reading is incorrect?

For experimental purposes, where should I be getting id from? I'm not
even sure what that /is/ much less where to find it in any of the logs.

 
> As for the method conversion: it gets fed into the MD5 in binary, so you
> need to feed the binary value in. (ie if size(method)==4, and GET is 1,
> then the result will be 0x00000001 - but don't forget to adjust for your
> endianness.

I've now fiddled with several methods of feeding binary data into the
hashing module--but I'm not sure if any of them result in the actual
result needed. Regardless of whether the correct data format is being
fed, the resulting hash is still incorrect.

I've tried both 16 bit and 32 bit binary (via a pack/unpack pair), as
well as the Perl 5.6 sprintf %b conversion. method_t is an unsigned
int, so I think it's 32 bits on my box--and I must assume the same
endianness that Perl generates from an unpack operation on the same
machine. None result in a matching MD5...

Any other thoughts?

-- 
Joe Cooper <joe@swelltech.com>
http://www.swelltech.com
Web Caching Appliances and Support