Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Thu, 3 Jan 2013 19:24:12 +0000 (UTC)
From: "Travis Paul (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12625895.1357240790690.75558.1357241052897@arcas>
In-Reply-To: <JIRA.12625895.1357240790690@arcas>
References: <JIRA.12625895.1357240790690@arcas>
Subject: [jira] [Updated] (COUCHDB-1635) Error handling code in
 validate_doc_update assumes a string for the error value
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/COUCHDB-1635?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Travis Paul updated COUCHDB-1635:
---------------------------------

          Environment: CentOS 6.3 x86_64 (CouchDB RPM from EPEL)
    Affects Version/s: 1.0.3
   =20
> 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: Futon, HTTP Interface
>    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_repor=
t.txt
>
>
> CouchDB crashed when trying to throw the following objects from a validat=
e_doc_update function:
> throw({forbidden: [{}] });
> // will attach: forbidden_crash_report.txt
> throw({unauthorized : [{}] });
> // will attach: 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.
> =20
> I decided to run some more tests before filing a bug:
> throw({forbidden: [] });
> // {"error":"forbidden","reason":""}
> throw({forbidden: {} });=20
> // {"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 fea=
ture request as it seems Futon expects strings and the Definitive Guide sug=
gests this is expected behavior:
> "When you=E2=80=99re trying to prevent an authorized user from saving inv=
alid 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 administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira