couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Continuous-mode _changes feed without chunked encoding?
Date Tue, 01 May 2012 17:30:26 GMT
As far as I'm concerned the only reason for the chunked encoding is because we have no idea
about the Conent-Length.  If content-length: 99999999999 is really an acceptable option I
don't think there are any other blockers to offering an optional non-chunked encoding.


On May 1, 2012, at 12:42 PM, Jens Alfke wrote:

> Is it possible to receive a continuous-mode _changes feed from CouchDB *without* the
response using HTTP chunked encoding?
> I ask because the use of chunked encoding with a never-closed connection is causing several
> (1) It doesn’t work with some cell carriers’ (e.g. O2’s) wireless networks; no
data ever arrives and the request times out. Anecdotally this is because they use HTTP proxies
that don’t handle chunked mode very well.
> (2) The HTTP framework in iOS and Mac OS X (NSURLConnection) has a similar problem; I’ve
filed a bug report on this, but I suspect it’s trying to obey the letter of the law[2] and
wait for the possible extra HTTP header fields in the response trailer before sending any
response to the client.
> Obviously it is possible to work around this by using the long-poll mode instead. The
disadvantages are
> * difficult to parse the changes incrementally before the entire response has arrived,
because that would require a streaming (SAX-mode) JSON parser. This is a performance problem
during replication.
> * requires more HTTP connections to be made, so has greater latency.
> Technically it’s not kosher to send an indefinitely-long never-closed response without
chunked mode. But it’s been done for a long time for services like MP3 streaming (ShoutCast).
Generally they just include a fictitious huge content-length like 999999999999.
> —Jens
> [1]
> [2]

View raw message