On Jul 24, 2009, at 5:54 PM, Chris Anderson wrote:
On Fri, Jul 24, 2009 at 12:58 PM, Christopher Lenz<[email protected]>
wrote:
On 24.07.2009, at 14:37, Benoit Chesneau wrote:
Reading the spec and with feedback from cmlenz on irc, I'm changing
my position for GET :)
If content-length is know, I think CouchDB should send unchunked
until
the client don't ask for specific encoding with TE in headers and
http
version is 1.1 :
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.39
(Background: the one thing chunked encoding gives you over "identity"
encoding with a Content-Length header is that you can detect some
kind of
data corruptions before having consumed the entire response. Benoit
noted
that this was important to him.)
I can't really figure out a nice way to have the client request
chunked
encoding. "TE: chunked; q=1" is implicit in HTTP/1.1, so how would
a client
say: "really, I'd prefer chunked encoding"?
We *could* have CouchDB use chunked encoding for attachments GETs
only when
"TE: chunked" is specified, but that'd be a proprietary hack, AFAICT.
There's also "TE: trailers" to indicate that the client supports
trailers in
chunked responses. We could base the decision on that header, but
that'd be
just as much of a hack IMO.
Maybe a query string parameter really is the way to go here?
Agreed with all of the above. I was just looking at that the other
day. We should switch to unchunked by default, with a Content-Length
header.
As far as retaining the ability to serve chunked, I think a query
parameter is as sane a way as any.
I'd love to see this patch come from someone else, as I've been
working on that code path a lot lately and it could use someone else's
eyes.
I think we should mark this blocking for 0.10, as it's so easy and the
? thing makes it a user-facing feature.
Yes, there is no need for it to be chunked. I remember at some point I
tried switch it to regular encoding, but it caused errors in the
replicator and I never got around to debugging it.
I see no good reason for a http client to request a chunked encoding,
it's easier and more efficient to deal with a content length than it
is to parse out chunk segments. A good reason send a chunked encoding
is it allows a Content-MD5 trailer to be computed on-the-fly. But I
don't think we need to support the browser requesting a chunked
encoding.
-Damien
Chris
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
--
Chris Anderson
http://jchrisa.net
http://couch.io
