The "chunked" problem is fixed in branch 1956-attachment-handling, but I'm not sure if that is ready to merge yet, so you're right that it is still a problem at the moment.
I also vaguely recall the final CRLF problem, and have a feeling it was patched a while back, but I'm not completely sure. I'll check.... The MIME headers are still ignored. I'd like to sort this out, but it raises a host of questions about backward-compatibility, and what to do if there is a mixture of _attachments entries and MIME headers, especially if they are incompatible with each other. I haven't got around to thinking out a proposal for answering those questions yet. Nick On 25 March 2014 18:40, Jens Alfke <[email protected]> wrote: > > On Mar 25, 2014, at 7:37 AM, JC de Villa <[email protected]> wrote: > > > This is absolutely driving me nuts. > > I'm sure it's easy. Uploading multiple attachments just don't seem to > want to work for me. > > This sounds like my experience getting my replicator to interoperate with > CouchDB a few years ago :) > > Here's a brain dump of things I remember: > > * Make sure the line breaks in the MIME separators/headers are CRLF, not > just LF! > * CouchDB crashes if a multipart body is sent in HTTP 'chunked' mode > (COUCHDB-1403, filed by me two years ago and still unresolved. My colleague > working on the Java port of my replicator just ran into this a few weeks > ago.) > * I remember there being a bug in CouchDB where it required a CRLF after > the closing MIME separator, i.e. the body had to end "--separator--\r\n" > not just "--separator--") but I can't find a reference to the bug in my > source code anymore. It may have been fixed. > * CouchDB used to ignore the headers in attachment MIME parts and assumed > that the attachments appeared in the same order as in the "_attachments" > object in the main JSON body. I believe this has been fixed and that it now > looks at the Content-Disposition header to find the attachment's filename, > but I can't remember for sure. > > Hope this helps! > > --Jens
