On Fri, Aug 3, 2012 at 12:24 PM, Jens Alfke <[email protected]> wrote: > > On Aug 3, 2012, at 12:33 AM, Pieter van der Eems > <[email protected]> wrote: > >> We have an IOS client using TouchDB which syncs with CouchDB (1.2) on >> our server. >> The IOS client is a black box for me so I can't do any debugging there. > > The HTTP headers in the logs show that it's TouchDB 0.8; the latest release > is 0.93. If this is an app in the wild it's understandable that it's not > running the latest release, but there have been several multipart upload bugs > fixed since then (where "then" = June 20) that _might_ be causing this. > > IIRC, most of those bugs involved HTTP auth; is that involved here? The > headers in the pastie don't include "Authorization:" but that might have been > stripped from the log for security purposes. > > When I was debugging these, it was the CouchDB side that was the black box :) > so I'm curious to know what the CouchDB experts make of the logs you > captured, i.e. what they imply might have been wrong with the formatting of > the multipart data. > > [Fri, 03 Aug 2012 07:12:52 GMT] [error] [<0.2639.144>] > function_clause error in HTTP request > [Fri, 03 Aug 2012 07:12:52 GMT] [info] [<0.2639.144>] Stacktrace: > [{couch_db,write_streamed_attachment, > [<0.4031.144>, > > #Fun<couch_doc.16.119974875>,-1576], > [{file, > > "/opt/build-couchdb/dependencies/couchdb/src/couchdb/couch_db.erl"}, > {line,1031}]}, > > In the CouchDB sources I have on hand (which are not up-to-date with 1.2) > write_streamed_attachment looks like >> write_streamed_attachment(_Stream, _F, 0) -> >> ok; >> write_streamed_attachment(Stream, F, LenLeft) when LenLeft > 0 -> >> Bin = read_next_chunk(F, LenLeft), >> ok = couch_stream:write(Stream, Bin), >> write_streamed_attachment(Stream, F, LenLeft - size(Bin)). > > I'm very weak at Erlang, but I think what happened is that the call to this > function didn't match either of those patterns, which would imply that > LenLeft < 0. Which in turn would imply that in the previous call to > read_next_chunk returned a number larger than LenLeft; I'm not sure whether > or not this is possible... > > —Jens
I've seen errors like this before. IIRC, the underlying issue is that there's a bug in the attachment handling related to gzipped vs identity content lengths. Specifically I think it was when CouchDB receives an attachment that's gzipped it doesn't bother doing an "gunzip > /dev/null" type operation to get the identity length and then when it sends the attachment to something that doesn't understand gzip compression there's a mismatch in what lengths are expected. Or something along those lines.
