couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson (JIRA)" <>
Subject [jira] Commented: (COUCHDB-484) validate_doc_update returns an HTTP 500 if validation fails
Date Fri, 01 Jan 2010 18:33:54 GMT


Chris Anderson commented on COUCHDB-484:


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.


> validate_doc_update returns an HTTP 500 if validation fails
> -----------------------------------------------------------
>                 Key: COUCHDB-484
>                 URL:
>             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
> 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.

View raw message