couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin R. Coombes" <>
Subject list functions, error checking, and content-type
Date Fri, 22 Feb 2013 17:12:48 GMT

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?


View raw message