Re: Why MD5 Headers are Imperative

>
>OK, here's a use case.  Bear with me please, as it integrates @etag later 
>on.  I have a wiki where multiple authors have agreed to work on version 2 of 
>a shared document.  The existing version 1 of the document is served at this 
>location:
>

My example ends up not being a wiki in the real world, but I have decided to 
configure Typo3 this way because it is typical, in a CMS situation, to have 
multiple administrators and authors managing a page which only exists as a 
standalone <entry>, never as a <feed>.

It is also typical for a CMS to implement a draft toggle, in Typo3 it's 
actually a "visible" toggle but same diff, either can be modeled under 
app:control using app:draft or by extension.  Only one editor has the ability 
to toggle app:draft from "yes" to "no", there are only two <entry> documents, 
one for the old and one for the new.  When published, the version with the 
new <updated> simply wins out over the old, no overwrite necessary, and the 
original version remains accessible.  There is no need in this very real-
world use case (I have the Open eGov project in mind for this) to set 
the eTag of http://example.com/resource to anything but atom:id+atom:updated.

All output representations, in HTML, XHTML, WAP, PDF or what-have-you, are 
transformed using XSLTC in response to content negotiation.  So yes, we want 
the Atom entry document to be as persistently cached as possible despite the 
fact that no user of the system will ever receive an Atom representation of 
the documents so managed.  Very real-world-today.

You can have a <collection> titled "drafts" which links to the correct xml:id 
without affecting the main <collection> or the ability for an administrator 
to alter the main page in the presence of a new draft while disallowing such 
direct edits by the editors of the new draft.  Pretty flexible.  Suggestions:

5.3.1   Retrieving  a  Resource 
 
    Client                                      Server 
      |                                            | 
      |   1.)  APP-GET  to  Member  URI                 | 
      |------------------------------------------>| 
      |                                            | 
      |   2.)  Writable Member  Representation        | 
      |<------------------------------------------| 
      |                                            | 
 
    1.   The  client  sends  an APP-GET  request to  the  Member  URI  to  
        retrieve its  writable representation, as follows:

        1a.  The client MUST force revalidation on the server
        1b.  The client MUST send an X-APP-MD5 header with the value "GET"
        1c.  The client MAY send an URL parameter with a specific XML ID:
                http://example.com/resource;id={xml:id}
            This supports the selection of multiple revisions of a Member
            Resource when an @xml:id exists for <link rel='edit'/>
 
    2.   The  server  responds  with  the  writable representation  of  the 
        resource.  An APP-aware server MUST:

        2a.  Send a VARY:X-APP-MD5 header in response to any GET request 
            for the Member URI
        2b.  Send a Content-Md5 header in response to any APP-GET request 
            as per 1b
 
 
5.3.2   Updating  a  Resource 
 
    Client                                      Server 
      |                                            | 
      |   1.)  APP-PUT  to  Member  URI                 | 
      |------------------------------------------>| 
      |                                            | 
      |   2.)  409  Conflict                          | 
      |<------------------------------------------| 
      |                                            | 
      |   3.)  200  OK                                | 
      |<------------------------------------------|  
 
    1.   The client sends an updated representation  to  the  Member's URI 
        utilizing APP-PUT as follows:

        1a.  The client MUST send an X-APP-MD5 header whose content is equal to 
      the value the server returned in the Content-Md5 header

    2.   If the X-APP-MD5 value of the APP-PUT request is not equal to the 
      current Content-Md5 value of the Member URI the server MUST respond 
      with a status code of 409.
 
    3.   Upon  a  successful  update  of  the  resource  the  server  
      responds  with  a  status  code  of  200. 

-EJB