Kevin, I believe this was fixed as a part of : https://issues.apache.org/jira/browse/COUCHDB-430
and I think may come out in a soon 1.3 release. On Fri, Feb 22, 2013 at 11:45 AM, Kevin R. Coombes < [email protected]> wrote: > 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 >> https://issues.apache.org/**jira/browse/COUCHDB-430<https://issues.apache.org/jira/browse/COUCHDB-430> >> . >> >> On 22 February 2013 17:12, Kevin R. >> Coombes<kevin.r.coombes@gmail.**com<[email protected]>> >> 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 >>> (http://stackoverflow.com/**questions/7595662/couchdb-** >>> list-api-cant-seem-to-return-**plain-text<http://stackoverflow.com/questions/7595662/couchdb-list-api-cant-seem-to-return-plain-text> >>> ), >>> 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 >>> >>
