Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: 207.97.245.171 is neither permitted
 nor denied by domain of julian.goacher@innerfunction.com)
Message-ID: <502A0F1C.6080504@innerfunction.com>
Date: Tue, 14 Aug 2012 09:41:00 +0100
From: Julian Goacher <julian.goacher@innerfunction.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: Problems with multipart attachment updates
References: <50290C03.90701@innerfunction.com>
 <1CC8BC63-D2DF-4C7C-91A8-0FB9C6AC806A@couchbase.com>
 <697613A5-02EF-4910-8EF2-576E26101B8C@apache.org>
In-Reply-To: <697613A5-02EF-4910-8EF2-576E26101B8C@apache.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

It think the request is being processed correctly but that the update is
written incorrectly and the DB is left in a corrupt state (at least for
that document record). I'm concerned that it shouldn't be possible to
corrupt the DB this way, via a HTTP request, whether the request is
malformed or not.

Perhaps I should raise this on the dev list?

j/

On 13/08/2012 20:57, Robert Newson wrote:
> Attachments are not stored with base64 encoding, nor are they base64 encoded in a multipart PUT (that's part of the reason that this API and the 'standalone attachment API' is more efficient).
>
> I glanced at this earlier but didn't see anything obviously wrong. If the boundary is malformed, that would do it, among other things.
>
> B.
>
> On 13 Aug 2012, at 20:15, Jens Alfke wrote:
>
>> On Aug 13, 2012, at 7:15 AM, Julian Goacher <julian.goacher@innerfunction.com> wrote:
>>
>>>   [Mon, 13 Aug 2012 14:10:02 GMT] [error] [<0.6811.10>] Uncaught error
>>>   in HTTP request: {error,undef}
>>>   [Mon, 13 Aug 2012 14:10:02 GMT] [info] [<0.6811.10>] Stacktrace:
>>>   [{base64,encode,
>>>   [<<115,176,77,34,80,64,240,8,14,182,224,
>>>   181,170,42,191,128>>],
>>>                                          []},
>>>   {couch_doc,'-to_json_attachments/4-fun-0-',
>>>                                          4,
>> It looks like CouchDB is failing to base64-encode some data, which presumably would be the contents of your attachment, except that the values in the "<<"-delimited binary string are total garbage if interpreted as ASCII. That's as much as I can make out without a good knowledge of the innards of CouchDB�
>>
>> Your request looks fine to me.
>>
>> �Jens

-- 
Julian Goacher

CEO, InnerFunction Ltd.
Telephone:  +353 1  4007512
Mobile:     +353 86 2399240
Skype ID:   juliangoacher

http://innerfunction.com