[
https://issues.apache.org/jira/browse/COUCHDB-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795782#action_12795782
]
Chris Anderson commented on COUCHDB-484:
----------------------------------------
Dipesh,
I'm inclined to think the current behavior is not a bug. The current api allows
you to throw errors with 2 structures:
throw({forbidden: "message"}) is for when the operation is not allowed by the
currently logged in user and reauthenticating is unlikely to help. This is
appropriate when eg: a timestamp format is invalid or if a document is required
to have a title field. It results in a 403 status code.
throw({unauthorized : "message"}) is for when the current user is not allowed
to proceed but reauthenticating might help. Eg when a document may only be
updated by the original author. Or if only editors are allowed to mark
documents as ready for publication. It results in a 401 status code.
throw({foo : "bar"}) will result in a 500 (server) error which is appropriate
given that it doesn't match the API.
Of course this is open source and if lots of people agree with the patch then
I'm likely to change my mind. On reason I can see is if there are common 3rd
party libraries that throw structured errors and we'd like to accommodate them.
One other comment. Your patch looks really solid and ready to apply. So I'd be
upset if you were discouraged from contributing to CouchDB based on this one
experience. You've got the code chops, so hopefully we see more patches from
you.
Thanks,
Chris
> validate_doc_update returns an HTTP 500 if validation fails
> -----------------------------------------------------------
>
> Key: COUCHDB-484
> URL: https://issues.apache.org/jira/browse/COUCHDB-484
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
> Affects Versions: 0.9.1
> Reporter: Curt Arnold
> Attachments: validate_update.patch
>
>
> If a validate_doc_update method throws an exception to indicate that the
> proposed update is unacceptable, the http interface will return an 500 status
> code which indicates that the server is behaving unexpectedly. However, this
> situation is an error on the client side and should return a 4xx. To me,
> looks like 403 would be the appropriate status code. From
> http://www.ietf.org/rfc/rfc2616.txt:
> 10.4.4 403 Forbidden
> The server understood the request, but is refusing to fulfill it.
> Authorization will not help and the request SHOULD NOT be repeated.
> If the request method was not HEAD and the server wishes to make
> public why the request has not been fulfilled, it SHOULD describe the
> reason for the refusal in the entity. If the server does not wish to
> make this information available to the client, the status code 404
> (Not Found) can be used instead.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
