Hi Ryan,

I think that is the same reference that Robert Newson supplied, and the 
JIRA page notes the "fix version" as 1.4 -- which is why I asked if 
there was some timeline for the release of 1.4. It would certainly be 
nice if the fix could be included in 1.3....

Thanks,
     Kevin

On 2/22/2013 12:50 PM, Ryan Ramage wrote:
> 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<
> kevin.r.coombes@gmail.com>  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<kevin.r.coombes@gmail.com>>
>>>   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
>>>>