couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: svn commit: r797400 - /couchdb/trunk/src/couchdb/couch_httpd_db.erl
Date Sun, 26 Jul 2009 17:48:46 GMT

On Jul 24, 2009, at 5:54 PM, Chris Anderson wrote:

> On Fri, Jul 24, 2009 at 12:58 PM, Christopher Lenz<>  
> 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  :
>> (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  


> Chris
>> Cheers,
>> --
>> Christopher Lenz
>>  cmlenz at
> -- 
> Chris Anderson

View raw message