couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcello Nuccio <>
Subject Re: to CouchApp or not to CouchApp
Date Tue, 16 Aug 2011 16:16:13 GMT
Being html and json "exactly equally preferable" is not a problem, we
only need to find a smarter method to choose between the two.

Ignoring for an instant that this is hard to implement, as Jason says.
What is the problem if I send an HTML response, if the requested
resource is HTML?


2011/8/16 Robert Newson <>:
> 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 <> wrote:
>> 2011/8/16 Jason Smith <>:
>>> On Tue, Aug 16, 2011 at 9:30 PM, Marcello Nuccio
>>> <> 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

View raw message