Glad you got it working. Working with MIME is a whole world of pain; if your have the option of using an existing library to construct your requests, your life will be a lot easier. Or if you can use a library to construct some test requests and then use them as a template for your own code, that might also speed things up.
Nick On 26 March 2014 08:03, JC de Villa <[email protected]> wrote: > Good lord. It WAS the newlines. > > The only hurdle I have to get over now is when uploading multiple binary > attachments. But at least it's working now, and I can move on to figuring > that out. > > Thanks Nick, Jens for the help. :) > > > > On Wed, Mar 26, 2014 at 1:46 PM, JC de Villa <[email protected]> wrote: > > > Thanks everyone for looking into this. > > > > I just got in a few minutes ago to tinker with this again. I'll post back > > once I get it working (or not... :( ) > > > > > > On Wed, Mar 26, 2014 at 3:36 AM, Nick North <[email protected]> wrote: > > > >> Following up on my last message: the final newline is no longer > required. > >> > >> You could take a look at https://gist.github.com/NorthNick/9769261 - > this > >> is a dump of a request that works on CouchDb 1.5 for me. As Jens says, > the > >> crucial difference may well be in the use of CRLF around the boundary. > The > >> first boundary string is preceded by CRLFCRLF and followed by CRLF; the > >> later ones are preceded by CRLF and followed by CRLFCRLF. > >> > >> Nick > >> > >> > >> On 25 March 2014 19:03, Nick North <[email protected]> wrote: > >> > >> > 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 > >> > > >> > > >> > > >> > > > > > > > > -- > > JC de Villa > > > > > > -- > JC de Villa >
