Re: Content-MD5

Roy T. Fielding writes:
 > 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).
Http, (maybe unlike MIME?) *do have* multi keywords headers already
( Like for example Allow:, Accept:, Authorization:, Pragma:,
WWW-Authenticate:, etc..). Having a library that can parse inside
headers does not seem to me a problem (as it has to be done for other
headers too anyway).
 > Content-MD5 represents a message attribute.  Content-Digest does not.
It represent the attributes that there is *a* Digest available.
 > 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.
I don't know about IMS, but I expect any WWW lib to be able to write
same simple constructs even about multi-token headers
( even simple regexp do the job
  Unless /Content-Digest:.*MD5==18a34ec98aa84b961890470434f163fa/
)

 > >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.
It is *slightly* easier to process for the simplest client indeed,
But it looks very ugly, does not provide extensibility and flexibility
that changes in algorithm will demand,..etc...
Also the current Content-MD5 does not allow manual checking
 > Until it is proven otherwise, Content-MD5 will be the
 > preferred choice for HTTP.
Is there any chance of changing your mind ?
What do you think of the above, and of my proposal ?
( http://hplyot.obspm.fr/~dl/draft-contentdigest.txt for current
version)

Thx,
Regards

dl
--
Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|...  Freedom
Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept

Treasury cracking [Hello to all my fans in domestic surveillance]
 genetic Peking Mossad Castro

Received on Monday, 6 November 1995 03:27:28 UTC