Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of marcello.nuccio@gmail.com
 designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BANLkTi=As1tdbOH92K-Zn8fsZYw+4gygJA@mail.gmail.com>
References: <DA71E7AA-B2D4-437A-9BDC-522291CA79DC@thenoi.se>
	<6E5EE7D2-2A09-4893-8110-1C3E2734F16D@mooseyard.com>
	<BANLkTi=Ab3cOmAD+U6aKy4KARMrY76Y10g@mail.gmail.com>
	<5F06C81A-C701-45AE-8EA9-CEFED8D60EAA@mooseyard.com>
	<BANLkTi=As1tdbOH92K-Zn8fsZYw+4gygJA@mail.gmail.com>
Date: Sat, 2 Jul 2011 08:53:10 +0200
Message-ID: 
 <CAMWZAjkBL1+rAfuMUU_X7Gahdw-J_RxcgorXUdMxJHHTG9YVWg@mail.gmail.com>
Subject: Re: Debugging 302/Unauthorized error
From: Marcello Nuccio <marcello.nuccio@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

FYI, there is an ongoing discussion on this subject at
https://issues.apache.org/jira/browse/COUCHDB-1175

It would be great to get other opinions, because right now the
discussion is stuck, and I think it is an important one.

To sum it up, here is my position: CouchDB should do something similar
to what Rails does.
https://github.com/rails/rails/commit/1310231c15742bf7d99e2f143d88b383c3278=
2d3

If I GET http://localhost:5984/db/_design/ddoc/index.html it does not
make sense to me to obtain a json response.

What do you think?

Marcello

2011/7/2 Randall Leeds <randall.leeds@gmail.com>:
> On Fri, Jul 1, 2011 at 14:58, Jens Alfke <jens@mooseyard.com> wrote:
>>
>> On Jul 1, 2011, at 2:51 PM, Randall Leeds wrote:
>>
>>> The reasoning was that this response makes Futon much more friendly
>>> rather than relying on the browser's login dialogues.
>>> With "Accept: application/json" I think CouchDB does respond with a 401=
.
>>
>> Yeah, I=E2=80=99ve seen this kind of tension before, between APIs that w=
ant to use HTTP auth vs UIs that want to use cookie-based login. In some AP=
Is you have to append a query string (like ?auth=3Ddigest=E2=80=9D) to get =
HTTP auth; but that would be way too awkward to use in Couch.
>>
>> The Accept: header seems like a pretty roundabout way to tell the server=
 which behavior you want! I would never have guessed that. Why not use the =
auth headers? If the client went to the trouble of explicitly sending HTTP =
auth headers, the server should probably assume it meant to use auth, and r=
eturn a 401.
>>
>>> Since JSON is the only official interface to CouchDB it's debatable
>>> that CouchDB should be doing anything other than a 400 for this
>>> request ;).
>>
>> You mean 401, not 400, right? The request isn=E2=80=99t invalid, just un=
authorized.
>>
>> =E2=80=94Jens
>
> No, I meant 400. If we were really being pushy about forcing
> application/json we could reject a request that didn't include it if
> we felt like it.
> But I guess */* is almost always the last thing sent by most clients,
> so nevermind that.
> I was just being cheeky.
>