Issue when connecting to Java Listener from Couchbase Lite

iPad running Couchbase Lite 1.3.1
Java running Couchbase Lite 1.3.1

The Java has a listener setup.
The iPad has both a push and pull set to the Java’s listener.

Data pushes from the iPad to the Java correctly, but changes from the Java are not being pulled to the iPad.

Here are some logs from the iPad:

2016-10-07 12:10:01.046 REDACTED[2159:4312951] ChangeTracker: CBLSocketChangeTracker[0x158242f70 bucket1_thewurst2743_thewurst2743]: Starting...
2016-10-07 12:10:01.046 REDACTED[2159:4312951] Sync: CBLSocketChangeTracker[0x158242f70 bucket1_thewurst2743_thewurst2743]: POST //
2016-10-07 12:10:01.047 REDACTED[2159:4312951] ChangeTracker: Changes feed using proxy settings {
    ExceptionsList =     (
    FTPPassive = 1;
    "__SCOPED__" =     {
        en0 =         {
            ExceptionsList =             (
            FTPPassive = 1;
2016-10-07 12:10:01.047 REDACTED[2159:4312951] ChangeTracker: CBLSocketChangeTracker[0x158242f70 bucket1_thewurst2743_thewurst2743]: Started... <>
2016-10-07 12:10:01.052 REDACTED[2159:4312951] ChangeTracker: CBLSocketChangeTracker[0x158242f70 bucket1_thewurst2743_thewurst2743]: Event 1 on <__NSCFInputStream: 0x156dbc7a0>
2016-10-07 12:10:01.075 REDACTED[2159:4312951] CBLSocketChangeTracker[0x158242f70 bucket1_thewurst2743_thewurst2743]: Connection error #7, retrying in 128.0 sec: CFCFNetworkError[-1005]

Could the issue be as simple as Couchbase Lite performing POST requests while the listener only accepts GET requests for _changes as per the API?

I see that the gateway has a POST version for _changes, but its parameters are in the request’s JSON body rather than the URL. I’m not sure if that is what is intended here, though, because Couchbase Lite is performing a POST with its parameters in the URL.

After further testing, the issue does not seem to be using a POST request rather that a GET as I initially thought. The listener also accepts POST requests for the changes feed, it is just not listed in its API.
I am still having the issue, however.

As you wrote, in 1.3.1, both iOS and Android support POST /_changes but it isn’t documented (filed

When iOS starts a pull with Android as the remote the request is closed.

I think it’s because iOS is sending the Connection: close header and with that header Android doesn’t return the expected response.

curl -H 'Content-Type: application/json' -H 'Connection: close' -vX POST 'http://localhost:5984/user2/_changes?feed=normal&heartbeat=300000&style=all_docs&active_only=true' -d '{"feed":"longpoll","heartbeat":300000,"style":"all_docs","since":17,"accept_encoding":"gzip"}'
*   Trying ::1...
* connect to ::1 port 5984 failed: Connection refused
*   Trying
* Connected to localhost ( port 5984 (#0)
> POST /user2/_changes?feed=normal&heartbeat=300000&style=all_docs&active_only=true HTTP/1.1
> Host: localhost:5984
> User-Agent: curl/7.43.0
> Accept: */*
> Content-Type: application/json
> Connection: close
> Content-Length: 93
* upload completely sent off: 93 out of 93 bytes
* Empty reply from server
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server

Without the Connection: close header that request works fine.


Thanks for the reply!

Is there a way to work around this or maybe a setting I can change to keep that from happening?

It looks more like a bug but I’m not sure what the expected header value is. I tried to override the value of the header using CBLReplication.headers but that option works for new headers, not overriding headers set by CBL. @jens is the Connection: close header set on the CBL replicator on iOS? I could try to change the header in the source code and see if that makes a difference.


We don’t explicitly set that header, but it may be a side effect of using CFStream’s HTTP API, which doesn’t support keep-alive.

Android’s response seems wrong, though. It’s closing the socket without returning any data. I suggest you file an issue.

OK. Filed

Thanks for the help guys!

I’ll be sure to watch that issue for any new developments.

Sorry for taking time to investigate this issue. This issue will be addressed with v1.4.0 release.

You could verify the fix with using nightly build.