Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.220.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <12119867-1D77-4943-B87C-B8369C7005C8@couchbase.com>
References: 
 <CAANDF52sazxb8ZpdsECFD-WZ5MmC=BtQPP+9426JF4QtjHze+A@mail.gmail.com>
 <12119867-1D77-4943-B87C-B8369C7005C8@couchbase.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Fri, 3 Aug 2012 12:36:18 -0500
Message-ID: 
 <CAJ_m3YAcuc34UOuHAbHmYz5s18KgAkMi+LQ9pX=8aTZ-nz4yZw@mail.gmail.com>
Subject: Re: function_clause error in HTTP request
To: user@couchdb.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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@interact=
iveblueprints.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 relea=
se 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 b=
ugs fixed since then (where "then" =3D June 20) that _might_ be causing thi=
s.
>
> IIRC, most of those bugs involved HTTP auth; is that involved here? The h=
eaders in the pastie don't include "Authorization:" but that might have bee=
n stripped from the log for security purposes.
>
> When I was debugging these, it was the CouchDB side that was the black bo=
x :) so I'm curious to know what the CouchDB experts make of the logs you c=
aptured, 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/depend=
encies/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 =3D read_next_chunk(F, LenLeft),
>>     ok =3D 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 th=
is function didn't match either of those patterns, which would imply that L=
enLeft < 0. Which in turn would imply that in the previous call to read_nex=
t_chunk returned a number larger than LenLeft; I'm not sure whether or not =
this is possible...
>
> =97Jens

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.