couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Shattuck <>
Subject Re: to CouchApp or not to CouchApp
Date Tue, 16 Aug 2011 18:02:35 GMT
On Tue, Aug 16, 2011 at 11:55 AM, Jens Alfke <> 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.


> 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.


> - 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.


View raw message