incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Eck <matthias....@jibbigo.com>
Subject Re: Attachment retrieval
Date Thu, 09 Jun 2011 00:46:56 GMT
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 <randall.leeds@gmail.com> wrote:
> On Jun 8, 2011 5:05 PM, "Matthias Eck" <matthias.eck@jibbigo.com> 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
>

Mime
View raw message