[
https://issues.apache.org/jira/browse/COUCHDB-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979421#action_12979421
]
Benoit Chesneau commented on COUCHDB-1020:
------------------------------------------
202 is a successful response though. I understand your point anyway. Sending
202 is more for Quality reporting than anything.
> 202 status on "DELETE /db"
> --------------------------
>
> Key: COUCHDB-1020
> URL: https://issues.apache.org/jira/browse/COUCHDB-1020
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
> Affects Versions: 1.2
> Reporter: Benoit Chesneau
> Priority: Minor
> Fix For: 1.2
>
>
> Current status is 200 . Following irc discussion there are 2 points of you
> considering tthat sicne db isn't accessible from HTTP api, 200 is ok.
> But still data is on the disk and effectively, deletion is asynchronous. HTTP
> Spec on DELETE :
> [[[
> A successful response SHOULD be 200 (OK) if the response includes an entity
> describing the status, 202 (Accepted) if the action has not yet been enacted,
> or 204 (No Content) if the action has been enacted but the response does not
> include an entity.
> ]]]
> and status 202 :
> [[[
> The request has been accepted for processing, but the processing has not been
> completed. The request might or might not eventually be acted upon, as it
> might be disallowed when processing actually takes place. There is no
> facility for re-sending a status code from an asynchronous operation such as
> this.
> The 202 response is intentionally non-committal. Its purpose is to allow a
> server to accept a request for some other process (perhaps a batch-oriented
> process that is only run once per day) without requiring that the user
> agent's connection to the server persist until the process is completed. The
> entity returned with this response SHOULD include an indication of the
> request's current status and either a pointer to a status monitor or some
> estimate of when the user can expect the request to be fulfilled.
> ]]]
> Since it's true that deletion introduce an aysnchronous process to delete the
> db file an it's data, I think that 202 is more appropriate here.
> 202 would mean, that resource isn't available but deletion is running.
> Related to #COUCHDB-1019 we could pass a pid or taskid to the response
> eventually.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
