[
https://issues.apache.org/jira/browse/COUCHDB-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13902583#comment-13902583
]
Isaac Z. Schlueter commented on COUCHDB-2063:
---------------------------------------------
The HTTP spec states that a 409 response should include enough information to
resolve the conflict. Currently, CouchDB does not do this. Sending the `_rev`
is not enough to resolve the conflict. Sending the winning-revision doc IS
enough, and is the default behavior for a GET anyway.
Returning the `_rev` alone is clearly a bad idea. It is not enough data to
resolve the conflict, but IS enough data to PRETEND to have resolved it, which
encourages bad behavior, as has been repeatedly mentioned.
By default, a `GET` only returns the winning revision. That is what a 409 PUT
response should include.
Regarding the discussion about what to return as the `doc` param on a 409
response, why not just respect the exact same args, and return the exact same
data, as what `GET /db/doc` would be?
If you do `PUT /db/doc?conflicts=true`, then ok, send the _conflicts in the
doc. Same if you do `PUT /db/doc/?revs=true`, send all the _revisions info.
> Return current document with 409 response
> -----------------------------------------
>
> Key: COUCHDB-2063
> URL: https://issues.apache.org/jira/browse/COUCHDB-2063
> Project: CouchDB
> Issue Type: Bug
> Security Level: public(Regular issues)
> Reporter: Isaac Z. Schlueter
>
> You do a PUT, and it doesn't have the current rev.
> So then you do a GET, to get the current rev.
> Then you re-try your PUT.
> Please make the second request unnecessary. Just send the current doc in the
> 409 response body, unless the user opts-out with a `?send_current=false` or
> something.
> There are almost no examples of cases where you'd do a PUT and *not* want to
> immediately GET the doc on a 409. The only case I could think of would be an
> in-place modifying follower where you don't care about a 409, because it
> means that another change is coming in the stream anyway. Are there any
> others? Even in those cases, you could just set the opt-out flag to not get
> the current data in the response.
> The only harm in doing this is that outdated apps will still do the
> (now-unnecessary) GET. That's not so bad. They'll keep working.
> Systems with a single write-master and multiple read-slaves, however, will be
> able to leverage this to great effect, rather than relying on cache-busting
> query params and other kludges.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
