Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: Problems with multipart attachment updates
From: Robert Newson <rnewson@apache.org>
In-Reply-To: <502A0F1C.6080504@innerfunction.com>
Date: Tue, 14 Aug 2012 16:54:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <15C4F38D-0972-465E-BDB8-46F4DF772D14@apache.org>
References: <50290C03.90701@innerfunction.com>
 <1CC8BC63-D2DF-4C7C-91A8-0FB9C6AC806A@couchbase.com>
 <697613A5-02EF-4910-8EF2-576E26101B8C@apache.org>
 <502A0F1C.6080504@innerfunction.com>
To: user@couchdb.apache.org


I don't think you've corrupted the database. We've had issues in the =
past where we've allowed data in that we can't render on the way out, =
all to do with our old UTF-8 encoder/decoder. I suspect this is another =
case of the same or similar (mostly because you are sending a json =
attachment, which might cause internal code to interpret as UTF-8 =
whether you sent it that way or not). The multipart/put request is used =
pretty much exclusively by the replicator, and those brave few who =
discover it by watching the replicator or hear about it on #couchdb, so =
it isn't necessarily tolerant to new client code.

All that said, I'd love to get to the bottom of this one. It should =
either come back out fine or the write should be rejected. Once we have =
identified the nature of the bug, we can decide which it is. Did you =
file a JIRA ticket? If not, please do so and mark it as 'Fix For' 1.3 =
and a blocker. Simplest sequence of steps to reproduce is hugely =
appreciated.

B.

On 14 Aug 2012, at 09:41, Julian Goacher wrote:

> 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.
>=20
> Perhaps I should raise this on the dev list?
>=20
> j/
>=20
> 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).
>>=20
>> I glanced at this earlier but didn't see anything obviously wrong. If =
the boundary is malformed, that would do it, among other things.
>>=20
>> B.
>>=20
>> On 13 Aug 2012, at 20:15, Jens Alfke wrote:
>>=20
>>> On Aug 13, 2012, at 7:15 AM, Julian Goacher =
<julian.goacher@innerfunction.com> wrote:
>>>=20
>>>>  [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=85
>>>=20
>>> Your request looks fine to me.
>>>=20
>>> =97Jens
>=20
> --=20
> Julian Goacher
>=20
> CEO, InnerFunction Ltd.
> Telephone:  +353 1  4007512
> Mobile:     +353 86 2399240
> Skype ID:   juliangoacher
>=20
> http://innerfunction.com
>=20