[jira] Commented: (COUCHDB-815) Non-standard HTTP methods for view handlers (AKA WebDAV is b0rken) [PATCH]
[
https://issues.apache.org/jira/browse/COUCHDB-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885118#action_12885118
]
Jason Smith commented on COUCHDB-815:
-
A workaround if you have admin access is to make an Erlang design document with
a show function to define those atoms:
{
_id: _design/enable_dav,
usage: curl localhost:5984/dav/_design/enable_dav/_show/add_atoms,
language: erlang,
shows: {
add_atoms: fun(Doc, {Req}) -
'PROPFIND', 'PROPPATCH', 'MKCOL', 'COPY', 'MOVE',
'LOCK', 'UNLOCK',
{[{\body\, \WebDAV enabled\\n\}]}
end.
}
}
And then you hit the view once per VM execution.
Non-standard HTTP methods for view handlers (AKA WebDAV is b0rken) [PATCH]
--
Key: COUCHDB-815
URL: https://issues.apache.org/jira/browse/COUCHDB-815
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.0
Reporter: Jason Smith
Priority: Minor
Attachments: bad_allow_any_http_method.patch
CouchDB prevents the new view server handler methods, _show, _update, etc.
from handling unknown HTTP methods. This prevents Couch apps from being able
to implement extensions to the HTTP specification or to add
application-specific methods to HTTP, violating the spirit of _show and
_update.
For example, it is not possible to make a CouchApp WebDAV server because
_show and _list must support the PROPFIND method.
In couch_httpd:handle_request_int/5, the response from Mochi is coerced to an
atom if and only if the atom already exists (using
couch_util:to_existing_atom/1). That is an odd whitelist, to say the least:
$ curl localhost:5984 -X PROPFIND # Crashes mochiweb when
to_existing_atom throws badarg
curl: (52) Empty reply from server
$ curl localhost:5984 -X list_to_binary # Any atom works
{error:method_not_allowed,reason:Only GET,HEAD allowed}
Considering the cURL commands above, I filed this as a bug, not a feature. I
will explore some options and submit patches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-815) Non-standard HTTP methods for view handlers (AKA WebDAV is b0rken) [PATCH]
[
https://issues.apache.org/jira/browse/COUCHDB-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Smith updated COUCHDB-815:
Attachment: allow_http_method_convert_to_binary.patch
Upon further investigation, I believe there is a bug in
couch_util:to_existing_atom. The comment says that it will return the original
value if no atom exists. But why does it throw an exception then?
The attached patch properly catches the error:badarg thrown by the
*_to_existing_atom BIFs. This allows the method parameter to remain a string
Unfortunately, methods of string (list) type are converted to a
list-of-integers when sending to the view server. Therefore
couch_httpd_external:json_req_obj must go ahead and
I like this patch:
* It does as little as possible at the early stage, when the request comes in
* It does not convert unknown requests to atoms--pattern matching will keep
them away from existing code
* Yet it correctly forwards unknown methods to the view server _show et al
whether standard or not
Non-standard HTTP methods for view handlers (AKA WebDAV is b0rken) [PATCH]
--
Key: COUCHDB-815
URL: https://issues.apache.org/jira/browse/COUCHDB-815
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.0
Reporter: Jason Smith
Priority: Minor
Attachments: allow_http_method_convert_to_binary.patch,
bad_allow_any_http_method.patch
CouchDB prevents the new view server handler methods, _show, _update, etc.
from handling unknown HTTP methods. This prevents Couch apps from being able
to implement extensions to the HTTP specification or to add
application-specific methods to HTTP, violating the spirit of _show and
_update.
For example, it is not possible to make a CouchApp WebDAV server because
_show and _list must support the PROPFIND method.
In couch_httpd:handle_request_int/5, the response from Mochi is coerced to an
atom if and only if the atom already exists (using
couch_util:to_existing_atom/1). That is an odd whitelist, to say the least:
$ curl localhost:5984 -X PROPFIND # Crashes mochiweb when
to_existing_atom throws badarg
curl: (52) Empty reply from server
$ curl localhost:5984 -X list_to_binary # Any atom works
{error:method_not_allowed,reason:Only GET,HEAD allowed}
Considering the cURL commands above, I filed this as a bug, not a feature. I
will explore some options and submit patches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[
https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885235#action_12885235
]
Jochen Kempf commented on COUCHDB-720:
--
Here are the details of my system configuration in order to help you reproduce
the issue:
- Remote Machine: Ubuntu 10.04 Server, Nginx Webserver with SSL (self signed
certificate and applying this configuration:
http://www.friendpaste.com/2VzN9vD63KV6JDUWQdIT1X), CouchDB 0.11, CouchDB
Lucene -0.6.0, CouchDB Authentication is disabled by setting the null
authentication handler
- Local Machine: Ubuntu 9.10, CouchDB 0.11
Databases to be replicated must have at least one design document to trigger
the issue. I would recommend to trigger a pull replication on the local machine
with the remote DB having the design document and the local machine not. Then
the replication process should freeze once the desing document on the remote
machine is hit.
I used the full url syntax for replication (both in Futon and console):
{target: http://user:passw...@localhost:5984/db;, source:
http://user:passw...@remote/db} - thus the remote machine directly redirects
to the 5984 port without need to specify it.
I hope you can reproduce and fix that issue before the 1.0 release as I really
cannot use CouchDB in my application due to that issue.
Thanks for your help!
Pull replication fails due to 401 Authentication required while push
replication works fine
-
Key: COUCHDB-720
URL: https://issues.apache.org/jira/browse/COUCHDB-720
Project: CouchDB
Issue Type: Bug
Components: Futon, HTTP Interface, Replication
Affects Versions: 0.10.1, 0.11
Environment: Remote server having Nginx reverse proxy and basic
authentication enabled
Reporter: Jochen Kempf
Priority: Blocker
Pull replication fails using both Futon Replicator and http request throwing
an 401 Authentication required error. This just happens when design
documents are existent.
Push replication on the other hand works fine.
See used code here: http://gist.github.com/364072
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-816) Futon's Temp View and View output automatically sets descending=true with nothing to let the user know this is the case. Expose query url in the UI to clarify.
Futon's Temp View and View output automatically sets descending=true with nothing to let the user know this is the case. Expose query url in the UI to clarify. --- Key: COUCHDB-816 URL: https://issues.apache.org/jira/browse/COUCHDB-816 Project: CouchDB Issue Type: Improvement Components: Futon Affects Versions: 0.11 Environment: Mac OS X 10.6.4, Google Chrome 5.0.375.55 Reporter: Adam Venturella Priority: Minor Propose to provide feedback to the user with the query url that was used to generate the output or set Futon to output as querying a view would output. Additionally, clicking the chevron in the upper right of Futon when displaying a view/temp view shows the raw output, but it shows it as it would be returned by querying the view not through Futon. In all the Futon UI has a bit of bi-polar disorder in the consistency which it displays it's information as it relates to views and temp views =) A really fancy, definitely more work, pie in the sky solution would be to provide configurable query string options when running the view/temp view. Really though, just showing the query that was actually run to generate the results (with the query options) would be a great first step. This would expose that descending is set to true which can then be taken into account if, for example, you are writing a list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
delayed_commits false
Hi All, delayed_commits were enabled to have better performance especially for single writers. The price you pay for is that you potentially lose up to one second of writes in case of a crash. Such a setting makes sense, though in my opinion it shouldn't be enabled by default. I expect* that people running into performance issues at least take a look at the README or a FAQ section somewhere. There the delayed_commit setting could be pointed out. I'd like to be able to say that on a vanilla CouchDB it's hard to lose data, but I can't atm. I'm also well aware that there will be plenty of performance tests when 1.0 is released and people will complain (if delayed_commits would be set to false by default) that it is horrible slow. Though safety of the data is more important for me. If the only reason why delayed_commits is true by default are the performance tests of some noobs, I really don't think it's a price worth paying. *I know that in reality people don't I would like to see delayed_commits=false for 1.0 Cheers, Volker
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[
https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885270#action_12885270
]
Klaus Trainer commented on COUCHDB-720:
---
Hi Couchers!
On my CouchDB 0.10.0 instance delivered with Ubuntu 10.04 amd64 I experience
the same pull replication problem (although I don't use a proxy or SSL etc.) in
the case I have an [admins] -entry (for instance admin = secret) in the
config file.
In my configuration, only the [httpd] port and the [admins] entry differ from
the original (i.e., default) CouchDB configuration.
The thing is that with that configuration all tests succeed, except the oauth
and the replication one.
For instance, when replicating, I get the following output:
kla...@devil:~$ curl -vX POST http://admin:sec...@127.0.0.1:5991/_replicate -d
'{source:test_suite_db_a,target:http://127.0.0.1:5991/test_suite_db_b}'
* About to connect() to 127.0.0.1 port 5991 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 5991 (#0)
* Server auth using Basic with user 'admin'
POST /_replicate HTTP/1.1
Authorization: Basic YWRtaW46c2VjcmV0
User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k
zlib/1.2.3.3 libidn/1.15
Host: 127.0.0.1:5991
Accept: */*
Content-Length: 77
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: CouchDB/0.10.0 (Erlang OTP/R13B)
Date: Mon, 05 Jul 2010 16:15:13 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 378
Cache-Control: must-revalidate
{ok:true,session_id:280fe9ab1efeff12017da569ec443edf,source_last_seq:17,history:[{session_id:280fe9ab1efeff12017da569ec443edf,start_time:Mon,
05 Jul 2010 16:15:13 GMT,end_time:Mon, 05 Jul 2010 16:15:13
GMT,start_last_seq:0,end_last_seq:17,recorded_seq:17,missing_checked:0,missing_found:2,docs_read:2,docs_written:0,doc_write_failures:2}]}
(Just to clarify, it's basically the same output I see in Firebug when running
the Test Suite's replication test. Everything replicates fine, except _design
documents.)
When removing the [admins] entry from the config file, everything, including
replication of _design documents, works well:
kla...@devil:~$ curl -vX POST http://127.0.0.1:5991/_replicate -d
'{source:test_suite_db_a,target:http://127.0.0.1:5991/test_suite_db_b}'
* About to connect() to 127.0.0.1 port 5991 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 5991 (#0)
POST /_replicate HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k
zlib/1.2.3.3 libidn/1.15
Host: 127.0.0.1:5991
Accept: */*
Content-Length: 77
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: CouchDB/0.10.0 (Erlang OTP/R13B)
Date: Mon, 05 Jul 2010 16:19:37 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 378
Cache-Control: must-revalidate
{ok:true,session_id:220e214ea84bc5fe8c123e41db372fec,source_last_seq:17,history:[{session_id:220e214ea84bc5fe8c123e41db372fec,start_time:Mon,
05 Jul 2010 16:19:37 GMT,end_time:Mon, 05 Jul 2010 16:19:37
GMT,start_last_seq:0,end_last_seq:17,recorded_seq:17,missing_checked:0,missing_found:2,docs_read:2,docs_written:2,doc_write_failures:0}]}
I don't believe that this behavior is correct. Although my configuration is
different, I suppose it to be related to the present ticket.
Pull replication fails due to 401 Authentication required while push
replication works fine
-
Key: COUCHDB-720
URL: https://issues.apache.org/jira/browse/COUCHDB-720
Project: CouchDB
Issue Type: Bug
Components: Futon, HTTP Interface, Replication
Affects Versions: 0.10.1, 0.11
Environment: Remote server having Nginx reverse proxy and basic
authentication enabled
Reporter: Jochen Kempf
Priority: Blocker
Pull replication fails using both Futon Replicator and http request throwing
an 401 Authentication required error. This just happens when design
documents are existent.
Push replication on the other hand works fine.
See used code here: http://gist.github.com/364072
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: delayed_commits false
For the concurrent performance tests I wrote in relaximation it's actually better to run with delayed_commits off because it measures the roundtrip time of all the concurrent clients. The reason it's enabled by default is because of apache-bench and other single writer performance test tools. From what I've seen, it doesn't actually improve write performance under concurrent load and leads to a kind of blocking behavior when you start throwing too many writes at it than it can fsync in a second. The degradation in performance is pretty huge with this blocking in my concurrent tests. I don't know of a lot of good concurrent performance test tools which is why I went and wrote one. But, it only tests CouchDB and people love to pick up one of these tools that tests a bunch of other dbs (poorly) and be like CouchDB is slow because they are using a single writer. But, IMHO it's better to ship with more guarantees about consistency than optimized for crappy perf tools. -Mikeal On Mon, Jul 5, 2010 at 8:49 AM, Volker Mische volker.mis...@gmail.comwrote: Hi All, delayed_commits were enabled to have better performance especially for single writers. The price you pay for is that you potentially lose up to one second of writes in case of a crash. Such a setting makes sense, though in my opinion it shouldn't be enabled by default. I expect* that people running into performance issues at least take a look at the README or a FAQ section somewhere. There the delayed_commit setting could be pointed out. I'd like to be able to say that on a vanilla CouchDB it's hard to lose data, but I can't atm. I'm also well aware that there will be plenty of performance tests when 1.0 is released and people will complain (if delayed_commits would be set to false by default) that it is horrible slow. Though safety of the data is more important for me. If the only reason why delayed_commits is true by default are the performance tests of some noobs, I really don't think it's a price worth paying. *I know that in reality people don't I would like to see delayed_commits=false for 1.0 Cheers, Volker
Re: delayed_commits false
For a relatively sane look at the tradeoff's we're talking about, this is a good resource: http://developer.postgresql.org/pgdocs/postgres/runtime-config-wal.html I wish it was simple to write a heuristic which would detect single serialized client workloads, and delay commits, but I don't think it is. I lean (slightly) toward leaving delayed_commits = true because the worst case scenario, even in the case of a crash, isn't data corruption, just lost data from the most recent activity. It is also worth noting that there is an API to ensure_full_commit aside from the configuration value, so if you have high-value data you are writing, you can call ensure_full_commit (or use a header value to make the last PUT or POST operation force full commit) I think this is worth discussing. I'm not strongly in favor of the delayed_commit=true setting, but I do think it is slightly more user-friendly... Chris On Jul 5, 2010, at 10:02 AM, Mikeal Rogers wrote: For the concurrent performance tests I wrote in relaximation it's actually better to run with delayed_commits off because it measures the roundtrip time of all the concurrent clients. The reason it's enabled by default is because of apache-bench and other single writer performance test tools. From what I've seen, it doesn't actually improve write performance under concurrent load and leads to a kind of blocking behavior when you start throwing too many writes at it than it can fsync in a second. The degradation in performance is pretty huge with this blocking in my concurrent tests. I don't know of a lot of good concurrent performance test tools which is why I went and wrote one. But, it only tests CouchDB and people love to pick up one of these tools that tests a bunch of other dbs (poorly) and be like CouchDB is slow because they are using a single writer. But, IMHO it's better to ship with more guarantees about consistency than optimized for crappy perf tools. -Mikeal On Mon, Jul 5, 2010 at 8:49 AM, Volker Mische volker.mis...@gmail.comwrote: Hi All, delayed_commits were enabled to have better performance especially for single writers. The price you pay for is that you potentially lose up to one second of writes in case of a crash. Such a setting makes sense, though in my opinion it shouldn't be enabled by default. I expect* that people running into performance issues at least take a look at the README or a FAQ section somewhere. There the delayed_commit setting could be pointed out. I'd like to be able to say that on a vanilla CouchDB it's hard to lose data, but I can't atm. I'm also well aware that there will be plenty of performance tests when 1.0 is released and people will complain (if delayed_commits would be set to false by default) that it is horrible slow. Though safety of the data is more important for me. If the only reason why delayed_commits is true by default are the performance tests of some noobs, I really don't think it's a price worth paying. *I know that in reality people don't I would like to see delayed_commits=false for 1.0 Cheers, Volker
Re: delayed_commits false
The more I think about this the more I think we need to write up some specific use cases and ideal configurations for each. For DesktopCouch and maybe even mobile CouchDB builds that tend to support a couple clients talking to one database each delayed-commits is a better user experience. But, delayed-commits is currently terrible for a production multi-user CouchDB. The more features we add the bigger a problem this will become. I really don't want to end up with a page like the one Postgres has with a bunch of technical points about config options. I think we should target use cases and write up ideal configurations for those users. -Mikeal On Mon, Jul 5, 2010 at 11:17 AM, J Chris Anderson jch...@gmail.com wrote: For a relatively sane look at the tradeoff's we're talking about, this is a good resource: http://developer.postgresql.org/pgdocs/postgres/runtime-config-wal.html I wish it was simple to write a heuristic which would detect single serialized client workloads, and delay commits, but I don't think it is. I lean (slightly) toward leaving delayed_commits = true because the worst case scenario, even in the case of a crash, isn't data corruption, just lost data from the most recent activity. It is also worth noting that there is an API to ensure_full_commit aside from the configuration value, so if you have high-value data you are writing, you can call ensure_full_commit (or use a header value to make the last PUT or POST operation force full commit) I think this is worth discussing. I'm not strongly in favor of the delayed_commit=true setting, but I do think it is slightly more user-friendly... Chris On Jul 5, 2010, at 10:02 AM, Mikeal Rogers wrote: For the concurrent performance tests I wrote in relaximation it's actually better to run with delayed_commits off because it measures the roundtrip time of all the concurrent clients. The reason it's enabled by default is because of apache-bench and other single writer performance test tools. From what I've seen, it doesn't actually improve write performance under concurrent load and leads to a kind of blocking behavior when you start throwing too many writes at it than it can fsync in a second. The degradation in performance is pretty huge with this blocking in my concurrent tests. I don't know of a lot of good concurrent performance test tools which is why I went and wrote one. But, it only tests CouchDB and people love to pick up one of these tools that tests a bunch of other dbs (poorly) and be like CouchDB is slow because they are using a single writer. But, IMHO it's better to ship with more guarantees about consistency than optimized for crappy perf tools. -Mikeal On Mon, Jul 5, 2010 at 8:49 AM, Volker Mische volker.mis...@gmail.com wrote: Hi All, delayed_commits were enabled to have better performance especially for single writers. The price you pay for is that you potentially lose up to one second of writes in case of a crash. Such a setting makes sense, though in my opinion it shouldn't be enabled by default. I expect* that people running into performance issues at least take a look at the README or a FAQ section somewhere. There the delayed_commit setting could be pointed out. I'd like to be able to say that on a vanilla CouchDB it's hard to lose data, but I can't atm. I'm also well aware that there will be plenty of performance tests when 1.0 is released and people will complain (if delayed_commits would be set to false by default) that it is horrible slow. Though safety of the data is more important for me. If the only reason why delayed_commits is true by default are the performance tests of some noobs, I really don't think it's a price worth paying. *I know that in reality people don't I would like to see delayed_commits=false for 1.0 Cheers, Volker
Re: 1.0 Vote
+1 All tests, JavaScript and Etap, are passing for me (Mac OS X 10.6 and Mandriva GNU/Linux). On Sat, Jul 3, 2010 at 4:41 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:13 AM, Jan Lehnardt j...@apache.org wrote: On 29 Jun 2010, at 16:38, Noah Slater wrote: On 29 Jun 2010, at 15:20, J Chris Anderson wrote: So I went through both trunk and 0.11.x looking for things that are out of place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is ready for release. For trunk, I think there are a couple of small patches that Adam wants to hold back for 1.1. There is also the Windows stuff, which looks like we should wait for, before cutting 1.0. I am waiting for a go command, so just let me know. Please can everyone check that make distcheck is working for them. Let's try to avoid the test failures again for this release. Works for me on 0.11.x and trunk and Mac OS X 10.6.4 and Ubuntu Karmic. Would love to see more people sending in results here :) Cheers Jan -- works for me on openbsd 4.7-current (erlang R13b04), macosx 10.6.4 (erlang R13b04 R14a) and ubuntu lucid (erlang R13b04), - benoit -- Filipe David Manana, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
Re: 1.0 Vote
+1 for trunk (0.12.0a64d82c8-git), OS X 10.6.4, Erlang R13B04 All tests are passing. On 05.07.2010, at 21:37, Filipe David Manana wrote: +1 All tests, JavaScript and Etap, are passing for me (Mac OS X 10.6 and Mandriva GNU/Linux). On Sat, Jul 3, 2010 at 4:41 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:13 AM, Jan Lehnardt j...@apache.org wrote: On 29 Jun 2010, at 16:38, Noah Slater wrote: On 29 Jun 2010, at 15:20, J Chris Anderson wrote: So I went through both trunk and 0.11.x looking for things that are out of place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is ready for release. For trunk, I think there are a couple of small patches that Adam wants to hold back for 1.1. There is also the Windows stuff, which looks like we should wait for, before cutting 1.0. I am waiting for a go command, so just let me know. Please can everyone check that make distcheck is working for them. Let's try to avoid the test failures again for this release. Works for me on 0.11.x and trunk and Mac OS X 10.6.4 and Ubuntu Karmic. Would love to see more people sending in results here :) Cheers Jan -- works for me on openbsd 4.7-current (erlang R13b04), macosx 10.6.4 (erlang R13b04 R14a) and ubuntu lucid (erlang R13b04), - benoit -- Filipe David Manana, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
Re: 1.0 Vote
I'd like to suggest we resolve this ticket before 1.0, so that replication works as advertised. https://issues.apache.org/jira/browse/COUCHDB-720 Hopefully it will be easy. Has anyone started digging into it yet? Chris On Jul 5, 2010, at 1:19 PM, Sebastian Cohnen wrote: +1 for trunk (0.12.0a64d82c8-git), OS X 10.6.4, Erlang R13B04 All tests are passing. On 05.07.2010, at 21:37, Filipe David Manana wrote: +1 All tests, JavaScript and Etap, are passing for me (Mac OS X 10.6 and Mandriva GNU/Linux). On Sat, Jul 3, 2010 at 4:41 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:13 AM, Jan Lehnardt j...@apache.org wrote: On 29 Jun 2010, at 16:38, Noah Slater wrote: On 29 Jun 2010, at 15:20, J Chris Anderson wrote: So I went through both trunk and 0.11.x looking for things that are out of place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is ready for release. For trunk, I think there are a couple of small patches that Adam wants to hold back for 1.1. There is also the Windows stuff, which looks like we should wait for, before cutting 1.0. I am waiting for a go command, so just let me know. Please can everyone check that make distcheck is working for them. Let's try to avoid the test failures again for this release. Works for me on 0.11.x and trunk and Mac OS X 10.6.4 and Ubuntu Karmic. Would love to see more people sending in results here :) Cheers Jan -- works for me on openbsd 4.7-current (erlang R13b04), macosx 10.6.4 (erlang R13b04 R14a) and ubuntu lucid (erlang R13b04), - benoit -- Filipe David Manana, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
Re: 1.0 Vote
Can someone create a failing test? Reading the comments on COUCHDB-720, I'm not sure if there is actually a bug, or it's just a config issue. -Damien On Jul 5, 2010, at 2:04 PM, J Chris Anderson wrote: I'd like to suggest we resolve this ticket before 1.0, so that replication works as advertised. https://issues.apache.org/jira/browse/COUCHDB-720 Hopefully it will be easy. Has anyone started digging into it yet? Chris On Jul 5, 2010, at 1:19 PM, Sebastian Cohnen wrote: +1 for trunk (0.12.0a64d82c8-git), OS X 10.6.4, Erlang R13B04 All tests are passing. On 05.07.2010, at 21:37, Filipe David Manana wrote: +1 All tests, JavaScript and Etap, are passing for me (Mac OS X 10.6 and Mandriva GNU/Linux). On Sat, Jul 3, 2010 at 4:41 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:13 AM, Jan Lehnardt j...@apache.org wrote: On 29 Jun 2010, at 16:38, Noah Slater wrote: On 29 Jun 2010, at 15:20, J Chris Anderson wrote: So I went through both trunk and 0.11.x looking for things that are out of place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is ready for release. For trunk, I think there are a couple of small patches that Adam wants to hold back for 1.1. There is also the Windows stuff, which looks like we should wait for, before cutting 1.0. I am waiting for a go command, so just let me know. Please can everyone check that make distcheck is working for them. Let's try to avoid the test failures again for this release. Works for me on 0.11.x and trunk and Mac OS X 10.6.4 and Ubuntu Karmic. Would love to see more people sending in results here :) Cheers Jan -- works for me on openbsd 4.7-current (erlang R13b04), macosx 10.6.4 (erlang R13b04 R14a) and ubuntu lucid (erlang R13b04), - benoit -- Filipe David Manana, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
Re: 1.0 Vote
I suspect it's due to nginx's config. On Mon, Jul 5, 2010 at 10:44 PM, Damien Katz dam...@apache.org wrote: Can someone create a failing test? Reading the comments on COUCHDB-720, I'm not sure if there is actually a bug, or it's just a config issue. -Damien On Jul 5, 2010, at 2:04 PM, J Chris Anderson wrote: I'd like to suggest we resolve this ticket before 1.0, so that replication works as advertised. https://issues.apache.org/jira/browse/COUCHDB-720 Hopefully it will be easy. Has anyone started digging into it yet? Chris On Jul 5, 2010, at 1:19 PM, Sebastian Cohnen wrote: +1 for trunk (0.12.0a64d82c8-git), OS X 10.6.4, Erlang R13B04 All tests are passing. On 05.07.2010, at 21:37, Filipe David Manana wrote: +1 All tests, JavaScript and Etap, are passing for me (Mac OS X 10.6 and Mandriva GNU/Linux). On Sat, Jul 3, 2010 at 4:41 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:13 AM, Jan Lehnardt j...@apache.org wrote: On 29 Jun 2010, at 16:38, Noah Slater wrote: On 29 Jun 2010, at 15:20, J Chris Anderson wrote: So I went through both trunk and 0.11.x looking for things that are out of place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is ready for release. For trunk, I think there are a couple of small patches that Adam wants to hold back for 1.1. There is also the Windows stuff, which looks like we should wait for, before cutting 1.0. I am waiting for a go command, so just let me know. Please can everyone check that make distcheck is working for them. Let's try to avoid the test failures again for this release. Works for me on 0.11.x and trunk and Mac OS X 10.6.4 and Ubuntu Karmic. Would love to see more people sending in results here :) Cheers Jan -- works for me on openbsd 4.7-current (erlang R13b04), macosx 10.6.4 (erlang R13b04 R14a) and ubuntu lucid (erlang R13b04), - benoit -- Filipe David Manana, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men. -- Filipe David Manana, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
Re: 1.0 Vote
With version 0.10.0 (I haven't tested it with other versions) it seems to be quite easy to create a failing test. Just set up an admin account the way it is described here: http://wiki.apache.org/couchdb/Setting_up_an_Admin_account If that were a config issue for some reason, we should definitely fix the documentation... Cheers, Klaus On Mon, 2010-07-05 at 14:44 -0700, Damien Katz wrote: Can someone create a failing test? Reading the comments on COUCHDB-720, I'm not sure if there is actually a bug, or it's just a config issue. -Damien On Jul 5, 2010, at 2:04 PM, J Chris Anderson wrote: I'd like to suggest we resolve this ticket before 1.0, so that replication works as advertised. https://issues.apache.org/jira/browse/COUCHDB-720 Hopefully it will be easy. Has anyone started digging into it yet? Chris On Jul 5, 2010, at 1:19 PM, Sebastian Cohnen wrote: +1 for trunk (0.12.0a64d82c8-git), OS X 10.6.4, Erlang R13B04 All tests are passing. On 05.07.2010, at 21:37, Filipe David Manana wrote: +1 All tests, JavaScript and Etap, are passing for me (Mac OS X 10.6 and Mandriva GNU/Linux). On Sat, Jul 3, 2010 at 4:41 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:13 AM, Jan Lehnardt j...@apache.org wrote: On 29 Jun 2010, at 16:38, Noah Slater wrote: On 29 Jun 2010, at 15:20, J Chris Anderson wrote: So I went through both trunk and 0.11.x looking for things that are out of place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is ready for release. For trunk, I think there are a couple of small patches that Adam wants to hold back for 1.1. There is also the Windows stuff, which looks like we should wait for, before cutting 1.0. I am waiting for a go command, so just let me know. Please can everyone check that make distcheck is working for them. Let's try to avoid the test failures again for this release. Works for me on 0.11.x and trunk and Mac OS X 10.6.4 and Ubuntu Karmic. Would love to see more people sending in results here :) Cheers Jan -- works for me on openbsd 4.7-current (erlang R13b04), macosx 10.6.4 (erlang R13b04 R14a) and ubuntu lucid (erlang R13b04), - benoit -- Filipe David Manana, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[ https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885350#action_12885350 ] Filipe Manana commented on COUCHDB-720: --- Jochen, Your friendpaste URL pointing to your nginx config seems to be no longer available. I'm not experienced with nginx, but googling a bit, the following thread might help you: http://www.pubbs.net/200908/nginx/22292-proxycache-when-authorization-http-header-presents.html hope it helps Pull replication fails due to 401 Authentication required while push replication works fine - Key: COUCHDB-720 URL: https://issues.apache.org/jira/browse/COUCHDB-720 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface, Replication Affects Versions: 0.10.1, 0.11 Environment: Remote server having Nginx reverse proxy and basic authentication enabled Reporter: Jochen Kempf Priority: Blocker Pull replication fails using both Futon Replicator and http request throwing an 401 Authentication required error. This just happens when design documents are existent. Push replication on the other hand works fine. See used code here: http://gist.github.com/364072 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 1.0 Vote
Klaus, I've just replied to your comment for ticket 720. Does it solve your problem? On Mon, Jul 5, 2010 at 10:56 PM, Klaus Trainer klaus.trai...@web.de wrote: With version 0.10.0 (I haven't tested it with other versions) it seems to be quite easy to create a failing test. Just set up an admin account the way it is described here: http://wiki.apache.org/couchdb/Setting_up_an_Admin_account If that were a config issue for some reason, we should definitely fix the documentation... Cheers, Klaus On Mon, 2010-07-05 at 14:44 -0700, Damien Katz wrote: Can someone create a failing test? Reading the comments on COUCHDB-720, I'm not sure if there is actually a bug, or it's just a config issue. -Damien On Jul 5, 2010, at 2:04 PM, J Chris Anderson wrote: I'd like to suggest we resolve this ticket before 1.0, so that replication works as advertised. https://issues.apache.org/jira/browse/COUCHDB-720 Hopefully it will be easy. Has anyone started digging into it yet? Chris On Jul 5, 2010, at 1:19 PM, Sebastian Cohnen wrote: +1 for trunk (0.12.0a64d82c8-git), OS X 10.6.4, Erlang R13B04 All tests are passing. On 05.07.2010, at 21:37, Filipe David Manana wrote: +1 All tests, JavaScript and Etap, are passing for me (Mac OS X 10.6 and Mandriva GNU/Linux). On Sat, Jul 3, 2010 at 4:41 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:13 AM, Jan Lehnardt j...@apache.org wrote: On 29 Jun 2010, at 16:38, Noah Slater wrote: On 29 Jun 2010, at 15:20, J Chris Anderson wrote: So I went through both trunk and 0.11.x looking for things that are out of place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is ready for release. For trunk, I think there are a couple of small patches that Adam wants to hold back for 1.1. There is also the Windows stuff, which looks like we should wait for, before cutting 1.0. I am waiting for a go command, so just let me know. Please can everyone check that make distcheck is working for them. Let's try to avoid the test failures again for this release. Works for me on 0.11.x and trunk and Mac OS X 10.6.4 and Ubuntu Karmic. Would love to see more people sending in results here :) Cheers Jan -- works for me on openbsd 4.7-current (erlang R13b04), macosx 10.6.4 (erlang R13b04 R14a) and ubuntu lucid (erlang R13b04), - benoit -- Filipe David Manana, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men. -- Filipe David Manana, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[
https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885351#action_12885351
]
Filipe Manana commented on COUCHDB-720:
---
Klaus,
instead of
kla...@devil:~$ curl -vX POST http://admin:sec...@127.0.0.1:5991/_replicate -d
'{source:test_suite_db_a,target:http://127.0.0.1:5991/test_suite_db_b}'
try
kla...@devil:~$ curl -vX POST http://admin:sec...@127.0.0.1:5991/_replicate -d
'{source:test_suite_db_a,target:http://admin:sec...@127.0.0.1:5991/test_suite_db_b}'
(add user:passwd@ to the target url in the json content)
does it help?
Pull replication fails due to 401 Authentication required while push
replication works fine
-
Key: COUCHDB-720
URL: https://issues.apache.org/jira/browse/COUCHDB-720
Project: CouchDB
Issue Type: Bug
Components: Futon, HTTP Interface, Replication
Affects Versions: 0.10.1, 0.11
Environment: Remote server having Nginx reverse proxy and basic
authentication enabled
Reporter: Jochen Kempf
Priority: Blocker
Pull replication fails using both Futon Replicator and http request throwing
an 401 Authentication required error. This just happens when design
documents are existent.
Push replication on the other hand works fine.
See used code here: http://gist.github.com/364072
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 1.0 Vote
On Jul 5, 2010, at 2:56 PM, Klaus Trainer wrote: With version 0.10.0 (I haven't tested it with other versions) it seems to be quite easy to create a failing test. Can you attach your failing test script to the bug? Then someone else can validate if it's fixed in trunk. Thanks. -Damien Just set up an admin account the way it is described here: http://wiki.apache.org/couchdb/Setting_up_an_Admin_account If that were a config issue for some reason, we should definitely fix the documentation... Cheers, Klaus On Mon, 2010-07-05 at 14:44 -0700, Damien Katz wrote: Can someone create a failing test? Reading the comments on COUCHDB-720, I'm not sure if there is actually a bug, or it's just a config issue. -Damien On Jul 5, 2010, at 2:04 PM, J Chris Anderson wrote: I'd like to suggest we resolve this ticket before 1.0, so that replication works as advertised. https://issues.apache.org/jira/browse/COUCHDB-720 Hopefully it will be easy. Has anyone started digging into it yet? Chris On Jul 5, 2010, at 1:19 PM, Sebastian Cohnen wrote: +1 for trunk (0.12.0a64d82c8-git), OS X 10.6.4, Erlang R13B04 All tests are passing. On 05.07.2010, at 21:37, Filipe David Manana wrote: +1 All tests, JavaScript and Etap, are passing for me (Mac OS X 10.6 and Mandriva GNU/Linux). On Sat, Jul 3, 2010 at 4:41 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:13 AM, Jan Lehnardt j...@apache.org wrote: On 29 Jun 2010, at 16:38, Noah Slater wrote: On 29 Jun 2010, at 15:20, J Chris Anderson wrote: So I went through both trunk and 0.11.x looking for things that are out of place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is ready for release. For trunk, I think there are a couple of small patches that Adam wants to hold back for 1.1. There is also the Windows stuff, which looks like we should wait for, before cutting 1.0. I am waiting for a go command, so just let me know. Please can everyone check that make distcheck is working for them. Let's try to avoid the test failures again for this release. Works for me on 0.11.x and trunk and Mac OS X 10.6.4 and Ubuntu Karmic. Would love to see more people sending in results here :) Cheers Jan -- works for me on openbsd 4.7-current (erlang R13b04), macosx 10.6.4 (erlang R13b04 R14a) and ubuntu lucid (erlang R13b04), - benoit -- Filipe David Manana, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[
https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885352#action_12885352
]
Klaus Trainer commented on COUCHDB-720:
---
Filipe, thanks for the hint! Now that I've tried that it works
I know, you were actually hinting at that previously...
Curiously enough, I don't need to specify authentication neither in the request
URL, nor in the header, as long as I specify it in the JSON body:
kla...@devil:~$ curl -vX POST http://127.0.0.1:5991/_replicate -d
'{source:test_suite_db_a,target:http://admin:sec...@127.0.0.1:5991/test_suite_db_b}'
* About to connect() to 127.0.0.1 port 5991 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 5991 (#0)
POST /_replicate HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k
zlib/1.2.3.3 libidn/1.15
Host: 127.0.0.1:5991
Accept: */*
Content-Length: 90
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: CouchDB/0.10.0 (Erlang OTP/R13B)
Date: Mon, 05 Jul 2010 22:04:35 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 381
Cache-Control: must-revalidate
{ok:true,session_id:3716ed1b266f152ebce117accd073498,source_last_seq:19,history:[{session_id:3716ed1b266f152ebce117accd073498,start_time:Mon,
05 Jul 2010 22:04:35 GMT,end_time:Mon, 05 Jul 2010 22:04:35
GMT,start_last_seq:0,end_last_seq:19,recorded_seq:19,missing_checked:0,missing_found:17,docs_read:17,docs_written:17,doc_write_failures:0}]}
Pull replication fails due to 401 Authentication required while push
replication works fine
-
Key: COUCHDB-720
URL: https://issues.apache.org/jira/browse/COUCHDB-720
Project: CouchDB
Issue Type: Bug
Components: Futon, HTTP Interface, Replication
Affects Versions: 0.10.1, 0.11
Environment: Remote server having Nginx reverse proxy and basic
authentication enabled
Reporter: Jochen Kempf
Priority: Blocker
Pull replication fails using both Futon Replicator and http request throwing
an 401 Authentication required error. This just happens when design
documents are existent.
Push replication on the other hand works fine.
See used code here: http://gist.github.com/364072
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[ https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885356#action_12885356 ] Filipe Manana commented on COUCHDB-720: --- Klaus, great! :) Pull replication fails due to 401 Authentication required while push replication works fine - Key: COUCHDB-720 URL: https://issues.apache.org/jira/browse/COUCHDB-720 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface, Replication Affects Versions: 0.10.1, 0.11 Environment: Remote server having Nginx reverse proxy and basic authentication enabled Reporter: Jochen Kempf Priority: Blocker Pull replication fails using both Futon Replicator and http request throwing an 401 Authentication required error. This just happens when design documents are existent. Push replication on the other hand works fine. See used code here: http://gist.github.com/364072 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[ https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885362#action_12885362 ] Jochen Kempf commented on COUCHDB-720: -- I'll take a look to the nginx proxycache discussion and see if that helps. @Klaus: I already commented the admin line out and additionally deactivated authentication setting the null authentication handler I took a look into the nginx log and here is the same 301 response that freezes replication: 201.215.36.77 - jochen [05/Jul/2010:18:44:18 -0400] GET /mytest/_local%2F4eddf88684f747f720130295073f965a HTTP/1.1 200 426 - CouchDB/0.11.0 201.215.36.77 - jochen [05/Jul/2010:18:44:19 -0400] GET /mytest/_changes?style=all_docsheartbeat=1since=4feed=normal HTTP/1.1 200 145 - CouchDB/0.11.0 201.215.36.77 - jochen [05/Jul/2010:18:44:20 -0400] GET /mytest/_design%2Ftest?open_revs=[\x221-967a00dff5e02add41819138abb3284d\x22]revs=truelatest=true HTTP/1.1 301 0 - CouchDB/0.11.0 Here is a link showing my nginx configuration: http://gist.github.com/464797 I still cannot successfully do pull replications! Pull replication fails due to 401 Authentication required while push replication works fine - Key: COUCHDB-720 URL: https://issues.apache.org/jira/browse/COUCHDB-720 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface, Replication Affects Versions: 0.10.1, 0.11 Environment: Remote server having Nginx reverse proxy and basic authentication enabled Reporter: Jochen Kempf Priority: Blocker Pull replication fails using both Futon Replicator and http request throwing an 401 Authentication required error. This just happens when design documents are existent. Push replication on the other hand works fine. See used code here: http://gist.github.com/364072 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-817) Natively support coffeescript
Natively support coffeescript - Key: COUCHDB-817 URL: https://issues.apache.org/jira/browse/COUCHDB-817 Project: CouchDB Issue Type: New Feature Reporter: Matt Parker i'd love to be able to put coffeescript map and reduce function/files directly into my ddoc, instead of having to compile them first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 1.0 Vote
Hi Damien, I've finally succeeded running CouchDB from trunk (after having to solve some invalid UTF-8 JSON and LD_LIBRARY_PATH problems) and all tests pass successfully :) The issue I have with version 0.10.0 does not exist in trunk anymore, since when running tests from the Test Suite, CouchDB will be put in Admin Party mode, i.e., all admin accounts are removed from the configuration. Cheers, Klaus On Mon, 2010-07-05 at 15:00 -0700, Damien Katz wrote: On Jul 5, 2010, at 2:56 PM, Klaus Trainer wrote: With version 0.10.0 (I haven't tested it with other versions) it seems to be quite easy to create a failing test. Can you attach your failing test script to the bug? Then someone else can validate if it's fixed in trunk. Thanks. -Damien Just set up an admin account the way it is described here: http://wiki.apache.org/couchdb/Setting_up_an_Admin_account If that were a config issue for some reason, we should definitely fix the documentation... Cheers, Klaus On Mon, 2010-07-05 at 14:44 -0700, Damien Katz wrote: Can someone create a failing test? Reading the comments on COUCHDB-720, I'm not sure if there is actually a bug, or it's just a config issue. -Damien On Jul 5, 2010, at 2:04 PM, J Chris Anderson wrote: I'd like to suggest we resolve this ticket before 1.0, so that replication works as advertised. https://issues.apache.org/jira/browse/COUCHDB-720 Hopefully it will be easy. Has anyone started digging into it yet? Chris On Jul 5, 2010, at 1:19 PM, Sebastian Cohnen wrote: +1 for trunk (0.12.0a64d82c8-git), OS X 10.6.4, Erlang R13B04 All tests are passing. On 05.07.2010, at 21:37, Filipe David Manana wrote: +1 All tests, JavaScript and Etap, are passing for me (Mac OS X 10.6 and Mandriva GNU/Linux). On Sat, Jul 3, 2010 at 4:41 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Sat, Jul 3, 2010 at 1:13 AM, Jan Lehnardt j...@apache.org wrote: On 29 Jun 2010, at 16:38, Noah Slater wrote: On 29 Jun 2010, at 15:20, J Chris Anderson wrote: So I went through both trunk and 0.11.x looking for things that are out of place. I fixed one small thing in 0.11.x, and as far as I'm concerned it is ready for release. For trunk, I think there are a couple of small patches that Adam wants to hold back for 1.1. There is also the Windows stuff, which looks like we should wait for, before cutting 1.0. I am waiting for a go command, so just let me know. Please can everyone check that make distcheck is working for them. Let's try to avoid the test failures again for this release. Works for me on 0.11.x and trunk and Mac OS X 10.6.4 and Ubuntu Karmic. Would love to see more people sending in results here :) Cheers Jan -- works for me on openbsd 4.7-current (erlang R13b04), macosx 10.6.4 (erlang R13b04 R14a) and ubuntu lucid (erlang R13b04), - benoit -- Filipe David Manana, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[ https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885379#action_12885379 ] Randall Leeds commented on COUCHDB-720: --- I believe the problem is that ibrowse does not specify basic auth headers automatically and couch_rep_httpc has to parse the url and add the appropriate options. I'm doing this work right now and will add info when I have it. Pull replication fails due to 401 Authentication required while push replication works fine - Key: COUCHDB-720 URL: https://issues.apache.org/jira/browse/COUCHDB-720 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface, Replication Affects Versions: 0.10.1, 0.11 Environment: Remote server having Nginx reverse proxy and basic authentication enabled Reporter: Jochen Kempf Priority: Blocker Pull replication fails using both Futon Replicator and http request throwing an 401 Authentication required error. This just happens when design documents are existent. Push replication on the other hand works fine. See used code here: http://gist.github.com/364072 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-818) _bulk_docs throws Attachment name can't start with '_' but document POST API does not
_bulk_docs throws Attachment name can't start with '_' but document POST API
does not
---
Key: COUCHDB-818
URL: https://issues.apache.org/jira/browse/COUCHDB-818
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 0.12
Environment: Mac OS X 10.6.3
Reporter: Benjamin Young
When inserting documents via the _bulk_docs API, I get this error if I try to
include an attachment that begins with an underscore:
{
error: bad_request
reason: Attachment name can't start with '_'
}
However, if I submit a single doc with an attachment beginning with an
underscore, no such error is generated.
Not sure which one should win, but thought they should be the same. :)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[ https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885386#action_12885386 ] Randall Leeds commented on COUCHDB-720: --- I retract my previous statement. ibrowse is parsing the username/password. I had a feeling it must be, but I just didn't see it at first. Jochen: Is that nginx configuration shortened from a full version? I only see the _changes location. Where are the rules for other ssl connections? Pull replication fails due to 401 Authentication required while push replication works fine - Key: COUCHDB-720 URL: https://issues.apache.org/jira/browse/COUCHDB-720 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface, Replication Affects Versions: 0.10.1, 0.11 Environment: Remote server having Nginx reverse proxy and basic authentication enabled Reporter: Jochen Kempf Priority: Blocker Pull replication fails using both Futon Replicator and http request throwing an 401 Authentication required error. This just happens when design documents are existent. Push replication on the other hand works fine. See used code here: http://gist.github.com/364072 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
