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