Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Thu, 7 Feb 2013 14:35:12 +0000 (UTC)
From: "Frank (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12631268.1360247568270.260392.1360247712758@arcas>
In-Reply-To: <JIRA.12631268.1360247568270@arcas>
References: <JIRA.12631268.1360247568270@arcas>
Subject: [jira] [Updated] (COUCHDB-1672) Replication does not work through
 HTTPS
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/COUCHDB-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Frank updated COUCHDB-1672:
---------------------------

    Description: 
Hi there,

First thank you all for this amazing DB that CouchDB is. It makes our life easier, fits well with our project and does really a great job. In the following, you will find some details about the issue we encounter while replicating our user databases.

Short description: the replication to an online CouchDB failed when we start the replication from a local CouchDB.

Erlang version: 14A
Operating System: Debian 6 Squeeze wrapped in an OpenVz container.
Host Operating System: Proxmox 2.1

More infos :
* replication works when https is disabled.
* replication fails when https is enabled.
* Https connections works through a browser or an http client such as curl.
* Https connections works through a browser or an http client such as curl if ssl encryption is handled by a Nginx reverse proxy and couchdb is configured to run without https.
* same issues when "verify_certificate" option is set to false
* same issues when the certificate is approved by a certificate authority.
* we tried with two couchdb instances that live on different machines and that talk each other via the web.
* we tried with two couchdb instances that live in different machines that talk each other via a private network.


Logs:

>From the target of the replication:
no logs


>From the source of the replication:

    [info] [<0.28429.3>] Retrying HEAD request to https://user:*****@couch2.myadresse.com:6984/MyDB/ in 16.0 seconds due to error {conn_failed,{error,eoptions}}
    [info] [<0.1080.0>] 127.0.0.1 - - POST /_replicate 500
    [error] [<0.28430.3>] ** Generic server <0.28430.3> terminating
    ** Last message in was {'EXIT',<0.28429.3>,killed}
    ** When Server state == {state,"https://user:passwd@couch2.myadresse.com:6984/MyDB/",
                               20,[],[],
                               {[],[]}}
    ** Reason for termination ==
    ** killed

    [error] [<0.28430.3>] {error_report,<0.31.0>,
                          {<0.28430.3>,crash_report,
                           [[{initial_call,
                                 {couch_httpc_pool,init,['Argument__1']}},
                             {pid,<0.28430.3>},
                             {registered_name,[]},
                             {error_info,
                                 {exit,killed,
                                     [{gen_server,terminate,6},
                                      {proc_lib,init_p_do_apply,3}]}},
                             {ancestors,
                                 [<0.28429.3>,couch_rep_sup,
                                  couch_primary_services,couch_server_sup,
                                  <0.32.0>]},
                             {messages,[]},
                             {links,[]},
                             {dictionary,[]},
                             {trap_exit,true},
                             {status,running},
                             {heap_size,377},
                             {stack_size,24},
                             {reductions,485}],
                            []]}}


  was:
Hi there,

First thank you all for this amazing DB that CouchDB is. It makes our life easier, fit well with our project and do really a great job. In the following you will find some details about the issue we encounter while replicating our user databases.

Short description: the replication to an online CouchDB failed when we start the replication from a local CouchDB.

Erlang version: 14A
Operating System: Debian 6 Squeeze wrapped in an OpenVz container.
Host Operating System: Proxmox 2.1

More infos :
* replication works when https is disabled.
* replication fails when https is enabled.
* Https connections works through a browser or an http client such as curl.
* Https connections works through a browser or an http client such as curl if ssl encryption is handled by a Nginx reverse proxy and couchdb is configured to run without https.
* same issues when "verify_certificate" option is set to false
* same issues when the certificate is approved by a certificate authority.
* we tried with two couchdb instances that live on different machines and that talk each other via the web.
* we tried with two couchdb instances that live in different machines that talk each other via a private network.


Logs:

>From the target of the replication:
no logs


>From the source of the replication:

    [info] [<0.28429.3>] Retrying HEAD request to https://user:*****@couch2.myadresse.com:6984/MyDB/ in 16.0 seconds due to error {conn_failed,{error,eoptions}}
    [info] [<0.1080.0>] 127.0.0.1 - - POST /_replicate 500
    [error] [<0.28430.3>] ** Generic server <0.28430.3> terminating
    ** Last message in was {'EXIT',<0.28429.3>,killed}
    ** When Server state == {state,"https://user:passwd@couch2.myadresse.com:6984/MyDB/",
                               20,[],[],
                               {[],[]}}
    ** Reason for termination ==
    ** killed

    [error] [<0.28430.3>] {error_report,<0.31.0>,
                          {<0.28430.3>,crash_report,
                           [[{initial_call,
                                 {couch_httpc_pool,init,['Argument__1']}},
                             {pid,<0.28430.3>},
                             {registered_name,[]},
                             {error_info,
                                 {exit,killed,
                                     [{gen_server,terminate,6},
                                      {proc_lib,init_p_do_apply,3}]}},
                             {ancestors,
                                 [<0.28429.3>,couch_rep_sup,
                                  couch_primary_services,couch_server_sup,
                                  <0.32.0>]},
                             {messages,[]},
                             {links,[]},
                             {dictionary,[]},
                             {trap_exit,true},
                             {status,running},
                             {heap_size,377},
                             {stack_size,24},
                             {reductions,485}],
                            []]}}


> Replication does not work through HTTPS
> ---------------------------------------
>
>                 Key: COUCHDB-1672
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1672
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Replication
>            Reporter: Frank
>
> Hi there,
> First thank you all for this amazing DB that CouchDB is. It makes our life easier, fits well with our project and does really a great job. In the following, you will find some details about the issue we encounter while replicating our user databases.
> Short description: the replication to an online CouchDB failed when we start the replication from a local CouchDB.
> Erlang version: 14A
> Operating System: Debian 6 Squeeze wrapped in an OpenVz container.
> Host Operating System: Proxmox 2.1
> More infos :
> * replication works when https is disabled.
> * replication fails when https is enabled.
> * Https connections works through a browser or an http client such as curl.
> * Https connections works through a browser or an http client such as curl if ssl encryption is handled by a Nginx reverse proxy and couchdb is configured to run without https.
> * same issues when "verify_certificate" option is set to false
> * same issues when the certificate is approved by a certificate authority.
> * we tried with two couchdb instances that live on different machines and that talk each other via the web.
> * we tried with two couchdb instances that live in different machines that talk each other via a private network.
> Logs:
> From the target of the replication:
> no logs
> From the source of the replication:
>     [info] [<0.28429.3>] Retrying HEAD request to https://user:*****@couch2.myadresse.com:6984/MyDB/ in 16.0 seconds due to error {conn_failed,{error,eoptions}}
>     [info] [<0.1080.0>] 127.0.0.1 - - POST /_replicate 500
>     [error] [<0.28430.3>] ** Generic server <0.28430.3> terminating
>     ** Last message in was {'EXIT',<0.28429.3>,killed}
>     ** When Server state == {state,"https://user:passwd@couch2.myadresse.com:6984/MyDB/",
>                                20,[],[],
>                                {[],[]}}
>     ** Reason for termination ==
>     ** killed
>     [error] [<0.28430.3>] {error_report,<0.31.0>,
>                           {<0.28430.3>,crash_report,
>                            [[{initial_call,
>                                  {couch_httpc_pool,init,['Argument__1']}},
>                              {pid,<0.28430.3>},
>                              {registered_name,[]},
>                              {error_info,
>                                  {exit,killed,
>                                      [{gen_server,terminate,6},
>                                       {proc_lib,init_p_do_apply,3}]}},
>                              {ancestors,
>                                  [<0.28429.3>,couch_rep_sup,
>                                   couch_primary_services,couch_server_sup,
>                                   <0.32.0>]},
>                              {messages,[]},
>                              {links,[]},
>                              {dictionary,[]},
>                              {trap_exit,true},
>                              {status,running},
>                              {heap_size,377},
>                              {stack_size,24},
>                              {reductions,485}],
>                             []]}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira