I'm saying that multipart/related uploads should allow attachments considerably larger than 64 mb. The limit, on Cloudant, should be available disk space in the cluster and your budget, since disk usage is part of the metered service.
From what I've read here and elsewhere, this is probably more like a bug in the clustering code for attachment stream (since we fork the stream during the request to make 3 copies of it) and/or a timeout in the load balancing layer. This is something I'd like to see fixed (assuming I'm right in that last paragraph) and it sounds easy to reproduce. B. On 9 Sep 2012, at 22:36, Jens Alfke wrote: > > On Sep 9, 2012, at 2:28 PM, Robert Newson <[email protected]> wrote: > >> No, there's no way to do that, since a document must change from one >> revision to another atomically. > > That’s what I thought. > >> The CouchDB replicator uses multipart/related PUT to send the document and >> all attachments (streamed) in a single request. The max_document_size (4gb, >> insanely, in couchdb, 64mb on cloudant) does not apply to streamed >> attachments or the multipart/related PUT method. It seems like you're >> asserting that TouchDB doesn't follow suit, which would surprise me. > > TouchDB’s replicator uploads docs with attachments in MIME multipart/related > format. But Cloudant is rejecting them anyway. Are you saying it ought to be > allowing HTTP uploads of arbitrary size as long as the main JSON doc is < > 64MB? Because that isn’t what's happening. > > —Jens
