logo       

Re: Why MD5 Headers are Imperative: msg#00463

network.syndication.atom.protocol

Subject: Re: Why MD5 Headers are Imperative


>
>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>
Google Custom Search

News | FAQ | advertise