On Mon, Dec 21, 2009 at 11:07 PM, Olaf van der Spek
<[email protected]> wrote:
>>>> But on the other hand, HTTP "Content-MD5" header RFC (1864) explicitly
>>>> mentions network byte ordering as I originally quoted. Being a
>>>> standards-compliant HTTP server, IMO, we should be doing whatever the
>>>> RFC says, even if it's a nuance.
>>>
>>> What RFC? The MD5 one? Or the HTTP MD5 one (1864)?
>>>
>> The HTTP MD5 RFC (1864), since that's what Apache "ContentDigest" implements.
>
> So what exactly are you proposing?
> An example of actual bytes in de MD5 in BE and LE would help.
>
Please review this patch to util_md5.c. It's a naive,
platform-independent implementation of LE to BE conversion.
Here is a sample run through the function:
before: 141cc61b 1d4d266a 7b0abec2 beb7a7f8
after: f8a7b7be c2be0a7b 6a264d1d 1bc61c14
Thanks,
-deepak
--- util_md5.c.orig 2009-12-22 10:37:41.000000000 +0530
+++ util_md5.c 2009-12-22 11:26:46.000000000 +0530
@@ -128,6 +128,23 @@
static char basis_64[] =
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
+/* convert 128-bit number from little-endian to big-endian
+ * warning: input is modified
+ */
+AP_DECLARE(void) ap_le2be_128bits_inplace(char *data)
+{
+ char tmp;
+ int i, j;
+
+ j = 15;
+ for (i=0; i<8; i++) {
+ tmp = data[i];
+ data[i] = data[j];
+ data[j] = tmp;
+ j--;
+ }
+}
+
AP_DECLARE(char *) ap_md5contextTo64(apr_pool_t *a, apr_md5_ctx_t *context)
{
unsigned char digest[18];
@@ -140,6 +157,7 @@
apr_md5_final(digest, context);
digest[sizeof(digest) - 1] = digest[sizeof(digest) - 2] = 0;
+ ap_le2be_128bits_inplace(digest);
p = encodedDigest;
for (i = 0; i < sizeof(digest); i += 3) {
*p++ = basis_64[digest[i] >> 2];
