[
https://issues.apache.org/jira/browse/COUCHDB-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shorin updated COUCHDB-1635:
--------------------------------------
Component/s: (was: Futon)
(was: HTTP Interface)
JavaScript View Server
> Error handling code in validate_doc_update assumes a string for the error
> value
> -------------------------------------------------------------------------------
>
> Key: COUCHDB-1635
> URL: https://issues.apache.org/jira/browse/COUCHDB-1635
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
> Affects Versions: 1.0.3
> Environment: CentOS 6.3 x86_64 (CouchDB RPM from EPEL)
> Reporter: Travis Paul
> Attachments: forbidden_crash_report.txt, unauthorized_crash_report.txt
>
>
> CouchDB crashed when trying to throw the following objects from a
> validate_doc_update function:
> throw({forbidden: [{}] });
> // see: forbidden_crash_report.txt
> throw({unauthorized : [{}] });
> // see: unauthorized_crash_report.txt
> It seems that the CouchDB error handling code assumes a string for the
> error value, futon does this as well.
> Robert Newson responded to me on the mailing list with:
> I can easily believe our error handling code assumes a string for the
> error value. File a JIRA ticket?
> error_info({Error, Reason}) when is_list(Reason) ->
> error_info({Error, ?l2b(Reason)});
> This clause assumes, erroneously, that a list is really a string and
> so converts it to a binary. In this case, the list contains objects.
>
> I decided to run some more tests before filing a bug:
> throw({forbidden: [] });
> // {"error":"forbidden","reason":""}
> throw({forbidden: {} });
> // {"error":"forbidden","reason":{}}
> // futon reports: Error: unauthorized [object Object]
> throw({unauthorized : [] });
> // {"error":"unauthorized","reason":""}
> throw({unauthorized : {} });
> // {"error":"unauthorized","reason":{}}
> // futon reports: Error: unauthorized [object Object]
> throw({ foo: [{}] });
> // I'm not quite sure what to make of this result:
> // {"error":"case_clause","reason":"{[{<<\"foo\">>,[{[]}]}]}"}
> But I'm not 100% sure this is a bug, it may actually be somewhat of a feature
> request as it seems Futon expects strings and the Definitive Guide suggests
> this is expected behavior:
> "When you’re trying to prevent an authorized user from saving invalid data,
> use this:
> throw({forbidden : message});"
> However crashing and not sending a response suggest that it is a bug.
> My use case is that I am trying to return an array of json-schema errors with
> all of the validation errors instead of a single message.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
