Note: Made some updates according to new information. Old ideas happen to be added as comments below. Note: Made some updates (again) according to new information. Old ideas happen to be added as comments below (again).

We're running two cases of CouchDB on separate computer systems behind Apache reverse proxies. When trying to duplicate between your two instances:

curl -X POST http://user:pass@localhost/couchdb/_replicate -d '{ "source": "db1", "target": "http://user:pass@10.1.100.59/couchdb/db1" }' --header "Content-Type: application/json"

(we began using curl to debug the issue)

we get an error much like:

{"error":"case_clause","reason":"{error,\n    {{bad_return_value,\n         {invalid_json,\n             <<\"<!DOCTYPE HTML PUBLIC \\\"-//IETF//DTD HTML 2.0//EN\\\">\\n<html><head>\\n<title>404 Not Found</title>\\n</head><body>\\n<h1>Not Found</h1>\\n<p>The requested URL /couchdb/db1/_local/01e935dcd2193b87af34c9b449ae2e20 was not found on this server.</p>\\n<hr>\\n<address>Apache/2.2.3 (Red Hat) Server at 10.1.100.59 Port 80</address>\\n</body></html>\\n\">>}},\n     {child,undefined,\"01e935dcd2193b87af34c9b449ae2e20\",\n         {gen_server,start_link,\n             [couch_rep,\n              [\"01e935dcd2193b87af34c9b449ae2e20\",\n               {[{<<\"source\">>,<<\"db1\">>},\n                 {<<\"target\">>,\n                  <<\"http://user:pass@10.1.100.59/couchdb/db1\">>}]},\n               {user_ctx,<<\"user\">>,\n                   [<<\"_admin\">>],\n                   <<\"{couch_httpd_auth, default_authentication_handler}\">>}],\n              []]},\n         temporary,1,worker,\n         [couch_rep]}}}"}

So after further research it seems that apache returns this error without trying to gain access to CouchDB (based on the log files). To become obvious when given the next URL

/couchdb/db1/_local/01e935dcd2193b87af34c9b449ae2e20

Apache passes the request to CouchDB and returns CouchDB's 404 error. However when replication happens the URL really being passed is

/couchdb/db1/_local%2F01e935dcd2193b87af34c9b449ae2e20

which apache determines is really a missing document and returns its very own 404 error for without ever passing the request to CouchDB. This a minimum of provides me with newer and more effective leads however i could still use help if anybody comes with an answer offhand.

The origin CouchDB (localhost) is suggesting the remote URL was invalid. Rather than a CouchDB response, the origin gets the Apache httpd proxy's file-not-found response.

Regrettably, you might have some reverse-proxy troubleshooting to complete. My first guess may be the Host header the origin is delivering towards the target. Possibly it's not the same as whenever you connect from another location?

Finally, I believe you most likely know this, however the path

/couchdb/db1/_local%2F01e935dcd2193b87af34c9b449ae2e20

Is not a typical CouchDB path. When CouchDB sees a request, it will possess the /couchdb removed, therefore the totally for any document known as _local%2f... within the database known as db1.

Incidentally, it's very important to not allow the proxy customize the pathways before they hit couch. Particularly, should you send %2f then CouchDB ought to receive %2f and when you signal / then CouchDB ought to receive /.

From official documentation...

Observe that HTTPS proxies are theoretically supported but don't operate in 1..1. The reason being 1..1 ships with ibrowse version 1.5.5. The CouchDB version in trunk (where 1.1 depends) ships with ibrowse version 1.6.2. This later ibrowse consists of fixes for HTTPS proxies.

Are you able to see which version of ibrowse is involved? Maybe update that ver?

Another thought I've is regarding the SSL certs. Without having any, and that i know you do not :), then technically you are doing SSL wrong. In java we all know you will find ways for this, but maybe try investing in proper certs since all SSL stuff essentially involves certs.