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 randall.leeds@gmail.com
 designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6E5EE7D2-2A09-4893-8110-1C3E2734F16D@mooseyard.com>
References: <DA71E7AA-B2D4-437A-9BDC-522291CA79DC@thenoi.se>
	<6E5EE7D2-2A09-4893-8110-1C3E2734F16D@mooseyard.com>
Date: Fri, 1 Jul 2011 14:51:19 -0700
Message-ID: <BANLkTi=Ab3cOmAD+U6aKy4KARMrY76Y10g@mail.gmail.com>
Subject: Re: Debugging 302/Unauthorized error
From: Randall Leeds <randall.leeds@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 23, 2011 at 11:01, Jens Alfke <jens@mooseyard.com> wrote:
>
> On Jun 23, 2011, at 8:26 AM, Martin Hewitt wrote:
>
> 7. Attempt a PUT of a design doc:
>
> curl -i -X PUT -d
> "{\"one\":\"two\"}"=C2=A0http://testuser:testpassword@127.0.0.1:5984/test=
user_database/_design/test/
>
> 8. I get an error response:
> HTTP/1.1 302 Moved Temporarily
> Server: CouchDB/1.2.0a1075588 (Erlang OTP/R14B)
> Location:=C2=A0http://127.0.0.1:5984/_utils/session.html?return=3D%2Fmart=
in_test%2F_design%2Ftest&reason=3DName%20or%20password%20is%20incorrect.
>
> Slightly off-topic to the original question =E2=80=A6 but this seems like=
 an
> inappropriate server response from an HTTP and API standpoint.
> 1. The client is sending credentials using HTTP auth (basic or digest). I=
f
> the credentials are invalid the correct response is a 401 Unauthorized, n=
ot
> a redirect.

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.

> 2. The URL being redirected to is part of the Futon admin UI. This might =
be
> appropriate for an end-user interacting through a browser, but not for an
> app.

An app can use the content-type negotiation to receive the 401 and do
its own behavior (redirect, show dialog, etc).
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 ;).

> 3. The _utils directory isn=E2=80=99t present in all CouchDB installation=
s; e.g.
> mobile installs, so this redirect might go to a missing page.

I think you still have a valid point. If Futon were making every
request with XMLHTTPRequest it could handle a 401 in its own beautiful
way without CouchDB's coddling.
Perhaps this problem can go away with Futon2 which uses Sammyjs?

 Hopefully, others on the list know more about this issue than I do
and will correct me if I'm wrong.