couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Problems with multipart attachment updates
Date Tue, 14 Aug 2012 15:54:23 GMT

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.
> 
> 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
> 


Mime
View raw message