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] https://github.com/couchbaselabs/TouchDB-iOS/issues/72
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1

Reply via email to