INTEGOK; CONTENT-MD5 -- consensus

The modification to the last two sentences of the section leaves no
objection unmet at this time, so consensus is declared for the next
draft.

--------------------------
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
paragraph. 

   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,
   HTTP allows transmission of text types with any of
   several line break conventions and not just the canonical
   form using CR-LF. Conversion of all line breaks
   to CR-LF should not be done before computing or checking
   the digest: the line break convention used in the text
   actually transmitted should be left unaltered when
   computing the digest.



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

Received on Thursday, 11 April 1996 10:55:47 UTC