incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcello Nuccio <marcello.nuc...@gmail.com>
Subject Re: to CouchApp or not to CouchApp
Date Tue, 16 Aug 2011 15:47:58 GMT
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

Mime
View raw message