From user-return-23599-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Fri Feb 22 18:50:41 2013 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A54E0E866 for ; Fri, 22 Feb 2013 18:50:41 +0000 (UTC) Received: (qmail 6319 invoked by uid 500); 22 Feb 2013 18:50:40 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 6240 invoked by uid 500); 22 Feb 2013 18:50:40 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 6229 invoked by uid 99); 22 Feb 2013 18:50:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Feb 2013 18:50:40 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ryan.ramage@gmail.com designates 209.85.214.182 as permitted sender) Received: from [209.85.214.182] (HELO mail-ob0-f182.google.com) (209.85.214.182) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Feb 2013 18:50:33 +0000 Received: by mail-ob0-f182.google.com with SMTP id va7so869196obc.27 for ; Fri, 22 Feb 2013 10:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=hc9jGY+DHE6GfzdhWhgsMQc2YkueWhMwDQlj8bD6gNM=; b=OVeO1pdlyW9/vYCGCZr8YETFJKqDWdgsqOXs3k2MzJ4+9lU1VlmgfKqHyiBtR2HOIV YFxnzHAfKNGxZ98GkmYiFxeYNp4ZFmG2WGZAOxtphVhlAsj99fElSYy1dmTuCgRy+O7p 8S0A6MnYpMBc8ARdF8sl6QL0Mm0FDNxy1cOZiHzhuP8AwvIJzM4UWNhfsOl4AWMUxiWn Iv+u7aGPbAScRk/Uzr6yn/klUoDFKE2bNBHgpmrvEmPbcEmjsKvSrJfMaGD6nalSCy3O z+WQrSJ+jrPBhHmgsO7FYvxLD4BWynoNZoeaRub2TjcChQU/YJKuHagOrUw55fNrJHe5 LE9w== MIME-Version: 1.0 X-Received: by 10.182.14.39 with SMTP id m7mr1160945obc.96.1361559012041; Fri, 22 Feb 2013 10:50:12 -0800 (PST) Received: by 10.60.47.75 with HTTP; Fri, 22 Feb 2013 10:50:11 -0800 (PST) In-Reply-To: <5127BCD2.1070009@gmail.com> References: <5127A710.6020709@gmail.com> <5127BCD2.1070009@gmail.com> Date: Fri, 22 Feb 2013 11:50:11 -0700 Message-ID: Subject: Re: list functions, error checking, and content-type From: Ryan Ramage To: user Content-Type: multipart/alternative; boundary=14dae9399ad140e3d604d654a984 X-Virus-Checked: Checked by ClamAV on apache.org --14dae9399ad140e3d604d654a984 Content-Type: text/plain; charset=ISO-8859-1 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 >> . >> >> 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 >>> (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 >>> >> --14dae9399ad140e3d604d654a984--