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 <[email protected]> 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
