You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jens Alfke <je...@couchbase.com> on 2012/02/06 19:21:48 UTC

Multipart vs chunked

tl;dr: CouchDB* doesn’t seem to correctly parse MIME multipart uploads when the HTTP transfer is chunked. It generates an Erlang exception.

I spent the weekend trying to implement multipart document+attachment uploads in my client code. In doing so I ran into what I think is a bug in CouchDB — after I’d gotten the client side working, every upload produced an Erlang exception on the server. I tried changing around the client-side code so it precomputed the body length instead of sending the body in ‘chunked’ encoding, and that made CouchDB happier.

The exception looks like:

[error] [emulator] Error in process <0.15079.3> with exit value: {badarith,[{couch_httpd_db,'-receive_request_data/2-fun-0-',3},{couch_httpd,read_until,3},{couch_httpd,parse_part_body,1},{couch_httpd,parse_multipart_request,3},{couch_doc,'-doc_from_multi_part_stream/2-fun-1-'... 

Is this a known bug, or should I file something?

—Jens

* Well, Couchbase Single Server 2.0.0dev4, which I think is basically CouchDB 1.1.1.


Re: Multipart vs chunked

Posted by Alexander Gabriel <al...@barbalex.ch>.
Thanks a lot!
Alex




2012/2/6 Jens Alfke <je...@couchbase.com>

>
> On Feb 6, 2012, at 11:19 AM, Alexander Gabriel wrote:
>
> oh, I spent my last weekend trying to get a multipart upload working
> unsuccessfully too. Is it possible to see when this problem has been
> solved?
>
> You can track the bug report I just filed:
> https://issues.apache.org/jira/browse/COUCHDB-1403
>
> Or else: How is body length precomputed then communicated?
>
> Not sure exactly what you mean; in my case I worked around the bug by
> computing the body length (by adding up the sizes of the attachment files
> and MIME boundary strings) then set that as a Content-Length header on the
> request; this tells the HTTP library I use (NSURLConnection on Mac OS) not
> to use chunked encoding.
>
> —Jens
>

Re: Multipart vs chunked

Posted by Jens Alfke <je...@couchbase.com>.
On Feb 6, 2012, at 11:19 AM, Alexander Gabriel wrote:

oh, I spent my last weekend trying to get a multipart upload working
unsuccessfully too. Is it possible to see when this problem has been
solved?

You can track the bug report I just filed: https://issues.apache.org/jira/browse/COUCHDB-1403

Or else: How is body length precomputed then communicated?

Not sure exactly what you mean; in my case I worked around the bug by computing the body length (by adding up the sizes of the attachment files and MIME boundary strings) then set that as a Content-Length header on the request; this tells the HTTP library I use (NSURLConnection on Mac OS) not to use chunked encoding.

—Jens

Re: Multipart vs chunked

Posted by Alexander Gabriel <al...@barbalex.ch>.
oh, I spent my last weekend trying to get a multipart upload working
unsuccessfully too. Is it possible to see when this problem has been
solved? Or else: How is body length precomputed then communicated?

Alex

Am Montag, 6. Februar 2012 schrieb Robert Newson <rn...@apache.org>:
> Pretty obvious bug, yes. We're attempting to evaluate whether the atom
> 'chunked' is greater than zero.
>
>>receive_request_data(Req) ->
>  >   receive_request_data(Req, couch_httpd:body_length(Req)).
>>
>>receive_request_data(Req, LenLeft) when LenLeft > 0 ->
>
>
> On 6 February 2012 13:21, Jens Alfke <je...@couchbase.com> wrote:
>> tl;dr: CouchDB* doesn’t seem to correctly parse MIME multipart uploads
when the HTTP transfer is chunked. It generates an Erlang exception.
>>
>> I spent the weekend trying to implement multipart document+attachment
uploads in my client code. In doing so I ran into what I think is a bug in
CouchDB — after I’d gotten the client side working, every upload produced
an Erlang exception on the server. I tried changing around the client-side
code so it precomputed the body length instead of sending the body in
‘chunked’ encoding, and that made CouchDB happier.
>>
>> The exception looks like:
>>
>> [error] [emulator] Error in process <0.15079.3> with exit value:
{badarith,[{couch_httpd_db,'-receive_request_data/2-fun-0-',3},{couch_httpd,read_until,3},{couch_httpd,parse_part_body,1},{couch_httpd,parse_multipart_request,3},{couch_doc,'-doc_from_multi_part_stream/2-fun-1-'...
>>
>> Is this a known bug, or should I file something?
>>
>> —Jens
>>
>> * Well, Couchbase Single Server 2.0.0dev4, which I think is basically
CouchDB 1.1.1.
>>
>

-- 



***********************************************************



Alexander Gabriel
Wiesenstrasse 22
8800 Thalwil
079/ 372 51 64
alex@barbalex.ch
www.barbalex.ch

Re: Multipart vs chunked

Posted by Robert Newson <rn...@apache.org>.
Pretty obvious bug, yes. We're attempting to evaluate whether the atom
'chunked' is greater than zero.

>receive_request_data(Req) ->
 >   receive_request_data(Req, couch_httpd:body_length(Req)).
>
>receive_request_data(Req, LenLeft) when LenLeft > 0 ->


On 6 February 2012 13:21, Jens Alfke <je...@couchbase.com> wrote:
> tl;dr: CouchDB* doesn’t seem to correctly parse MIME multipart uploads when the HTTP transfer is chunked. It generates an Erlang exception.
>
> I spent the weekend trying to implement multipart document+attachment uploads in my client code. In doing so I ran into what I think is a bug in CouchDB — after I’d gotten the client side working, every upload produced an Erlang exception on the server. I tried changing around the client-side code so it precomputed the body length instead of sending the body in ‘chunked’ encoding, and that made CouchDB happier.
>
> The exception looks like:
>
> [error] [emulator] Error in process <0.15079.3> with exit value: {badarith,[{couch_httpd_db,'-receive_request_data/2-fun-0-',3},{couch_httpd,read_until,3},{couch_httpd,parse_part_body,1},{couch_httpd,parse_multipart_request,3},{couch_doc,'-doc_from_multi_part_stream/2-fun-1-'...
>
> Is this a known bug, or should I file something?
>
> —Jens
>
> * Well, Couchbase Single Server 2.0.0dev4, which I think is basically CouchDB 1.1.1.
>