couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Goacher <julian.goac...@innerfunction.com>
Subject Re: Problems with multipart attachment updates
Date Tue, 14 Aug 2012 18:57:47 GMT
I'm not sure how easily this can be reproduced. To put some context on
this, I've been developing a client to write attachments using the
multipart put, and yes, I've found that couch is not very tolerant of
malformed requests. Initial revisions of the client had bugs which
caused a range of errors, mainly down to the client not terminating
boundary strings correctly (using LF instead of CRLF). But early on I
was also using chunked encoding and so running into this issue:
https://issues.apache.org/jira/browse/COUCHDB-1403. Couch would fail to
send a response during a lot of this testing; in some cases this was
probably fair enough (if it was still expecting request content), but in
other cases it would generate an error with no response (which isn't
good - don't ask for test cases, this was done over several days and
I've lost the specifics).

Now in all my testing I was deleting the database and creating it and
the target document anew before attempting to write the attachment. I
was developing across two machines (both Mac OS X running Couch 1.2.0)
and I have a situation now where the example in my original post works
on one machine and fails on the other. I have it in my head that my
original round of testing has somehow 'corrupted' the database, but
considering that, as I've said, I recreate the db, this doesn't make
much sense as an explanation...

I'll go ahead and create a Jira ticket, but I'm not sure much progress
can be made on this issue. I think the larger issue here is about the
robustness of the multipart put functionality - it would be very useful
if this functionality was robust & reliable.

j/

On 14/08/2012 16:54, Robert Newson wrote:
> 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.

-- 
Julian Goacher

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

http://innerfunction.com


Mime
View raw message