incubator-couchdb-user mailing list archives

On Fri, Aug 3, 2012 at 12:24 PM, Jens Alfke <jens@couchbase.com> wrote:
>
> On Aug 3, 2012, at 12:33 AM, Pieter van der Eems <p.van.der.eems@interactiveblueprints.nl>
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.