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 : > On Fri, Jul 1, 2011 at 14:58, Jens Alfke 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. >