In <200105081322(_dot_)JAA26827(_at_)astro(_dot_)cs(_dot_)utk(_dot_)edu> Keith
Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
actually I think it's clear (or should be) that the MD5 computation
should be completely independent of canonicalization.
That was the intention of RFC 1864, but unfortunately it does not deliver,
as its text is written. It provides for all "line endings" to be
canonicalized into CRLF before computing the hash, but it does not define
what is or is not a "line ending". For text/* types, that is no problem,
of course, but what about random application types? For some of them, the
concept of "line ending" is perfectly clear. For others it is not (someone
mentioned PDF).
that is, even
if the canonicalization was done improperly, the MD5 needs to be
computed over the form of the body part that exists *after*
canonicalization and *prior* to any content-transfer-encoding.
Yes, but the content-transfer-encoding provides a second opportunity to
canonicalize LF into CRLF (the encoding engine is likely separate from the
Copntent-MD5 engine) and so may introduce some CRLFs not appropriate for
that application type, and strange things may then arise upon upcoding.
I think the only safe way is to encode all CRLF in application types as
=0D=0A, giving
foo=0Dbar=0Abax=0D=0A=CRLF
thus not relying on the CRLF at the end of the CTE lines for any meaning.
But encoding engines do not currently work this way :-( . So it seems to
me that a Content-MD5 engine (assuming it has no opportunity to alter the
document, or to influence the encoding) is forced to try and 2nd guess
what the encoding is going to do (or has already done).
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Snail: 5
Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5