As a quick followup to this, I can remove the username:password from the source URL, and the POST to _replicator will return an "error":"unauthorized", which is what I expect.
However, the POST returns no response when using username:password in the URL. So, replicator seems to be hanging when trying to authenticate against my couchdb during replication. Also, the replication gets created (visible via _active_tasks), but the POST never gets a response back, and the replication never completes, it always times out. Any help would be greatly appreciated. Thanks again, ~Jay -----Original Message----- From: Jay Clark Sent: Monday, March 10, 2014 12:06 PM To: [email protected] Subject: Replication consistently fails Hi, I’m trying to figure out why my app is having difficulty replicating, and hoping someone here can help. I have a couchdb 1.4 server setup behind an Apache reverse proxy. We’re only allowing HTTPS connections to the Apache server, and couchdb user credentials are needed to access any db. I’m inside a corporate network, but have verified with sysadmins that the appropriate (documented) ports are open for CouchDB replication to happen. The couchdb server in question is in a DMZ. Please let me know if that’s enough info. While my laptop is on my corporate (public) wi-fi network, I’m trying to replicate a db from my server (in our DMZ) with this post to _replicate, but it consistently times out: {"source":"https://username:[email protected]/dbname","target":"eeb"} While I’m external to our network, the replication succeeds without problem. Using a REST client inside my corporate network, I get no response and it eventually times out. The Erlang log shows this message: Replicator, request GET to "https://username:*****@estante.maflt.org/dbname/_changes?feed=normal&style=all_docs&since=0&heartbeat=10000"; failed due to error timeout We’ve scoured logs for errors or issues related to connectivity from our public LAN and our DMZ, and nothing appears to be blocking our connection. Regular HTTP/HTTPS can go through just fine. I can access Futon just fine on the server, and the server pull can replicate into itself just fine. Could someone point me in the right direction to figure out why replication seems to fail so consistently like this? Are there other ports we need to be looking at? Other protocols being used? Is there a flaw in my replication request? Is there some network config I need to have our sysadmin look at that could be preventing this? As far as I can tell though, the behavior seems to indicate that the document is not fully getting posted to the localhost’s _replicate method. Thank you, Jay Clark
