couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Continuous-mode _changes feed without chunked encoding?
Date Tue, 01 May 2012 17:55:45 GMT

Do you know if that solution works for those cases? Given that they
screw up chunked encoding I wouldn't have high hopes that they
wouldn't do something else weird like trying to buffer the entire
unchunked request as well.

Also I'm wondering if the large content-length is even required. Isn't
it perfectly acceptable to just omit the content-length entirely? If I
remember my HTTP correctly, in that case the body length is then just
defined as all bytes that can be read before the server closes the

On Tue, May 1, 2012 at 12:30 PM, Adam Kocoloski <> wrote:
> 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.
> Adam
> 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 problems[1]:
>> (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