Hi all,
I'm experimenting problem with the current method used when
authentification fail. If you pass worng authentificatino headre you
are redirected to an html page asking for credention. So technically
we do :
401 - 302 - 200
Which is wrong if we follow the spec. The response MUST include a
We do this on purpose (to prevent browsers prompting for credentials
in a dialog box) but you can include a custom request header to get
the WWW-Authenticate response header.
If you add a header called X-CouchDB-WWW-Authenticate then the value
of that header is returned, verbatim, in
On Tue, Dec 7, 2010 at 11:28 AM, Robert Newson robert.new...@gmail.com wrote:
We do this on purpose (to prevent browsers prompting for credentials
in a dialog box) but you can include a custom request header to get
the WWW-Authenticate response header.
Yes.. What I said. Introducing wrong HTTP
Dear developers,
After going into the theoretical depths[1] of what performance hits
there may be and how replication will be affected, I've decided to
just implement a simple solution and see how far I can get.
I've decided to try to implement a validate_doc_get function, in the
same manner as
On Tue, Dec 7, 2010 at 10:19 AM, Benoit Chesneau bchesn...@gmail.com wrote:
Which is wrong if we follow the spec. The response MUST include a
WWW-Authenticate header field [..] [1] . It also introduce some bugs,
try for example to create a database when not logged.
The reason we use a 302
damn. Some typos. Here is better text
Hi all,
I'm experimenting problem with the current method used when
authentication fail. If you pass authentication headers you are
redirected to an html page asking for credentials. So technically we
do :
401 - 302 - 200
Which is wrong if we follow the
On Tue, Dec 7, 2010 at 1:22 PM, Filipe David Manana fdman...@apache.org wrote:
I'm not a CouchApps developer, so I'm not completely aware of all the
issues involved. Nevertheless, I support your idea.
The issue you describe is related to
https://issues.apache.org/jira/browse/COUCHDB-972 I
[
https://issues.apache.org/jira/browse/COUCHDB-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12968720#action_12968720
]
Benoit Chesneau commented on COUCHDB-972:
-
There is a discussion started today
Hi, the mochiweb we're shipping in 1.1.0 has abandoned support for R12B05, so
we should revisit our minimum required Erlang version. Do we have a compelling
reason for supporting anything below R13B04? That release introduces support
for recursive type specifications, which are useful when
On Tue, Dec 7, 2010 at 5:38 PM, Adam Kocoloski kocol...@apache.org wrote:
Hi, the mochiweb we're shipping in 1.1.0 has abandoned support for R12B05, so
we should revisit our minimum required Erlang version. Do we have a
compelling reason for supporting anything below R13B04? That release
On Dec 7, 2010, at 5:40 PM, Paul Davis wrote:
On Tue, Dec 7, 2010 at 5:38 PM, Adam Kocoloski kocol...@apache.org wrote:
Hi, the mochiweb we're shipping in 1.1.0 has abandoned support for R12B05,
so we should revisit our minimum required Erlang version. Do we have a
compelling reason for
On Tue, Dec 7, 2010 at 5:43 PM, Adam Kocoloski kocol...@apache.org wrote:
On Dec 7, 2010, at 5:40 PM, Paul Davis wrote:
On Tue, Dec 7, 2010 at 5:38 PM, Adam Kocoloski kocol...@apache.org wrote:
Hi, the mochiweb we're shipping in 1.1.0 has abandoned support for R12B05,
so we should revisit
On Tue, Dec 7, 2010 at 5:46 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
On Tue, Dec 7, 2010 at 5:43 PM, Adam Kocoloski kocol...@apache.org wrote:
On Dec 7, 2010, at 5:40 PM, Paul Davis wrote:
On Tue, Dec 7, 2010 at 5:38 PM, Adam Kocoloski kocol...@apache.org wrote:
Hi, the mochiweb
+1 for R13B04.
On Tue, Dec 7, 2010 at 10:53 PM, Paul Davis paul.joseph.da...@gmail.com wrote:
On Tue, Dec 7, 2010 at 5:46 PM, Paul Davis paul.joseph.da...@gmail.com
wrote:
On Tue, Dec 7, 2010 at 5:43 PM, Adam Kocoloski kocol...@apache.org wrote:
On Dec 7, 2010, at 5:40 PM, Paul Davis wrote:
Not to hijack the thread but the Mochiweb upgrade also makes eunit a
build dependency which has caused issues on Debian installs (eunit
being a separate and optional package).
On Tue, Dec 7, 2010 at 11:03 PM, Robert Newson robert.new...@gmail.com wrote:
+1 for R13B04.
On Tue, Dec 7, 2010 at
On 8 Dec 2010, at 00:05, Robert Newson wrote:
Not to hijack the thread but the Mochiweb upgrade also makes eunit a
build dependency which has caused issues on Debian installs (eunit
being a separate and optional package).
Didn't you propose a patch to mochiweb that makes eunit
I did and it was rewritten upstream
(https://github.com/mochi/mochiweb/commit/e8156a1c44d054f1f6e9396c828751ed22418d7f).
It's after the release we have so we have a few options;
1) Upgrade to a newer version.
2) Backport the patch.
3) Add eunit dependency to autotools.
I vote for 3 for 1.1 and
I vote for just deleting the eunit bits in our packaged version. Its
not like we use them. And I'd rather delete the eunit code rather than
grab it as a dependency (and then deal with figuring out what to do
when there's an installed version or not or should be but a distro has
stripped it out).
righto.
On Wed, Dec 8, 2010 at 12:53 AM, Paul Davis paul.joseph.da...@gmail.com wrote:
I vote for just deleting the eunit bits in our packaged version. Its
not like we use them. And I'd rather delete the eunit code rather than
grab it as a dependency (and then deal with figuring out what to do
[
https://issues.apache.org/jira/browse/COUCHDB-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969156#action_12969156
]
Adam Kocoloski commented on COUCHDB-968:
Rebased the 968 branch on my github on
[
https://issues.apache.org/jira/browse/COUCHDB-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski updated COUCHDB-968:
---
Fix Version/s: 1.1
1.0.2
Duplicated IDs in _all_docs
[
https://issues.apache.org/jira/browse/COUCHDB-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski reassigned COUCHDB-968:
--
Assignee: Adam Kocoloski
Duplicated IDs in _all_docs
---
22 matches
Mail list logo
