On Tue, Aug 16, 2011 at 11:55 AM, Jens Alfke <j...@couchbase.com> wrote: > > On Aug 16, 2011, at 9:52 AM, Marcello Nuccio wrote: > > But, by default, CouchDB does not send the WWW-Authenticate header, > and no one has asked to change this default. > > Actually I do think that should be changed, I just hadn’t asked for it. I > lost a couple of hours trying to figure out why I couldn’t get auth to work > on my server, until someone told me I had to edit the config file to get > correct behavior. >
+1 > > On Aug 16, 2011, at 10:41 AM, Robert Newson wrote: > > You said 'what is not standard' and I told you. Not sending the header > for a 401 is response is not standard (the standard says we MUST send > it). > > We cannot follow the standard here, we are going to have to find some > compromise heuristic. > > IMHO the best behavior is: > > - CouchDB intrinsically returns a 401, with the required WWW-Authenticate > header. That is the correct HTTP behavior when the client is trying to access > a read-protected resource without being authenticated. > +1 > - There would be some way for a CouchApp to intercept and override this > response, so that it can instead return a custom response such as a 302 > redirect to its own login page. > > Returning a 302 rather than a 401 is prioritizing the app-server usage of > CouchDB over the REST/database server usage, and I think that’s backwards. I > agree with prior messages in this thread that CouchApps are nifty but > limited, and we shouldn’t be breaking regular HTTP behavior in the server > just so that CouchApps can show fancy login pages. > Exactly. Just as any other CouchDB client code would have to. CouchApp shouldn't be "special" in any way, and certainly shouldn't impact how other clients see the DB. ss
