W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1995

Re: Content-MD5

From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Mon, 06 Nov 1995 00:56:27 -0800
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9511060056.aa06369@paris.ics.uci.edu>
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=="


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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:56 UTC