We were initially planning on using pythons email.mime module to build the request, but the ability to change the line separator is available only on python >= 3.2.
Oh well, looks like we're rolling our own. Thanks again. :) On Wed, Mar 26, 2014 at 4:13 PM, Nick North <[email protected]> wrote: > 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 > > > -- JC de Villa
