couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin R. Coombes" <>
Subject Re: list functions, error checking, and content-type
Date Fri, 22 Feb 2013 18:45:38 GMT
Thanks; yes, it sounds exactly like that issue.

  If I read the "JIRA issues" page correctly, this problem is fixed as 
of version 1.4.  Since the current stable release is 1.2.1, is there 
some (broad and clearly not binding...) estimate of when 1.4 might be 
available and usable by mere mortals?

On 2/22/2013 11:17 AM, Robert Newson wrote:
> 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