[
https://issues.apache.org/jira/browse/COUCHDB-968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969158#action_12969158
]
Adam Kocoloski commented on COUCHDB-968:
I'll commit this tomorrow if no one objec
[
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
> ---
>
[
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:comment-tabpanel&focusedCommentId=12969156#action_12969156
]
Adam Kocoloski commented on COUCHDB-968:
Rebased the 968 branch on my github on to
righto.
On Wed, Dec 8, 2010 at 12:53 AM, Paul Davis 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
> when there's an instal
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).
O
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 t
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 build-option
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 wrote:
> +1 for R13B04.
>
> On Tue, Dec 7, 2010 at 10:53 PM, Paul Davis
+1 for R13B04.
On Tue, Dec 7, 2010 at 10:53 PM, Paul Davis wrote:
> On Tue, Dec 7, 2010 at 5:46 PM, Paul Davis
> wrote:
>> On Tue, Dec 7, 2010 at 5:43 PM, Adam Kocoloski wrote:
>>> On Dec 7, 2010, at 5:40 PM, Paul Davis wrote:
>>>
On Tue, Dec 7, 2010 at 5:38 PM, Adam Kocoloski wrote:
>>>
On Tue, Dec 7, 2010 at 5:46 PM, Paul Davis wrote:
> On Tue, Dec 7, 2010 at 5:43 PM, Adam Kocoloski wrote:
>> On Dec 7, 2010, at 5:40 PM, Paul Davis wrote:
>>
>>> On Tue, Dec 7, 2010 at 5:38 PM, Adam Kocoloski wrote:
Hi, the mochiweb we're shipping in 1.1.0 has abandoned support for R12B05,
On Tue, Dec 7, 2010 at 5:43 PM, Adam Kocoloski wrote:
> On Dec 7, 2010, at 5:40 PM, Paul Davis wrote:
>
>> On Tue, Dec 7, 2010 at 5:38 PM, Adam Kocoloski wrote:
>>> Hi, the mochiweb we're shipping in 1.1.0 has abandoned support for R12B05,
>>> so we should revisit our minimum required Erlang ver
On Dec 7, 2010, at 5:40 PM, Paul Davis wrote:
> On Tue, Dec 7, 2010 at 5:38 PM, Adam Kocoloski 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 anyt
On Tue, Dec 7, 2010 at 5:38 PM, Adam Kocoloski 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
> introduces suppo
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 des
[
https://issues.apache.org/jira/browse/COUCHDB-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968789#action_12968789
]
Filipe Manana commented on COUCHDB-687:
---
Hi Juuso,
Again, thanks for your efforts.
[
https://issues.apache.org/jira/browse/COUCHDB-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968720#action_12968720
]
Benoit Chesneau commented on COUCHDB-972:
-
There is a discussion started today abo
On Tue, Dec 7, 2010 at 1:22 PM, Filipe David Manana 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 think.
>
Ah! indee
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 th
On Tue, Dec 7, 2010 at 10:19 AM, Benoit Chesneau 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 actually is for c
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 11:28 AM, Robert Newson 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 response is plainly
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 WWW-Authentic
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
24 matches
Mail list logo