From user-return-16510-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Mon Jun 6 05:55:15 2011 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7D9624221 for ; Mon, 6 Jun 2011 05:55:15 +0000 (UTC) Received: (qmail 25676 invoked by uid 500); 6 Jun 2011 05:55:13 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 25628 invoked by uid 500); 6 Jun 2011 05:55:09 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 25599 invoked by uid 99); 6 Jun 2011 05:55:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Jun 2011 05:55:08 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of eronenp@gmail.com designates 209.85.216.173 as permitted sender) Received: from [209.85.216.173] (HELO mail-qy0-f173.google.com) (209.85.216.173) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Jun 2011 05:55:03 +0000 Received: by qyk36 with SMTP id 36so693266qyk.11 for ; Sun, 05 Jun 2011 22:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=FDCWPAUSKfjbKUpe7+TZKcEhgzfGQtFb12kehCw/LqQ=; b=SHvj1g3uA5Siu8pGPIzATUh7gKpbjg+XFBtb0uWh+SaOnwKrsGcLZAUrtHu1Lwn7hh 04TzZsufrZydB80mGRG2epQkh/umy5hEF7xK6l/x3HH5s6w0qAeh6eEOBEZLXUlu7tS8 kHAyKbYSiyKXQ8tCzP2JjyWUafTBlOd5gQuJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ObH2Q7JxB4kU1iWCK9PpAv5OxlNhP/1keBMwY4/5Uwr6SIQ9Dboiuf9E61vjvm+tkp XM0WUiVeYy+kS5dROldq4NBnwwULjHWHpUBzxGkSPLAM6WL3Qg1dmb3snpdZ7HUo6+qc QYfjBQiF6egDOO5wy02SVnwAahPHcbrLTXJR4= MIME-Version: 1.0 Received: by 10.224.210.138 with SMTP id gk10mr1719486qab.188.1307339682369; Sun, 05 Jun 2011 22:54:42 -0700 (PDT) Received: by 10.224.45.209 with HTTP; Sun, 5 Jun 2011 22:54:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 6 Jun 2011 08:54:42 +0300 Message-ID: Subject: Re: Issue: _changes feed's Content-Encoding is wrong From: Pasi Eronen To: user@couchdb.apache.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Curl normally hides the chunked transfer encoding from the user. If you add the "--raw" option (requires Curl >=3D7.16.2), the chunk prefixes will be visible, too. Best regards, Pasi On Mon, Jun 6, 2011 at 08:27, Jens Alfke wrote: > I=92ve been trying to figure out why my Cocoa code can=92t read the db/_c= hanges feed. It acts as though it never makes a connection to the server. I= =92ve finally concluded that it=92s because CouchDB=92s HTTP response is, t= o put it bluntly, lying: > >> $ curl -i 'http://127.0.0.1:5984/testdb/_changes?feed=3Dcontinuous' >> HTTP/1.1 200 OK >> Transfer-Encoding: chunked >> Server: CouchDB/1.1.1 (Erlang OTP/R14B) >> Date: Mon, 06 Jun 2011 05:12:42 GMT >> Content-Type: text/plain;charset=3Dutf-8 >> Cache-Control: must-revalidate >> >> {"seq":1,"id":"cf8a2e561cccbc5570ec8f391d041cce","changes":[{"rev":"1-4f= ad6ccf08b52a49a65734784296dcdd"}]} >> {"seq":2,"id":"cf8a2e561cccbc5570ec8f391d0428c6","changes":[{"rev":"1-a1= eee1babb5545b9b45d4aaf1b55eb75"}]} >> =85 > > > Note the header =93Transfer-Encoding: chunked=94. The problem is, the bod= y of the response is *not* in chunked format as defined by the HTTP spec [1= ]. Chunked format consists of a sequence of =91chunks=92, each of which is = prefixed by an ASCII chunk size. The actual body doesn=92t have those, it= =92s just a normal unencoded response. > > What I=92m assuming is that Cocoa=92s NSURLConnection code sees the heade= r and expects to read a chunk header, then gets confused when it doesn=92t = find one. (What I see is that it never calls me back with any response data= ). Other CouchDB requests are working fine for me, but they don=92t include= the Transfer-Encoding header. > > Has anyone else run into trouble with this? Is there a way to disable tha= t header short of modifying the CouchDB source code? > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1