Reproduced locally. From here on, let's stick to commenting via the 1175 ticket.
The change was deliberate but has unintended side-effects. I'm currently +1 on reverting this change in 1.1.1, but I'd like to finally nail the exact semantics for this content-type negotiation once and for all. B. On 17 June 2011 16:32, Marcello Nuccio <[email protected]> wrote: > 2011/6/17 Robert Newson <[email protected]>: >> Hi Marcello, >> >> The current logic for CouchDB 1.1.0 is this; >> >> 1) If the client accepts "application/json" then respond with 401 and >> content-type "application/json" (i.e, a normal HTTP/REST response. >> 2) if the client accepts "text/html" then respond with a 302 to the >> authentication_redirect url. >> >> This is from couch_httpd:error_headers/4. > > I have responded here: > https://issues.apache.org/jira/browse/COUCHDB-1175?focusedCommentId=13051132&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13051132 > > >> I'll note that Futon does not produce login popups under the >> conditions you describe but perhaps I failed to reproduce your test >> scenario (in Firefox 4.0.1, anyway). > > Did you setup a security object with "admins" and "readers" for the DB? > > If you are not logged in, Futon should display an alert with: > > Error: unauthorized > You are not authorized to access this db. > > This is the same behaviour as CouchDB-1.0. > > The problem is when you try to access a couchapp in the protected DB. > Since you are not redirected to a login page, you get stuck with a > access denied error. > > Hope I have been clear... my English is very basic... sorry. > > Marcello >
