couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <>
Subject Re: to CouchApp or not to CouchApp
Date Tue, 16 Aug 2011 17:55:55 GMT

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

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message