couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: Help with setting a fake CouchDB replication endpoint
Date Sun, 22 Feb 2015 21:53:31 GMT

sorry, miss your email.

On Sun, Feb 8, 2015 at 12:35 AM, Giovanni P <> wrote:
> HEAD / -> just says I'm here
> GET / -> returns {update_seq: "1-initial", instance_start_time: "0"}
> GET /_local/someidentificator -> 404
> GET /_changes (I show only my design doc id, with a _rev of "1-initial")
> GET /_design/<id>?revs=true&open_revs=all&latest=true

Actually, you'd miss /db/_revs_diff resource where you should
determine a missing revs list which will be passed as argument for
open_revs query param.

> At this point I should return a bizarre multipart/mixed response, which I
> do (you can check it by curling or visiting
> but at this point the CouchDB replicator starts to make repeated requests
> to both / and /_design/<id>?revs=true&open_revs=all&latest=true and I don't
> know what exactly went wrong.
> Is it my multipart/mixed response that is wrong? (probably, because it is
> written by hand, but where is it wrong and how should I be doing this?) or
> is it something else?

Yes, it is. For documents with attachments in multipart format,
document object MUST contains an _attachments field with the following
fields per attachment: content_type, length, but instead of data with
base64 encoded content, there should be "follows": true field be which
signs that the attachment content goes in next body parts. See
for an example.

> Cloudant DBs do not return this multipart/mixed
> response no matter how much I try, they return a strange JSON array.

Their response is similar to CouchDB one if you explicitly accept
application/json. However, for handling attachments in this case you
need to additionally pass attachments=true query parameter and get
ready to deal with a huge json blob which could ruin your client.


View raw message