Re: Why MD5 Headers are Imperative

Eric J. Bowman wrote:
> [snip]
> My counter-proposal is that a last-modified timestamp is not an achievable 
> goal when the data format is Atom, which is why it's based on the MD5 header. 
> Unless, of course, we just decide that Atom Format is borked somehow and that 
> it shouldn't be adhered to in APP, which can indeed force the issue by making 
> a fundamental change to a widely deployed format...
>  

As I've said before, the MD5 header does not help anything.  For
example, suppose I get an entry today and the system IT guy updates the
server software overnight.  As part of the software update, atom entries
are now rendered with a different namespace prefix and without any
formatting whitespace.  Suddenly all of my MD5 headers for all of the
entities will be different, and yet none of the underlying entries will
ever have been updated.

> Under the implementation I based my spec extension on, app:modified works 
> perfectly well because only editors ever need to see it and it's decoupled 
> from <updated>, Last-Modified and eTag.  The only way I have found to keep 
> any of this straight is the pattern I recognized in the Content-Md5 headers 
> as I was building it. They give a completely unambiguous means of determining 
> the freshness of the retrieved version for editing and allows the 
> representation PUT back to the server to go to a non-public version, i.e. the 
> next draft, instead of only the published, cached version.
> 

No, Content-MD5 headers do nothing more than ensure that the body of the
http message got from point A to point B without being modified;  they
do not guarantee freshness of the resource representation.  If you're
absolutely convinced that an md5 hash is useful as a validator in your
implementation, then use the md5 hash as the resource entity-tag.

- James