incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: list functions, error checking, and content-type
Date Fri, 22 Feb 2013 17:17:10 GMT
Sounds like

On 22 February 2013 17:12, Kevin R. Coombes <> wrote:
> Hi,
> I am currently using CouchDB 1.2.0 on a Windows 7 machine. I have a database
> with several different view functions, and I am trying to define a list
> function that only makes sense when combined with _some_ of the views. Under
> the (not unrealistic) assumption that anything that a user *can* do, sooner
> or later, someone *will* do, I'd like the list function to check that the
> view it is being called with actually makes sense.  If not, then I want to
> use the HTTP response to send an error message, with a proper error code.
> My first (failed) attempt looked something like this:
> function(header, request) {
>   var row = getRow();
>   if (row.hasRequiredField) {
>     start({"headers": "Content-Type": "text/html"});
>     // do what you need to do to 'send' this and all other rows
>   } else {
>     start({"code" 400, "headers": {"Content-Type": "text/html"}});
>     send("Helpful error message explaining the problem.");
> }
> This fails because the first call to "getRow" starts writing the HTTP
> response and sets the Content-Type to "application/json".  Thus the later
> "start" calls fail to set the Content-Type or the response code.
> The only alternative I can think of at this point is to peek into the
> "request" argument to see if I can tell if the request is valid.  But I
> think the only information I can get that might be relevant is the name of
> the view (by parsing the path element), and that causes difficulties with
> maintaining the application over time.  I must either maintain a "white
> list" of known acceptable views or a "black list" of known unacceptable
> views. (And, applying the user principle above to the developer/maintainer,
> I know that I will forget to update this list at some point in time.)
> I found a StackOverflow question about this issue from September 2011
> (,
> but since the issue still exists, I assume that change either never got
> requested in JIRA or never got implemented.
> Is there some other way to accomplish what I want? Or do I have to give up
> on sending proper error codes and just set the Content-Type globally before
> calling getRow?  Or should I put the issue into JIRA and hope someone fixes
> it?
> Thanks,
>     Kevin

View raw message