couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Vander Wilt <nate-li...@calftrail.com>
Subject Binary form fields versus update handlers
Date Thu, 16 Sep 2010 04:59:13 GMT
Hello all,

Tonight I decided I'd see how quickly I could implement a custom image upload site for The
iPhone App Formerly Known As Tweetie (http://developer.atebits.com/tweetie-iphone/custom-image/)
using a CouchDB update handler.

Unfortunately for me, Twitter.app sends the image as binary data:

'--com.aTeBiTs.TwEeTiE.oeunht43353r4cg345nt\r\nContent-Disposition: form-data; name="message"\r\n\r\nTest
\r\n--com.aTeBiTs.TwEeTiE.oeunht43353r4cg345nt\r\nContent-Disposition: form-data; name="media";
filename="image.jpg"\r\nContent-Type: image/jpeg\r\n\r\n\xff\xd8' + more_binary_data

...and this causes mochiweb unhappiness:
{mochiweb_socket_server,235,{child_error,{ucs,{bad_utf8_character_code}}}}

I'm assuming MochiWeb is able to handle binary POST data, and this exception is just due to
CouchDB wanting to convert the request to something JavaScript can handle. But beyond that
(and that's a pretty lousy starting point, eh?) I'm wondering if and how we can make things
like my little project possible.

In this case, my update handler needs to be able to put some of the form parts/fields (which
are UTF-8able) into a document and another of the form fields (the one with the binary) as
an attachment to a document. Would it be reasonable for Couch to pull out binary form parts
(detected in some suitable fashion) in some fashion? Perhaps a separate req.attachments structure
(with base64 encoding already done, naturally)? I'm no RFC2388 expert (at least not yet :-)
but I wanted to get this out for discussion as a first step.

thanks,
-natevw
Mime
View raw message