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 <[email protected]>: > On Fri, Jul 1, 2011 at 14: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 > > 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. >
