[
https://issues.apache.org/jira/browse/COUCHDB-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981425#action_12981425
]
Paul Joseph Davis commented on COUCHDB-973:
-------------------------------------------
The fact that 410's can be cached makes me even more hesitant to switch over to
them because unless clients are sending the etags from possibly unknown
previous entries it would seem like a bad possibility of masking a re-created
document. Which seems like a reason why they would have said if we know that a
resource can be recreated to use 404.
We don't keep anything similar at the db level so I don't think that's really
affected by this.
> Return 410 when GETing a previously deleted document (rather than 404)
> ----------------------------------------------------------------------
>
> Key: COUCHDB-973
> URL: https://issues.apache.org/jira/browse/COUCHDB-973
> Project: CouchDB
> Issue Type: Bug
> Reporter: Benjamin Young
> Priority: Trivial
> Attachments: 410.patch
>
>
> When you GET a nonexistent doc you get (as you should) a 404 Not Found error.
> However, if you GET a document that has previously existed you also get the
> 404 response. It would be more informative (IMO) for the 410 Gone response
> code to be used. 410 Gone's intention is for exactly this use case, and it
> could have some value to CouchDB developers who need to know the document did
> exist.
> CouchDB is already half way there as in the body of the 404 response it does
> state that the document did exist (at least prior to compaction), so
> outputing a 410 (again, prior to compaction) would hopefully be a trivial
> patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
