Replicator now runs in background, using iOS background-task API
Value is desired timeout in milliseconds, e.g. 60000 for 1 minute. This applies to all HTTP requests sent by the replicator. Default is 1 minute. Fixes couchbaselabs/TouchDB-iOS#270
CFStream doesn't automatically look up the system HTTP proxy settings; you have to get those settings and then set the stream to use them. :-p Fixes #259 (I think — haven't verified this in an environment with a proxy)
Add support for filtering _changes by doc_ids, to facilitate named document replication (There's not yet any public API for this; that will need to come later.)
Router: interpret "+" as space in URL query params
…ymbols removed before querying the database.
If TDSocketChangeTracker gets an unparseable response whose beginning looks like the expected JSON, assume the socket got cut off by some intermediary and go through the usual retry mechanism. Fixes #241.
Manually copied over from CouchbaseLite commit 8ee5c3d
A futile attempt to address truncated feeds (#241); but I think these are good changes to make anyway even if they didn't help that.
* If a TDRemoteRequest gets an auth challenge and finds a new credential based on the Realm string, it now remembers that in its authorizer, and the replicator will pick it up and use that as its authorizer from then on. This should help pick up credentials registered with non-empty realms. * TDRemoteRequest now tries the 'proposed' credential, if there is one, on its first pass through the auth challenge handler. * Added more logging about the auth flow, for future debugging needs. I am not sure if these will fix issue #242 but they should help.
It now works similarly to the puller, using an NSIndexSet to keep track of which sequences haven't yet been uploaded, and only advancing the checkpoint to just before the first sequence in the set. This will fix possible edge cases/race conditions where the checkpoint may have been advanced too optimistically, causing a doc that failed to be pushed once to never be retried. (Fixes #246)
These strings are in JSON "error" properties in error responses and in individual items of a _bulk_docs response.
If TDSocketChangeTracker gets a 401 or 407 and can't find a credential, or the credential is rejected, it now logs a message of the form TDSocketChangeTracker[...]: HTTP auth failed; sent Authorization: %@ ; got WWW-Authenticate: %@ showing the Authorization header it sent (if any, else null) and the WWW-Authenticate response header. These headers are also returned in the NSError as keys "HTTPAuthorization" and "HTTPAuthenticateHeader" (although this is of limited use since this info won't make it all the way up to the public replication API, yet.) This should help in diagnosing issue #242.
Note that this invalidates all saved persistent replications that used Persona/BrowserID auth, because the property in the replication doc was renamed too. It also changes the server endpoint that the replicator hits to log in from /db/browserid to /db/persona. (This is equivalent to commit 111859c from CouchbaseLite, although it's not a direct cherry-pick. I had to make the same changes manually because too many things have been renamed for a merge to work.)
If the first new revision received by the puller fails to be read or written, the last-sequence ID won't advance. But the puller was instead getting a null sequence ID instead of the checkpointed one, and trying to save that, which deleted the checkpoint. So the next pull would start over from the beginning.
TDEscapeID wasn't escaping "?". This led to the replicator constructing invalid URLs for docs whose ID contains "?", which meant they'd never get replicated.
TDPuller was saving its checkpoints to the remote JSON doc as numbers but they were then read back and cast to string, causing the comparison to fail. This meant the puller would start over from the beginning every time. I also added some more logging.
I'm not sure whether such parameters are allowed, but JSON encoding seems like the reasonable way to send them to the remote _changes feed (as opposed to calling ObjC -description on them, which the code used to do...) Potential fix for issue #239.
It's possible in rare cases for the didReceiveResponse: delegate method to be called twice. Handle this correctly by creating a new _reader within that call. Thanks to @kjots, @chaisehocking, @drekka for tracking this down! Speculatively fixes #236.
Took out the -stop call. The remaining call to -revisionFailed will ensure that the pull is retried later. And in the case being reported, where the call fails due to being canceled when going offline, the replication will continue when it goes back online. Fixes #233.