Re: Why MD5 Headers are Imperative

Eric,

I haven't been following your conversations with Henry so I may have
missed something fundamental here, but using the Content-MD5 header
doesn't solve anything for the simple fact that a client can make
structural changes to an Atom entry that has zero semantic impact.

For instance, the following two entries are semantically identical
despite being structurally different.

<entry xmlns="http://www.w3.org/2005/Atom";>
  <id>tag:example.org,2006:foo</id>
  <title>Test</title>
  <updated>2006-12-12T12:12:12Z</updated>
  <link href="http://www.snellspace.com"; />
  <summary>Testing</summary>
</entry>

<a:entry xmlns:a="http://www.w3.org/2005/Atom";>
  <a:summary type="text">Testing</a:summary>
  <a:title type="text">Test</a:title>
  <a:updated>2006-12-12T12:12:12Z</a:updated>
  <a:link rel="alternate" href="http://www.snellspace.com"; />
  <a:id>tag:example.org,2006:foo</a:id>
</a:entry>

The md5 of the first is 4e3376ce3aa2fa7b433715721aade2a1. The md5 of the
second is b8d410e34895cfb76fc7b12ff8f2c1d9, despite being semantically
identical.

- James


Eric J. Bowman wrote:
> A GET on the Member resource does not imply that the purpose of the 
> requesting client is to edit the document.
> 
> Therefore, insignificant changes allowed in the Atom format must not be 
> overridden by any requirement that such changes be reflected in either an 
> eTag or Last-Modified header, for the same reasons I described in regards to 
> the app:modified element -- it leads to insignificant changes to the Member 
> resource invalidating cached versions, which seems to be at cross-purposes 
> with the purpose of allowing the publisher to determine significance in 
> atom:updated.
> 
> Thus, the determination of freshness for editing purposes and detection of 
> the lost-edit problem cannot be dependent upon existing HTTP cache-control 
> mechanisms which are reliant upon Last-Modified and eTag because to do so 
> forces insignificant changes to invalidate cached versions of the Member 
> resource which may also be dereferenced by feed readers, etc.
> 
> If the purpose of an Atom Publishing Protocol is to interface with Atom-
> format documents which uniquely allow this divergence then some method other 
> than HTTP cache-control must be used to determine whether the Member resource 
> has been edited on the back-end in a way which has not changed its cached 
> representation. What we need is some method to implement a "validated miss" 
> which doesn't ivalidate requests (which may not have the purpose of editing) 
> for the Member resource, but which serves an undeniably fresh editable 
> representation to APP clients, while preventing the lost-update problem.
> 
> At first I thought, "When the user intention is to edit a Member resource, an 
> APP client MUST use "max-age:0" in the GET request to force the validated 
> miss."  But no, this just revalidates the cache-control headers.  Then I 
> thought, "An APP client will ACCEPT 'application/atomserv+xml' so we can VARY 
> based on ACCEPT."  But no, that also breaks the cacheability of the Atom 
> format by unnecessarily fracturing the cached versions of the Member resource 
> into an infinite number of possibilities instead of just one.
> 
> Content negotiation can solve the problem, however.  So let's extend HTTP 1.1 
> with an APP-specific header, for example when requesting the Member resource 
> an APP client MUST send "X-APP-MD5:GET" AND "max-age:0".  An APP-aware server 
> MUST return VARY:X-APP-MD5 and a Content-Md5 header.  Now we have one cached 
> Member representation which is not susceptible to insignificant edits, and 
> one cached Member representation whose cacheing is essentially based on the 
> Content-Md5 header.  The PUT request reflects the value of Content-Md5 back 
> to the server in the "X-APP-MD5" header.
> 
> When an APP client is browsing but not intending to edit (some clients may 
> always intend to edit, as well) it does not send the "X-APP-MD5" header, in 
> which case the presence of VARY:X-APP-MD5 allows it to retrieve non-fresh 
> cached versions just like other clients.
> 
> -EJB
> 
> 
> 
>