couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick North <>
Subject Re: Uploading attachments using Multipart/related
Date Tue, 25 Mar 2014 19:03:14 GMT
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.


On 25 March 2014 18:40, Jens Alfke <> wrote:

> On Mar 25, 2014, at 7:37 AM, JC de Villa <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message