Bill de hÓra wrote:
>
> Joe Gregorio wrote:
>> On 6/1/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
>>> What's the APP way of dealing with no response received and/or double
>>> posting?
>>
>> I agree with Tim, these are out of scope to the core protocol.
>
> I'm not sure. Partial failure is core to HTTP. Maybe there are sane
> responses that can be sent back on POST/GET to help the client move to
> the right app state.
>
As Tim indicated, it would make sense to, at the very least, make it
clear that these situations could occur. It would also likely be sane
to suggest to clients that if they do decide to attempt to repost an
entry, the subsequent posts should be identical to the original (same
atom:id, same atom:updated, etc). If the server thinks it is seeing a
duplicate, it could return a 409 Conflict with a Location header that
identifies the URI of the potentially conflicting entry. If the
reported conflict turns out to be a false positive, the client could
repost the entry using a different atom:id/atom:updated/whatever.
# Request
POST /collection HTTP/1.1
Host: example.org
...
# Response
HTTP/1.1 409 Conflict
Date: nnnn
Location: /collection/members/1
...
Thinking out loud: Would it make sense to suggest (but not require) that
clients include Message-ID headers in their POST requests if they are
concerned about the possibility of accidentally posting duplicates?
Doing so would provide a simple solution that works consistently with
entry and media posts and operates independently of whatever policy the
server has in place for modifying/retaining the value of
atom:id/atom:updated/etc.
- James
