RFC 2068                        HTTP/1.1                    January 1997


14.16 Content-MD5

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

           Content-MD5   = "Content-MD5" ":" md5-digest

           md5-digest   = 

   The Content-MD5 header field 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 that may have been applied to the
   message-body. If the message 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 may 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. The Transfer-Encoding header field is not
     allowed within body-parts.

     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



Fielding, et. al.           Standards Track                   [Page 113]

RFC 2068                        HTTP/1.1                    January 1997


     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 CRLF.
     Conversion of all line breaks to CRLF 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.