I spent a long time struggling with my reverse proxy configuration.
Here's the relevant part of my nginx config. We rewrite requests to
CouchDB so it does not see the prefix. Critically we also use
proxy_redirect to rewrite redirects issued by CouchDB so that they
point at the correct location "/db" instead of "127.0.0.1:5984".
location /db {
rewrite /db/(.*) /$1 break;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $proxy_host;
proxy_pass http://127.0.0.1:5984;
proxy_redirect https://127.0.0.1:5984 https://$host/db;
}
On Tue, Jun 16, 2015 at 12:46 PM, Rutherford, Tim - Exelis
<[email protected]> wrote:
> I have been struggling for a while now to get couchdb continuous replication
> to work with a remote database behind an https reverse proxy. I'm not sure if
> I am missing something, but as far as I can tell, it should work and just
> isn't.
>
> My setup has a windows machine running couchdb (version 1.5.1) on the default
> port 5984 and a remote couchdb (version 1.5.1) behind apache httpd using
> HTTPS.
>
> Apache httpd is configured with: ProxyPass /futon http://localhost:5984
>
> I added a replication document to _replicator that looks like this:
> {
> "source": {
> "url": "https://[remote
> ip]/futon/iss-local<https://[remote%20ip]/futon/iss-local>",
> "headers": {
> "Authorization": "Basic [valid base64 user:pass]"
> }
> },
> "target": "iss-remote",
> "create_target": true,
> "continuous": true,
> "user_ctx": {
> "roles": ["_admin"]
> }
> }
>
> The replication document is successfully added and replication_state is set
> to triggered.
> The status page shows the Replication task and the status column shows
> "Checkpointed source sequence 0, current source sequence 20416, progress 0%".
>
> It never progresses from there. iss-remote is created successfully, but no
> documents are added. Checking CouchDB's log file shows a series of error
> messages like this:
> [Thu, 28 May 2015 22:04:46 GMT] [error] [<0.22546.4>] Replicator, request GET
> to "https://[remote
> ip]/futon/iss-local/1_33333?revs=true&open_revs=%5B%22615-738587c5fb3aa93f573fa5a79d3cf3ec%22%5D&latest=true<https://[remote%20ip]/futon/iss-local/1_33333?revs=true&open_revs=%5B%22615-738587c5fb3aa93f573fa5a79d3cf3ec%22%5D&latest=true>"
> failed due to error timeout
> [Thu, 28 May 2015 22:04:46 GMT] [info] [<0.22544.4>] Retrying GET to
> https://[remote
> ip]/futon/iss-local/1_33333?revs=true&open_revs=%5B%22615-738587c5fb3aa93f573fa5a79d3cf3ec%22%5D&latest=true
> in 1.0 seconds due to error timeout
>
> Couch then waits a bit and tries again and I get the same error message.
>
> Which doesn't make sense to me because that URL works correctly using
> multiple tools (web browser, curl, and even using an httpc:request() in
> erlang) from the same machine.
>
> If I expose port 80 on the remote server and use http instead everything
> works as expected. Documents are replicated and progress goes up to 100%.
>
> As far as I can tell, this is an issue with couchdb when talking to the
> reverse proxy. I tried exposing couchdb's https port 6984 using the same
> certificate and it worked fine.
>
> I have installed a new version of apache and only configured the proxypass
> and ssl and I still get the same issue.
>
> I ran wireshark (with ssl decryption using the certificate from the server)
> on the machine that I am replicating to and I don't see any issues. I see the
> GET request from the error log and a corresponding 200 response with data. A
> little while later, the error message shows up in the log.
>
> Has anyone seen this before? Is there anything I can do to fix it?
>
> Thank you,
> Tim Rutherford
>
>
> ________________________________
>
> This e-mail and any files transmitted with it may be proprietary and are
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this e-mail in error please notify the
> sender. Please note that any views or opinions presented in this e-mail are
> solely those of the author and do not necessarily represent those of Exelis
> Inc. The recipient should check this e-mail and any attachments for the
> presence of viruses. Exelis Inc. accepts no liability for any damage caused
> by any virus transmitted by this e-mail.
