Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <80877B30-A67E-4FA6-B19A-93087D80BF55@couchbase.com>
References: 
 <CAANDF52sazxb8ZpdsECFD-WZ5MmC=BtQPP+9426JF4QtjHze+A@mail.gmail.com>
	<12119867-1D77-4943-B87C-B8369C7005C8@couchbase.com>
	<CAJ_m3YAcuc34UOuHAbHmYz5s18KgAkMi+LQ9pX=8aTZ-nz4yZw@mail.gmail.com>
	<80877B30-A67E-4FA6-B19A-93087D80BF55@couchbase.com>
Date: Mon, 6 Aug 2012 20:31:20 +0200
Message-ID: 
 <CAANDF50cmP9WCL+UuUErDf2Y9aBWqib17Fe5HwNQ_vN9ONqOqw@mail.gmail.com>
Subject: Re: function_clause error in HTTP request
From: Pieter van der Eems <p.van.der.eems@interactiveblueprints.nl>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

2012/8/6 Jens Alfke <jens@couchbase.com>:
>
> On Aug 3, 2012, at 10:36 AM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>
>> 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.
>
> I searched for this in Jira and found COUCHDB-1177 <https://issues.apache.org/jira/browse/COUCHDB-1177> which has the exact same backtrace, although nothing in its description mentions attachments or gzip.

We checked the IOS/TouchDB side and no attachments were gzipped.
I did find a similar bug there:
https://github.com/couchbaselabs/TouchDB-iOS/issues/116

Pieter