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
|