Re: (INTEGOK) rough consensus

I am having a hell of a time keeping connected to the discussions -- our
network and workstations keep failing due to multiple power failures
and server problems.

Typos and rough wording changes:

> 10.13	Content-MD5
> The Content-MD5 entity-header field is an MD5 digest of the entity-body,

                                field provides an MD5 digest ...

> as defined in [RFC 1864], for the purpose of providing an end-to-end

                RFC 1864 [xx], 

> integrity check of the entity-body.
> 	ContentMD5	= "Content-MD5" ":" digest
> 	digest	= <base64 of 128 bit MD5 digest as per RFC 1864>

        Content-MD5     = "Content-MD5" ":" md5-digest
        md5-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

  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 headers: proxies and

                                              header field; proxies and

> gateways MUST NOT generate it, as this would defeat its value and an

                                                          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 the header

                                                        in this header field

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

The above is too terse.
  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.

> 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

                   may be computed

> happens to be a MIME multi-part content-type. (Note that the multi-part

             be a "multipart" type.  ...

> 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

                                           so conversion of all line
  breaks to CRLF form 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.

Why not just say that and leave out the rest?  I think the note is far
more effective (and more likely to always be accurate) then the paragraph
above it.

 ...Roy T. Fielding
    Department of Information & Computer Science    (
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056

Received on Monday, 1 April 1996 18:56:06 UTC