Ned Freed and Larry Masinter inform me about composite MIME types and
use of Content-MD5 by them, leading to some additional explanatory
words.  The net net is that the computation doesn't change, but it takes
a few words to explain why.

I think this is really it -- if there are no objections in 24 hours,
we'll consider this closed for the next draft (we have to get it out --
even if minor amendments are required later.)

Here's an update of the section.
10.13	Content-MD5

The Content-MD5 entity-header field is an MD5 digest of the entity-body,
as defined in RFC 1864 [xx], for the purpose of providing an end-to-end
message integrity check (MIC) of the entity-body. (Note: an MIC is good
for detecting accidental modification of the entity-body in transit, but
is not proof against malicious attacks.)

	ContentMD5	= "Content-MD5" ":" md5-digest
	md5-digest	= <base64 of 128 bit MD5 digest as per RFC 1864>

The Content-MD5 header may be generated by an origin server to function
as an integrity check of the entity-body. Only origin-servers may
generate the Content-MD5 header field; proxies and gateways MUST NOT
generate it, as this would defeat its value as an end-to-end integrity
check. Any recipient of the entity-body, including gateways and proxies,
MAY check that the digest value in this header field matches that of the
entity-body as received. 

The MD5 digest is computed based on the content of the entity body,
including any Content-Encoding that has been applied, but not including
any Transfer-Encoding.  If the entity is received with a
Transfer-Encoding, that encoding must be removed prior to checking the
Content-MD5 value against the received entity.

This has the result that the digest is computed on the octets of the
entity body exactly as, and in the order that, they would be sent if no
Transfer-Encoding were being applied.

HTTP extends RFC 1864 to permit the digest to be computed for MIME
composite media-types (e.g., multipart/* and message/rfc822), but this
does not change how the digest is computed as defined in the preceding

   Note: There are several consequences of this. The entity-body for
   composite types many contain many body-parts, each with its own MIME
   and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
   and Content-Encoding headers). If a body-part has a
   Content-Transfer-Encoding or Content-Encoding header, it is assumed
   that the content of the body-part has had the encoding applied,
   and the body-part is included in the Content-MD5 digest as
   is -- i.e., after the application. Also, the HTTP Transfer-Encoding
   header makes no sense within body-parts; if it is present, it is
   ignored -- i.e. treated as ordinary text.

   Note: while the definition of Content-MD5 is exactly
   the same for HTTP as in RFC 1864 for MIME entity-bodies,
   there are several ways in which the application of
   Content-MD5 to HTTP entity-bodies differs from its
   application to MIME entity-bodies. One is that HTTP,
   unlike MIME, does not use Content-Transfer-Encoding,
   and does use Transfer-Encoding and Content-Encoding.
   Another is that HTTP more frequently uses binary content types
   than MIME, so it is worth noting that in such cases,
   the byte order used to compute the digest is the
   transmission byte order defined for the type. Lastly,
   the canonical form of text types in HTTP includes several
   line break conventions, so conversion of all line breaks
   to CR-LF is not required before computing or checking
   the digest: any acceptable convention should be left
   unaltered for inclusion in the digest.

Paul J. Leach            Email:
Microsoft                Phone: 1-206-882-8080
1 Microsoft Way          Fax:   1-206-936-7329
Redmond, WA 98052

Received on Monday, 8 April 1996 12:32:13 UTC