Curl normally hides the chunked transfer encoding from the user. If you add the "--raw" option (requires Curl >=7.16.2), the chunk prefixes will be visible, too.
Best regards, Pasi On Mon, Jun 6, 2011 at 08:27, Jens Alfke <[email protected]> wrote: > I’ve been trying to figure out why my Cocoa code can’t read the db/_changes > feed. It acts as though it never makes a connection to the server. I’ve > finally concluded that it’s because CouchDB’s HTTP response is, to put it > bluntly, lying: > >> $ curl -i 'http://127.0.0.1:5984/testdb/_changes?feed=continuous' >> 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=utf-8 >> Cache-Control: must-revalidate >> >> {"seq":1,"id":"cf8a2e561cccbc5570ec8f391d041cce","changes":[{"rev":"1-4fad6ccf08b52a49a65734784296dcdd"}]} >> {"seq":2,"id":"cf8a2e561cccbc5570ec8f391d0428c6","changes":[{"rev":"1-a1eee1babb5545b9b45d4aaf1b55eb75"}]} >> … > > > Note the header “Transfer-Encoding: chunked”. The problem is, the body of the > response is *not* in chunked format as defined by the HTTP spec [1]. Chunked > format consists of a sequence of ‘chunks’, each of which is prefixed by an > ASCII chunk size. The actual body doesn’t have those, it’s just a normal > unencoded response. > > What I’m assuming is that Cocoa’s NSURLConnection code sees the header and > expects to read a chunk header, then gets confused when it doesn’t 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’t include the > Transfer-Encoding header. > > Has anyone else run into trouble with this? Is there a way to disable that > header short of modifying the CouchDB source code? > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1
