Endless replication when using reverse-proxy.

[SukantGujar]

Hi Colin,

This is totally a non-issue with library. I needed your help in debugging a problem I am facing and as I didn't have your email, I am reaching out to you here.

To prevent having to expose CouchDB endpoint to my application users, I tried to add a simple reverse-proxy using request in my express app -

```
// Bind /db to couch DB backend
var DATABASE_URL = 'http://localhost:5984';

// middleware itself, preceding any parsers
app.use(function(req, res, next){
    var proxy_path = req.path.match(/^\/db(.*)$/);
    if(proxy_path){
        var db_url = DATABASE_URL + proxy_path[1];
        console.log("db_url: " + db_url);
        req.pipe(request({
        uri: db_url,
        method: req.method
        })).pipe(res);
    } else {
        next();
    }
});

Also, I added dbServer > publicURL: 'http://localhost:8080/db/' in superlogin config, so that the private DB urls come mapped to the `/db` endpoint. Things went good this far. However, when I ran the application, the replication initiated by pouch-mirror went amok and never ended. The calls trough the proxy are going through, however somehow the replication is screwed up. The private DB size ballooned very quickly from mere 8.1k to 1MB in no time.

Do you have experience with a setup like this? Would be great if you can give me any pointers.

Thanks!

[colinskow]

CouchDB is designed to be exposed to end users. If you setup the security features correctly you have nothing to worry about. To access CouchDB with a browser, you will need to enable CORS.

I'm not sure if you have deeper reasons for using a reverse proxy, but it seems to me like a waste of server resources.

Definitely something about your implementation is screwing up the replication algorithm. The simplest solution is to not use a proxy.

[colinskow]

Join slack.pouchdb.com to communicate with myself and a lot of helpful people with CouchDB experience.

[SukantGujar]

Thanks Colin. One primary reason for using proxy is to prevent the CORS exchanges, which are slow and repetitive. And to allow gzip compression. Then there's the need to have as less ports exposed as possible and also less important needs like to be able to have the backend replacable in future. But frankly, I am hesitant to expose CouchDB unless I truly understand the security undertakings.

[SukantGujar]

After closer inspection, I found that the proxy code was not sending over the query string parameters to PouchDB. The following change fixed the issue -
req.pipe(request({ qs:req.query, uri: db_url })).pipe(res);

[colinskow]

The reverse proxy won't actually provide any additional security. Any attack that could be leveled against Couch will pass straight through the proxy unless you heavily filter the requests. It is much easier to study up on CouchDB security and do it right than to filter proxy requests.

The proxy will likely add lag to your requests, so you need to measure this against the benefits of GZIP. Not to mention as your app scales you will save a lot of money by not needing to scale the proxy servers.

[SukantGujar]

Your points are very valid Colin. I think the right thing for me to do is to take metrics with both approaches. Thanks to Superlogin's publicURL concept, its a one line change for me to switch from public facing CouchDB to a proxied one.
Another aspect here is that my application is not as chatty with the server. In fact around 80% of the time the interactions would be client side only. So the local PouchDB instance would be busy and occasionally the app would sync with the server.