incubator-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 14:30:18 GMT
2011/8/16 Benoit Chesneau <>:
> On Tuesday, August 16, 2011, Marcello Nuccio <>
> wrote:
>> 2011/8/16 Benoit Chesneau <>:
>>> On Tue, Aug 16, 2011 at 1:01 PM, Robert Newson <>
> wrote:
>>>> My revised proposal was to send text/html (and 302's) in all cases
>>>> except for the very specific case where the Accept header is exactly
>>>> one item and that item is 'application/json'. All programmatic calls
>>>> can meet that (libraries incapable of this are de facto poor
>>>> libraries), and the ambiguity is vanquished.
>>> <myuserdevopinion>
>>> should be application/json imo. We are a document oriented db speaking
>>> in json first. If someone accept text/html where the only thing we
>>> send on resource is json, we should send an error by default (maybe a
>>> setting could override that).
>> This is not what is needed to fix the bug.
>> The only requirement is: if I ask an HTML, give me an HTML, not a JSON.
> that's not how the spec works.

Sorry, I said it wrong.

What I wanted to say is:
if I request a resource with a mime-type of "text/html", I expect the
response to be "text/html", if the Accept header says "text/html" is
an acceptable format. In this case the value of "q" is not relevant
because we only have the resource in HTML format.

You can do a little test:

$ curl -o/dev/null -D- -H 'Accept: image/jpeg,image/png;q=0.1'
HTTP/1.1 200 OK
Content-Type: image/png

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).


View raw message