2011/8/16 Jens Alfke <j...@couchbase.com>: > > 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 I thought this default was there for a good reason, but if there's no problem to change it, then follow the standard. > 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. +1 The only problem I see is: How does it know (the couchapp) what to do? May be that this simply shifts the problem from the server to the couchapp... the problem of the heuristic to use is still here... > 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. ok. Marcello
