couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: Attachment retrieval
Date Thu, 09 Jun 2011 09:03:39 GMT
This is a change between CouchDB 1.0.x and 1.1.x.

This API is predominantly used by the replicator, which is why it has
been enhanced (no more base64 inflation) and why it isn't documented.
I'll note that I didn't make the change itself, I believe that was
Filipe. The only change I made was to add the "digest" key, as this
allows us to verify that attachments are replicated correctly.


On 9 June 2011 01:46, Matthias Eck <> wrote:
> Hi Randall,
> Adding a -H"Accept:application/json" to curl did indeed help and the
> result is now with inline data as on 1.0.1
> The original problem actually occurred using the PHPonCouch library,
> but I was able to fix that now as well by adding this header.
> Thanks,
> Matt
> On Wed, Jun 8, 2011 at 5:10 PM, Randall Leeds <> wrote:
>> On Jun 8, 2011 5:05 PM, "Matthias Eck" <> wrote:
>>> > It sounds like you're issuing the request from the browser. I'd be
>>> > interested to know the details (if you can provide them from the debug
>>> > console or something) of the request headers. Also it'd be helpful to
>>> > know what version of CouchDB is running on each server (and at the
>>> > time of replication, if you've since upgraded).
>>> I was using Chrome and Firefox browsers to issue those requests with
>>> the same results.
>>> The CouchDB version on the original server is: 1.0.1 on the replicated
>>> one it is 1.1.0.
>>> The database was replicated yesterday, and I have not upgraded since.
>>> I tried it now via curl.
>>> If I request the same document id from the two servers without
>> attachments=true
>>> the result is almost exactly the same (the replicated one only adds a
>>> "digest" field to the attachments section.)
>>> If I request the document with attachments, the results for the
>>> original server are as expected:
>> {"_id":"110221155249562","_rev":"2-ddaf35a53663fb95160709dc74ad4e8f",...,"_attachments":{"log.wav":{"content_type":"audio/x-wav","revpos":2,"data":"UklGRiSAAABXQVZ...."}}}
>>> For the new one it is quite different with some additional headers and
>>> a different encoding:
>>> --695b0c17ab17db91c79747840eb69037
>>> content-type: application/json
>> {"_id":"110221155249562","_rev":"2-ddaf35a53663fb95160709dc74ad4e8f",...,"_attachments":{"log.wav":{"content_type":"audio/x-wav","revpos":2,"digest":"md5-bMqMA4X3anyOl2M89lifrQ==","length":32812,"follows":true}}}
>>> --695b0c17ab17db91c79747840eb69037
>>> RIFF$200^@^@WAVEfmt ^P^@^@^@^A^@^A^@200>^@^@^@}^@^@^...
>>> It seems to me that the wave file is not put in the json structure but
>>> transferred separately.
>>> Thanks
>>> Matt
>> Thanks, Matt. This is what I expected. What happens if you add an Accept:
>> application/json header?
>> It seems CouchDB is using the multipart mime format for sending the data. I
>> know this was added in 1.1, but I'm not sure it's meant for serious public
>> consumption and isn't really documented. Though, it's probably unintentional
>> that the header parsing affects you like this. If, with the accept header,
>> you get the inline data as on 1.0.1 then I'd say this is not a bug, though
>> it's still surprising (clearly).
>> Let me know what happens and I'll figure out the best course of action.
>> Robert Newsom should also chime in since I believe he wrote this piece.
>> -R

View raw message