Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jens@couchbase.com designates
 206.225.164.28 as permitted sender)
From: Jens Alfke <jens@couchbase.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Date: Tue, 16 Aug 2011 09:23:06 -0700
Subject: Re: to CouchApp or not to CouchApp
Thread-Topic: to CouchApp or not to CouchApp
Thread-Index: AcxcMMfZUnxeLjCFQcWFT8z0RNRaHQ==
Message-ID: <C9195240-BB05-44A5-AE13-11AA5B338ADB@couchbase.com>
References: 
 <CA+5KyPSE3BULUc7KONgx8ZqfNKW++_r8vgdhh7HLxLr0JgfM0A@mail.gmail.com>
 <CAONf+LQKjE6NVCsLKWb3wzmWOwrS2ej+_PCJS4Z=uV3hj0OtOg@mail.gmail.com>
 <CAOHkvcP0XMAFvvFhaw3azEyqBxPMhNxFwkYX+5_x52ScSaxEbg@mail.gmail.com>
 <CAMkGvyNO4GC8e+PWu8u7BpV6b4OUvXZ3v37y5kpnXdrYgn_nBA@mail.gmail.com>
 <4E371B93.8060303@kearns.net.au>
 <CAAL6JQj_u0RgDhQG95oFrQfJ3MUeRXHb+Q6d1Cc6DEBUwaE_vA@mail.gmail.com>
 <CAONf+LTt0Hmuhx8PTs_LdzzX-fHQDAhQg_kJabTQAnfnBdxZqQ@mail.gmail.com>
 <CAOHkvcNutCimOggckR3ivc2=DCAP1ZhPTC2XpnP1o_E82_Pvaw@mail.gmail.com>
 <CA+5KyPR56FpKXiQ6Zyxu0V2jwaKbOghbTZyJ10Ou=YXyyk6zhA@mail.gmail.com>
 <CAONf+LTd+qQtLBb7iXb-H_HJs4Xm+t+Bw0G4CMLCC8X=bYwdFQ@mail.gmail.com>
 <CAAL6JQhytD90Jn3f7LT-HUMVH=T5GgTEMXWzaR6kQ5BgqZGRSw@mail.gmail.com>
 <CAAL6JQjbpOD9GOu-dDDf7-1-44pANT3U=ZKaNYEBXPcX11C8pA@mail.gmail.com>
 <CAN-3CBLheiAds-L5Vps-amEHN-F-17yRqHzbzNzAq-Ev9BKa5g@mail.gmail.com>
 <CAMWZAjnE9p2QB7zujjGqL-JiLMnbbimmuz3V-f+pW_bNeL4hng@mail.gmail.com>
 <CAN-3CBLog0VMXZYN622+3ZN=_JV09fi1UTW54rFR=-3nP6+sVQ@mail.gmail.com>
 <CABvT1DHODFHdq3Uu6AcKGuk+Vmf+EJvV0Lyj=Q7A_iAehst+iw@mail.gmail.com>
 <CAJNb-9p--g2d_UMWAtSjbyTLRYdt_h0T0sLckX5k=+HJ2kyUHg@mail.gmail.com>
 <CAMWZAj=8GRLuvF2GDr=bi=g05j9_w+JBt76ohmscNX2Pvz4Eqw@mail.gmail.com>
 <CAJNb-9pQGzvZ8pmqSxoY0Jyk+8Z+sXYzYgTgOmqiVr3Ww+hDaw@mail.gmail.com>
 <CAMWZAjmSY_jdvyZ4+tjbO6TdbRAUb+gd4UhVrbSKTgvNmrgRJQ@mail.gmail.com>
 <CAN-3CB+LwerwsdcxLfRW70NwWvHDiTg7spRKJ0tBAZQzsuX8QA@mail.gmail.com>
 <CAMWZAjms30L_TosKNt54Bqn9fHteJOuuanYKqnA-UrAa6+Bkcw@mail.gmail.com>
 <CABvT1DEZYDTe5YLX=LOA1raLPtUq_MgPNFQKbf5z2Ff6PWqS3g@mail.gmail.com>
In-Reply-To: 
 <CABvT1DEZYDTe5YLX=LOA1raLPtUq_MgPNFQKbf5z2Ff6PWqS3g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_C9195240BB0544A5AE1311AA5B338ADBcouchbasecom_"
MIME-Version: 1.0

--_000_C9195240BB0544A5AE1311AA5B338ADBcouchbasecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


On Aug 16, 2011, at 9:06 AM, Robert Newson wrote:

Talk of 'following the standard' while preserving the behavior of
returning a 302 for an unauthorized request is contradictory. We're
deliberately not following the standard 401 response here because the
universal user agent behavior we'd get is unpalatable.

Yeah, this is a hack. It=92s mixing up =91CouchDB as REST data store=92 wit=
h =91CouchDB as web-app server=92. Returning a 302 might be appropriate at =
an application layer, but it=92s absolutely not at the REST/database layer.

Using the browser Accept header to determine behavior seems like the wrong =
thing to do, as it=92s only tenuously connected to the actual database/app =
dichotomy. (What if I=92m asking the database to fetch an attachment whose =
type is known to be text/html?)

Couldn=92t the CouchApp define some kind of handler to be called in case of=
 unauthorized access, and that handler could then decide to return a 302?

=97Jens

--_000_C9195240BB0544A5AE1311AA5B338ADBcouchbasecom_--