httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Nagaraj <n.dee...@gmail.com>
Subject Re: network byte ordering in "ContentDigest"?
Date Mon, 21 Dec 2009 16:07:25 GMT
On Mon, Dec 21, 2009 at 8:03 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Mon, Dec 21, 2009 at 3:07 PM, Deepak Nagaraj <n.deepak@gmail.com> wrote:
>>> It's 16 bytes, what reordering did you want to do? Byte order only
>>> applies to stuff larger than individual bytes.
>>>
>> The RFC considers it as a 128-bit "digest" (=number).  It can be
>> divided into 16 bytes in either host order or network order.  Because
>> the RFC says "when viewed in network order", it implies that we need
>> to do host-to-network conversion.  This is the conversion I'm
>> referring to.
>
> AFAIK that really doesn't apply. It's not an int, it's a 16-byte
> 'array' that shouldn't be reordered.
>
You're right about MD5.  I checked the MD5-algorithm RFC (1321).  It
specifies that the digest is generated in little-endian order.

"""
The message digest produced as output is A, B, C, D. That is, we begin
with the low-order byte of A, and end with the high-order byte of D.
"""

So as long as the generator and verifier both follow the MD5 algorithm
as per its RFC, we should be OK.

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.

Thanks,
-deepak

Mime
View raw message