(INTEGOK) rough consensus

What follows is text for the (currently TBS) section on Content-MD5
header. There are objections to it, but rough consensus is believed to
exist. The most likely outcome of the objections (IMHO) is that a new
header for content integrity and authentication mechanisms will be
proposed for HTTP/1.2.

If there are any problems you have with this, please let me know, or
I will believe enough consensus exists to make add this to the 1.1 draft
to close this issue.

--------------------
10.13	Content-MD5

The Content-MD5 entity-header field is an MD5 digest of the entity-body,
as defined in [RFC 1864], for the purpose of providing an end-to-end
integrity check of the entity-body.

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

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

When being generated, the MD5 digest is computed based on the value of
the entity-body after Content-Encoding (if any) but before
Transfer-Encoding (if any) is applied; when being checked, after
Transfer-Encoding has been removed, but before Content-Encoding has been
removed.

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, unlike
MIME, the digest is computed over the entire entity-body, even if it
happens to be a MIME multi-part content-type. (Note that the multi-part
bodies may themselves have Content-MD5 headers.) 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
network byte order. Lastly, the canonical form of text types in HTTP
includes several line break conventions, so conversion to CR-LF is not
always required before computing or checking the digest: any acceptable
convention should be left unaltered for inclusion in the digest.

>      Note: the net result of the above is that the digest is
      computed on the content that would be sent over-the-wire, in
>      network byte order, but prior to any transfer coding being 
>      applied.



----------------------------------------------------
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 Monday, 1 April 1996 01:32:37 UTC