Sounds like https://issues.apache.org/jira/browse/COUCHDB-430.
On 22 February 2013 17:12, Kevin R. Coombes <[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), > 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
