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
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:56 UTC