On Wed, Sep 15, 2010 at 9:59 PM, Nathan Vander Wilt <[email protected]> wrote: > 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.
I like your proposed solution (the magic base64). It will probably be easy enough to patch based on otherstuff happening in CouchDB (look at the attachment POST api). I dont' have time these days to hack something like this, but you have my full encouragement. Chris > > thanks, > -natevw -- Chris Anderson http://jchrisa.net http://couch.io
