On Mar 7, 2009, at 7:35 PM, Antony Blakey wrote:
On 08/03/2009, at 10:48 AM, Jan Lehnardt wrote:
http://osdir.com/ml/db.couchdb.devel/2008-07/msg00127.html (lmgtfy
"safari sends post twice", seriously, this is tiring).
Sorry, I tried a number of searches (e.g. "safari double post bug"),
and couldn't find that.
Is it possible to get some reciprocal benefit of the doubt rather
than immediate hostility?
Those lmgtfy links seem to be about the double post being
triggered by the browser client, as opposed to e.g. a ruby client.
I knew about that problem, but I've not seen a problem report due
to *middleware* e.g. proxy/cache ignoring the non-idempotency of
POST.
The point is that CouchDB can't know if requests come from a broken
or compliant middleware system with new ones coming up all the time.
But we're only talking about this problem in the context of XHR
right? And so the advice to not use POST without a UUID is specific
to XHR apps, rather than all use cases?
The problem is if there is a network error, a client has no way to if
a POST commit was successful. The success or failure response can get
lost, and the id of the document is completely unknown to the client.
But if the client knows the doc id beforehand, then it can later check
the db (or reattempt the update) to see if the update was successful
or lost. And wIth deterministic rev ids, the client could just do the
update again and get a success response despite the update maybe
already having being committed.
-Damien
