That message is not well worded for this situation. It means that instead of web sockets for the changes feed, the replicator is falling back to HTTP(s) transport (HTTP or HTTPS depending on the endpoint the replication was given).
Is there an easy way to verify the replication is happening over HTTPS? We restarted the Sync Gateway from command line to watch its output and didn’t see anything that immediately indicated HTTPS over normal HTTP, and then we actually saw a few “TLS handshake error” messages every so often. These seem to be intermittent at best: several GETs and POSTs will all go through fine but then suddenly a PUT fails with the TLS handshake error, then some more GETs and successful PUTs.
I can try to put together a cleaned-up log if you think it would help, but otherwise just some way for us to confirm things are working as we think they are would be great. If not, no worries as we can probably just Wireshark it and figure it out that way.
Do you happen to know which endpoints are being called that cause the TLS handshake errors? That usually happens when a replicator is setup with HTTP against an HTTPS backend, but I think it could also happen if the client in question doesn’t understand TLS 1.2. If all requests are coming from the same client then this is not possible (it won’t intermittently fail) but one situation I’ve been in is where I forgot to shut down a separate client and it was causing issues without me realizing.
EDIT Just to be clear about the message about falling back to HTTP, all that happens is that the replicator shuts down and starts back up with the same settings, except UseWebSocket will be switched to false.
We have Sync Gateway configured for HTTPS and we have the iOS code using the NSURLSession-based handler which should get us TLS 1.2.
I should have mentioned sooner we are doing cookie-based authentication in case that makes a difference.
One of our developers discovered that if we use SetCookie with the Secure parameter set to false we no longer see the WebSocketSharp.doHandshake() exception in our app’s log, but we still see the TLS handshake errors in the Sync Gateway log (coming from our app). Is this bad to have SetCookie use “Secure = false” despite pointing to an HTTPS endpoint?
A section of the Sync Gateway log output can be seen here:
Note there is one changes feed set to “normal” and then others are “websocket”.
The Secure=true property of a cookie just tells the client not to send that cookie over a non-SSL connection. This is useful if the cookie contains sensitive data. Secure=false is a no-op AFAIK, since that’s the default.
In any case, cookies won’t have any effect on the SSL handshake, since that happens well before cookies are sent.