Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAMWZAjms30L_TosKNt54Bqn9fHteJOuuanYKqnA-UrAa6+Bkcw@mail.gmail.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>
Date: Tue, 16 Aug 2011 17:06:20 +0100
Message-ID: 
 <CABvT1DEZYDTe5YLX=LOA1raLPtUq_MgPNFQKbf5z2Ff6PWqS3g@mail.gmail.com>
Subject: Re: to CouchApp or not to CouchApp
From: Robert Newson <rnewson@apache.org>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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.

Following the standard for content-type negotiation is still broken
for browsers (like IE) that regard html and json as exactly equally
preferable. We could just agree that this negotiation is broken on IE
and follow the original proposal in the ticket (to account for
q-values correctly). I've no idea if that's acceptable but it doesn't
sound likely.

B.

On 16 August 2011 16:47, Marcello Nuccio <marcello.nuccio@gmail.com> wrote:
> 2011/8/16 Jason Smith <jhs@iriscouch.com>:
>> On Tue, Aug 16, 2011 at 9:30 PM, Marcello Nuccio
>> <marcello.nuccio@gmail.com> wrote:
>>> Since sketch.png is available only as "image/png", Apache responds
>>> with "image/png" even if "image/jpeg" is preferred according to the
>>> Accept header.
>>>
>>>>> This is what I do if the user is authenticated, and I see no reason
>>>>> for not doing it when the response is a 401.
>>>>
>>>> i don't follow. how it is related?
>>>
>>>
>>> I ask to apply the same logic whatever the status code of the
>>> response. If when the response is "200 OK" the content-type is
>>> "text/html", then why not respond with the same content-type for a
>>> "401 Unauthorized" response?
>>>
>>> Obviously the content will be different (an html login form for the 401).
>>
>> Did you see my previous two emails? Quick summary:
>>
>> 1. That is not the standard. IMHO, if CouchDB should change, it should
>> change toward the standard.
>> 2. Regardless of #1, it is hard to implement. The example of a public
>> image is not the question. The question is you request *something* but
>> you do not have permission. How should Couch respond? To me, the
>> answer is becoming very clear: obey the client Accept header. If the
>> client explicitly asks for HTML, send a 302 bounce; otherwise send 401
>> JSON. If that breaks futon or some applications, we can fix those
>> as-needed once and for all.
>
> Saying it is hard to implement could be enough reason for not doing
> it. However it would be great to first find the "right" solution, and
> then say "ok, maybe some day we could do it, but for now the best
> workaround is...".
>
> Why do you say it is not the standard?
> I am NOT saying to ignore the Accept header. Nothing of what I have
> said makes CouchDB less standard compliant.
>
> Sending 302 instead of 401, is not more standard-compliant than
> sending 401 with the correct content-type.
>
> Sorry, but I think I am missing something obvious...
>
> Marcello
>