Why MD5 Headers are Imperative

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