- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Mon, 01 Apr 1996 18:28:15 -0800
- To: Paul Leach <paulle@microsoft.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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 (fielding@ics.uci.edu)
University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/
Received on Monday, 1 April 1996 18:56:06 UTC