Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of north.n@gmail.com designates
 209.85.220.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGHTdUW6nCJJ-j8z6TGQjUQKsE=RuZ-XuQYN1SVpS2TBV_AHVg@mail.gmail.com>
References: 
 <CAOvw+NYLZYV3Y0kqcaWQDdYnEWY3FRRVgGVZwrWsrKwpx8r98w@mail.gmail.com>
	<CAHdjipJ+Sg_3R8Fb1dQSWP-ABxxfhK-KWtqkj_hd1k7qzT=7xQ@mail.gmail.com>
	<CAOvw+NY2rkZMEcg0ugNQ+D6_2jDVhVrOX-9+QzmubgqONFK1hQ@mail.gmail.com>
	<CAHdjipJs+1gFKhZb3y--41DAmCrBXDBEDxCj_7ynq1JovYabRg@mail.gmail.com>
	<CAOvw+NbzJ2asPGADZrrAeyKVQG=C7ws18atjCQeAdU49RvuZQA@mail.gmail.com>
	<CAGHTdUWirGM=0tbFArS5A=bYbFcv=gJjd6nSMEp+VPeTr9v5JQ@mail.gmail.com>
	<CAOvw+NZWz7-_qynVgQxchWg5vgSQUmDKE0xdQrdqJ7gFVaODgw@mail.gmail.com>
	<CAGHTdUXZuY7N9uz=QxsNvfA0J9_98Ctduf-X4S6_EHCyyj8Hew@mail.gmail.com>
	<CAOvw+NYZgz1Abt7jDMocRj+o1G2J6k=jUHRmRxnc8z5yU7+z4w@mail.gmail.com>
	<CAOvw+NY6DznenQNy-1SzK4F3RdbFeBqDroHK+vVC5K3y_n9piA@mail.gmail.com>
	<E0AECE4E-D2F3-4ED1-B303-92256959F56F@couchbase.com>
	<CAGHTdUW6nCJJ-j8z6TGQjUQKsE=RuZ-XuQYN1SVpS2TBV_AHVg@mail.gmail.com>
Date: Tue, 25 Mar 2014 19:36:40 +0000
Message-ID: 
 <CAGHTdUU1VEk9shLmr9zWbVCb_X50BTNdNYZC5_PtdBpfXAgBZw@mail.gmail.com>
Subject: Re: Uploading attachments using Multipart/related
From: Nick North <north.n@gmail.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=bcaec521594d9f1c7a04f5737835

--bcaec521594d9f1c7a04f5737835
Content-Type: text/plain; charset=ISO-8859-1

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 <north.n@gmail.com> 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 <jens@couchbase.com> wrote:
>
>>
>> On Mar 25, 2014, at 7:37 AM, JC de Villa <jc.devilla@gmail.com> 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
>
>
>

--bcaec521594d9f1c7a04f5737835--