Being html and json "exactly equally preferable" is not a problem, we only need to find a smarter method to choose between the two.
Ignoring for an instant that this is hard to implement, as Jason says. What is the problem if I send an HTML response, if the requested resource is HTML? Marcello 2011/8/16 Robert Newson <rnew...@apache.org>: > Talk of 'following the standard' while preserving the behavior of > returning a 302 for an unauthorized request is contradictory. We're > deliberately not following the standard 401 response here because the > universal user agent behavior we'd get is unpalatable. > > Following the standard for content-type negotiation is still broken > for browsers (like IE) that regard html and json as exactly equally > preferable. We could just agree that this negotiation is broken on IE > and follow the original proposal in the ticket (to account for > q-values correctly). I've no idea if that's acceptable but it doesn't > sound likely. > > B. > > On 16 August 2011 16:47, Marcello Nuccio <marcello.nuc...@gmail.com> wrote: >> 2011/8/16 Jason Smith <j...@iriscouch.com>: >>> On Tue, Aug 16, 2011 at 9:30 PM, Marcello Nuccio >>> <marcello.nuc...@gmail.com> wrote: >>>> Since sketch.png is available only as "image/png", Apache responds >>>> with "image/png" even if "image/jpeg" is preferred according to the >>>> Accept header. >>>> >>>>>> This is what I do if the user is authenticated, and I see no reason >>>>>> for not doing it when the response is a 401. >>>>> >>>>> i don't follow. how it is related? >>>> >>>> >>>> I ask to apply the same logic whatever the status code of the >>>> response. If when the response is "200 OK" the content-type is >>>> "text/html", then why not respond with the same content-type for a >>>> "401 Unauthorized" response? >>>> >>>> Obviously the content will be different (an html login form for the 401). >>> >>> Did you see my previous two emails? Quick summary: >>> >>> 1. That is not the standard. IMHO, if CouchDB should change, it should >>> change toward the standard. >>> 2. Regardless of #1, it is hard to implement. The example of a public >>> image is not the question. The question is you request *something* but >>> you do not have permission. How should Couch respond? To me, the >>> answer is becoming very clear: obey the client Accept header. If the >>> client explicitly asks for HTML, send a 302 bounce; otherwise send 401 >>> JSON. If that breaks futon or some applications, we can fix those >>> as-needed once and for all. >> >> Saying it is hard to implement could be enough reason for not doing >> it. However it would be great to first find the "right" solution, and >> then say "ok, maybe some day we could do it, but for now the best >> workaround is...". >> >> Why do you say it is not the standard? >> I am NOT saying to ignore the Accept header. Nothing of what I have >> said makes CouchDB less standard compliant. >> >> Sending 302 instead of 401, is not more standard-compliant than >> sending 401 with the correct content-type. >> >> Sorry, but I think I am missing something obvious... >> >> Marcello >> >
