incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Debugging 302/Unauthorized error
Date Fri, 01 Jul 2011 22:06:31 GMT
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 <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’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

Mime
View raw message