Subject: Pace409Response

From: Robert Sayre <[email-masked]>
Date: Fri, 09 Jul 2004 18:43:22 -0400

http://www.intertwingly.net/wiki/pie/Pace409Response

--Abstract--

Add sections about "409 Conflict" response status codes to the APP draft.

--Status--

Active. Please direct discussion to the atom-syntax list.

--Rationale--

Currently, some AtomAPI implementations return status code 400 when they
receive a valid Atom representation that conflicts with the state on the
server. Status code 400 is reserved for problems arising from malformed
syntax.

--Proposal--

Atom Publishing Protocol

PostURI 

3.1.3  Response

   The possible status codes from a POST are 201, 303, 400, 401, 404, 409,
410, and 500.

3.1.3.x Status Code 409

   The request contained a valid Atom Entry, but it conflicts with state on
the server.The response SHOULD contain enough for information for the user
to resolve the conflict.
   
[[ more about response body format ]]

EditURI 

3.2.x  Response to PUT Requests

   The possible status codes from a PUT are ...409, ...

3.2.x.x Status Code 409

   The request contained a valid Atom Entry, but it conflicts with the state
of the resource, or other state on the server.

   For example, a server could signal that client has erred in this manner
if it receives a request containing an atom:id element whose value differs
from that of the resource found at the requested URI.

   The response SHOULD contain enough for information for the user to
resolve the conflict.

[[ more about response body format ]]

--Impacts--

Atom Publishing Protocol status codes.

---

From: Janne Jalkanen <[email-masked]>
Date: Mon, 12 Jul 2004 18:05:37 +0300

>the server.The response SHOULD contain enough for information for the user
+1

This would be immensely useful with Wikis, for example.  Though the 
response format needs to be worked out - perhaps the current contents of 
the page?

However, there needs to be a way to tell the Wiki that "ok, this is no 
longer an editing conflict, but a resolved version".  Typically this is 
done with some nonce or datetime value.

/Janne

---

From: Robert Sayre <[email-masked]>
Date: Mon, 12 Jul 2004 14:42:51 -0400

Janne Jalkanen wrote:

> response format needs to be worked out - perhaps the current contents 
> of the page?
>

We can tackle the response format later. This Pace is just about getting 
the status code in there.

> longer an editing conflict, but a resolved version".  Typically this 
> is done with some nonce or datetime value.

I'm a wiki ignoramus, so you're losing me here. Could you show me an 
example client/server exchange?

Robert Sayre

---

From: Janne Jalkanen <[email-masked]>
Date: Tue, 13 Jul 2004 13:00:18 +0300

> example client/server exchange? 

JSPWiki (and most other wikis, I'd assume) does things the following way:

1. GET the editor page, which inserts the contents of the page in a 
<textarea> element.  Also, a hidden parameter is added within the FORM, 
which contains the last-modified date of the page.
2. Upon save, i.e. POST, the server checks the hidden parameter against 
the real last-modified date of the page.  If they differ, someone must 
have changed the page contents while you were editing.
3. Show a conflict-message to the user, with a new hidden timestamp
4. The user edits the page to resolve the conflict, and saves again.  If 
the timestamps again differ, the conflict process is repeated.  If not, 
the page gets saved.

Typically, most wikis also are smart enough to show a "someone is 
already editing this page, are you sure you want to edit this page", but 
rarely do they have exclusive locking.  This is because spambots and 
random users tend to just click on the edit-link, then leave it using 
the "back" -key and leave the lock hanging.  This could probably be 
circumvented with Javascript, but that tends to bring more problems than 
not. :)

The hidden parameter can also be a hash code against the page contents 
or something, but in general a timestamp is used.

/Janne