Re: Content-MD5

Aside from the issues of duplication and the history of Content-MD5,
nobody has presented a valid design reason for defining a generic
header field.

HTTP (or Internet mail) header fields are designed to optimize the
semantics of <message-attribute>:<message-value>.  From a design
perspective, the best way to process Internet messages is to read
them into a hash table with the field-name as the key.  Then, when
a particular system function needs a particular message attribute,
it does a simple table look-up to obtain the value of that attribute
(or nil if the attribute was undefined).

Content-MD5 represents a message attribute.  Content-Digest does not.
Content-MD5 allows the recipient's semantic parser (the step after
message parsing) to determine if an MD5 has been calculated without
parsing the contents of any particular field.  Content-Digest does not.
Content-MD5 will make it easy for me to define a generic IMS construct of

    GET / HTTP/1.1
    Unless: Content-MD5 eq "qyeur87168587646846109hgs=="

or  

    PUT /happy HTTP/1.1
    Unless: Last-Modified ne "Mon, 06 Nov 1995 00:51:58 GMT"

Content-Digest would not.

>From a perspective of having designed several HTTP systems, Content-MD5
(and Content-SHA, Content-Sum, etc.) is a better design choice for the
HTTP protocol.  Until it is proven otherwise, Content-MD5 will be the
preferred choice for HTTP.


 ...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, 6 November 1995 01:07:40 UTC