You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Randall Leeds <ra...@gmail.com> on 2011/07/01 23:51:19 UTC
Re: Debugging 302/Unauthorized error
On Thu, Jun 23, 2011 at 11:01, Jens Alfke <je...@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\"}" http://testuser:testpassword@127.0.0.1:5984/testuser_database/_design/test/
>
> 8. I get an error response:
> HTTP/1.1 302 Moved Temporarily
> Server: CouchDB/1.2.0a1075588 (Erlang OTP/R14B)
> Location: http://127.0.0.1:5984/_utils/session.html?return=%2Fmartin_test%2F_design%2Ftest&reason=Name%20or%20password%20is%20incorrect.
>
> Slightly off-topic to the original question … 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). If
> the credentials are invalid the correct response is a 401 Unauthorized, not
> 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’t present in all CouchDB installations; 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.
Re: Debugging 302/Unauthorized error
Posted by Randall Leeds <ra...@gmail.com>.
On Sat, Jul 2, 2011 at 11:45, Jens Alfke <je...@mooseyard.com> wrote:
>
> 2011/7/2 Randall Leeds <ra...@gmail.com>:
>>
>> 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.
>
> Not to beat this into the ground, but actually that would be a 406 Not Acceptable. (HTTP has a status code for every occasion!) However, the spec explicitly says that it’s OK to return JSON even if the client didn’t Accept: it:
>From http://tools.ietf.org/html/rfc2324
2.3.2 418 I'm a teapot
Any attempt to brew coffee with a teapot should result in the error
code "418 I'm a teapot". The resulting entity body MAY be short and
stout.
-Randall
Re: Debugging 302/Unauthorized error
Posted by Jens Alfke <je...@mooseyard.com>.
2011/7/2 Randall Leeds <ra...@gmail.com>:
>
> 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.
Not to beat this into the ground, but actually that would be a 406 Not Acceptable. (HTTP has a status code for every occasion!) However, the spec explicitly says that it’s OK to return JSON even if the client didn’t Accept: it:
> Note: HTTP/1.1 servers are allowed to return responses which are
> not acceptable according to the accept headers sent in the
> request. In some cases, this may even be preferable to sending a
> 406 response. User agents are encouraged to inspect the headers of
> an incoming response to determine if it is acceptable.
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>
Which seems eminently reasonable to me.
—Jens
Re: Debugging 302/Unauthorized error
Posted by Marcello Nuccio <ma...@gmail.com>.
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/1310231c15742bf7d99e2f143d88b383c32782d3
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 <ra...@gmail.com>:
> On Fri, Jul 1, 2011 at 14:58, Jens Alfke <je...@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’ve seen this kind of tension before, between APIs that want to use HTTP auth vs UIs that want to use cookie-based login. In some APIs you have to append a query string (like ?auth=digest”) 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 return 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’t invalid, just unauthorized.
>>
>> —Jens
>
> 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.
>
Re: Debugging 302/Unauthorized error
Posted by Randall Leeds <ra...@gmail.com>.
On Fri, Jul 1, 2011 at 14:58, Jens Alfke <je...@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’ve seen this kind of tension before, between APIs that want to use HTTP auth vs UIs that want to use cookie-based login. In some APIs you have to append a query string (like ?auth=digest”) 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 return 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’t invalid, just unauthorized.
>
> —Jens
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.
Re: Debugging 302/Unauthorized error
Posted by Robert Newson <rn...@apache.org>.
As a thought experiment, assume we drop all of this negotiation magic
and stick to accepting and returning application/json and returning
'correct' codes like 401 for unauthorized.
What are the consequences? Are they severe or are there good workarounds?
I get that hitting some urls in the browser will be less pleasant, but
that's not really a good enough reason, given the expectation of an
XHR call where the 401 can be nicely handled.
B.
On 1 July 2011 22:58, Jens Alfke <je...@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’ve seen this kind of tension before, between APIs that want to use HTTP auth vs UIs that want to use cookie-based login. In some APIs you have to append a query string (like ?auth=digest”) 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 return 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’t invalid, just unauthorized.
>
> —Jens
Re: Debugging 302/Unauthorized error
Posted by Jens Alfke <je...@mooseyard.com>.
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’ve seen this kind of tension before, between APIs that want to use HTTP auth vs UIs that want to use cookie-based login. In some APIs you have to append a query string (like ?auth=digest”) 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 return 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’t invalid, just unauthorized.
—Jens