|
Re: Why MD5 Headers are Imperative: msg#00463network.syndication.atom.protocol
> >There are now dozens of messages about this MD5 stuff. Is there a >Pace or another suggestion for specific wording changes in the spec? >If not, you're wasting your time. -Tim > I've been hashing out an idea and hoping to get some help with it, I never had the intention of first-time-authoring a Pace without any feedback from the group first. Now that I do have some preliminary wording, any assistance in turning it into a Pace would be greatly appreciated, but I still worry that at this late date, with so much pressure to "just release something", it's far too easy to just shoot this down without really considering it. I would feel so much better if anyone on the WG would even acknowledge that I'm not just clamoring for attention, but actually do have a point, and discuss the problem. Then I could re-lurk and get back to my business. Anyway, here's what I have, I know it needs work but that still isn't the point, the point remains that an Atom Publishing Protocol cannot and should not ignore the publisher-gets-control aspect of the underlying format by trying to make it WebDAV or something: 5.3 Once a resource has been created and the URI of its Atom Entry Document (its 'Member URI') is known, that URI may be used to update and delete the resource. The Member URI may also be used to retrieve a readable representation of the resource or, using the Atom Protocol, a writable representation of the resource. 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 P.S. I would like to thank everyone for their time, who has chosen to give of it, throughout the course of the project and as pertains to my concerns. |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: Why MD5 Headers are Imperative: 00463, Eric J. Bowman |
|---|---|
| Next by Date: | Re: Why MD5 Headers are Imperative: 00463, Eric J. Bowman |
| Previous by Thread: | Re: Why MD5 Headers are Imperativei: 00463, Robert Sayre |
| Next by Thread: | Re: Why MD5 Headers are Imperative: 00463, James M Snell |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |